Leveraging Campus Directories: Lightweight Authorization and Group Management Keith Hazelton University of Wisconsin-Madison

Leveraging Campus Directories: Lightweight Authorization and

Group Management

http://arch.doit.wisc.edu/keith/educause

Keith Hazelton

University of Wisconsin-Madison

Internet2 Middleware Architecture Committee for Education

Educause, October, 2004

2004-10-20 Educause, Denver 2

Outline

• Identity Management (IdM) defined

• Life story of enterprise Identity Management:– The starting point: Enterprise directories

– Authorization, the early years: Individuals, services, groups (NMI Project Grouper)

– Authorization and privilege management: The infrastructure matures (NMI Project Signet)

• Exploring the early authorization phase, “lightweight authorization”

• Copyright Keith Hazelton, 2004. This work is the intellectual property of the author. 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.


Identity Management (IdM) defined

• What is Identity Management (IdM)?“Identity management is the set of business processes, and a supporting infrastructure, for the creation, maintenance, and use of digital identities.” The Burton Group (a research firm specializing in IT infrastructure for the enterprise)

• What problems does Identity Management solve?


Identity Management is…

• “Hi! I’m Lisa.” (Identity)• “…and here’s my password to prove it.”

(Authentication)• “I want to open the Portal to check my email.”

(Authorization : Allowing Lisa to use theservices for which she’s authorized)

• “And I want to change my grade in last semester’s Physics course.”

(Authorization : Preventing her from doing things she’s not supposed to do)


Identity Management is also…

• New hire, Assistant Professor Alice– Department wants to give her an email

account before her appointment begins so they can get her off to a running start

• How does she get into our system and get set up with the accounts and services appropriate to faculty?


What questions are common to these scenarios?

• Are the people using these services who they claim to be?

• Are they a member of our campus community?• Have they been given permission?• Is their privacy being protected?


As for Lisa

• Sez who?– What Lisa’s username and password are?– What she should be able to do?– What she should be prevented from doing? – Scaling to the other 40,000 just like her on

campus


As for Professor Alice

• What accounts and services should faculty members be given?

• At what point in the hiring process should these be activated?

• Methods need to scale to 20,000 faculty and staff

• There is an Identity Management aspect to each and every one of these items


Identity Management, the Big, Scary Picture


IdM Starting Point: The Enterprise Directory


Enterprise Directory Services

• The Join: Establishing identity across systems

• Issuing digital identity credentials• Supporting authentication, Web Initial Sign-

on (Web-ISO)• Maintaining per-person information and

identity attributes• Making this available to application

developers and integrators


Authorization, the early years

• IdM value realized only when access to services & information enabled

• Authorization support is the keystone• Crude beginnings: If you can log in, you get it

all• Call to serve non-traditional audiences

breaks this model:– Applicants– Collaborative program students



• First refinement on “Log in, get it all:”• Add service flags to the enterprise directory

as additional identity information– Lisa: Eligible for email– Fred: Eligible for student health services– Sam: Enrolled in Molecular Biology 432

• The horrendous scaling problem



• Bringing in groups to deal with the scaling problem


Thanks to: [email protected]





Groups to the rescue

• Create a group, musketeers

• Say what services members of the group are eligible for

• Make selected individuals members of the group


Authorization and privilege management: The infrastructure matures (Signet)

• The emergence of Privilege Management:

By authority of the Dean grantor

principal investigators role (group)

who have completed training prerequisite

can approve purchases function

in the School of Medicine scope

for research projectsup to $100,000

limits

until January 1, 2006 condition


Back to the future: Lightweight Authorization and Groups

• NMI project Grouper: A toolkit for lightweight (group-based) authorization

• Led by Tom Barton, U Chicago

• International collaborative project– UI being developed at Bristol in UK


Grouper topics

• The problem with groups

• Case study: U Chicago’s “USITE” computer labs

• Tour of Grouper

• USITE case study revisited

• Grouper project status


Groups facilitate …

•Customization – application UI tailored to user’s affiliations with the organization

•Authorization–“Lightweight” - relationship info feeding access decisions

–“Heavyweight” - assignment of structured privileges to groups

•Messaging, scheduling, & collaboration–Departments, courses, programs, cmtes, teams, …


Group management issues

• Coordinating many sources of information• Provisioning groups in many locations• Supporting several styles of access to group membership information

• Aging of groups and of memberships• Use of subgroups vs. effective membership • Referring to set theoretic combinations of groups (compound groups)

• Privacy & visibility requirements


The USITE access problem

•Must control access to computers in labs independent of ability to authenticate

•U Chicago’s Networking Services & Information Technologies (NSIT) established the Identity Management Working Group to solve this type of problem

–You’ll see “nsit” and “usite” in names of things to follow


USITE access policy•Students

–23 categories of current students–Some entitle USITE access, some disenfranchise, others fail to entitle

–Time of year dependency for some categories

•Current faculty & staff are entitled•Other more loosely affiliated people are not entitled

•Exceptional administrative admits and denies across all categories above


Use of group management

• Various elemental USITE-related categories of people are modeled as groups

• Subgroups are used to roll-up effective admit or deny status

• Some groups are automatically managed, others manually

• Some roll-up groups are manually managed to deal with time dependency or change in access policy


Groups model for USITE access (ACL is “shaded green but not red”)

usite_eligible(manual)

admin_admit(manual)

uc:faculty(auto)

uc:staff(auto)

categories of entitled students

time dependent student categories

categories of barred students

admin_deny(manual)

usite_barred(manual)


Management related groups

• Management privileges for manually managed groups also need to be managed!

• So, more groups list who has what authority in managing groups that mediate USITE access– Director of Learning Environments

– Lab Managers

– Student staff


LDAP

Data flow & Grouper’s role in USITE access

uid: jdoeucAffiliation: …isMemberOf: …

SIS

HR

Dir. Learning Environments

Lab Managers

Loaders

GrouperAPI

Personregistry

Groupregistry

GrouperUI

GrouperAPI

lab

GrouperAPI

Student staff


Grouper groups

• Stored in an RDBMS, the Group Registry

• Attributes of groups– Name

– Description

– Members

• Possible to extend the set of attributes to support groups with more specific purposes


Grouper privileges

• Access privileges - who has what access (read, write) to a group’s attributes

• Naming privileges - who can create a group or subdirectory in what part of the directory of groups


Access privileges

• VIEW group’s name in lists & can refer to it, e.g., make it a subgroup of another group

• READ basic information about a group

• UPDATE membership and administer VIEW, READ, & UPDATE privileges

• ADMIN can modify everything, including group name, description, & privileges, and can delete the group

• OPTIN can add self to the members list

• OPTOUT can remove self from the members list


Naming privileges

• STEM privilege in a given directory enables creation of subdirectories and administration of CREATE and STEM privileges for the directory and its immediate subdirectories– Motivating idea: a directory is a naming “stem”

over which authority is exercised and delegated by those with stem privilege

• CREATE a group in a given directory


Built-in privilege implementation

• All access & naming privileges can be assigned to individual members or to groups– Subgroups, compound groups, and aging can be

used to manage privileges

• Abstracted interfaces are presented for privilege management– Sites can hook in their own privilege

management and bypass Grouper’s built-in system


USITE revisited – Grouper’s role

• Make an “nsit:usite” directory in the group registry

• Groups created within it– dir_learning_env, lab_managers, student_staff

– usite_eligible, usite_barred

– admin_admit, admin_deny

• Give stem privilege for “nsit:usite” to the Director of Learning Environments– She can run her groups empire within


USITE group access privileges

usite_eligibleA:dir_learning_env

V,R:all

admin_admitU:usite_manageV,R:usite_view

uc:facultyV,R:all

uc:staffV,R:all

categories of entitled students

time dependent student categories

categories of barred students

admin_denyU:usite_manageV,R:usite_view

usite_barredA:dir_learning_env

V,R:all

V:all V:all

V:allV:all V:all

V:all V:all V:all

V:all


USITE group management privileges


Oh, and Personal groups

• Any user can create groups named personal:username:groupname

• Good or evil?–Yeah! Low overhead to let everyone do groups–Booo! Valuable institutional data squirreled away in

unknowable spaces that go away

• Configuration: –on/off–Root directory for personal namespace (“personal” above)


Grouper v1 features

• API & UI for basic group management– Create, read, update, delete, import, export– Distributed management– Subgroups & compound groups– Aging of groups and memberships

• Abstracted interfaces for – Group and directory privileges– Subject lookup– Last activity


Phases of Grouper v1 development

• Phase 1: Basic management and export functions

• Phase 2: Compound groups & Signet integration

• Phase 3: Aging of groups and memberships

• Phase 1 API available before end of November 2004


Grouper deliverables

•U Chicago - Java API•U Bristol - Java UI•You – contributed loaders & connectors•Subject Lookup implementation

–jointly with Signet project

•Group Registry creation scripts & sample batch import/export scripts

•Documentation


Resources

• http://middleware.internet2.edu/dir/groups

• http://middleware.internet2.edu/signet

• [email protected]


Grouper in Context


Process diagram

Documents

Leveraging Campus Directories: Lightweight Authorization and Group Management Keith Hazelton University of Wisconsin-Madison