Cornell University
Replacing a System that (sorta) Works
Tom ParkerJoy Veronneau
Identity Management TeamOIT/CIT Security Office
Central Authorization
Central Authorization at Cornell is generically handled by a Permit Server
Developed at Cornell and has been in use for over a decade
The Permit Server maps groups of NetIDs to “permits”
A permit is just a string token, such as “cit.staff” or “cu.student”
Cornell’s Permit SystemAlso a Permit
Permit Server Stats Cornell has approximately 175,000 NetIDs. There are over 800 permits but only about 325
are active. Those active permits have about 500,000
memberships. On our busiest day, there are about 375,000
queries to the permit server. On that day the busiest minute has about 1,650
queries. Creation of new permits generally limited to sys
admins Not used for personal groups like mailing lists
Also a Permit
AdminUI designed for the 1990s No limitations, expirations Limited delegation features Users can’t see what permits they have Permits can’t do negative authorizations
For example, an institution may want to offer a service to all active students but only within the United States due to export regulations..
No self-enrollment options Anyone (or anything) can be included in a
Permit List No checks for misspellings or formatting errors
Current LimitationsAlso a Permit
Some Grouper Features that our Permit Server Doesn’t Have Distributed group management Composite groups - groups whose membership is
determined by the union, intersection, or relative complement of two other groups
Traceback of indirect membership A future version of Grouper may include aging of groups
and memberships Self enrollment and unenrollment Users can easily see what groups they are members of Users can create and manage their own groups Group membership flows nicely into LDAP directory Uses existing repositories for subject sources
Initial Investigations Fit-Gap analysis between
Permit Server System and Grouper
Early versions of Grouper running in test
Built and tested scripts to migrate permits into Grouper
Modified UI for Cornell look and feel
Emphasis on discovery and use cases
Requirements gathering
A grouper
Requirements,some easy, some not…
Requirements,some easy, some not…
Major Discussion Points Defining a namespace
Of 30 Requirements-gathering meetings, eight were devoted to defining the namespace
Migration strategy How would we roll out a new campus-wide
system without causing undue interruption to current services (or for that matter, any interruption whatsoever..)
Query mechanisms and LDAP security
Defining a Namespace Grouper will likely handle many different types of
groups. Some groups will be used to make authorization
decisions Some may be used for non-authorization activities such
as generating email lists and calendaring. When someone requests that a new group or
stem be created, we will need a process for defining where in the Grouper name-space the new stem or
group should be placed what it should be named.
Our Namespace Strategy Define a basic name-space of stems in which new
groups can be created so that as soon as we switch from using the Permit Server to using Grouper, we will be ready to create new groups.
Designate one or more people from each unit as the “owner” or “stem administrator” of their unit’s name-space.
In this way, we push authority to the departmental units and each unit can decide how they want to administer their Grouper stem.
Multiple Views of Delegated Authority HR View of Delegated Authority
Division Department, Unit, Job, Position, Also Role, Project, or other notions of responsibility Matrixed & non-matrixed
Fiscal Responsibility View(s) Role-based: Fiscal Officer, Account Manager, Account Supervisor Org Hierarchies: Responsibility Centers, Divisions, Departments, Units Account-based: Chart of Accounts, Account, Sub-Account, Object Codes, Project
Codes, etc. Academic View(s)
College, Department, Program, etc. Statutory vs. endowed Project-based (crosses all of the above)
Research View(s) Closely related to, sometimes the same as, Academic view(s) Based on Funding Source or… Based on Signature Authority Or Project-based
Issues For All Delegation, Matrixing, Effective-dating (time boxing), etc. Resolution of orthogonal views (cross-walking multiple Orgs) Base the multiple views on administered data in enterprise sources
Research Unit Reference Chart Office of Institutional Planning
Structure designed to provide a view of delegated authority at the organizational entity level from the Board of Trustees view
Currently updated once a year (every Spring) Willing to maintain this if users sign up to the idea
RURC has 48 Units Decent representation (ITMC) Makes sense because the structure below Unit
Name is political not logical, and therefore unfathomable…
Affiliates (have their own tree)
So, for example
So, for example
48 RURC Units
So, for example
48 RURC Units
about 12 of these
So, for example
48 RURC Units
about 12 of these
So, for example
HR nests its own org structure here
So, for example
HR nests its own org structure here
Our Migration Strategy Phased approach
Phase One: Permit Server replacement (I2 Grouper) Phase Two: Privilege Management (I2 Signet)
Staged rollout of new features New features come later Incl. addition of automatically provisioned groups
Making the Permit Server replacement as transparent to users as possible Application administrators can switch to native Grouper
at their convenience (if they don’t take *too* long - maybe a little over a year)
Builds credibility LDAP Security
Transparent cutover of Permit Server to Grouper System owners and application developers migrate at their
convenience
Transparent Cutover (Current view)
- We’re building a shim which is actually just an emulator
- Runs on same server and port as permitd
- Understands Cornell’s Stateless Server protocol (cussp)
- Translates cussp queries and updates into Grouper API calls
- Translates Grouper messages into cussp
- Applications talking to the Permit Server won’t know the difference
Transparent cutover of Permit Server to Grouper System owners and application developers migrate at their
convenience
Transparent Cutover (Cutover view)
- We’re building a shim which is actually just an emulator
- Runs on same server and port as permitd
- Understands Cornell’s Stateless Server protocol (cussp)
- Translates cussp queries and updates into Grouper API calls
- Translates Grouper messages into cussp
- Applications talking to the Permit Server won’t know the difference
Transparent cutover of Permit Server to Grouper System owners and application developers migrate at their
convenience
Transparent Cutover (Cutover view)
- We’re building a shim which is actually just an emulator
- Runs on same server and port as permitd
- Understands Cornell’s Stateless Server protocol (cussp)
- Translates cussp queries and updates into Grouper API calls
- Translates Grouper messages into cussp
- Applications talking to the Permit Server won’t know the difference
Query Mechanisms Read group memberships from directory or database?
(Heated discussion) The decision maker here was that some applications like
Oracle Calendar are delivered ready to read groups from a directory
We decided to use Grouper’s LDAP Provisioning Connector to push group membership informatiom into the electronic directory
We also need to provide a web service query to provide compatibility with existing applications
Security of Group Membership Information
The Permit server allowed us to specify whether or not a group’s membership is “secret”
Application principals could read a permit’s membership if authorized to do so.
We can preserve this model using Grouper’s group read privilege and ACI’s on the group directory.
dc = authz, dc = cornell, dc = edu
ou = groups
objectclass = cornelledugroupattribute = cornellgroupreadpriv
objectclass = edumemberattribute = hasmember
objec…....
cn = cit.adsm.backlinecornelledugroupreadpriv:backlineAppBindIDhasmember:[email protected]
cn = cit.adsm, ou = groupscornelledugroupreadpriv:GrouperAllhasmember:[email protected] :[email protected]
..
....
Groups Directory
Grouper Subject Sources NetIDs - yes GuestIDs - not yet Special Mailboxes - no Application IDs - yes (no source for them
exists currently…) Administrative IDs - yes (no source for
them exists currently…) Medical School NetIDs?