**Signet Call 5-Dec-08**

**Attending**

Tom Barton, U. Chicago (stand-in chair)
Dave Donnelly, Stanford
Klara Jelinkova, Duke
Chris Hyzer, U. Penn
Shilen Patel, Duke
Albert Wu, UCLA
Bert Bee-Lindgren, Georgia Tech
RL "Bob" Morgan, U. Washington
Renee Frost, Internet2
Ann West, EDUCAUSE/Internet2Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

**New Action Items**

[AI] (Bert) will create a roadmap for incremental adoption of a privilege management strategy. This will include a diagram to help clarify terms being used.

**Carry Over Action Items**

[AI] (Bob) will take the next steps to establish a new discussion venue for privilege management directions.

**Discussion**

- Progress Wrapping up Signet

Dave reported that in wrapping up work on Signet hooks and plug ins, a major bug was exposed with regard to database connectivity. Signet could only have one database connection open it was always open. Fixing that bug has required rework of the object relational model. Dave is also working on refactoring and repackaging. The effort to integrate Signet with Eddy has not been started. Dave will look into Eddy and web services between now and end of year.

- Privilege Management Discussion Based on Tom’s Framing Document

Tom created a document called “Interfaces fore Managing Access with Groups, Roles, and Privileges” to help frame the discussion of support for role and privilege management. It can be found as an attachment at:

https://mail.internet2.edu/wws/arc/signet-dev/2008-12/msg00001.html

Tom explained the three primary highlights that came out of his thinking about privilege management:

1. It makes sense to focus on identifiers as a means of being able to loosely couple things and layer services. This will promote incremental adoption.

2. It’s important to describe a set of interfaces including roles, resources, and references, in addition to groups and privileges.

3. There are quite a few systems of identifiers to be managed, so it will be helpful to have an underlying unified naming plan.

Albert raised the issue of a potentially exploding number of identifiers because of privileges with parameters.
Albert shared a use case at UCLA in the DACSS system: in defining which accounting unit for which an employee can make purchases and how much money they can spend per transaction, there are a massive number of combinations.

The group discussed the question: Is it OK to use templates for privileges, or must there be unique identifiers, even if two people have the exact same parameter values? Bert expressed the opinion that each person should have a unique identifier for his privileges, even if he shares those same privileges with another person. TomB stated that unique identifiers may be important for financial systems, but the answer may be different when privileges cross several systems. There are times when it’s valuable to say “all occupants of this role have the same privileges” An example of this could be a shared file system with a quota system, where there is a Quota A and Quota B. You don’t want to uniquely identify the assignment of Quota A for each person. You just want to say “Quota A”

Chris suggested that perhaps a type could be used, so in some cases all privilege combinations are specified up front and in some cases the privilege combinations are flexible.

TomB noted that the identifier assignment process is not addressed in his privilege management document. The model is not complete yet.

Bob remarked that privilege management analysis was done at Stanford years ago (including the idea of separating privileges from roles) and that work formed a conceptual basis for Signet. TomB stated he is not trying to rehash previous work, but he wants to think about terminology a little differently.

Albert stated that the user interface might be more important than data representations. We are asking humans to manage a complex set of data relationships. Most people are not trained to do this. Also the need to be able search and retrieve is crucial. Try to model how humans behave.

TomB summarized lessons from Grouper with respect to the UI: some institutions want a separate window for group management while others don’t want folks to know group management is going on. So maybe one UI isn’t realistic. Interfaces must be good at enabling others to create effective contextual UIs (such as UIs that let people know the range of values for a parameter).

Klara said it’s a challenge to keep design at a level that’s useful and also has enough granularity. Need to make progress and not drill too deep into some details.

Tom stated there were two defects with Signet as it developed.

1. It wasn’t possible to refer a privilege out of Signet. Signet was too vertical and couldn’t be layered very well.

2. There were problems with the scope parameter in Signet.

There was consensus that the range of requirements -- from groups with a small number of roles to applications with highly parameterized privileges -- are all on a continuum, and a system should be able to handle all parts of the continuum. APIs, hooks, auditing, and integration, are all layers around the continuum and all have same general requirements, if not same precise requirements.

It would be beneficial to lay out a roadmap showing incremental adoption and to have a toolset that supports gradual migration.

[AI] (Bert) will create a roadmap for incremental adoption of a privilege management strategy. This will include a diagram to help clarify terms being used.

Next Call: Friday, December 19 at noon ET.