1

By San Francisco State University A Case StudyIntegrated Identity Management System

Presentation to2nd Annual

CSU Secure Identity Management Infrastructure WorkshopJuly 12-14

LAX Crowne Plaza

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

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

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

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

Project: Conceptual View

pSeries 650 8Way pSeries 650 8Way

SAN

Legacy Systems

Legacy Systems

SFSU ArchitectureOperational Overview

Lotus

WebSphere

Tivoli

IHS2

LPAR2

IHS1

WPS1/WAS1

LPAR2

LPAR1

LPAR3

Oracle

LPAR1

LPAR3

Oracle

WPS2/WAS2

TDI / TIM Agents

xSeries 335 2Way

Backup Solution

TSM Server

TIM

pSeries 630 4Way

TAM Policy Server

LPAR1

LPAR2

TDS (Slave)

pSeries 630 4Way

TIM

TAM Policy Server

LPAR1

LPAR2

TDS (Master)

pSeries 615 1Way

TAM WebSeal

pSeries 615 1Way

TAM WebSeal

BigIPSprayers

Mail 6a

Mail 2a

Mail 3a

Mail 4a

Mail 5a

pSeries 650 8Way

Mail 6b

Mail 2b

Mail 3b

Mail 4b

Mail 5b

pSeries 650 8Way

QuickPlace3

QuickPlace4

LPAR1

LPAR2

pSeries 630 4Way

Domino Dev Server

IDI Dev Server

QuickPlace1

QuickPlace2

LPAR1

LPAR2

pSeries 630 4Way

Domino Test Server

TAM WebSeal

Test

DevTest

Mail 1a

pSeries 550 4Way

Mail 1b

pSeries 550 4Way

pSeries 650 8Way

LPAR2LPAR1

HTTP1

Oracle

HTTP2

WPS2/WAS2

LDAP

WPS1/WAS1

TAM Policy Test

xSeries 335 2Way

TDI / TIM Agents

SameTime1Instant

Messaging

Sametime2 Web

Conferencing

LPAR1LPAR2

pSeries 650 8Way

SMTP1

DominoAdmin Server

IDI

SameTime3Instant

Messaging

Sametime4 Web

Conferencing

LPAR2

pSeries 650 8Way

LPAR1

SMTP2

DominoHub Server

IDI

Portal Dev Server

pSeries 630 4Way

Oracle / TDS Dev Server

LPAR1

LPAR2

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

Iterative Process

Current EnvironmentStructure and content of

Oracle ID tables

RequirementsGroup with all faculty

members for WPS

Component ModelInteraction of Oracle ID tables, IDI, IDS, WPS

Component Specification

Definition of automatic groups in IDS

Definition of assembly line in IDI

Definition of Oracle trigger

Operational ModelDefinition of IDI and IDS

server placement

Configuration of IDI, IDS, assembly lines, Oracle

triggers

Configuration Parameters

Build Procedures Install & configure IDI, IDS, assembly lines,

Oracle triggers on designated servers

Test Specifications Create test cases based on Use Cases to verify

solution

Micro Design

Use CasesCreate/modify automatic

group member list

Production Implementation

Tivoli Directory Server

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

Solution Outline

SFSU Databases

IDS LDAP

Domino Messaging

TAM Policy Server

Magic

Student InformationManagement System

Human ResourcesManagement System

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

Use Cases

Primary Actor

University Person

Staff

Faculty

CEL Faculty

Site Visitor

Alumnus

Prospective Student

Student

Life Cycle

Manual Groups

Membership & Attribute

Account Management

Credential

Migration

External

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

Use CasesSubject 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

Component Model

Client Tier

Provisioning Tier

Directory TierServices TierAccess Control Tier

Router

Web Browser

Notes Client

POP/IMAP Client (incl. PDA)

WebSeal IDS LDAP

Domino Security

(Net, Server, DB ACL)

Domino Directory

Domino CAADT/AdminP

IDI

WMM

AFS

PeopleSoft HRMS/FMS

Oracle Forms

Component Overview for Identity Management Release 1

Oracle ID Tables

Kerberos DB

PL/SQL Web App AC

Application Specific AC

Access

Auth

DirData

Data

New Component

Existing Component

Sendmail

RADIUS

Networking VPN

WirelessModemPool

Kerberos Access

Oracle / PeopleSoft Accounts

Team Workplace

Lotus IMWC (Sametime)

Lotus IMWC (Sametime)

Security

WPS

Domino Messaging

PL/SQL Web Apps

Lotus IMWC (Sametime)

TAM Policy Server

University Data Tier

Oracle Database

hr_interfaceUser Table

PeopleSoft Data

Account Generation

Password Set / Reset

stu_xxxGroup Table

Transaction Control

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

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

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

Technical Specifications – Directory Schema and DIT

o=sfsu.edu

ou=universitypersons

ou=alumni

ou=external

ou=prospective

ou=administrators

o=sfsu.edu

ou=classes

ou=orggroups

ou=groups

ou=20051

ou=20054

ou=20053

ou=20052

Top

Person

inetOrgPerson

eduPerson

sfsuPerson

ibm-dynamicMember

organizationalPerson

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

Technical Specifications – Oracle Data Source

IDI

Person_Processor_AL

Person_Add/Mig_AL

Person_Update_AL

Person_Susp/React_AL

Person_Delete_AL

Person_ChangeAffiliation_AL

Person_Dom_Stud_AL

Person_DominoAdd/Mig_AL

Person_DominoAdd/Mig_AL

Group_Processor_AL

Group_Add_AL

Group_Remove_AL

Group_Membership_AL

APROD

IDS LDAP

Domino Messaging

TAM Policy Server

User Change Table

Group Change Table

Group Shadow

Transaction Control

Queue Control

User Change Log

Entry Queue

Group Change Log

Person Shadow

Trigger

Trigger

Build/Update Person

Transactions

Build/Update Group

Transactions

Sendmail

CMT

SIMS

Migration WebSIte

HRMS

Password Change

20

Technical Specifications – TDI

IDI

IDI

APROD

IDS LDAP

Domino Messaging

TAM Policy Server

User Change Table

Group Change Table

Group Shadow

Transaction Control

Queue Control

User Change Log

Entry Queue

Group Change Log

Person Shadow

Trigger

Trigger

Build/Update Person Transac

tions

Build/Update Group

Transactions

Sendmail

CMT

SIMS

Migration

WebSIte

HRMS

Password

Change

Person_Processor_AL

Person_Add/Mig_AL

Person_Update_AL

Person_Susp/React_AL

Person_Delete_AL

Person_ChangeAffiliation_AL

Person_Dom_Stud_AL

Person_DominoAdd/Mig_AL

Person_DominoAdd/Mig_AL

Group_Processor_AL

Group_Add_AL

Group_Remove_AL

Group_Membership_AL

21

Technical Specifications – TDI Person Processing

Domino_AL_Caller

Domino_AL_Caller

OracleCL_Person_Input

LDAP_Person_Update

LDAP_Group_Lookup

TAM_Person_Delete

OracleCL_Person_Output

LDAP_Group_Iterator

LDAP_Person_Delete

LDAP_Person_Lookup

TAM_Person_Susp/React

Domino_Person_Susp/React

Person_AL_Caller

LDAP_Person_Add

TAM_Person_Import

Domino_SOAP_Dispatcher

HTTP_SOAP_Server

Domino_Person_Delete

Domino_Person_Update

Domino_Person_Update_Config

TAM_Person_Update

Person_Processor_AL

Person_Add/Mig_AL

Person_Update_AL

Person_Susp/React_AL Person_Delete_AL

TAM_Person_Delete

LDAP_Group_Iterator

LDAP_Person_Update

TAM_Person_Import

Person_ChangeAffiliation_AL

OracleCL_Person_Output

Domino_Person_Add

Domino_Person_Add_Config

CMT_MigDB_Output

CMT_PWFile_Output

Sendmail_ForwardFile_Output

Person_Dom_Stud_AL

Person_DominoAdd/Mig_AL

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

Technical Specifications - Provisioning

Mail 1b 4 CPU16 GB RAM

Mail 1a 4 CPU16 GB RAM

SMTP1

DominoAdmin Server

TDI 1

CMT

4 CPU8 GB RAM

SMTP2

DominoHub Server

TDI 2

Sendmail Server

Oracle Database

Server

Mail 2a

Mail 3a

Mail 4a

Mail 5a

Mail 6a

TDI 3

8 CPU16 GB RAM

Mail 2b

Mail 3b

Mail 4b

Mail 5b

Mail 6b

TDI 4

8 CPU16 GB RAM

TDS LDAP (Master)

TAM Policy Server

2 CPU4 GB RAM2 x 36GB

4 CPU8 GB RAM

2 CPU4 GB RAM

tim02.sfsu.edutamps02.sfsu.edu2 CPU4 GB RAM2 x 36GB

TDS LDAP (Replica)

cetus1.sfsu.edu

TAM Policy Server / ACLd

tds02.sfsu.edu2 CPU4 GB RAM

tamps02.sfsu.edu2 CPU4 GB RAM2 x 36GB

Mail 1a 4 CPU16 GB RAM

SMTP1

DominoAdmin Server

TDI 1

CMT

4 CPU8 GB RAM

SMTP2

DominoHub Server

TDI 2

Sendmail Server

Oracle Database

Server

Mail 2a

Mail 3a

Mail 4a

Mail 5a

Mail 6a

TDI 3

8 CPU16 GB RAM

Mail 2b

Mail 3b

Mail 4b

Mail 5b

Mail 6b

TDI 4

8 CPU16 GB RAM

TDS LDAP (Master)

TAM Policy Server

2 CPU4 GB RAM2 x 36GB

4 CPU8 GB RAM

2 CPU4 GB RAM

tim02.sfsu.edutamps02.sfsu.edu2 CPU4 GB RAM2 x 36GB

TDS LDAP (Replica)

TAM Policy Server / ACLd

2 CPU4 GB RAM

2 CPU4 GB RAM2 x 36GB

24

Technical Specifications - Operations

RouterWeb Browser

tim01.sfsu.edutamps01.sfsu.edu2 CPU4 GB RAM2 x 36GB

Mail 2a

Mail 3a

Mail 4a

Mail 5a

Mail 6a

TDI 3

8 CPU16 GB RAM

Mail 2b

Mail 3b

Mail 4b

Mail 5b

Mail 6b

TDI 4

8 CPU16 GB RAM

HTTP1

WPS1/WAS1

Oracle

2 CPU2 GB RAM

4 CPU8 GB RAM

2 CPU6 GB RAM

HTTP2

WPS2/WAS2

Oracle

2 CPU2 GB RAM

4 CPU8 GB RAM

2 CPU6 GB RAM

TAM WebSeal

1 CPU2 GB RAM

TAM WebSeal 1 CPU

2 GB RAM

tim02.sfsu.edutamps02.sfsu.edu2 CPU4 GB RAM2 x 36GB

TDS LDAP (Replica)

TAM Policy Server / ACLd

2 CPU4 GB RAM

2 CPU4 GB RAM2 x 36GB

Mail 1a 4 CPU16 GB RAM

Mail 1b 4 CPU16 GB RAM

TDS LDAP (Master)

TAM Policy Server

2 CPU4 GB RAM

2 CPU4 GB RAM2 x 36GB

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

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

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