case study: university of california, berkeley and san francisco

Open Identity SummitOpen Identity Summit

ForgeRock and UCB/UCSF Next Gen IAM Strategy

Dedra ChamberlinDeputy Director, Identity and Access ManagementUniversity of California, Berkeley and San Francisco

Francesco MeschiaIAM Engineer, UC Berkeley

Mukesh YadavIAM Engineer, UC San Francisco

Open Identity Summit Change to Partner logo/presenter

UCB IAM Then

ID Match and Registry – Homegrown, LDAP as registry

Credential management – Homegrown apps to MIT Kerberos and AD

WebSSO - CAS/Shibboleth

Directory - Oracle DSEE

Provisioning – Homegrown and some Waveset

Central Access Management – Homegrown Coldfusion app


UCSF IAM Then

ID Match and “Registry” – Mainframe

Credential Management – Custom Apps in ITAM

WebSSO - “MyAccess” (Shibboleth + ITAM, ITIM LDAP)

Directory – OpenDS

Provisioning – Very little IBM Tivoli

Central Access Management – One legacy app for managing mainframe-based permissions


Joint Strategy Development

Migrate away from “do-it-all” vendor solutions

Modular architecture – interoperable components

Reduce cost for implementation and support

Avoid vendor lock-in

Leverage efforts across the two campuses

Partner with other higher ed institutions – Community Framework for Educations and Research (CIFER)

http://ciferproject.org


UCB/UCSF NextGen and ForgeRock

UCB

Current: Oracle DSEE > ForgeRock OpenDJ

Future: OpenIdM and AD, Activiti/OpenIdM for access control

UCSF

Recent: IBM Tivoli > OpenIdM and OpenDJ

Future OpenIdM and AD, Activiti/OpenIdM for access control


CalNet goes OpenDJ

Francesco MeschiaCalNet TeamUniversity of California, Berkeley


LDAP @ UC Berkeley The CalNet LDAP directory is the main user information

repository in use at UC Berkeley

3.2M users, ~300 applications using it

Diversified population (faculty, students, staff, various other types of affiliates)

Used as authoritative source of information about campus affiliates

Very heavily used, high uptime required

Various privacy policies in force for different slices of the populations (e.g. FERPA policies for students)


LDAP @ UC Berkeley Originally implemented on Sun Directory Server

Then on Oracle Directory Server Enterprise Edition

Started looking for an alternative in 2011

Easy migration of ACLs was important

Reliable replication equally important

Compatibility with standards and with some proprietary features (e.g. external changelog) was important as well

Vendor and community support highly desired

Generally better performance very important, too!


OpenDJ to the test Functional validation (tests against a number of

representative applications)

Replication and deployment options

Performance tests


From lab to campus Technical features were just one part of the problem

The CalNet LDAP is very heavily used (~300 applications, ~1M binds per day incl. anonymous binds)

Migration downtime hardly an option

“Big Switch Day” also unrealistic


Migration strategy Keep it simple: no major directory tree overhaul, almost

plain 1:1 migration

No “Big-bang-style” rollout

6-month-long “parallel staging”

Both Oracle DSEE and OpenDJ available for production and for QA

OpenDJ synchronized with Oracle DSEE at all times

All applications have 6 months to test and migrate

At the end of the 6-month window, Oracle DSEE is decommissioned


Synchronization strategy Only 11 applications have write access to CalNet LDAP

And 5 of those are CalNet-managed applications

If we schedule the migration of the 11 “writers” at the beginning or at the end of the window, synchronization only needs to be unidirectional

Much easier… and provides a backup plan in case anything goes wrong


Migration


How to synchronize? Our first idea was to use OpenIDM

Initial reconciliation, then synchronization

Turned out CalNet LDAP structure is unsuitable

Too much information other than just users and groups

Hierarchical structure with subentries not really compatible with OpenIDM model


How to synchronize? We ended up writing our own code

We frequently poll Oracle DSEE changelog and carry over changes to OpenDJ

Starting with a fresh LDIF backup

All user attributes

A few operational attributes are actually translated (e.g. resource limits)

We manually translate a few seldom-changed operational attributes (most of all, ACIs)

Closed-loop control with parallel watchdog process


Project status Parallel window closes at the end of July

Applications are currently hitting the QA environment

Users report much better performance

Synchronization was flawless for the last 5 months

Excellent support from ForgeRock during these months

Two replication bugs were found thanks to the sync-and-watchdog feedback loop, and promptly fixed

Looking forward to complete migration!


Migration from IBM to ForgeRock

Mukesh Yadav

UCSF

Project GoalProject Goal

Migrate from ITIM to OpenIDM

Migrate from ITDS to OpenDJ(Credential store)

Migrate from IBM Self Service to home grown Self Service

………..Achieve above all without any user impact

ITIM – IBM Tivoli Identity Manager ITAM –IBM Tivoli Access ManagerITDS – IBM Tivoli Directory Server ITDI – IBM Tivoli Directory Integrator

New ToolsNew Tools

Development tools Groovy on Grails

Twitter bootstrap

Directory Store OpenDJ

Provisioning tool OpenIDM

Migration ChallengesMigration Challenges

Get user passwords from old Directory Server to New(OpenDJ)

Continuous Sync’ing passwords until go live from old to new Directory Server

Get Security questions and answers from old Directory Server to new repository(MySQL) This was big challenge because security answers were hashed with

salt+MD5

Product features we usedProduct features we used

OpenDJ Password policy

Virtual static group

OpenIDM Custom module to generate MD4 password

Policy to remove user password from target if affiliation expires

LiveSync between

ITDS and OpenDJ

EDS to OpenIDM

OpenIDM to Credential Store(OpenDJ)

Product features not usedProduct features not used

Workflow

OOTB UI apps

Old System designOld System design

LDAPCredLDAPCredDB2DB2

WebSEALWebSEAL

SelfServiceSelfService

ITIMITIM

EAI AppEAI App

ITDIITDI

Feed file from

mainframe

Feed file from

mainframe

ITIM LDAPITIM LDAP

VPNVPN

SD AdminSD Admin

UCSF Home grown

UCSF Home grown ForgeRockForgeRock IBMIBM OthersOthers ITIM – IBM Tivoli Identity Manager ITAM –IBM Tivoli Access Manager

ITDS – IBM Tivoli Directory Server ITDI – IBM Tivoli Directory Integrator

AppAppShibShib

Move from old to New(Side by Side)Move from old to New(Side by Side)

LDAPCredLDAPCredDB2DB2


ITIMITIMITDIITDI

Feed file from

mainframe

Feed file from

mainframe

ITIMLDAPITIMLDAP

SD AdminSD Admin

UCSF Home grown



LDAPLDAP

OpenIDMOpenIDM

MySQLMySQL

ApacheApache

Self ServiceSelf Service

EDSEDS

SD AdminSD AdminVPNVPNShibShib

WebSEALWebSEAL

AppApp EAI AppEAI AppVPNVPNShibShib

The DayThe DayWebSEALWebSEAL ApacheApache

EAI AppEAI App Self Service

Self Service SD AdminSD Admin

LDAPCredLDAPCred

openIDMopenIDM

MySQLMySQLEDSEDSLDAPCredLDAPCredDB2DB2


ITIMITIMITDIITDIFeed file

from mainframe

Feed file from

mainframe

ITIM LDAPITIM LDAP

VPNVPN

SD Admin

SD Admin

UCSF Home grown



ShibShibAppApp

The DayThe DayWebSEALWebSEAL ApacheApache

EAI AppEAI App Self Service

Self Service SD AdminSD Admin

LDAPCredLDAPCred

OpenIDMOpenIDM

MySQLMySQLEDSEDSLDAPCredLDAPCredDB2DB2


ITIMITIMITDIITDIFeed file

from mainframe

Feed file from

mainframe

ITIM LDAPITIM LDAP

VPNVPN

SD Admin

SD Admin

UCSF Home grown



ShibShibAppApp

Current StateCurrent State

LDAPCredLDAPCred

OpenIDMOpenIDM

MySQLMySQL

ApacheApacheSelf ServiceSelf Service

EDSEDS

SD AdminSD AdminVPNVPN

UCSF Home grown

UCSF Home grown ForgeRockForgeRock IBMIBM OthersOthers

ShibShib

What I like about these productsWhat I like about these products

Installation Ease of installation

No dependency on SA’s for installing any dependencies

Data Sync’ing is really easy

Support If support engineers cannot reproduce a reported issue, I can zip my

OpenIDM directory and ftp to them.

DemoDemo

Self service Self register

Change Password

Reset security questions

Admin tool Reset password

Suspend Account

Create temporary password

Q & AQ & A

case study: university of california, berkeley and san francisco

Technology

rw app nro app

ro app n app

legacy app

ewriter app

open identity summit

ro app ndseeldap

rw app nopendjnds

esync processwriter