Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
May 18, 2005

*Participants*
Tom Barton, U. Chicago (Chair)
Minh Nguyen, Stanford U.

RL "Bob" Morgan, U. Washington

John Ballem, Brown U.

Shelley Henderson, USC

Blair Christensen, U. Chicago
Gary Brown, U. Bristol

Ann West, EDUCAUSE/Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*

[AI] {Gary}, {Blair}, {Minh}, and {Tom} will coordinate efforts after the call to prioritize and minimize the list of fixes for the initial UI release of Grouper v0.6.

 

Carry-over *Action Items*

[AI] {Blair} will send signatures of the new methods to the {grouper-dev} list, which will appear in the transition between v0.5.1 and v0.6.

 

*Discussion* 

{Blair} has begun to work the Subject API into Grouper. Once one becomes a member of a group within Grouper, there is a cache copy of the subject, where you will assign a member key. The caching, in this case, is primarily for performance reasons. Searches for person attributes made within Grouper will be made by means of the Subject Interface.

 

{Minh} described a similar approach for incorporating the Subject Interface into Signet. If the ID of that person is stored locally, it would be available as a quick reference. In this way, the privileges of the person could be listed, without needing to go through the source adapter. {Blair} agreed that Grouper will have a similar setup.

 

The Group discussed how searches for classes are performed – searches could be called directly from the API, though the exact method is not clear. If you have a list of attributes to search against, you could call it accordingly. The API needs to know about the subject, and this could be done by calling the SI from the API. However, this may not account for complex searches.

 

Another aspect to consider is how the API is used for provisioning. Here, it is important to know which source you should be searching for a particular type. How do we substantiate the source manager? What is the requirement to characterize types? If you know which sources the subjects are in, it reduces the number of sources that you would have to include in the search.

 

How do we scope a query, if it is not restricted by type? For example, if your search results in multiple returns – it might include everything with the ID that you provided, in excess. A subject type would always be specified, and this would be handled by the implementation adapter. How can we assure uniqueness in subjects, to facilitate searches? What are the constraints – type plus ID, source plus ID? How are subjects uniquely identified if we allow multiple sources for each subject? For example, listing both sourceID plus subjectID fields would give unique results. How pertinent is it that we distinguish subject types from group types?

 

If Grouper takes on the ability to search against multiple sources, or even a subset – this will raise the complexity accordingly. What is the need for hiding and deleting multiple sources in real time? Representation of multiple sources might be an issue that Grouper will address later, as is necessary. What is the need for creating multiple and an unlimited number of stems? Once the requirements are better understood, management of the subject type and ID would avoid conflict.

 

The subject type and source are effectively the same. However, the type can only have one source. This may prove to limit actual practices. – What use cases would utilize this? A source might provide you with more than one type – for example, a user and group having the same name. It should remain flexible so you may configure as you wish; in this way, you can adjust the number of adapters per sources for person types. How does that interface with protocol? This would have to be supported in the subject API, and though it may not pose a problem with coding, it would raise performance issues.

 

Another concern – if you want turn an authenticated user into a subject, it would entail iterating through all the sources. While the handling of AuthN is a different activity, the actions taken by a user still need to be recorded so that you know who they are and which actions they are allowed to perform. What should the internal security model look like – a subject table and a user table? How is the provisioning program incorporated, such that you can manage privileges?

 

Grouper v0.6 is expected to incorporate group types, though it may happen in a later version. There will be an expectation to have the ability to perform searches, and this will stay in the list of fixes. Also included is how effective memberships will work in the API, and how they are dealt with in the UI. {Gary} and {Blair} discussed what possible changes need to be made and the amount of time necessary to complete these tasks. [AI] {Gary}, {Blair}, {Minh}, and {Tom} will coordinate efforts after the call to prioritize and minimize the list of fixes for the initial UI release of Grouper v0.6. For more detailed information, see the dialogue on the Grouper Archive list https://mail.internet2.edu/wws/arc/grouper-dev/2005-05/msg00004.html >.

 

The next scheduled MACE-Dir-Groups call will be on Wednesday, June 1, 2005 at 12pm ET.