Jerry Waldorf's Blog

Identity Synchronization with SPMLv2

A common use case in the Identity Management universe is the synchronization of identity information between different applications. Sometimes this involves synchronizing information between a Human Resources Application and a Directory for example SAP HR to Microsoft Active Directory. When a new employee is added to the SAP HR Application a new user account needs to be created in the Active Directory. And when that employee's status in the SAP HR Application is changed to terminated the user account needs to be deleted from the Active Directory.

Another use case is the Password Synchronization scenario. If the user changes her password in one Directory we would like her password to be updated in the other applications that she has accounts in. For example, if the user changes her password in Active Directory then we would like her password to also be changed to the same value in the RACF system on z/OS.

There are a number of architectures that can solve these use cases. There are pull based architectures and push based architectures. I will try to go through each of these to describe the different possibilities. In general push based approaches tend to work well when you have few destinations and they are relatively static in number. Pull based approaches tend to work well when you have many subscribers and you don't know about the number of subscribers that will exist as they tend to come and go. Pull based models work very well in the web 2.0 world as demonstrated by the popularity of things link RSS and atom.

For the SAP HR --> Active Directory use case we can use the push model:

In this case our SPMLv2 Gateway will poll the SAP system checking to see if there are any new employees that have been added. It uses the BAPI/JCO calls to do this. If the SPMLv2 Gateway finds a new employee it would invoke the add operation over SPMLv2/HTTP to the Identity Manager which would in turn invoke the SPMLv2 add operation on the SPMLv2 Gateway that would add the new user to Active Directory using the LDAP transport to MS AD.

For the SAP HR --> Active Directory use case we can also use the pull model:

In this case our SPMLv2 Gateway will do the same polling to the SAP system as describe above. It will then store the changes into a local database that is made part of the SPMLv2 Gateway. All of these changes would be stored with a timestamp recording when the change was made. Now on a polling interval specified in the Identity Manager's configuration the IdM Server would call the SPMLv2 updates operation on the SPMLv2 Gateway retrieving all of the updates to employees (additions and modifications) and then make the corresponding add/modify/delete operation over SPMLv2 to the Gateway which would invoke the appropriate operation on the MS AD using LDAP. The same as in the use case above.

For the Active Directory password synchronization use case things are a little more complicated because we need to get the password changes out of Microsoft Active Directory. And because Active Directory does not store the password (it only stores a one way hash of the password) you cannot get access to it over LDAP. You need an agent that runs natively on Windows to capture the Password changes. And the agent must run on all of the domain controllers, so you will need one Gateway and potentially many agents all talking to that one gateway. So unlike the use cases above where you only need a Gateway, in this case you need to have an Agent on each domain controller and one Gateway to receive the information from all of them.

For the AD --> RACF using the push model:

In this use case the password Agent would let the Gateway know via a proprietary protocol (maybe over HTTPS) that a users password is being reset. The Gateway would query Active Directory for any additional information about the user needed and then make an SPMLv2 changePassword call to the Identity Manager which would then in turn invoke the SPMLv2 Gateway with the changepassword operation which would use the TN3270 screen scraper adapter to change the password in the legacy application.

For the AD --> RACF using the pull model:

In this use case the same flow of control would be done from the agent to the gateway. The gateway would store these changes locally in an updates database. All of these changes would be stored with a timestamp recording when the change was made. Now on a polling interval specified in the Identity Manager's configuration the IdM Server would call the SPMLv2 updates operation on the SPMLv2 Gateway retrieving all of the updates to users (additions and modifications as well as password changes) and then make the corresponding add/modify/delete/changePassword operation over SPMLv2 to the Gateway which would invoke the appropriate operation on the RACF system using TN3270. The same as in the use case above.

Posted at 12:20PM Aug 13, 2008 by Jerry Waldorf in Sun  |  Comments[2]