Signet Call 19-Dec-08

**Attending**

Mike Olive, Stanford (chair)
Tom Barton, U. Chicago
Dave Donnelly, Stanford
Bert Bee-Lindgren, Georgia Tech
Renee Frost, Internet2
Ann West, EDUCAUSE/Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

**Carry Over Action Items**

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

**Discussion**

Discussion focused on Bert’s document "Groups, roles, authorizations and privileges: Motivating a unified system."
https://mail.internet2.edu/wws/arc/signet-dev/2008-12/msg00005.html

Basic Approach

Bert stated that his proposed approach involves:

- Grouping together privileges, roles and groups (PRGs) in a common data model.

- Defining “assignment” as an attachment of a subject to a PRG.

- A concept of adding parameters (e.g. condition, state, and grace period/timer) to assignments.

More Details

- There are differences, of course, between management of privileges, roles and groups. Privileges are not as easily provisioned into LDAP, or anything else, as groups and roles are.

- There can be multiple memberships per subject per group.

- Assignment to a group is a membership in a group. The same subject might be a member more than once of a group to embody different kinds of parameters.

- When you define a group/role/priv, you also define the parameters associated with the memberships of that group, whether it’s quota, whether it’s what type of member (instructor or student), or whether it’s limits on privileges within the system (e.g. department restrictions, dollar amounts limits).

- Potentially, there would be thousands of PRGs, one per class.

- Example: “PURCHASE APPROVER” would be a PRG. Parameters within that PGR would define the size of a purchase a subject is authorized to approve.

Rules

- Could do group math with rules. Georgia Tech Uses rules to pull in and subtract out other groups.

- There could be a possibility to define a filter and use that in another PRG within a rule.

Big Picture

This approach is an attempt to normalize the data models for privileges, roles and groups down to a single concept.

There is some common antecedent object class for PRGs

The top class is keeping track of a lot. It’s very rich in terms of its generic abstracted functionality.

There are no subclasses to define whether something is a privilege, role, or group. It’s the parameters on a PRG that make it role-like, privilege-like or group-like.

Mapping

TomB suggested we could try to see how to use this model for implementing other kinds of interfaces. How can this be mapped this into
- Enterprise Grouper or
- uPortal tags or
- NIST RBAC model

Incremental Steps

TomB noted that we want people to be able to take small steps towards having greater capabilities towards managing groups roles and privileges.

Ideas:
Step 1. Implement life cycle parameters for memberships

Step 2. Support some parameters on what we currently call groups

Step 3. Deal with relatiotional parameter sets, where the values collected are not independent of each other, but rather they mean something to each other.

Step 4: Group itself could have some lifecycle management (aging out of expired groups).

Modular Approach

TomB noted he hopes whatever we produce in this space is not terribly vertically integrated. It's better to deliver smaller components. We should aim for services oriented technology and modules that allow for independent implementations, for example for campuses that already have Kuali identity Management (KIM).

Bert noted that the membership life cycle aspect is suitable to be a module outside of Grouper. It makes sense to take stand-alone Grouper and add an additional module to manage life cycles (like a loader with a UI that can run on top of Grouper).