ITIM Accesses and SoD

Just like all enterprise applications, IBM Tivoli Identity Manager has evolved over the years. New releases bring new functionality or even a new look and feel (as per v5.0 move away from the Ice Cream Parlour look of v4.x). The new functionality is typically a response to customer needs, competitor functionality or a general shift in focus.

Recent functional additions have included Accesses, Separation of Duties and Recertification. Fabulous you might think. However, I can't help thinking that some of these functions could be improved to make them actually work in a real world scenario.

Accesses
Accesses can be applied to roles and groups and allow end users to "request" these accesses through the self-service screens. This is great as it now provides us with a means of allowing users to request access to a File Share, for example. Or is it great? If all file shares were made accessible you might find that there are a lot of accesses that the end user needs to wade through. And what if the user isn't even entitled to an AD account which is a pre-requisite to getting access to a File Share? Well, in the ITIM world, the File Share access would still be displayed on screen!

What if you manage external users inside your ITIM. Can these external users (who may only access a web portal page, for example) now see the structure of your AD Groups because they are now accesses?

In short... why are accesses not locked down by ACIs in the same manner as almost all other ITIM data objects?

Separation of Duties
SoD has become a big issue in recent years and it is terrific that it is being addressed in ITIM. However, the implementation is restricted to Static Role clashes only. If, for example, I have a role in ITIM assigned to me by virtue of some attribute on my person record (ie. a Dynamic Role) then this cannot be used in the evaluation of SoD rules.

Take this example: I'm assigned the role of Approver because my Job Title is Manager (via a Dynamic role). A superior of mine assigns the role Auditor to me (via a static role). Ideally, I want to create a rule that states that Auditors cannot be Approvers. Unfortunately, I cannot create this rule in ITIM as the role of Approver is a Dynamic role.

I have no doubt that these issues are already well understood within IBM and that the next version of ITIM will address them. If that is not the case, that would be a terrible shame and a missed opportunity. Maybe my thoughts can help steer the product owners in the right direction? Do I have that amount of clout?