Cornell University

Replacing a System that (sorta) Works

Tom ParkerProject Manager

Identity Management TeamCornell Universityjtp5@cornell.edu

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 NAME LIST OF NETIDs

cit.staff bbb1, cjm5 , jtp5, rd29 , jv11, …

cu.employee aba1, cjm5 , jtp5 , rd29 , jv11, …

cu.student fbc4, gv455, rb553, tgm4, …

cit.update.eudora fbc4, gv455, jtp5, rd29 , jv11, …

On the Permit Server, we might see something like this table:

It’s a List-based SystemAlso a Permit

Whenever a new NetID is created during the hiring process (staff)

Whenever a new NetID is created during the the admissions process (students)

Service owners wishing to restrict a specialized service may request a permit for their application They are given tools to manage their

permit They decide when to assign or revoke a

permit for a particular user That is, if they remember to do so…

How are Permits Obtained?

Permits allow users to be put into “groups” Students Staff Chess Club Members

These groups can be big or small Application administrators can choose to use centrally

maintained permits, or they may opt to administer their own.

Some are maintained by central IT staff Who are the students? Who are the staff?

Others are maintained at a departmental level Who are the Human Ecology students? Who can download certain licensed software?

Various applications (including CUWebAuth, our Apache module for doing web-based authentication) know how to query the Permit Server and thus use the central authorization system

How are Permits Used?

Permit Server Stats Cornell has approximately 60,000 NetIDs. There are over 800 permits but only about 325

are active. Those active permits have about 300,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.

Regardless of whether a permit is centrally or locally owned, the permit is maintained manually

There are a few provisioning scripts developed in-house which cause a basic set of permits to be issued when NetIDs are created

Regularly scheduled “clean up” processes are in place to remove permit entries when a user’s association with the university changes student graduates student changes to employee employee changes to student Employee is terminated

Currently there is no way to automatically manage permits

Permits: High on Maintenance

AdminUI designed for the 1990s No automatic memberships 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

MODERN

Permits: Low on Features

So, we love Permits, but.. We recently had to restructure

the on-line course registration application because it was crashing the Permit Server.

We are starting to need more features, and a more modern system.

I2 Authorization Initiatives

Grouper (group-based membership) Signet (privileges and limitations) Shibboleth (open source

implementation to support inter-institutional sharing of web resources subject to access controls)

I2 Overview Maps Nicely to CU

Grouper

Cornell was following Grouper development efforts.

Grouper seemed like it might be a possible replacement for the Permit Server.

We looked into Grouper a little bit more and liked what we saw!

It’s a Group Management Service

A common user interface and standard API for managing groups.

Users can easily see what groups they are members of.

Users can create and manage their own groups.

A Few of the Grouper Features that the Permit Server Doesn’t Have basic group management by distributed

authorities subgroups 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 will include aging of

groups and memberships Self enrollment and unenrollment LDAP provisioning of group membership

information Uses existing repositories for subject sources

Grouper’s LDAP provisioning connector plays nicely with our campus-wide electronic directory.

For other in-house applications we can use a web-service to obtain group membership information directly from Grouper.

A big one for us: Grouper supports a delegated model of control

Why Grouper for CU?

Cornell’s Project Mgt. Methodology Bringing some corporate rigor to campus but in a

way that remains appropriate to a university environment

Requirements Use Cases Communication Plans Project Planning Migration strategies Thorough testing Rollout Planning

Lots of Up-Front Document Work

Initiation Plans Project PlanningProject Charters

Steering Committee, a Key Component

Department Role Stakeholder

Office of the Univ. Registrar Director, Technical Services Rob Bandler

Johnson School/JGSM Chief Technology Officer Kevin Baradet

CIT Information Systems IT Architect Steve Barrett

CIT Customer Svcs & Marketing Manager, Help Desk/Contact Center JP Brannan

CIT Systems & Operations Technical Lead/Manager Laurie Collinsworth

CIT Adv Tech & Architectures Technical Lead/Manager Ron DiNapoli

College of Ag & Life Science IT Security Officer, CALS Daniel Elswit

HR Info Systems & Records Adm Director, HR Records Administration Lyman Flahive

Campus Facilities Services Associate Director of IT Debra Howell

Digital Library Info Tech Director, Library Systems Marcy Rosenkrantz

CIT Information Systems Manager, Peoplesoft Applications Jolene Scaglione

School of Hotel Administration Sr. Web Systems Analyst Jason Woodward

Office of the Univ. Registrar Director, Technical Services Rob Bandler

Fit-Gap analysis between Permit Server System and Grouper

Early versions of Grouper running in test Emphasis on discovery and use cases Built and tested scripts to migrate permits into

Grouper Modified UI for Cornell look and feel Requirements gathering - over 30 meetings

Initial Investigations

Understanding the Requirements

Requirements,some easy, some not…

Relatively Easy Subject sources UI requirements Logging needs Cleanup utilities Updater utilities Communications Infrastructure updates Test plans

Security User documentation Business processes Availability

Not So Easy Query mechanisms Namespace Migration planning

Two Problems Loomed Large 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..)

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 Cornell unit as the “owner” or “stem administrator” of their unit’s name-space.

In this way, we would be pushing authority to the departmental units and each unit could decide how they want to administer their Grouper stem.

Orthogonal 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 every Spring Willing to maintain this if users signed up to the idea Partly because the structure below Unit Name is political

not logical, and therefore unfathomable….. Affiliates (have their own tree) RURC has 48 Units Decent representation (ITMC)

Our Migration Strategy Phased approach

Phase One: Permit Server replacement (I2 Grouper) Phase Two: Privilege Management (I2 Signet)

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)

Staged rollout of new features New features come later Incl. addition of automatically provisioned groups

Transparent cutover of Permit Server to Grouper System owners and application developers migrate at their

convenience

Transparent Cutover (Current view)

Transparent cutover of Permit Server to Grouper System owners and application developers migrate at their

convenience

Transparent Cutover (Developer’s view)

Transparent Cutover (Proj. Mgr’s view)

From a Project Manager’s point-of-view, a simple shim that fixes everything has a lot to offer..

The only feature I could think of to add…

Transparent Cutover (Proj. Mgr’s view)

The Shim is 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

For Example:General requirementsNew use casesBusiness processesCornell project InterdependenciesApplication-specific requirementsName space conventionsRoll-out requirementsBack-out strategySecurity

Requi

rem

ents

For Example:Fit-gap analysisPermit server log analysisTesting with I2 ApplicationsWorking Group participationKnown use cases

Discov

ery

Our Current Timeline

Project Planning

Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun

‘07

Jan

‘06

Target CutoverPhase One

Grouper

Signet availableFor testing

Phase One Requirements

Requirements Sign-off

(you are here)

We’re re-skinning the Grouper native

interface

Continued Campus Communications…

Questions?

Project Manager looking for Grouper

300 Pound Giant Grouper

Questions?

…is actually daydreaming about Permit Shim