The topic of Single Sign-On (SSO) has come up recently with…
If you have ever worked on an Oracle Identity Manager (OIM) project, you’ve probably come across a situation where OIM was lacking in an area where you expected it to “just work.” This seems to be a common feeling that many of the product’s customers share.
Plug-In to the Flexibility
My experience working on multiple OIM implementations tells me that no two organizations use the product exactly the same way. It’s actually pretty incredible how differently the product is used to accomplish similar tasks. I believe for this reason, the product is sometimes viewed as “missing” standard features. In reality, the product is delivered to customers in a state for them to make it fit their specific requirements, as needed. It’s flexible.
At Zirous, we have come to expect two things when working on projects involving OIM. First, it is likely that the core OIM product will not completely meet all the needs of an organization. Second, as the complexity of securing access to information systems increases, it becomes necessary to extend the functionality of OIM to cater to the specific business requirements.
So, how do you create customizations to the vendor-provided software that will not only be supported, but also survive patching and upgrades? Simple. Oracle has provided a plug-in framework within OIM. This framework allows developers to use supported APIs and mesh points to extend the product’s capabilities and meet an organization’s individual needs. The capabilities are enormous. However, while the process to implement customizations is simple, in reality, the work needed to make the changes is not always as easy. It requires a combination of product knowledge and experience to successfully customize OIM.
Oracle has supplied multiple plug-in points within OIM – too many to cover in this blog. So, I’ve described some of the most commonly used below. I’ve purposely kept out the technical babble, but would like to note that an understanding of Java and XML is required in order to create these types of customizations. Also, a solid understanding of how OIM behaves behind the scenes is extremely valuable – I can’t stress this part enough.
Status Change Events
Allows custom code to be used when changes to the status of a request occur.
Example: By default, OIM does not send a notification to the request beneficiary when a request is created on their behalf. A plug-in of this type could be created to send a notification to request beneficiaries when a request reaches the proper status (Request Created).
Request Data Validator
Allows custom code to be used for validation of request data upon request submission.
Example: By default, OIM does not require justification to be entered when submitting an access request. A plug-in of this type could be created to check the justification field at request submission to make sure it is not null. If a request fails this validation, submission is cancelled and a friendly popup displays on the screen to indicate that justification is required.
Allows custom code to be used to pre-populate an attribute value during request creation.
Example: When a request is made for a new Active Directory account, a pre-populate adapter could be used to automatically calculate and set the user’s Common Name value.
Allows custom code to be used to create scheduled jobs. The scheduled jobs can be configured to accept parameters and run on a recurring or as-needed manner.
Example: By default, OIM does not notify managers when a direct report is reaching their termination date. A plug-in of this type could be used to build a new scheduled job that sends a notification to a manager when the desired criteria are met about the termination date of a direct report.
Allows custom code to be triggered when operations are performed on entities.
This is a special kind of plug-in and includes a bit more complexity to trigger upon a specified system event. There are many different kinds of entities and operations. Two common examples of entities are Users and Roles. Two common examples of operations are Create and Modify.
There is also another configurable item that specifies which stage the event handler should trigger. There are various stages, but the most common are validation, preprocess and postprocess.
Example: An event handler could be created that triggers after a user is created in OIM. In this case, the event handler will specify the User entity, Create operation and postprocess stage. The business logic in the event handler could be coded to perform just about any imaginable task related to the affected user(s).
As previously mentioned, this was only a sample of what I consider the most common plug-ins. There are other plug-in points that can be used as well. OIM is incredibly versatile and can be made to do just about anything.
Deployment and Migration
Deploying plug-ins is a pretty simple process. After the coding is complete, the plug-in files (java classes and xml) are zipped up and can be registered and tested. Typically, the plug-in zip files are not environment specific, so it is common practice to deploy the same zip file in every environment. This makes migration simple.
Just because you can customize the software, doesn’t always mean you should. You want to avoid situations where enhancements impact one another and cause potential problems. Sometimes it is best to simply change a business process to make it fit the software instead. Again, this is where expertise is valuable.
One last item to point out is that all of the customizations described above do not affect the user interface (with the exception of a popup in some instances). The impact is to the functionality behind the scenes not visible to users. If UI customizations are necessary, those can be handled by other means.
At Zirous, we’ve run into complex requirements on every project where OIM is involved. If your organization finds itself in a situation where OIM doesn’t seem to be meeting the desired needs, chances are that Zirous can help you find the solution. Contact us to learn more!