Case Study: University of California, Berkeley and San Francisco
Upcoming SlideShare
Loading in...5
×
 

Case Study: University of California, Berkeley and San Francisco

on

  • 1,314 views

Presented by Dedra Chamberlin Deputy Director, Identity and Access Management University of California, Berkeley and San Francisco, Francesco Meschia IAM Engineer, UC Berkeley and Mukesh Yadav, IAM ...

Presented by Dedra Chamberlin Deputy Director, Identity and Access Management University of California, Berkeley and San Francisco, Francesco Meschia IAM Engineer, UC Berkeley and Mukesh Yadav, IAM Engineer, UC San Francisco at ForgeRock Open Stack Identity Summit, June 2013

Statistics

Views

Total Views
1,314
Views on SlideShare
1,265
Embed Views
49

Actions

Likes
0
Downloads
34
Comments
0

1 Embed 49

http://www.scoop.it 49

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Case Study: University of California, Berkeley and San Francisco Case Study: University of California, Berkeley and San Francisco Presentation Transcript

  • Open Identity SummitOpen Identity SummitForgeRock and UCB/UCSFNext Gen IAM StrategyDedra ChamberlinDeputy Director, Identity and Access ManagementUniversity of California, Berkeley and San FranciscoFrancesco MeschiaIAM Engineer, UC BerkeleyMukesh YadavIAM Engineer, UC San Francisco
  • Open Identity Summit Change to Partner logo/presenterUCB IAM Then ID Match and Registry – Homegrown, LDAP as registry Credential management – Homegrown apps to MIT Kerberosand AD WebSSO - CAS/Shibboleth Directory - Oracle DSEE Provisioning – Homegrown and some Waveset Central Access Management – Homegrown Coldfusion app
  • Open Identity Summit Change to Partner logo/presenterUCSF 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 managingmainframe-based permissions View slide
  • Open Identity Summit Change to Partner logo/presenterJoint 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 – CommunityFramework for Educations and Research (CIFER)http://ciferproject.org View slide
  • Open Identity Summit Change to Partner logo/presenter
  • Open Identity Summit Change to Partner logo/presenter
  • Open Identity Summit Change to Partner logo/presenterUCB/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
  • Open Identity SummitOpen Identity SummitCalNet goes OpenDJFrancesco MeschiaCalNet TeamUniversity of California, Berkeley
  • Open Identity Summit Change to Partner logo/presenterLDAP @ UC Berkeley The CalNet LDAP directory is the main user informationrepository in use at UC Berkeley 3.2M users, ~300 applications using it Diversified population (faculty, students, staff, variousother types of affiliates) Used as authoritative source of information about campusaffiliates Very heavily used, high uptime required Various privacy policies in force for different slices of thepopulations (e.g. FERPA policies for students)
  • Open Identity Summit Change to Partner logo/presenterLDAP @ 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 proprietaryfeatures (e.g. external changelog) was important aswell Vendor and community support highly desired Generally better performance very important, too!
  • Open Identity Summit Change to Partner logo/presenterOpenDJ to the test Functional validation (tests against a number ofrepresentative applications) Replication and deployment options Performance tests
  • Open Identity Summit Change to Partner logo/presenterFrom 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
  • Open Identity Summit Change to Partner logo/presenterMigration strategy Keep it simple: no major directory tree overhaul, almostplain 1:1 migration No “Big-bang-style” rollout 6-month-long “parallel staging” Both Oracle DSEE and OpenDJ available forproduction 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 isdecommissioned
  • Open Identity Summit Change to Partner logo/presenterSynchronizationstrategy 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 thebeginning or at the end of the window, synchronizationonly needs to be unidirectional Much easier… and provides a backup plan in caseanything goes wrong
  • Open Identity Summit Change to Partner logo/presenterMigrationDSEEldap.b.eOpenDJnds.b.eSync ProcessApp 2Writer App 1Writer App 2R/W App nR/O App 1R/O App nDSEEldap.b.eOpenDJnds.b.eSync ProcessR/O App nWriter App 1Writer App 2R/W App nR/O App 1R/O App nDSEEldap.b.eOpenDJnds.b.eSync ProcessApp 2Writer App 1Writer App 2R/W App nR/O App 1R/O App n App 2DSEEldap.b.eOpenDJnds.b.eSync ProcessWriter App 1Writer App 2R/W App nR/O App 1App 2R/O App nDSEEldap.b.eOpenDJnds.b.eSync ProcessWriter App 1R/O App 1App 2R/O App nWriter App 2R/W App nOpenDJnds.b.eldap.b.eWriter App 1R/O App 1App 2R/O App nWriter App 2R/W App n
  • Open Identity Summit Change to Partner logo/presenterHow 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 andgroups Hierarchical structure with subentries not reallycompatible with OpenIDM model
  • Open Identity Summit Change to Partner logo/presenterHow to synchronize? We ended up writing our own code We frequently poll Oracle DSEE changelog and carryover 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-changedoperational attributes (most of all, ACIs) Closed-loop control with parallel watchdog process
  • Open Identity Summit Change to Partner logo/presenterProject 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!
  • Open Identity SummitOpen Identity SummitMigration from IBM toForgeRockMukesh YadavUCSF
  • 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 impactITIM – 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 newDirectory Server Get Security questions and answers from old Directory Serverto new repository(MySQL) This was big challenge because security answers were hashed withsalt+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 designLDAPCredLDAPCredDB2DB2WebSEALWebSEALSelfServiceSelfServiceITIMITIMEAI AppEAI AppITDIITDIFeed filefrommainframeFeed filefrommainframeITIM LDAPITIM LDAPVPNVPNSD AdminSD AdminUCSF HomegrownUCSF Homegrown ForgeRockForgeRock IBMIBM OthersOthersITIM – IBM Tivoli Identity Manager ITAM –IBM Tivoli Access ManagerITDS – IBM Tivoli Directory Server ITDI – IBM Tivoli Directory IntegratorAppAppShibShib
  • Move from old to New(Side by Side)Move from old to New(Side by Side)LDAPCredLDAPCredDB2DB2SelfServiceSelfServiceITIMITIMITDIITDIFeed filefrommainframeFeed filefrommainframeITIMLDAPITIMLDAPSD AdminSD AdminUCSF HomegrownUCSF Homegrown ForgeRockForgeRock IBMIBM OthersOthersITIM – IBM Tivoli Identity Manager ITAM –IBM Tivoli Access ManagerITDS – IBM Tivoli Directory Server ITDI – IBM Tivoli Directory IntegratorLDAPLDAPOpenIDMOpenIDMMySQLMySQLApacheApacheSelf ServiceSelf ServiceEDSEDSSD AdminSD AdminVPNVPNShibShibWebSEALWebSEALAppApp EAI AppEAI AppVPNVPNShibShib
  • The DayThe DayWebSEALWebSEAL ApacheApacheEAI AppEAI AppSelfServiceSelfServiceSD AdminSD AdminLDAPCredLDAPCredopenIDMopenIDMMySQLMySQLEDSEDSLDAPCredLDAPCredDB2DB2SelfServiceSelfServiceITIMITIMITDIITDIFeed filefrommainframeFeed filefrommainframeITIMLDAPITIMLDAPVPNVPNSDAdminSDAdminUCSF HomegrownUCSF Homegrown ForgeRockForgeRock IBMIBM OthersOthersITIM – IBM Tivoli Identity Manager ITAM –IBM Tivoli Access ManagerITDS – IBM Tivoli Directory Server ITDI – IBM Tivoli Directory IntegratorShibShibAppApp
  • The DayThe DayWebSEALWebSEAL ApacheApacheEAI AppEAI AppSelfServiceSelfServiceSD AdminSD AdminLDAPCredLDAPCredOpenIDMOpenIDMMySQLMySQLEDSEDSLDAPCredLDAPCredDB2DB2SelfServiceSelfServiceITIMITIMITDIITDIFeed filefrommainframeFeed filefrommainframeITIMLDAPITIMLDAPVPNVPNSDAdminSDAdminUCSF HomegrownUCSF Homegrown ForgeRockForgeRock IBMIBM OthersOthersITIM – IBM Tivoli Identity Manager ITAM –IBM Tivoli Access ManagerITDS – IBM Tivoli Directory Server ITDI – IBM Tivoli Directory IntegratorShibShibAppApp
  • Current StateCurrent StateLDAPCredLDAPCredOpenIDMOpenIDMMySQLMySQLApacheApacheSelf ServiceSelf ServiceEDSEDSSD AdminSD AdminVPNVPNUCSF HomegrownUCSF Homegrown ForgeRockForgeRock IBMIBM OthersOthersShibShib
  • 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 myOpenIDM 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