MACE-paccman call 5-Aug-2010

*Attending*

Keith Hazelton, U. Wisconsin (stand-in chair)
Rob Carter, Duke
Paul Hill, MIT
Tom Barton, U. Chicago
Chris Hyzer, U. Penn
Mark Scheible, NC State
Dan Seibert, UCSD
Benn Oshrin, Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

New Action Items

[AI] (TomB) will introduce Rob and Rachana regarding sharing of caBIG use cases with MACE-paccman.

[AI] (TomB) will discuss with TomZ the possibility of future participation in MACE-paccman calls regarding the SPML and provisioning topic.

[AI] (Everyone) will give Rob feedback on his start on the “Use Case Tabulation” on the wiki:
https://spaces.internet2.edu/display/macepaccman/Use+Case+Tabulation

Carry Over Action Items

[AI] (Rob) will finish attaching numbers/identifiers to MACE-paccman use cases in preparation for promoting them (or pointers to them) from the wiki to the website.

[AI ] (Keith, Rob, Paul, and Albert) will move forward on mapping access management use cases to XACML.

[AI] (Keith) will continue communication with Leif concerning SPOCP.

[AI] (MichaelP) will work to polish the glossary, as a next step, until events warrant revisiting it.

[AI] (R.L. Bob) will separate “assurance” from “authentication” in the glossary.

DISCUSSION

*Review of Action Items from Previous Calls*

Keith reported that Albert is interested in contributing to the effort to map paccman use cases to XACML.

Rob reported that he submitted a track session proposal for the Interent2 2010 Fall Member Meeting related to MACE-paccman and access management issues.

Keith spoke with Brendan about potential MACE-paccman and/or MACE-Directories involvement with Oracle self help or Oracle buddies group. It was felt that this is not a MACE-Dir working group issue. Also, much of the Oracle discussion centers on technical issues and is not appropriate for MACE-paccman. Keith suggests those who are interested in issues that arise around the need to migrate to Oracle should contact him at hazelton@doit.wisc.edu.

Rob reported that he has started work on categorizing the use cases on the wiki. He has tried to provide more descriptive titles for each one.

[AI] (Everyone) will give Rob feedback on his start on the “Use Case Tabulation” on the wiki:
https://spaces.internet2.edu/display/macepaccman/Use+Case+Tabulation

Rob reported that he has not gotten response to his outreach about sharing caBIG use cases on the paccman wiki. TomB said that some of the support for caBIG is done at the Computational Institute at U Chicago.
http://www.ci.uchicago.edu/research/project_detail.php?id=79
TomB will introduce Rob to the people involved.

[AI] (TomB) will introduce Rob and Rachana regarding sharing of caBIG use cases with MACE-paccman.

**Federated Grouper Discussion**

Chris is the lead for the action item coming out of Advance CAMP in Raleigh : “Develop Capabilities in Grouper for Federated Group Management Similar to COmanage.”

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 use their applications. This creates an identity management challenge. 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 here on this call)

Chris said that it should be fairly simple to implement a solution for handling federated/external users within Grouper. A couple of tables holding subjects and attributes will be required, along with a few screens where users could log in or admins could enter information about a user. Chris is looking at how COmanage implemented the process.

An optional invitation process will most likely be included, where an authorized individual could go to a screen and type in email addresses of external people invited to access the applications/resources.

The system will generate some UUIDs or keys and email the invited person asking them to log in. Once the invited person logs in, their EPPN (or other identifier?) is known and stored in a table. The EPPN can be used as a subject source for Grouper and those people can be added to groups.

Another option would be for the inviter to enter the invitee’s unique identifier if known (instead of their email). CVS import could be used for this.

Ideally, the mechanism for accepting external users could be made flexible and customizable/pluggable so that LDAP and other sources could be handled, possibly including the eduPerson target pair-wise IDs.

PaulH noted that if using the targeted ID, the registration application must be marked as a cooperating application of the application being accessed, so you get the same targeted ID across systems. MIT uses targeted ID for applications hosted outside of MIT.

TomB observed that the model used at SURFnet for COIN is to integrate many applications into the COIN collab platform. In the model being suggested for Grouper, it could be hard to preserve privacy about which collaborations a user is involved in. Service operators would have access to that information.

Q: Has COIN developed a tool that does what a federated Grouper might do?

A: Perhaps Niels could shed light on that.

Q: If using the federated Grouper, Grouper would become an authoritative source of identity info about outsiders. In other places in the IdM infrastructure, we won’t know about attributes of federated users. Should Grouper therefore plug into the IdM infrastructure like it’s another source system?

A: Grouper can load group memberships into the person registery. Potentially an IdM system could come to Grouper to look up info using the subject web service. Grouper could be used as a reference for identities managed elsewhere.

Benn raised the use case of a student enrolled at one university and taking courses at another. Rob noted that this is in a class of use cases where the person making the decisions about whether someone should have access is interested in attributes about that person that are managed elsewhere.

This could be considered a contractual case, not a collaboration case. The campus hosting the courses needs to agree to let the student into this course and to access the course resources for the duration of the course. But there must be a bridge back to the student’s identity at her home institution.

What sort of support is needed at the infrastucture level? Maybe those are the bigger use cases we shouldn’t try to solve yet. Maybe we should just examine collaborative cases.

Paul suggested that there would need to be data ties between the institutions to support that kind of work. It’s not a matter of what the IdP can assert to the consuming application. Paul mentioned a use case at MIT where there are nightly feeds to an outside agency specifying who is authorized to do what on their website.

Keith observed that we are looking at a new scope to old issues that we used to look at within a single institution.

If we don’t have use cases that address this, we should get them. As Rob classifies the user cases, it would be good to have a tag for use cases that involve federated/external users.

*Synching Groups Between Group Management Systems*

Chris has been looking at issues with synching groups between Groupers (or between Grouper and another system)

Chris reviewed his work on this:
https://spaces.internet2.edu/display/GrouperWG/Syncing+groups+between+group+management+systems

The solution involves mapping each object from one Group management instance to another.

Most likely, this would be web service or XMPP based. SPML could be used as the data format across the web services

The upcoming standard groups API could be useful (developing this is an Action Item from ACAMP). Keith noted that it sounds like an interesting relationship between reviving SMPL and the standard group API

There has been some request for dynamic groups, so potentially if you could query your own Grouper, it would query a remote Grouper to get real-time data. One of the issues with that is the Grouper API is currently based on getting members from the local database. But the Grouper team could look at dynamic groups more closely in the future.

Concerning whether to use push or a pull approach, it was noted that pull is easier but push is preferred more by most architects.

There could be workflow issues involved in exchanging group info between organizations.

Chris requested that those with comments on these issues email grouper-dev@internet2.edu

Keith mentioned that it could make sense to again devote time on future MACE-paccman calls to discussing the ACAMP Action Item topics.

Next call: Thursday, Aug 26 at 1pm ET