Grouper Users - Open Discussion List

[Jessica Bibbee <>]

Grouper/Signet Working Groups Meeting, Spring 2005 Internet2 Member Meeting

May 2, 2005

 

*Participants*

Minh Nguyen, Stanford U.

Lynn McRae, Stanford U. (chair, Signet)

Tom Barton, U. Chicago (chair, MACE-Dir-Groups)

Blair Christensen, U. Chicago

RL "Bob" Morgan, U. Washington

Chad La Joie, Georgetown U.

Mike Grady, U. Illinois – Urbana Champaign

Andy Cohen, Stanford U.

Bruce Vincent, Stanford U.

Steve Lemons, Duke U.

John Ellis, Emory U.

Lonna Sherwin, Naval Postgraduate School 

Deke Kassabian, U. Pennsylvania

John Kalback, Penn State U.

Scott Smith, Penn State U.

Bob O'Connor, Penn State U.

Abrao Grynglas, World Bank

Igor Petrovski, World Bank

Bill Gordon, U. Cincinnati

Robert Banz, UMBC

Jen Leasure, The Quilt

Brendan Bellina, USC

Shelley Henderson, USC

Joy Verraneau, Cornell U.

Steve Barrett, Cornell U.

Roland Hedberg, TERENA

Shumon Huque, U. Pennsylvania

IJ Kim, Internet2

Steve Olshansky, Internet2

Jessica Bibbee, Internet2 (scribe)

 

*Discussion*

{Minh} guided the Group through the agenda, whose topics covered the general Subject API in Grouper/Signet. The API is in the initial draft, and includes basic functions of name, group, description, sites to add, additional attributes, name-value pairs.

 

The current Subject API came from the Grouper/Signet development. How many different uses are there for the Subject API? It is a way to reference entities that can be member from a group, or for the assignment of privileges by/to a grantor/grantee.   How useful is a repository adaptor?

 

Is there a need for the API to map external IDs to internal IDs? If so, what terminology would satisfy a unique name space; could we refer to it as: netID, logID, or profileID, etc? The general consensus of the Group seemed to connect with the use of the term: profileID. Are there practical reasons you would not want to use this name space? If this data changes, for example, pre- and post–marriage names, how long should this information be held?   Institutions have varying policy on this, and some never delete the data. There needs to be a consistent naming convention, where mapping IDs will track back to a single person, while still maintaining all current information that may act as a valid access point.

 

For each subject type, there is a member source, and a guest source, etc. How can we avoid a name space collision for different sources, while being able to reconcile across different attributes that are for the same subject? Can we look to Sakai or OKI's Agent OSID as an alternative to developing the API? First, the aim should be to use an existing schema - however, if it is not capable of meeting the requirements, then go ahead and fully develop the API.

 

The Group also looked at how Grouper/Signet will integrate with other applications and services, such as uPortal, Sakai, Kuali, and PeopleSoft.

 

Provisioning requirements within Grouper/Signet depend on what exactly you want to do with the memberships and groups.   – Which systems utilize these data, and how do we go about provisioning the data to them? How do we open up to real time needs, and do we need to distinguish between what is real time versus required?

 

In order to handle the provisioning, a framework must be set up that can adequately push data to the targeted systems. If you write your own framework, how do you detect changes, and how are events triggered? The Group would like to move in a direction that is agreed upon.