1. Who are you and what can you do? Identity Management Faust Gorham University of California, Merced 12/7/2004

2. Agenda Identity Management UC Merced - growth Challenges Goals Architecture Path – Lessons Learned Quick Demo Q&A

3. What is Identity Management “Identity management is the set of business processes, and a supporting infrastructure, for the creation, maintenance, and use of digital identities” The Burton Group

4. What Identity Management means to us The processes and technologies we will use to uniquely identify a person and what their affiliations are at UC Merced. Maintaining attributes for each person, including roles. Providing a unique identifier to each person that can be used for authentication and authorization.

5. UC Merced - 2002 85 Staff UCOP Email, thoughts of rolling out Exchange

6. UC Merced - 2004 32 Faculty 12 Grad Students 310 Staff Sun Email and Directory Oracle Calendar Banner SIS uPortal Library System (Innovative Integrated Interfaces)

7. UC Merced – August 2005 Targets: 60 Faculty 100 Grad Students 900 Students 500 Staff Sun Email and Directory Oracle Calendar Banner SIS uPortal SAKAI IDM Library, Housing (StarRez), Campus Card (Diebold), Dining, Facilities, Police

8. Challenges How do we deal with our user population growth? How do we give access to services and resources? How do we reduce costs and staff time necessary to manage users? How do we reduce silo building and duplication of user data in downstream systems? How do we prepare for SSO/WebISO? The Library will use RFID for book lending. How do we manage library privileges for lending, Inter-Library Loan? Access to buildings will be controlled by card readers. How do we provision access to users quickly? We have on average a 8 day lag between when a new staff or faculty member joins UC Merced and when their account is provisioned. How can we reduce that? How do we reduce double entry – SOR and then IT enters in Directory? Moving target of laws and regulations requiring different data policies.

9. Goal/Solution Create an identity management system that will provide a single repository to maintain contact, affiliation, relationship and role information about UC Merced users.

10. Technical Goals 1. Create business rules that determine how we define, modify, provision and deprovision: 1. Faculty, Staff, Students, Affiliates, Alumni 2. Create interfaces from our Systems of Record to the Identity Management system. 3. Create a unique identifier for each person coming from a SoR. 4. Create an attribute map that identifies for each affiliation/combo what fields we pull from which SoR, who owns them, who determines access/updates. 5. Populate LDAP and AD with all information necessary to provide authentication, personal information, affiliations, roles and relationships. 6. Develop automated tools for provisioning accounts that require “push” of data such as email and calendar. 7. Create self-service tools allowing MSOs to make user and group changes to data not owned by the SoR. Furthermore, create initial user entry tools. 8. Create self-service tools allowing end users to modify their directory information (alternate phone, cell phone) and reset their passwords. 9. Integrate all self-service tools into uPortal

11. UCM IT Architecture - Current Manual & Automated Processes IT Staff Calendar VPN Course Mgmt Document Mgmt E-Mail LDAP RADIUS Directory Services Data feeds Look-ups Active Directory Portal Desktops

12. UCM IT Architecture - Goal Outreach DB Student System Payroll Personnel System Alumni System Affiliates DB Identity Management Data feeds Look-ups SIS Self- Service Calendar Remote Access VPN Course Mgmt Document Mgmt E-Mail RADIUS Directory Services Portal Print Servers Desktops Campus Card Library System LDAP Active Directory

13. Our Path Identify the goals Determine benefits and drivers Develop sponsors and key support relationships Develop the project plan including all risks and potential roadblocks. Create the development team and the oversight group. Develop the project requirements and functional specification. Open presentation to entire campus for dissemination, input and support. Determine build vs. buy by evaluating the current product landscape, our resources and time available. Used Sun’s iForce center for evaluation and tested other products Acquire technical systems and setup necessary components. Implement the project. Phase I – Handle our inaugural applicants and provide LDAP logins to Banner Self Service (Mini Phase I – Complete, Full Phase I done 1/31/2005 Phase II – Develop ties to our Payroll Personnel System – 3/15/2005 Phase III – Develop additional ties to Banner for applicant to student transition – 4/1/2005 Phase IV – Create an Affiliates System and link to IDM – 6/1/2005 Communicate constantly with our constituents. Demonstrate value of IDM, demonstrate self-service capabilities, talk about next steps after IDM (WebISO)

14. Implementation - Phase I Develop applicant extract from Banner Import extract into IDM Apply rules to extract and assign UCMNetIDs Populate LDAP Modify Banner to use LDAP logins for Self Service. Create a tool to allow applicant self-claiming of UCMNetIDs After claim inform applicants

15. Lessons Learned Oracle does not support Secure LDAP with third party directory servers. We used TLS as a way to get around this. We used Oracle Wallets We have a tiered SIS implementation and the Wallet needed to sit on the database server. Import root certificate into the Wallet. Self-service web server has issues with setting up the search scope. LDAP log files are our friends. Password gets re-encrypted on submit, so erase and enter password again. Access to qualified SUN resources limited

16. Build vs. Buy Merced currently has a lack of staff resources One full time developer We are 6 months away from needing our IDM system Our list of critical projects needed by opening will take about 11 months Build not an option, buy instead Top products in the Market  Sun Identity Manager, Netegrity Identity Minder, Tivoli Identity Manager

17. Implementation – Phase I to II Develop resources to link to SOR Write business rules in IDM to process SOR data Join the systems to create one master record Convert manual processes to automated ones for provisioning into applications Populate LDAP, AD, Library, Campus Card from IDM Provision accounts into push systems After claim send postcards

18. Phase II – Lessons learned so far Spend as much time as you can going over your business processes with your key users Document BP and present for approval Politics, politics, politics Gaining access to addresses and SSN from data stewards difficult to acquire One way hashing of SSN in the IDM repository reduced data steward’s anxiety Store cross-system information in the IDM repository UCMUniqueID, SSID, EmployeeID, UCMercedNetID, SSN (hashed) Create processes to provide one identifier and request another. SIS group asked for Oracle based lookup WS? We are tied to Sun

19. Info about Identity Manager J2EE based Support for XML, SOAP and Java Repository will be Oracle RDBMS (supports others) Concept of Resource Adapters will allow us to link Sun’s Directory Server Active Directory Flat File However it can connect to any major system through established resources, also custom interfaces can be developed. Supports SAML (Security Assertion Markup Language) and SPML (Services Provisioning Markup Language) Business Process Editor built-in for creating workflows XPRESS  XML based language

20. IDM Continued

22. In XPRESS we can call Java functions and pass arguments from workflow variables accountId email status

23. Quick Demo http://169.236.253.43:8080/idm/

24. Additional Resources The Enterprise Directory Implementation Roadmap http://www.nmi-edit.org/roadmap/directories.html Internet 2 – Middleware http://middleware.internet2.edu/

25. Q&A