1. 1 By San Francisco State University A Case Study Integrated Identity Management System Presentation to 2 nd Annual CSU Secure Identity Management Infrastructure Workshop July 12-14 LAX Crowne Plaza

2. 2 Content Purpose The Project: SFSU Portal, Collaboration and ID Management Requirements and Solution Outline Use Cases and Component Model Technical Specifications Project Roadmap Conclusion

3. 3 Project: Scope of SFSU Portal, Collaboration & ID Management Solution Build an ID Management and SSO solution – Tivoli Directory Server 5.2, Tivoli Directory Integrator 6.0, Tivoli Access Manager 5.2 Build a high availablility Websphere Portal infrastructure - WPS 5.1 Build and migrate to a messaging and collaboration infrastructure - Domino 6.5.4, Sametime 6.5.4, Quickplace 6.5.4 Interconnect new systems, connect to old systems Prepare for IBM Workplace Comply with American Disabilities Act

4. 4 Project: Vision for Identity Management All users automatically gain access to resources based on their role with the university Faculty see Portal areas associated with their college and with general faculty Staff gain access to information pertaining to their department and job role Students find supporting information for their major and their class level progress, and have access to teamrooms for their classes All users automatically be provisioned with accounts in systems for which they are eligible, e.g. mail accounts, IM buddy lists, and team rooms by class roster Security enforced in a seamless and non-intrusive fashion

5. 5 Project: SFSU Portal, Collaboration & ID Management Solution University Projects are „different“ Security and privacy requirements are different from those encountered in the business world User Types and Life Cycle Processes add to the complexity Technology base and existing applications represent significant investment ID Management projects must take these factors into consideration Methodical approach to requirements, design and implementation needed Monolithic products will not fit out-of-the box Integration with projects ranging from ERP (PeopleSoft) and large database systems to open source

6. 6 Project: Conceptual View

7. 7 Project Approach Collaboration between SFSU Team and IBM Team Approach according to the established IBM Method Left-hand column: Successive levels of understanding, design and implementation detail Right-hand column: Specific example for automated group management Repeated validation and adaptation

8. 8 SFSU Requirements and Solution Outline ID Management driven by university processes, not by technical requirements Integrate with existing student and HR management systems Oracle DB is the authoritative source! No modifications should be necessary to CMS (HRMS, FMS) and Student Information Management System (SIMS) Minimize administrative burden Automate processes as much as possible Avoid help desk calls Provide transparent Single Sign-On (SSO) across university systems Provide the best service and greatest ease of use to the users

9. 9 Solution Outline

10. 10 Use Cases and Component Model Use Cases translate business events into technical activities e.g. hiring new staff requires adding them in LDAP and Domino Identification of actors (user types) is extremely important Life cycles of staff, faculty, and students differ significantly Component Model specifies all technical components that support the use cases on a logical basis Important to differentiate between Provisioning and Operations aspects Provisioning: e.g. user rename is reflected in directories, access control lists etc. Operations: e.g. user accesses a protected page of the Portal

11. 11 Use Cases Life Cycle use cases Add user Reactivate user Rename user Add user affiliation Remove user affiliation Temporarily suspend user Remove user Account management use cases Create Domino account Remove Domino account Setup mail forward Revoke mail forward Privacy Opt-In Privacy Opt-Out...

12. 12 Use Cases Subject Area Life Cycle Business Event A user becomes an active University Person (Staff or Faculty), Prospective Student, or External, and is added to the central LDAP directory. Actor(s) University Person, Prospective Student, External Scenario 1: University Person Termination Outcome A new person entry for the user is added to the central LDAP repository in the University Person container, including his name, password, and potentially mail account information. The user is registered as a TAM user. A mail account is created. Use Case Description A new staff or faculty member is hired and entered in the appropriate management systems, and the user chooses a password. Optionally, the user chooses an email account name. The change is written into the change log. ID Management: The new user data triggers the creation of the person entry in IDS LDAP. The appropriate attributes such as EduPersonAffiliation as well as group memberships are set. The user is imported into the TAM user registry; optionally, the account creation process is triggered. Scenario 2: Prospective Student Termination Outcome A new person entry for the user is added to the central LDAP repository in the Prospective container, including his name and password. The user is registered as a TAM user. Use Case Description A site visitor performs one of the actions that renders him a Prospective Student. The user is issued a UID and chooses a password. The change is written into the Oracle change log. ID Management: The new user data triggers the creation of the person entry in IDS LDAP. The appropriate attributes such as EduPersonAffiliation as well as group memberships are set. The user is imported into the TAM user registry.

13. 13 Component Model

14. 14 Component Model IBM Tivoli Directory Server The IBM Directory Server holds user credentials, such as passwords or public keys user attributes groups for authorization information for lookup such as email addresses and telephone numbers Furthermore, it contains information to control identity management with TIM and TAM IBM Tivoli Directory Integrator The IBM Tivoli Directory Integrator plays central role in automatically provisioning and maintaining user records and groups All activities are based on data from SFSU’s operational systems such as Oracle ID Tables, hr_interface and Student tables Target systems include IDS LDAP and Domino Directory

15. 15 Component Model IBM Tivoli Access Manager Webseal Webseal is part of the IBM Tivoli Access Manager suite intercepts all requests for the HTTP protocol authenticates them routes them to the appropriate resource if authorized Webseal reverse proxy acts as a control gateway for the portal infrastructure which IBM Tivoli Access Manager Policy Server TAM Policy Server enables users with various administrative roles to grant, modify and revoke access to IT resources through a central, homogenous interface TAM PS allows for the externalization of access control decisions from applications

16. 16 Technical Specifications – Directory Schema and DIT Directory Schema must accommodate special fields required by a university EduPersonAffiliation is a standard to hold the role of a person, e.g. faculty, staff, or student Directory Information Tree should reflect the different user types such as prospective students, faculty & staff, active students, and alumni Directory Tree should accommodate the various types of groups organizational units attributes, such as major, class standing, international students, etc. lists of classes

17. 17 Technical Specifications – Directory Schema and DIT

18. 18 Technical Specification - Provisioning Provisioning specifications define data sources, e.g. existing database tables data transformations and aggregations that translate business use cases into identity management activities interface between business systems and identity management system processes and tools to control identities in target systems Provisioning specifications also outline availability concepts (clustering, failover, backup & recovery) security and auditing administrative considerations

19. 19 Technical Specifications – Oracle Data Source

20. 20 Technical Specifications – TDI

21. 21 Technical Specifications – TDI Person Processing

22. 22 Technical Specifications – Operational Model Operational Model defines actual placement of logical components on physical hardware instances Collaboration between components very different for provisioning – nearly synchronous management of identities in the backend operations – synchronous control of identity and access for users and entities accessing the systems Availability considerations play key role Clustering key to resilience and fail-over Clustering difficult for provisioning because of data duplication No single point-of-failure allowed

23. 23 Technical Specifications - Provisioning

24. 24 Technical Specifications - Operations

25. 25 Project Roadmap Basic Provisioning to be completed by August to support Messaging migration Complete Provisioning portfolio to be implemented by October to support collaborative Portal pilot Cross-System Single-Sign-On and advanced user self service to be implemented by December

26. 26 Conclusion Integrated Identity Management allows automated and effective management of identities transparent and secure access to protected resources Methodological approach is crucial to map education-specific requirements to implementation control technical complexity Choice of powerful yet flexible components critical Collaboration between university and vendor teams has proven to be essential to bring about desired results Exchange of ideas and collaboration with other campuses welcome!

27. 27 Discussion Presented by Jonathan Rood Associate Vice President Division of Information Technology San Francisco State University For the preparation of the material in this presentation major appreciation is extended to: Hartmut Samtleben, IBM Solution Architect and James Gallece IBM Tivoli Security Services, IT Directory Specialist