We have always had customers who wanted to integrate their identity management system to a custom user interface. Recently, we have been noticing an increase in customers that want to integrate the identity management system (IDM) with an information technology service management system (ITSM). For those of you unfamiliar with the term, an ITSM is basically your trouble ticketing or IT request system. More organizations are using the ITSM as the central system for all user IT requests, such as for equipment and software. It’s part of a larger movement to attempt to centralize IT processes and measure the effectiveness of IT to provide those services. So if organizations are centralizing all IT requests, it seems only natural that they would want user requests for access to flow through the same system. This creates a “one stop shop” for all interactions between business users and IT.
Oracle Identity Manager (OIM) 11g R2 introduced a new request user interface that uses a more familiar metaphor, the shopping cart. System access is now something you search for in a catalog, add to your shopping cart and then “check out” to submit the request. This type of task-based UI is something users need little training to master because they use it all the time when they shop online; however, despite this tremendous leap forward in usability, some customers still want to move requests to the ITSM.
There is no out-of-the-box integration between OIM and any of the more popular ITSM systems. So this means a custom integration using the OIM API and the API of the ITSM is required. Here are four guidelines you should consider in your integration design:
Use the ITSM for requests only. While it may be tempting to hide the entire IDM system from end users, it’s unnecessary and will require you to re-engineer more than the request interface. Most users will understand that the ITSM is for service requests but things like password changes / resets happen elsewhere.
Keep access approvals in the IDM system. If your IDM system is like OIM, then it will be capable of supporting custom approval workflows. Use the IDM system for these approvals. Approvals may require the approver to do more than merely accept or reject the request. The approver may be asked to update fields in the request. Since this is something that is already happening on the IDM system, don’t reinvent the wheel. You also want your IDM system to be the single point of audit. This means that all data around the request should be collected and captured by the IDM system. If you have approvals occurring in the ITSM, you will need to pull data from the IDM and ITSM systems to get a complete picture for your auditors. By keeping the requests in the IDM system, you will simplify your ability to provide auditors with information.
Post status updates from the IDM to the ITSM. While users are going to be submitting access requests to the ITSM, they are also going to be checking on the status of those requests. It’s important to update the ITSM with the current status of the request from key points in the request workflow running in the IDM system.
Automatically synchronize the IDM catalog with the ITSM catalog. The catalog of requestable items in your IDM system are going to change constantly. You want to automate the synchronization of items from the IDM catalog into your ITSM catalog as much as possible. This is critical as you don’t want to duplicate configuration on your IDM and ITSM for every change to your access catalog.
This is by no means an exhaustive list, but it’s a good start. Your requirements are going to drive much of the specific design of your integration.
If you have any questions or comments, feel free to contact me. I’d like to hear how you are planning your ITSM / IDM integration. We’ve created several ITSM / IDM integrations for our customers and if you’re considering it, we can help.