Cornell University Replacing a System that (sorta) Works Tom Parker Project Manager Identity Management Team Cornell University 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 System Also a Permit

PERMIT NAMELIST OF NETIDs cit.staffbbb1, cjm5, jtp5, rd29, jv11, … cu.employeeaba1, cjm5, jtp5, rd29, jv11, … cu.studentfbc4, gv455, rb553, tgm4, … cit.update.eudorafbc4, gv455, jtp5, rd29, jv11, … On the Permit Server, we might see something like this table: It’s a List-based System Also 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 PlansProject PlanningProject Charters

Steering Committee, a Key Component DepartmentRoleStakeholder Office of the Univ. RegistrarDirector, Technical ServicesRob Bandler Johnson School/JGSMChief Technology OfficerKevin Baradet CIT Information SystemsIT ArchitectSteve Barrett CIT Customer Svcs & MarketingManager, Help Desk/Contact CenterJP Brannan CIT Systems & OperationsTechnical Lead/ManagerLaurie Collinsworth CIT Adv Tech & ArchitecturesTechnical Lead/ManagerRon DiNapoli College of Ag & Life ScienceIT Security Officer, CALSDaniel Elswit HR Info Systems & Records AdmDirector, HR Records AdministrationLyman Flahive Campus Facilities ServicesAssociate Director of ITDebra Howell Digital Library Info TechDirector, Library SystemsMarcy Rosenkrantz CIT Information SystemsManager, Peoplesoft ApplicationsJolene Scaglione School of Hotel AdministrationSr. Web Systems AnalystJason Woodward Office of the Univ. RegistrarDirector, Technical ServicesRob 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 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 requirements New use cases Business processes Cornell project Interdependencies Application-specific requirements Name space conventions Roll-out requirements Back-out strategy Security Requirements For Example: Fit-gap analysis Permit server log analysis Testing with I2 Applications Working Group participation Known use cases Discovery Our Current Timeline Project Planning FebMarAprMayJunJulAugSepOctNovDecJanFebMarAprMayJun ‘07 Jan ‘06 Target Cutover Phase One Grouper Signet available For 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