IT Service Catalog in OIM11G R2 - filtering objects

In the post "IT service catalog evolution" I discussed how the set of entitlements that IT offers to the business have been presented to the business in the various request interfaces that have been available in various provisioning products. A major and ongoing issue has been how to expose the entitlements that the business cares about. Traditionally the solution there were a couple of different ways to solve that problem if you are using OIM but if you wanted to solve the problem within the confines of the standard web interface you often ended up with a very large number of resoure objects (ROs aka application instances). Another reason for ending up with "too many ROs" could be that you have large numbers of independent target systems and each system has been modeled as an RO.

A large number of ROs comes with a number of issues but the biggest is usually that it can make it hard for the business to pick the right entitlement in the request interface.

In this post I will take a closer look on how you can resolve this problem in OIM11G R2 by utilizing the catalog concept.

The catalog offers the ability to not only present resource objects (application instances) but also use enterprise roles and entitlements. This gives you a very rich tool chest when it comes to displaying options but sometimes what you need to do is to selectively not showing certain options based on the attributes of the user that is using the request interface.


Daniel Gralewski has written an excellent introduction to the Catalog concept that is a very good starting point if you are unfamiliar with the feature. A more in depth discussion can be found in the OIM manual.

The object filtering approach requires that it is possible from a business standpoint to divide the objects in the request interface into a number of different buckets and then map these buckets to different groups of users. A typical situation may be that the following "buckets" exists:

• Birthright objects such as a base AD account
• Enterprise applications
• Applications that are used by a specific department such as HR or Finance apps
• Applications used in a specific geographic region i.e. EMEA

The discovery and categorizing exercise is very similar to role mining and if you drive it too far you will run into the same issues that plagued role mining projects. That said it is usually decently easy to perform some form of coarse grained sorting of the apps.

Once you have the apps sorted you can map the users through their cost centers or departments so that the users only see the objects that are interesting for them.

Daniel Gralewski has written a detailed howto that shows how to change the shopping cart icon based on if the user already is associated with an object or not. The same approach with some modifications to hide objects that the users really doesn't need to be able to request.

Alex Lopez has written a more advanced example that also uses multi step drop downs where the content of the first drop down is determined by the requesting user's attributes and the content of the second is determined by the pick in the first drop down. Very nice example that shows the versatility of the interface.

The catalog does offer a number of advanced capabilities and really gives the implementation team an ability to create a very customized user interface within the core product. This means that you don't have to take the very large base investment that a "ground up" user interface means and that the implementation also is decently upgrade safe.

The downside of the catalog approach is that you do need to do some business analyzes work up front to understand the who should be able to request what. The implementation team does need to have quite deep webcenter/adf skills to be able to perform the customization.

Overall the catalog is a very nice feature and clearly puts OIM clearly ahead of some of it's competition i.e. IBM SIM/TIM 6.0.

IT Service Catalog evolution

One of the eternal problems in Enterprise IAM is to bridge the gap between how the business looks at an entitlement and how this entitlement is actually provisioned and managed by IT into the target systems.

If look back to the 2001-2005 area when the first provisioning tools like Thor Xellerate (later OIM) and Access 360 ( later TIM and now ISIM) entered the market the tools basically offered a capability to automate the creation of core identities and the associated target system identities. The approach that these systems took closely followed how the enterprise access administrators within IT looked at the world. Most of these systems came with a request interface of variable level of usability (they were user friendly, they were just very picky about who they wanted to be friends with).

Move forward a bit to the 2005-2006 era and the request interfaces became more understandable but as they were meta data driven they were hampered by the basic data structure that basically dictated that a line item in the request interface should be a resource object which out of the box usually mapped to a user account in a target system. This is not very useful if what the business wants is to manage business entitlements which maps to one or more attributes such a group membership on the target system.

One way to solve this problem was to get yourself on of the new role management tools such as Vaau Role Manager (later Sun Role Manager and now Oracle Role Manager) or Bridgestream (later Oracle Role Manger and now dead). This approach worked if you could get the business to consolidate their access profiles into a set of distinct business roles that could then be mapped to IT roles that contained the actual entitlements.

Sometimes you could even map the users to business roles through user attributes such as physical location, cost center or reporting chain. If this was possible you had reached the nirvana of totally automated provisioning.

In practice this approach turned out to be hard to implement as it was very hard to capture the very complex nature of an enterprise entitlement management in a set of discrete rules. By the time you had finished one role mining the business had reorganized and you needed to start more or less from scratch. It was also very hard to get the business to spend time on working on defining and maintaining business roles.

If you couldn't get the money to buy a role mining and management tool what did you do then?

One option was to write your own which I did for an IBM IAM stack implementation that ran 2010-2011. This worked decently well to generate a base set of entitlements that should be given to each user upon user creation but the challenge was to keep the configuration files updated as the business evolved.

You could of course create a custom user interface that encapsulated all the complexities but that was a very expensive approach both from a time and cost perspective. I followed that approach in a Oracle eBusiness provisioning enablement project using IBM TIM in 2008 and it worked great but the project cost was substantial and the scope was limited to a single target system. Sena system as well as other system integrators have done a number of very successful implementations using this approach and if you have the time and funds and have a very complex it landscape this is clearly the approach that gives you the best result.

Another approach was to encapsulate the atomic entitlements into requestable objects and then present the business with a very long list of objects that they had to chose from. This approach was favored by the major analyst houses back in the 2010-2011 time frame and certainly works.

If you want to follow this approach using OIM I wrote some articles on how to do it back in 2010 that may be of interest:

• OIM 11g request management (note that this written way before I had access to OIM 11g)
• OIM Howto: Request based group membership management

As always there are downsides with taking this approach. One major downside is that the list of entitlements tends to get rather large in a major enterprise which makes it very hard for the business to pick the right entitlement which in turn makes the business very unhappy.

In OIM11G R2 there is a new concept called the catalog that gives you a new tool to address this particular issue. I will take a deeper look at catalog in a later post but it is a really nice addition to OIM and give you a low cost alternative to the custom interface.