Sun Identity Manager to Oracle Identity Manager Migration
This post is a work in progress ....
In this post I will talk about the migration from Sun Identity Manager to Oracle Identity Manager Environment.
The target OIM version which I am considering is 11g R2 PS2 (11.1.2.2.0) which is most recent as of this writing.
Well to start off with let just consider a feature by feature comparison of the 2 products.
Let us first look at what all things need to be migrated if we want to move from Sun IdM to Oracle IdM.
Data - Users, Orgs, Roles, Audit Data, Operational Data, Passwords, Challenge Questions & Answers
Configuration - Resources, Connectors, Workflows, Forms, UI, Password Polices, Access Policies, XPRESS Code,
Here is a Diagram of Sun Identity Manager Component Architecture
and here is a diagram of OIM component architecture
I will break down the different development artifacts and way to go about it while doing the migration
In this post I will talk about the migration from Sun Identity Manager to Oracle Identity Manager Environment.
The target OIM version which I am considering is 11g R2 PS2 (11.1.2.2.0) which is most recent as of this writing.
Well to start off with let just consider a feature by feature comparison of the 2 products.
Let us first look at what all things need to be migrated if we want to move from Sun IdM to Oracle IdM.
Data - Users, Orgs, Roles, Audit Data, Operational Data, Passwords, Challenge Questions & Answers
Configuration - Resources, Connectors, Workflows, Forms, UI, Password Polices, Access Policies, XPRESS Code,
Here is a Diagram of Sun Identity Manager Component Architecture
and here is a diagram of OIM component architecture
I will break down the different development artifacts and way to go about it while doing the migration
- UI - SIM uses jsp as its view technology. It was easier so complicated UI could be built as the developer saw it fit. OIM uses adf and far more complex way of doing the UI requirements.
- Approval Workflow - SIM used xpress based workflows where UI can be embedded directly into workflows and you could achieve any flow by coding for it. OIM has few different component like SOA composite, notification, escalation reminders etc but few things like form cannot be directly inserted wherever we feel like to present customized look and feel. There are lot of out-of-the-box which we will have to use when they are migrated to OIM
- Forms in SIM are a way to present data to end user using html components. There are lot of triggers which can attached to create javascript like affects.
- Access Policies - There is no direct equivalents in SIM for Access Policy in OIM. though resource can be directly assigned to roles for role based access policy.
- Rules - Role Membership rules are missing in SIM though similar equivalents can be developed.
- Roles - In SIM there are various catagories of roles but essentially they achieve the same goal. SIM roles can be directly mapped to OIM roles.
- Resources vs. Application Entities - In SIM a resource modeled a physical system with connection details where the provisioning and reconciliation operations were performed. Approval and Provisioning workflows worked in top of these. In OIM application instances which consists of RO + ITR represented both but within AIs to achieve that effect.
- Connectors - SIM connectors though java based were created with SIM framework in mind wherein the CRUD events were triggered based on standardized naming convention. In OIM, the connector operations are mapped individually wherein what class method will be triggered on these CRUD operations were configured regardless of any strict naming convention. The connector classes are ordinary java classes with 1to1 mapping of an event to a method. SIM connector classes implements and extends certain top level classes so that method could be automatically triggered based on event type. SIM Connectors cannot be used when migrating to OIM and new Out-of-the-box oim connectors needs to be used.
- Data Access - In SIM target end systems data of the users are fetched in real time but in OIM the data that is used for display is what was last stored during provisioning or reconciliation operation in the process forms.
- Support for attestation - Present in OIM not in SIM.
- Deferred Task Scanner was feature that allowed to trigger any kind of workflow on a later date one-time or a regular basis in SIM. To achieve something similar we have create scheduled job and task in OIM.
- Views - SIM offered views of all standard entities like user, org, roles etc which can be checked out and data can be accessed in forms, emails or any business workflows. OIM offers API to do something similar.
- APIs - Most of programming activities in SIM are done via XPRESS code but in OIM we have to make of standard java api to accomplish these.
- Reports - SIM offered out-of-the-box reports within the product itself and also customized reports could be developed without requiring any additional product. OIM 11g uses BI Publisher to view all out-of-the-box reports or to develop custom ones.
- Approval Engine - In SIM the approval engine is within the product itself but OIM 11g requires SOA Server as its approval engine.
- There is no equivalent of Sandbox feature for UI changes within OIM 11g to SIM.
- All the connectors to end systems were self contained within SIM and did not require any additional download unlike OIM wherein the connector needs to downloaded separately and installed.
Comments
Post a Comment