On September this year we embarked on a unique event – the gradual transition of Identity Management by former Sun to our own product, Identity Management CzechIdM. The product of the former Sun (today’s official name is the Oracle Waveset) is not longer a new owner by Oracle, further developed or supported. One of our customers has therefore decided to migrate to a fully supported CzechIdM.
Customer’s environment is quite extensive and SunIdM it serves a wide range of systems, we found ourselves as a major challenge: how to convert existing solutions under complicated new product without downtime and minimal change to the user? The answer is very gradual migration project: both Identity Management “you thread” and gradually we combine different systems for full operation. In his article, I’ll introduce you to the architecture and highlight solutions to some of the difficulties with which we encounter during implementation.
The basic idea
Demanding analysis led to the idea of both Identity Management concatenate. Install CzechIdM alongside the old Oracle Waveset and connect the both that will be one to the second one common end system. Indeed, when we provide two-way data flow between the two identity management system may one at a time to disconnect from Waveset and switching for full operation on CzechIdM.
The source of all identities for Waveset before migrating the personnel system Navision. The new installation will CzechIdM throughout the migration source Waveset. Only when they reconnected all systems except for personal, be transferred to the new version of Navision synchronization of identities and Waveset we can definitely off.
For security reasons, among them Waveset and CzechIdM do not communicate directly; into their midst, we put MySQL database synchronization. For Waveset is a common the ending system in which on-line exports the necessary user data for CzechIdM is the authoritative source.
Synchronizing organizational structure
In addition to information about the identity of Waveset we do CzechIdM had to convert the organizational structure. Finally, we decided to “synchronize together with identities”. We assume that the empty organization is important. Thanks to make do with identity information: organization, create the first identity, which is inside, and erase it with the last deleted identity.
During the gradual migration we encountered the following problem: some permissions and roles relate to systems that have been converted into CzechIdM, some of the systems are still connected to SunIdM. At the same time it must be possible all the roles and all rights to manage through a single administrative interface, which should be in the Waveset interface.
Therefore, in synchronization databases also store information about the assigned roles in Waveset. Some role in Waveset this applies to the systems that the Waveset long are not connected. This do not mind – about which user has assigned role, is propagated via the synchronization database to CzechIdM where the same role already assigned automatically and without approval.
The usual procedure
The usual procedure for the transfer of the current system we direct in the following six steps:
- Implementation connector CzechIdM
- Transfer of related structures roles and permissions to CzechIdM
- Transfer of business processes associated with the system
- Enrichment synchronizing database with the necessary identity information
- Pairing existing accounts with CzechIdM.
- Disconnect the system from Waveset.
In the article I outlined the problems of gradual migration from (Sun IdM) Oracle Waveset to CzechIdM. If you are interested in this topic and want to learn more, or stand before a similar challenge and you need help, email me at email@example.com!