Internet2 Fall Meeting

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

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

4. ----------------- Applications and Services ------------------ MYIU Library PplSft FIS UISAppl OnCourse ERA Insite Steel Web Pgs Active Directory Shakes/ Jewels Modems Eclipse Others Virtual Private Network (VPN) Authentication Authentication API Authorization API Information Extract (LDAP) University Addressbook Authorization & Roles DB Personal Account Creation & Administration (Self Service) Accounts Staff EMPID SID MATH Major Grades Clerk IU.EDU E-mail Name Space ISN Enterprise Directory/ Information Store C201 Acct Manager PIN UITS HR Rep Account/Information Mgt & Maint Password Token Local/ Campus Support Providers IUK Advisor Core Services GDS Extract/Load Process Kerberos Extract/Load Process Safeword AS Server University People Information Other University Affiliations Other Directories ADS, Departmental HR Data Demographic Data Others Alumni Foundation Continuing Studies Others

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/answers • UMBC - 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 levels • UMBC • 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? • Chicago • Problem: 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 Internet2 Spring 2001 Meeting: Early Adopters Report