Grouper Developers Forum

[Emily Eisbruch <>]

Grouper Call 4-Aug-2010

**Attending**

Tom Barton, U. Chicago, (chair) 

Chris Hyzer, U. Penn  

Shilen Patel, Duke  

Gary Bristol, Bristol  

Rob Hebron, Cardiff

Tom Zeller, U. Memphis   

Ann Kitalong-Will, Independent

Steve Olshansky, Internet2   

Emily Eisbruch, Internet2 (scribe)  

**Action Items**

New Action Items

 [AI] (Rob) will contact Chris about moving the ESB work to the web services project.

[AI] (Chris) will add a JIRA (for Grouper 1.6.2) on enhancing QuickStart with attributes and with the new import format 

[AI] (Chris) will forward his info. on federated group management/ Grouper external users to the COmanage–dev list and the MACE-paccman list. (done)

[AI] (TomZ) will define terms related to "federated" versus "external" group management on the wiki, to help clarify the issues.

Carry Over Action Item

[AI] (Rob) will look at issues relating to testing the ESB Connector. 

Note: Add to the agenda for a future call : Discuss a stem set table to reflect the structural relationships among stems.

**Discussion**

*Grouper 1.6.1 Release*

Grouper 1.6.1 is almost ready for release. Chris drafted a summary of the release:

https://lists.internet2.edu/sympa/arc/grouper-dev/2010-08/msg00006.html

TomZ said there was a small fix still needed related to order of operations with Ldappc-ng.

TomZ and Chris will resolve a question about naming conventions for the files. 

*Testing the Grouper 1.6.1 Release*

Chris did unit tests on the binary of the API and it worked fine.

Rob tested the upgrade of the database. It worked properly on Postgres.

Chris or Gary will do additional testing. 

Quickstart needs some updating for testing of future releases.

[AI] (Chris) will add a JIRA (for Grouper 1.6.2) on enhancing QuickStart with attributes and with the new import format 

Chris has updated the wiki pages to reflect updates he worked on for Grouper 1.6.1

Target is Friday, Aug. 6 to release Grouper 1.6.1 

Release steps on the wiki will be followed

https://spaces.internet2.edu/display/GrouperWG/Release+steps

*Advance CAMP Action Items: models, approach, process*

https://spaces.internet2.edu/display/ACAMPActionItems/Home

Three interconnected action items coming out of Advance CAMP in Raleigh are particularly relevant to Grouper:

- Define a standard group API (TomB is the lead)

- Develop Capabilities in Grouper for Federated Group Management Similar to COmanage (Chris is the lead)

- Determine How Federated Provisioning Should Work and Participate in SPML Standards Work to Support it (TomZ is the lead)

Chris summarized his writeup on Grouper and External Users:

https://spaces.internet2.edu/display/GrouperWG/Grouper+external+users

In many cases, institutions want the ability to allow “external” people (from outside of their institution) to to use their applications. This creates an identity management challenge: How to feed external subjects into a subject source? Possible approaches:

- Some schools have an Identity Management system that can handle this. 

- COmanage provides a solution. 

- Grouper will be enhanced to provide a solution (to be discussed on this call) 

The enhancement to Grouper will consist of a few DB tables, and some UI screens.  Users will self register (perhaps from an invite). Invitation is one way to solve the problem of the admin knowing what the user identifier will be.

Users will go to self service application to log in. Grouper will pull the info available about the user from Shibboleth. The user will enter the rest.  There will be a way to get subjects into tables.

Steven mentioned at ACAMP he would like see a feature in COmanage so someone who invites external users is able to specify which groups to add them to. Chris listed that as Phase 2 for this Grouper enhancement.

The design for the Grouper does not depend on Shibboleth. Could potentially use PKI or other mechanism, assuming it’s possible to get the userID and attributes.  We might want to include something in the design to ensure that plug-ins can support various authentication technologies. 

Only a userID will be required. Other attributes can be handled optionally. 

Issues:

• There will be a need to handle unresolvable subjects.
• Deprovisioning: Provide a way to specify a lifetime for a membership / specify a membership delete date? (could this be handled via the Shib authentication?

TomB: Should we put these issues out to stakeholders?

Who are the stakeholders? (Perhaps ask some of these questions of the ACAMP attendee list?) Chris noted that Penn could be a user of this external users feature.

Chris would like to review his plan with someone who knows a lot about COmanage. Chris forwarded his links to the COmanage-dev list and the paccman list.

*Syncing Between Group Management Systems*

Chris developed ideas on the wiki about sharing a group between more than one Grouper instance, or syncing between group management systems in general. This issue overlaps w Standard Group API concept.

https://spaces.internet2.edu/display/GrouperWG/Syncing+groups+between+group+management+systems

We can currently synch between Grouper and LDAP. But synching with another Grouper is a new issue

Web services or XMPP could be used, but the hope is to use SPML to implement this communication.

It’s not clear what the use cases are, so we need to identify some real use cases.

If using XMPP, there is the issue that XMPP servers trust others without proper SSL lookups. So it would be necessary to encrypt that somehow.  Public key cryptography or DNS SRV are possibly pluggable encryption solutions.

TomZ noted that push and pull corresponds to web services vs XMPP. SPML could be used as an XML format and then either web services or XMPP could be used. So the approach would be to define the web services schema to support XML. SPML v 2 provides much flexibility. We can decide on the standard API for groups and then design SPML to suit that

TomZ has already worked on taking info from the Grouper API and representing it as attributes and SPML. The next step is take SPML and transfer it into the Grouper API. This is a process that would need to be developed. 

TomB does not want a method-oriented API, he prefers to start with the objects themselves, with the simplest reasonable description of group objects. TomZ noted that it’s worth looking at the Ldappc-ng  XML config file, where groups and members are represented simply in XML

It was agreed to also consider the SPML approach as an option for the ESB connector, even if this means redoing / converting some work.

An issue: What if two targets or two federated organizations may use the same identifier for two different people, So there is a need for a target ID to delineate people with the same ID. SMPL provides a possibility for a string identifier. It was observed that using strings is not an adequate solution. We might need to provide a standard format for that, a syntactical and management solution.

*Terminology and Moving Forward*

TomZ raised the question: What’s difference between provisioned, federated and external?

It was noted that there are minor differences that should be clarified. 

[AI] (TomZ) will define terms related to "federated" versus "external" group management on the wiki, to help clarify the issues.

Future discussion on the ACAMP Action Items will take place on the Grouper and paccman calls. 

On the next Grouper-dev call, TomZ will have a chance to report on how he's organizing progress on his SPML/provisioning action item.

Next Meeting: Wed. Aug 18 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