Identity Management PanelTom Barton, U. ChicagoMichael Berman, CSU- CalPoly PonomaMark Bruhn, Indiana UniversityJack Suess, UMBC

Internet2 Fall Meeting

Internet2 Spring 2001 Meeting: Early Adopters Report 2

How do you define who is eligible for different services?

CSU• Obvious: staff, faculty, students

• Less obvious: –Alumni, supporters?–Parents –Sponsored or affiliate ID’s–Transient e.g. meetings and conferences–Former employees–Research partners–Affiliates: auxiliaries, credit union, teachers

Internet2 Spring 2001 Meeting: Early Adopters Report 3

Eligibility (cont)

CSU Issues

• Intermittent roles – persistent ID’s?–Lecturers, seasonal employees–students

• Multiple roles – change roles, keep ID’s?–Student workers–Staff students

• Multi-campus issues- common id across CSU

• Does everyone need to be in your IDM? “Frontier-class” service

Internet2 Spring 2001 Meeting: Early Adopters Report

Authentication API University Addressbook

OnCourseActive

DirectorySteel Web PgsPplSft Insite

Shakes/Jewels

----------------- Applications and Services ------------------

Modems

Foundation

Other University AffiliationsContinuing

StudiesOthers

University People Information

Eclipse

Alumni

MY IU UIS Appl

Virtual Private Network (VPN)

ERAFIS

DemographicData

HR Data Others

Library Others

Person

al Accou

nt C

reation &

Ad

min

istration (S

elf Service)

Authorization APIInformation Extract

(LDAP)

Extract/Load Process Extract/Load Process GDS

EnterpriseDirectory/

InformationStore

PIN

TokenPassword

Authentication

SIDEMPID

ISN

MATHMajor

C201

UITS

IUK

IU.EDUE-mailNameSpace

GradesClerk

AcctManager

HRRep

Advisor

KerberosSafeword

AS Server

Core Services

Authorization& Roles DB

Other DirectoriesADS, Departmental

Accou

nts S

taffL

ocal/ Cam

pu

s Su

pp

ort P

roviders

Accou

nt/In

formation

Mgt &

Main

t

Internet2 Spring 2001 Meeting: Early Adopters Report 5

Eligibility (other)

Indiana

•Policy defines who can have and sponsor accounts.

•Accounts Management System will implement policy in software.

UMBC

•Adding alumni access now

•Looking at how students can grant parents/guardians access

Internet2 Spring 2001 Meeting: Early Adopters Report 6

What were the challenges in creating a single namespace?

Indiana

•Had to work across 8 campuses plus 4 major data centers

•Ground work in 1988 with "username format summit"*Namespace consolidation project began "in earnest" in 1997

•Required high-level leverage (University CIO)

•Consisted of iterative generation and review of name lists of various naming organizations

Internet2 Spring 2001 Meeting: Early Adopters Report 7

•Namespace (cont)

•Person who had an identifier the longest got to keep it

•Took over 3 years to complete

•In 2002, moved namespace to enterprise LDAP directory

•UMBC created common namespace in 1995

•In 2002 we allowed users to select account name and promote that they create custom email aliases (up to 3). Giving custom email aliases lessens namespace complaints

•Chicago - Have single namespace only for centrally operated infrastructure – there are several other significant IT providers with their own namespaces

Internet2 Spring 2001 Meeting: Early Adopters Report 8

How do you handle distribution of credentials

CSU

Traditional: come to the Help Desk • Doesn’t scale • Inappropriate for many users • What credentials do you accept ?

Self-service • Balance risk and service

– Differentiate on service class

• ID resolution difficult

Appropriate use acknowledgement

Use student orientation for distribution

Internet2 Spring 2001 Meeting: Early Adopters Report 9

Distribution (cont)

Indiana

•Online through Account Management System; faculty/staff/students use secrets; affiliate sponsors use their own accounts

•Password change feature propagates password across all [central]systems

•Working on unknown-password reset feature, using pre-primed questions/answersUMBC - Same as IU. Reset requires proof.

Chicago – similar to IU

Internet2 Spring 2001 Meeting: Early Adopters Report 10

Does authentication strength vary by application type?

Indiana

•Determined by application/function owner, with input from Security and Audit

•Central auth system provides different levels:

•Campus ID/pin (going away)

•Network ID/password (Kerberos)

•Guest ID/password ("shallow credentials")

•Challenge/response token (Safeword/AS)

Internet2 Spring 2001 Meeting: Early Adopters Report 11

•Authentication Strength (cont)

•New IU-CAS (based on Yale CAS) supports these last three levelsUMBC

•Similar to IU but wrote own WebISO

•WebISO controls level of security (timeout, attributes provided, etc.) through service ticket

Chicago - not there yet

Internet2 Spring 2001 Meeting: Early Adopters Report 12

How do you handle authorization to services?

ChicagoProblem: some integrated services still assume that authentication implies authorization.

Remedy: extensions to existing identity management processes & infrastructure, and to end applications, to manage & convey information needed by authorization policies.

Basic strategy:• 15-20 automatically maintained major affiliation

types (example: faculty, staff, student, affiliate and several gradations of each), to handle major elements of much authorization policy

Internet2 Spring 2001 Meeting: Early Adopters Report 13

Authorization (cont)

Basic strategy (cont’d):• Manually managed positive or negative

expressions of service-oriented exceptions, to handle security, administrative, or other exceptions countenanced within authorization policy.

• Mediated, delegated management of forward references to group memberships, to convey more transient or locally meaningful information bearing on authorization policy.

• Feed selected identity data to other IT provider silos to provision their needs.

Internet2 Spring 2001 Meeting: Early Adopters Report 14

Authorization (cont)

Expanding series of policy & implementation oriented discussions to define per-service access policies.

Our webISO deployment is young and is not designed to facilitate authorization per se.

Thinking about potential for “Shib as webISO” to both authenticate and transport attributes for authorization.

Contemplating adoption of “export form” of Stanford’s Authority Manager.

UMBC - PeopleSoft is forcing us to look at how to handle roles via LDAP so we can better manage instances.

Internet2 Spring 2001 Meeting: Early Adopters Report 15

How do you insure privacy and accountability?

CSU

Rapidly evolving area • G-L-B, CA SB-1386, etc.

When do you want to meet your lawyer?

Accountability of staff• Access to confidential personal data

Documentation of data access rules• Avoiding data steward “shock”

Internet2 Spring 2001 Meeting: Early Adopters Report 16

Privacy (cont)

Logging• Purpose

–Debugging, Audit, Legal - FOIA• General rule: never keep more than you need• Who has access for what purposes?

Indiana•Access to accounts/devices/network data governed by Policy onPrivacy of IT Resources (IT-07)

• Person-attributable logs kept for 30-60 days• Device-attributable netflow logs kept for 5 days mail

backups kept for 30 days

Internet2 Spring 2001 Meeting: Early Adopters Report 17

•Privacy (cont)

Chicago•HIPAA security motivating collaborative ID Mgmt with hospital to enable account auditing

Internet2 Spring 2001 Meeting: Early Adopters Report 18

How do you handle revocation of credentials?

UMBC•Worked with IT Steering Committee and faculty senate 18 months on account deletion plans.

•Developed state diagram, accounts transition through these states. Time in each state is determined by UMBCperson affiliation

•Requires ability to delegate authority on accounts to sponsoring entity. They can sponsor anyone but take responsibility for those they sponsor.

•Runs nightly based on last effective date

•Highly political - everyone wants free access

Internet2 Spring 2001 Meeting: Early Adopters Report 19

Account State Diagram

Internet2 Spring 2001 Meeting: Early Adopters Report 20

Revocation (cont)

Internet2 Spring 2001 Meeting: Early Adopters Report 21

Revocation (cont)

Indiana Now

•Run each semester

•Emails sent out to persons no longer eligible

•Affiliates and their sponsor get an email

•Student accounts disabled ~4 weeks into second un-enrolled semester

•Policy dictates employee accounts are disabled after 30 days

•Soon - PeopleSoft nightly extract checked nightly; emails sent automatically to (students/faculty/staff). Nightly script checks directory expiration date on affiliate accounts; sends emails automatically

Internet2 Spring 2001 Meeting: Early Adopters Report 22

How does Shibboleth fit into your identity management plans?

Outsourced or hosted services/systems• At minimum, a secure authN mechanism.• Potential to have campus-managed attributes passed to

hosted application to map user to app-specific roles. • SyQuest’s HigherMarkets procurement service.• Will explore with other vendors as we prospect them.

InCommon• We’re investigating how to manage eduPersonEntitlement

values to enable remote access to library databases

Internet2 Spring 2001 Meeting: Early Adopters Report 23

Shibboleth (cont)

Bridging intra-campus security domains?• Could be used for a service that must be provided

to constituents across separate user namespaces, but …

• … we won’t give up on the goal of unified namespace for services with broad constituencies.

Shibboleth (next generation?) as webISO?• Authentication and secure attribute transport

service all in one• Potential use for both authorization and

provisioning• Not real yet!

Internet2 Spring 2001 Meeting: Early Adopters Report 24

Questions

Contact Information:

Tom Barton - tbarton@uchicago.edu

Mark Bruhn - mbruhn@indiana.edu

Michael Berman - amberman@csupomona.edu

Jack Suess - jack@umbc.edu

Slides- http://userpages.umbc.edu/~jack/i2-identity