Enriching Identity Through GroupsEDUCAUSE Distributed Access Management CAMP

Joy VeronneauCornell University, Identity Management

November 8, 2006

A Little Bit of Background

• Examples of Groups at Cornell:– People allowed to download Eudora– Students– Employees– People allowed to access the Identity

Management Request Tracking System– Chess club mailing list

• Cornell currently manages groups such as these with an in-house application called the “Permit Server”

Why Not LDAP Groups?

• We looked at doing this a couple of years ago, but our Directory data feeds aren’t robust enough….

Cornell’s Permit System

• Central Authorization at Cornell is generically handled by the Permit Server

• The Permit Server maps groups of NetIDs to “permits”

• A permit is just a string token, such as “cit.staff” or “cu.student”

A List-Based System

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:

How Permits are Used

• A service or resource may be restricted to users who hold specific permits

• Various applications (including CUWebAuth, our Apache module for doing web based authentication) know how to query the permit server and thus utilize the central authorization system

• Application administrators can choose to utilize centrally maintained permits, or they may opt to administer their own permit

Permits: High on Maintenance

• Regardless of whether or not a permit is centrally or locally maintained, the permit is maintained manually, except for a few provisioning scripts which cause a basic set of permits to be issued when NetIDs are created.

• Regularly scheduled “clean up” processes are in place to remove permits when a user’s association with the university changes - student graduates, student changes to employee, employee changes to student, or termination.

Speaking of High on Maintenance

• Try to buy a ticket to Slope Day if you are a Grad student…

• Administrative UI designed in the 1990s• No automatic memberships/roles• No limitations, expirations• Limited delegation features• Users can’t see what permits they have• No self-enrollment options• 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 or other laws….

Permits: Low on Features

MODERN

Permit Server Stats• Cornell has approximately 60,000 active

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 were about 375,000

queries to the Permit Server - on that day the busiest minute was about 1650 queries.

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.

Introducing the Internet2 Grouper Initiative

• 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!

Grouper - 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

Cool Stuff• Any user can log into Grouper and see what

groups they are a member of. Currently at Cornell, users have no idea what permits they have…

• Groups can be subjects in Signet and then assigned limits/privileges.

• The LDAP Provisioning Connector will automatically provision your groups into your directory.

Grouper, Shibboleth, & Remote Authorities

• AuthN is handled outside of Grouper - go ahead and use Shibboleth, CAS, or your own SSO

• What about people not in local Identity Management systems?– Add a subject source pointing to a little

database of ePPN & description (or whatever attributes are desired) of remote subjects to give restricted access to Grouper

– Eg: check out the MyVocs.org project

Cornell Look and Feel

Oracle

4 Subject Sources:NetIDs, GuestIDs, ServiceIDs, Admin Principals

Yes

SoonYes

FutureJune 2007

Example Grouper Screens(With the Cornell Style Sheet)

Grouper Migration Project at Cornell

Initiation Plans Project PlanningProject Charters

Phase One Requirements

What Requirements?

• How to define the Namespace - stem hierarchy

• The Migration Plan

• What do we need to use for Subjects, subject sources, etc. GuestIDs?

• Directory Requirements

• UI requirements

What Requirements?

• User documentation requirements• How to do group membership queries• Logging• Cleanup requirements - restore utility• Infrastructure upgrades• Availability, backups, monitoring, metrics• Security• Load testing

Permit Server - Simplest Diagram

Migration Strategy

Migration Plan Details• Develop infrastructure that supports Grouper - LDAP

modifications, other software modifications• Migrate the Permit Database to the Grouper groups registry• Put the shim in place• Permit administration utility retired in favor of the Grouper UI• Everything will just work• Application administrators convert to native Grouper/LDAP

queries when they are ready.

Designing Our Namespace

• Goals:– We want the new namespace to be better

organized than the Permit Server namespace.

– We want to be able to let each Cornell Unit decide how they want their stem to look, and how they want to administer it.

And the Winner Is…cu

cuunits affiliates

Arts & Sciences

Alumni Affairs and Development

Human ResourcesROTC

Paleontological Research

Group Membership Queries: Web Service or LDAP?

• Decided we need both• Would LDAP Connector be ready in time?• Web Services for updates• LDAP for applications that come enabled for

LDAP group lookups• Still working on LDAP ACI protection scheme

• Initial investigations:– Fit-Gap analysis between Permit Server System and Grouper– Early versions of Grouper running in test– Baseline discovery and use cases– Requirements gathering - over 30 meetings– Built and tested scripts to migrate permits into Grouper– Modified UI for Cornell look and feel

• Migration strategy:– Phased approach– Start with 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)– Addition of automatically provisioned groups comes later

Work Accomplished to Date

Interesting Things we Found While Gathering Requirements for the Migration Project

• The Permit UI doesn’t do any error checking when you add NetIDs to a permit. One permit had quotes around all the NetIDs, i.e. “jv11” rather than jv11. Wasn’t going to migrate well.

• There are about 20 Kerberos admin principals in use that have permits but aren’t in the directory - we will have to create a directory branch just for those.

• We found 5 or 6 org charts when deciding how to build our namespace for our stem hierarchy.

• The permit server daemon was not logging every command.• Our provisioning scripts were assigning quite a few permits that aren’t in use

anymore.• We gave several demos of Grouper and the campus is enthusiastic about the

project.• Requirements gathering takes a long time - at least two months.

Larger Tasks To Do Before Go-Live

• Load testing!• Deciding on and implementing an ACI scheme for

protecting group membership information in LDAP.• Building a web service interface to the Grouper API -

although a prototype is finished.• Integrating our CUWebAuth Authorization software

with native Grouper.• Writing the permit shim.

Things to do Later, After the Migration

• Start populating groups automatically from systems of record - for example, class lists, departmental employees

• Signet

How Come You’re Not Done Yet?

• Phasing out Kerberos 4; will be Kerberos 5 only

• Integrating Active Directory with LDAP and Kerberos

• Provisioning Alumni• Password Complexity Enforcement• Campuswide GuestID system

Central Authorization, The Big Picture

Protect Your Grouper Database Password!