cornell university replacing a system that (sorta) works tom parker joy veronneau identity...

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…

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

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

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]

:[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?

cornell university replacing a system that (sorta) works tom parker joy veronneau identity...

Documents