Page tree
Skip to end of metadata
Go to start of metadata

Discussion around migrating user data during login time based on - http://www.theidentitycookbook.com/2015/06/seamless-user-profile-migration-from.html

  • User migration of any AM/DJ deployment architecture

  • Key challenges
    • migrate users from legacy SQL repo's such as MSSQL, MySQL, Orac
    • migrate users from home grown stores that were never built for scale/flexibility/security
    • migrate users from NoSQL due to dirty-data
    • upgrade password storage algo - eg SHA1 to salted SHA256/PBKDF2
    • only migrate active users
    • don't want to reset users password
    • don't want to interrupt users login journey

  • Can leverage out of the box authentication modules to integrate with existing JDBC/SQL credentials stores
  • JDBC model has a nice plug point for integrating with hashing algorithms - allows hash compare, taking entered clear text password, running through the transform plugin in order to generate hash value.  The more complex the hash, the more effort needed when building the plugin, but the option is there
  • Idea is to create a clean DJ user profile store which will be new user store
  • Point AM to existing credential store first
  • User logs in and AM looks in DJ first - as user won't exist, next step is to leverage existing credential store
  • If authentication successful, AM can be configured to dynamically create a profile in DJ
  • During authentication can also "capture" the clear text entered password, in order to store in DJ
  • IDM can then be used post login, to enrich the basic profile that DJ creates, pulling in data from multiple stores if necessary
  • Next time user logs in, AM checks DJ first and as user has been migrated, we use DJ as credential store
  • Password storage can be upgraded during this process
  • DJ supports a range of password storage options - http://www.theidentitycookbook.com/2015/06/password-storage-in-opendj.html
  • Modern algorithms are supported - new ones can be coded
  • Benefits of migration
    • reduced license costs by only migrating active users - not all users
    • close down legacy stores after, say, 90 days
    • algorithm upgraded to more secure/modern version


  • No labels