Signet and Grouper A Use Case Study

for Central Authorization at Cornell University

March 2006

Cornell’s Permit System • Central Authorization at Cornell is

generically handled by something called 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”

• On the permit server, we might see something like this table:

A List-Based System

PERMIT NAME LIST OF NETIDs

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

cu.employee aaa1, ... , cjm5 , ... , jtp5 , ... , rd29 , ... ,

cu.proxy another list of netids

How are they Obtained? • Through the hiring process (staff)

• Through the admissions process (students)

• Individuals wishing to restrict a specialized service may request ownership of a permit– They are given tools for managing it– They decide when to assign or revoke a permit

for a particular user

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

Group Authorization

• Users at Cornell are often put into “groups”– Students– Staff– Chess Club Members

• These groups can be big or small• 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?

Permits: High on Maintenance

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

• Home grown provisioning scripts cause a basic set of permits to be issued when IDs 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)

• Currently there is no capability of automatically populating permits

• Old and clunky administrative UI• No automatic memberships• No limitations, expirations• No 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 within the United States due to export or other laws

Permits: Low on Features

Internet2* 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)

* Internet2 is a consortium being led by 207 universities working in partnership with industry and government to develop and deploy advanced network applications and technologies

Central Authorization, The Big Picture*

* Barton and McRae, Internet2

Grouper Overview• Manages groups, not privileges (however a

group can be authorized to do something…)• Privileges and limitations can be added to a

group later via Signet…• Grouper gets its information on NetIDs from

the directory and maintains group information in an Oracle database. (can use other DBs but we like Oracle anyway…)

• Group information can in turn be pushed out to other repositories (such as a directory...)

Signet Overview• Central repository and toolkit for privilege information...• Management analysts define privileges in Signet based

on previously defined policy decisions and then specify the relevant set of permissions to go with them…

• Signet has a Web-based UI where users assign privileges and delegate authority across all areas for which they have authority…

• Signet internally maps assigned privileges into system-specific terms needed by applications…

• Privileges are exported into applications and infrastructure services using the appropriate notification mechanisms (e-mail, xml, webmethods, etc…)

View privileges assigned to yourself

Adding a privilege

Back-of-Napkin Overview

Use Case One

Identify someone as a member of the Engineering

College Faculty…

• This is a job for Grouper…• Grouper admin creates

engineering college faculty group based to be automatically populated from PeopleSoft based on Job info so membership is automatic.

• Admin for this group is designated. Members can also be added by the group admin.

• Group info is maintained in the Whitepages Directory where applications can access group membership information.

Use Case One

Use Case Two

Engineering College Student Group…

• This is another job for Grouper.

• “Who is a student” is a fuzzy area. We have students who don’t actually register until the end of the semester. Different services may define “student” differently.

• One university lets each service determine who is defined as a student for their service.

• Could use the Whitepages Directory attribute “cornelledutype=student - Engr” but this might include a small number of students that you don’t want. It depends how exact you need to be. One option is to refine the group membership rules to use the SIS DB.

Use Case Two

Use Case Three

A user needs to request a privilege for themselves…

For example: a user requests a change in their accounting security (change in account range or

group in the Accounting Data Warehouse…)

• This is a job for Signet.• This could possibly be

implemented as a self-granting privilege with a prerequisite for approval.

• Requesting the privilege causes a trigger which sends an email to the person who can grant the privilege.

Use Case Three

Use Case Four

An application that has its own authorization database wants

to use the Signet UI as its front-end…

• The application can be integrated into Signet as a subsystem. An initial synchronization is done to populate Signet with current AuthZ info from the application.

• When a privilege change is made in Signet, a message is sent which is picked up by a WebMethods integration and forwarded to the application’s Authz DB in the correct format.

Use Case Four

Use Case Five

Prerequisites and multiple approvals required for authorization…

For example, the prerequisites are: Review of Security Instructions; Approval of Dept. Lead; Approval of Organization Lead; Approval of Distribution Lead.

• The permission type is set up in Signet requiring these prerequisites.

• An admin requests the permission for a user.

• E-mails are sent from Signet requesting each approval but there is no sense of workflow for these in Signet (approvals may not be accomplished in order.) However, Signet could be linked to a workflow system to accomplish this if necessary.

• Question: would we need to load an organization tree or is netid designation sufficient?

Use Case Five

Use Case Six

Updating a GuestID account expiration based on a permission change…

Example: A GuestID is created on 7/20/06 for Blackboard use with an account expiration date of 9/1/2006. On 8/22/06, the permission is enabled for the GuestID account to access a

resource until 12/31/06 (after the account expires.) The account expiration date needs to be updated.

• GuestID AuthZ info can be written from Signet to the GuestID Directory where it can be accessed by the authorization infrastructure.

• All GuestID AuthZ requirements can be met with the exception of extending an account’s expiration date when a privilege is extended beyond that date. We may have to come up with something clever there - e.g. a webmethods integration might do the job.

Use Case Six

So what else is interesting about Grouper and Signet?• The number of groups will be 3-4 times the

number of people in your directory - at least!• Signet keeps a history so you can look at a

specific date and see who had what privileges on that date.

• We can hook up Signet to some of our reporting tools.

• Scalability? They haven’t done any UI performance testing….

MORESo what else is interesting about Grouper and Signet?

• At Stanford, they have decided that the privileges you have are public information and anyone can look at them.

• Will Grouper and Signet eventually be able to share one UI? Maybe…

Contact us:

Identity Management TeamCornell Information Technologies/Security GroupCornell University, Ithaca, New York

Project Director, Andrea Beesing, amb3@cornell.eduProject Manager, Tom Parker, jtp5@cornell.eduTechnical Lead, Joy Veronneau, jv11@cornell.edu

Further information on Grouper and Signet :http://middleware.internet2.edu/

Copyright Joy Veronneau, Tom Parker, Andrea Beesing 2006 This work is the intellectual property of the authors. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.