**Signet Call 14-March-2008**

**Attending**
Mike Olive, Stanford (chair)
Michael Gettes, MIT
Tom Barton, U. Chicago
Bert Bee-Lindgren, Georgia Tech U.
Josh Drummond, UC-Irvine
Neil Matatall, UC-Irvine
Ann West, Internet2
Steve Olshansky, Internet2 (scribe)

*New Action Items*
[AI] (Mike) will send a note out to the list with some context about auditing issues and requesting folks to talk with their respective auditors for their perspectives, and report/discuss via the list.

*Carryover Action Items*
[AI] (Mike) will develop an initial strawman set of test cases to float to the list for feedback. Mike will also contact U. Washington for information on their authority manager (ASTRA), for additional data points about how other systems approach these issues.

[AI] {Mike} will contact {Michael Gettes} about potential COmanage requirements to drive Signet functionality.

[AI] {Mike} will work with {Tom Barton} about centralizing a Signet and Grouper [combined] roadmap.

**Discussion**
*Status update on next Signet release - v1.3.0*
Final glitches are being ironed out, and the tentative plan is for a beta release next week. It will include import/export of metadata, management of tree structures for organizational scope, privilege set management. Release notes will accompany the release, including expected behavior of the import/export function.

It was noted that UC-Irvine has integrated code into Signet that handles group privileges.

*Exploding privileges for group membership*
There are 2 distinct functionalities involved:
1. the ability to assign a privilege to a group definition specifically. This is handled through the subject API.
2. integration between Grouper and Signet, where a group definition is expanded into individual privileges, by means of an interface API - i.e. hooks or plug-ins

There was a discussion about the interaction between Signet and Grouper, and whether this ought to be tightly coupled (groups of users are brought into Signet) or loosely coupled (by reference)? There are use cases where you want to explode groups, and other cases in which you don't.

Is the intent to manage a group of users, and they all have a distinct privilege set? Or is the intent to bulk-load signet with users to be given privileges? How deeply coupled are Signet and Grouper?

Consensus was that there ought to be a group interface in Signet that allows it to interface with Grouper or other sources of group management.

There was a wide-ranging discussion of logging - what actions are logged and where, and if/whether this will meet the requirements of the various auditors likely to be interested - security, financial, etc. E.g. who had what privilege(s) at a particular moment in time? What was the reason (causality) that a particular person was granted a particular privilege at a particular time?

An original design goal was that Signet would be fully auditable. Is this still viable? What specifically should be auditable? It is unlikely that someone will want to select a privilege and see a long list of the comings and goings of users, but more likely to want to select a user and see a history of privileges coming and going. When do you log that a user was granted a privilege? When do you log that an association is made between a group and a privilege?

What are the driving use-cases?

Audit purposes and compliance checking are certainly important, and would argue for the ability to explode the group membership. The other use case would be for the auditing requirement to be realized externally, e.g. against a directory. Would this external repository meet the needs of a real audit? E.g. this would leave out the reasoning or causality underlying the changes…

Audit capability really belongs with the management tool whose actions are being audited, and ideally there could be an interface allowing a manager to select what actions are logged…

if the privilege is conferred to a group, the membership may change over time and thus the privilege would be inherited by new members. Thus there ought to be a mechanism for notification within Signet that this membership change has occurred. How would this be triggered? There is a need to continue to reflect the exploded membership of the group over time. We need to define the points of interaction and results desired.

[AI] (Mike) will send a note out to the list with some context about auditing issues and requesting folks to talk with their respective auditors for their perspectives, and report/discuss via the list.

Privilege granting is an event, and implementation of that privilege would be an attribute of that event or a separate event.

If we imagine large groups inheriting privileges, and exploding those groups within Signet, this would be a fairly large group database, and thus a significant scaling challenge. Thus we might want to park this functionality for now…

It would seem to be less than optimal to have Signet explode groups only once upon import, but rather integrate the systems such that a user entering or leaving a group would allow that user to inherit the privileges associated with that group -- this would argue for the loosely coupled approach.

Note that there will be a combined Signet/Grouper session on Monday 21-April 1:30-3:00 PM at the Spring Internet2 Member meeting. At this meeting we ought to revisit the roadmap to ensure it has the right things in it, in the desired order of priority.
http://events.internet2.edu/2008/spring-mm/sessionDetails.cfm?session=3739&event=280