Open Registry Role Definition Design Discussion

Present:

Benn Oshrin
Jeremy Rosenberg
Jon Finke
Dave Steiner
Nancy Mond
Rob Urquhart

Note taker:

Nancy Mond

Agenda: How should role definitions be represented in Open Registry?

Background:

Current system in place at Rutgers defines roles based on a small set of affiliation types:

Student
Summer Student
Winter Student
Alumni
Faculty
Staff
Student Worker
Guest

Downstream systems provide services, access based on these affiliations, along with other attributes.

High Level Goals for Open Registry:

• Provide more fine grain affiliations.
• Provide more information for determining which services, access should be granted. For example, may want to limit access based on the campus that is associated with the role.
• Support for more affiliation types: Conference Attendee, Foundation, Continuing Education...
• What other goals should we be targeting?

Data Model Design Points to Consider:

• Ease of grouping people to give them access. (Integration with Grouper?)
• Reduce data duplication. Sor role records and calculated role records need role definition data. If the data is put in the role record instead of the role definition it will be duplicated in the Sor and the calculated role.
• Normalize the schema so that if a data item changes it only needs to change once in the role definition.
• Bound the ability of SoRs to create new roles.
• Ease of reference data maintenance.
• Flexibility of design.

Role Definition Design:

Original Role Definition:

Organization, Title, Affiliation, Code

Current Role Definition:

Organization, Title, Affiliation, Code, Campus and System of Record

Proposed Definition Up for Discussion:

Affiliation, Code and System of Record

Visual UML representation for discussion

Notes:

The discussion generated the following observations, insights, etc.:

• Primary goal for role definitions: to define a persons relationship to the university and to support granting of entitlements to services and resources.

• Benn said that organizational unit + title implies affiliation.

• Benn mentioned that the intention of providing title in the role definition was to be able to for example establish that a person is a Faculty member and a Professor and a Faculty and a Department Chair. This would enable the granting of privileges to the role of department chair instead of to the individual. This would facilitate the easy transfer of those entitlements to a new department chair when that role is transferred to someone new. Folks on the call pointed out that given the state of the data available from the current SoRs (Payroll/HR) that this data would not be available.

• Benn suggested that this information may need to be provided from a different SoR.

• Dave pointed out that various groups at the University still want to work with coarse grain roles.

• It was agreed that all information used by various groups in the University for determining entitlements did not need to reside in the role definition and that it could also reside in the person's role record.

• It was pointed out that other information currently in the role definition may not be obtainable at all universities. For example, the Payroll/HR system at some universities do not provide the organizational unit.

• There was a discussion about the usefulness of having thousands of records in the role definition table. There was agreement that we need to determine what information would facilitate the granting of privileges. This effort would also involve figuring out if the information is currently be provided by the existing SoRs and if not how to get it elsewhere.

• All agreed that it would be necessary to have a separate conversation around the granting of privileges and then to revisit the role definition.

• It was agreed that campus will be removed from the role definition table, that SoR will be examined further to determine if it should be removed and to relax the constraints on organizational unit and title to permit them to be null, at least for now.

• Suggestion was made that any time folks do local customizations to deal with special cases that it be documented. This helps with memory loss and staff changes

• Benn mentioned work being done in the Jasig Open Source Identity Management initiative with Grouper and that the OpenRegistry community should participate in this effort.

Action Items:

• Nancy and Dave will look at Registry code to try to determine if there is any impact to removing SoR from the role definition table.
• Nancy or Dave will remove the campus from the role definition table.