Draft Minutes: Grouper Call 20-Nov-2013
Tom Barton, U. Chicago (Chair)
Jim Fox, U. Washington
Dave Langenberg, U. Chicago
Chris Hyzer, U. Penn
Shilen Patel, Duke
Emily Eisbruch, Internet2, scribe
New Action Items
[AI] Jim update the Grouper roadmap with an item about scaling out Grouper.
Reference the Grouper Always Available web service… extend it to the RESTful service
[AI] (Shilen) email Jim and Chris about what calls are needed for CIFER API for Duke's project
Carry Over Action items
[AI] (DaveL) will work on the PSP aspect of GRP 914 when Shilen finished the ChangeLog work.
[AI] (Chris) do additional follow-up on the U. Penn Grouper security Analysis, including going through the automated penetration test report.
[AI] (Andrew) let us know what emerges from the Apereo security notification process work.
Identity Week Outcomes
Grouper was mentioned at numerous points during Identity Week. The core team led or presented at several Advance CAMP breakout sessions.https://spaces.at.internet2.edu/display/ACAMPScribe2013/scribing+for+ACAMP+2013
Grouper was also discussed at these CAMP sessions:
memberOf: Box to ERP (Univ. of Tulsa):https://spaces.at.internet2.edu/display/ACAMPScribe2013/scribing+for+ACAMP+2013
Practical Experiences of IAM and Distributed Services (Newcastle):https://spaces.at.internet2.edu/download/attachments/37650846/930+James.pptx?version=1&modificationDate=1384536994074
DaveL convened an Advance CAMP session on provisioning strategyhttps://spaces.at.internet2.edu/display/ACAMPScribe2013/Tues+9.45am+SalonsA-D
One message that emerged: many people are in favor of narrowly focused provisioning tools versus the general approach of the PSP.
Overall, it seems there is not much uptake of SCIM so far. Requires a tipping point to change the default behavior to develop something proprietary. There are some cloud providers that will handle the provisioning problem for you. DaveL is still doing the Grouper SCIM integrataion work for SURFnet.https://spaces.at.internet2.edu/display/Grouper/Grouper+SCIM+integration
Grouper will maintain the PSP, but perhaps not expand its functionality. PSP does a reasonable job of provisioning LDAP and AD, and it's in use quite a bit.
Jim convened an Advance CAMP session on FailSafe APIs for Grouperhttps://spaces.at.internet2.edu/display/ACAMPScribe2013/Tues+2pm+SantaBarbara
-This session was well received. Jim discussed the need for multiple copies of the database, whether it's caches in LDAP or multiple Groupers with multiple databases, some slave, some master.
-This is about scale, for large Grouper deployments.
-When the Grouper Client is not in picture.
-Something is needed in front of Grouper to handle the REST API calls.
-Some calls need to be directed to slave servers and not the master servers.
-Dispatching is needed to the caches or to the main service.
Chris: Jim's architecture has service in front of service.
Another approach: the service could reverse proxy to another one.
When dispatching is added to web service provider, the request goes to read-only or the read-write web service. Then a decision would be made on whether the request goes to the local database or to another web service location. This is a potential point of failure. Might use DNS load balancing.
There is agreement about the conceptual architecture. Deployers can decide on the operational architecture they use.
Chris: Another possible optimization is to start caching subject identifiers in the members table so you don't have to go to the subject source. The subject source can be a bottleneck. Subject identifiers sometimes change, especially in the use case where a subject gets a new identifier. There are several use cases around Net Ids, but we can provide ways for these to be handled.
Jim will add scaling of Grouper to the Grouper roadmap.
[AI] Jim update the Grouper roadmap with an item about scaling Grouper.
Reference the Grouper Always Available web services, extend this to RESTful web services.https://spaces.at.internet2.edu/display/Grouper/Grouper+always+available+web+services+and+clienthttps://spaces.at.internet2.edu/pages/viewpage.action?pageId=14517754
Grouper UI Demo at Advance CAMP
Chris demoed the new Grouper UI at Advance CAMP. Positive feedback was received.
One person suggested that scrolling should be available at top and bottom of the page for search results.
This is the approach that Google now has for displaying search results. Due to space availability, this is simpler to implement on a large screen versus on a mobile screen.
Jim: users at U-W have also requested to be able to page at top or bottom. This is handy for a user that knows they want to page through several screens.
Chris: we can include the paging ability at top of screen for the desktop version. On a mobile device, it can disappear. Could be done for a version after the initial release.
Chris is currently working on the combo boxes for the new Grouper UI
Roles and Permissions Work
Jim looked at the roles and permissions capabilities of Grouper.
He plans to do some work on the CIFER API version.
Chris: CIFER API work that was done previously needs to be redone to address some revamping in the CIFER project. Chris plans to address this after he finishes the current work on the Grouper UI, which is high priority for the Grouper 2.2 release.
A CIFER API version could be helpful to Duke and University of Washington.
Shilen: For the upcoming Duke project, it would be helpful to have a sense of where things are going with the CIFER API.
Suggested approach is to work on the CIFER API spec first, leaving the reference implementations (which take longer) for later. Shilen will email Jim and Chris on what calls will be needed for the Duke project.
[AI] (Shilen) email Jim and Chris about what CIFER API calls are needed for the Duke project.
Chris learned that Stanford is moving away from using the CSRFGuard.https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
To address CSRF, Chris will most likely make a simple filter to check the refer, unless it's a GET or it's on a whitelist.
AWS and Servlet Filter
Chris stated that Penn is moving some things to Amazon Web Services. Penn does not do session clustering in its apps. For doing auto-scaling with AWS, it's fine with sticky load balancing for scaling up, such as with adding a new app server. But when scaling down, there are issues with moving sessions. Chris may develop a servlet filter that would cache the encrypted session in an Amazon storage layer. There would be a cookie that would get checked. This might work with the Grouper UI as well. Let Chris know if your site is interested in such a servlet filter.
Univ. of Wisconsin had a problem deleting a stem and its related groups, as described here:https://lists.internet2.edu/sympa/arc/grouper-users/2013-11/msg00010.html
Shilen explained this problem can happen when Group B is added as a member of Group A at about the same time Group B is being deleted. The problem only happens if the membership being added is a disabled membership. The result is that Group A has a corrupt membership.. There is no direct foreign key since this happens through the members table. This is an uncommon occurrence, and there is no easy way to prevent this from happening,
Decision: Make the Bad Membership Finder Utility detect this situation and clean it up.https://spaces.at.internet2.edu/display/Grouper/Bad+Membership+Finder+Utility
Also, delete the bad membership when a group is deleted.
Next Grouper Call: Wed. Dec. 4 at noon ET