Case Study: University of California, Berkeley and San Francisco

Open Identity SummitOpen Identity Summit
ForgeRock and UCB/UCSF
Next Gen IAM Strategy
Dedra Chamberlin
Deputy Director, Identity and Access Management
University of California, Berkeley and San Francisco
Francesco Meschia
IAM Engineer, UC Berkeley
Mukesh Yadav
IAM 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 Meschia
CalNet Team
University 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
DSEE
ldap.b.e
OpenDJ
nds.b.eSync Process
App 2
Writer App 1
Writer App 2
R/W App n
R/O App 1
R/O App n
DSEE
ldap.b.e
OpenDJ
nds.b.eSync Process
R/O App n
Writer App 1
Writer App 2
R/W App n
R/O App 1
R/O App n
DSEE
ldap.b.e
OpenDJ
nds.b.eSync Process
App 2
Writer App 1
Writer App 2
R/W App n
R/O App 1
R/O App n App 2
DSEE
ldap.b.e
OpenDJ
nds.b.eSync Process
Writer App 1
Writer App 2
R/W App n
R/O App 1
App 2
R/O App n
DSEE
ldap.b.e
OpenDJ
nds.b.eSync Process
Writer App 1
R/O App 1
App 2
R/O App n
Writer App 2
R/W App n
OpenDJ
nds.b.e
ldap.b.e
Writer App 1
R/O App 1
App 2
R/O App n
Writer App 2
R/W App n

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 Manager
ITDS – 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
LDAP
Cred
LDAP
Cred
DB2DB2
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
AppApp
ShibShib

Move from old to New(Side by Side)Move from old to New(Side by Side)
LDAP
Cred
LDAP
CredDB2DB2
ITIMITIMITDIITDI
Feed file
from
mainfra
me
Feed file
from
mainfra
me
ITIM
LDAP
ITIM
LDAP
SD AdminSD Admin
UCSF Home
grown
UCSF Home
LDAPLDAP
OpenIDMOpenIDM
MySQLMySQL
ApacheApache
Self ServiceSelf Service
EDSEDS
SD AdminSD Admin
VPNVPNShibShib
WebSEALWebSEAL
AppApp EAI AppEAI App
VPNVPNShibShib

The DayThe Day
WebSEALWebSEAL ApacheApache
EAI AppEAI App
Self
Service
Self
Service
SD AdminSD Admin
LDAP
Cred
LDAP
Cred
openIDMopenIDM
MySQLMySQLEDSEDSLDAP
Cred
LDAP
Cred
DB2DB2
ITIMITIMITDIITDI
Feed file
from
mainframe
Feed file
from
mainframe
ITIM
LDAP
ITIM
LDAP
VPNVPN
SD
Admin
SD
Admin
UCSF Home
grown
UCSF Home
ShibShib
AppApp

The DayThe Day
WebSEALWebSEAL ApacheApache
EAI AppEAI App
Self
Service
Self
Service
SD AdminSD Admin
LDAP
Cred
LDAP
Cred
OpenIDMOpenIDM
MySQLMySQLEDSEDSLDAP
Cred
LDAP
Cred
DB2DB2
ITIMITIMITDIITDI
Feed file
from
mainframe
Feed file
from
mainframe
ITIM
LDAP
ITIM
LDAP
VPNVPN
SD
Admin
SD
Admin
UCSF Home
grown
UCSF Home
ShibShib
AppApp

Current StateCurrent State
LDAP
Cred
LDAP
Cred
OpenIDMOpenIDM
MySQLMySQL
ApacheApache
Self ServiceSelf Service
EDSEDS
SD AdminSD Admin
VPNVPN
UCSF Home
grown
UCSF Home
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

Case Study: University of California, Berkeley and San Francisco

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Case Study: University of California, Berkeley and San Francisco

Ähnlich wie Case Study: University of California, Berkeley and San Francisco (20)

Mehr von ForgeRock

Mehr von ForgeRock (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Case Study: University of California, Berkeley and San Francisco