Grouper Developers Forum

[Emily Eisbruch <>]

Draft Minutes: Grouper-dev Call 28-Sept-2011

Attending

Tom Barton, University of Chicago (chair)  
Shilen Patel, Duke
Jim Fox, University of Washington
Chris Hyzer, U. Penn
Tom Zeller, Unicon
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe) 

New Action Items

[AI] (TomZ) will review the Grouper LDAP Loader doc and provide feedback to Chris, possibly with lessons learned from LDAPPC work.
https://spaces.internet2.edu/display/Grouper/Grouper+-+Loader+LDAP

[AI] (Chris) will ask the Grouper-users list about their use cases for Grouper LDAP Loader (DONE)

Carry Over Action Items

[AI] (TomZ) will update JIRA to reflect the priorities 

[AI] (Gary) will email the Grouper-Dev list with specifics on UI accessibility issues 

[AI] (Rob) will follow up with Danno on obtaining the server for the Continuous Integration Environment.  

[AI] (Everyone) review Rob's chapters and give him feedback on the Grouper Users List.

DISCUSSION

Planning Agenda for 3-Oct-2011 Face to Face Grouper WG Session at 2011 FMM

- Present Grouper 2.0 Features
- Grouper Survey main takeaways
- Discuss focus of Grouper  v2.1 & v2.2 development (Chris will lead and Shilen will take notes on the projected slides)
- Ask for use cases to drive v2.x - open discussion
- Connection with OSIdM4HE effort

Grouper Loader Work 

- Chris requests feedback on the Grouper Loader work.
- Configuring the LDAP is an issue
- With sources XML database, there was an option to read from the Grouper hibernate properties, could implement something similar here
- What about lists for sets of groups maintained in a single declaration?
- Standard attributes in LDAP are DN valued.
-  TomB: Chris should  coordinate with TomZ regarding handling /mapping /parsing of the DN

- Replicating some LDAP groups into corresponding groups in Grouper will be straightforward
- However, associating the values of the attribute with the subject can be complex

TomB:  There could be a use case (of interest to U. Chicago and perhaps others) where there is an  LDAP search filter for attributes, and groups should be defined for each of the attribute values.
For example: “for all values of this attribute, would like to have the value define a name of a group, and all folks with that value are members of the group”

[AI] (Chris) will ask the Grouper-users list about their use cases for Grouper LDAP Loader (DONE)

[AI] (TomZ) will review the Grouper LDAP Loader doc and provide feedback to Chris, possibly with lessons learned from LDAPPC work.
https://spaces.internet2.edu/display/Grouper/Grouper+-+Loader+LDAP
===

Shib and Grouper

- Chris believes there are problems with putting the Grouper API inside of Shib.

-The problems include potential library conflicts and also the fact that depending on the Grouper database creates a single point of failure. 

- Distributed caching is a better approach. 

- API should only be in the UI and the WS and the loader and LDAPPC.  

- Everything else should be web service or some other interface 

- Need to have a high performance, highly available way to securely control entitlements or memberships.
- Jim agreed, should have a fast readable cache and get info from there, rather than from Grouper. For U-W it’s LDAP, could be something else at another institution
- An important question is : what group memberships should this particular SP know about?
- When filtering groups, Is it possible to implement security in Grouper so you don’t have to do anything to the filter?

At U-W, if an SP asks for attributes, groups are obtained and attributes are computed  from the membership

Duke does that too,  using a filter that gets edited when an SP needs a group membership

TomZ has been working on this for LDAPPC NG – taking attributes from the source and transforming them as they should appear for the target

- It's about the attribute management capabilities in LDAPPC and in the IdP, about managing attribute statements that are sent out, including some dealing w access management
- The Shib attribute resolver is very flexible, which will be useful moving forward as groups have more utility.
- The IdP ought to have all the info and make its decisions there.
- It is agreed that putting the Grouper API into Shib is problematic

Next Grouper call: Wed. Oct. 12 at noon ET.

Emily Eisbruch, Technology Transfer Analyst

Internet2

office: +1-734-352-4996 | mobile +1-734-730-5749

Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook