Cornell University

Cornell University Central Authorization Replacing a System that (sorta) Works Tom Parker Joy Veronneau Identity Management Team OIT/CIT Security Office

Cornell’s Permit System Also a Permit • 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”

Permit Server Stats Also a Permit • 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

Current Limitations 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

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 A grouper • 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

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

48 RURC Units about 12 of these So, for example

HR nests its own org structure here So, for example

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 (Current view) • Transparent cutover of Permit Server to Grouper • System owners and application developers migrate at their convenience - 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 (Cutover view) • Transparent cutover of Permit Server to Grouper • System owners and application developers migrate at their convenience - 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.

Groups Directory dc = authz, dc = cornell, dc = edu objectclass = cornelledugroup attribute = cornellgroupreadpriv objectclass = edumember attribute = hasmember objec…. . ou = groups . . cn = cit.adsm.backline cornelledugroupreadpriv:backlineAppBindID hasmember:se10@cornell.edu :pb10@cornell.edu cn = cit.adsm, ou = groups cornelledugroupreadpriv:GrouperAll hasmember:jv11@cornell.edu :jtp5@cornell.edu . . . . . .

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