Sunday, October 3, 2010

[OIM vs TIM] Basic RBAC

In my previous post RBAC vs ABAC I talked about using your favorite provisioning tool to implement a simple case of AD group membership management. I thought it might be interesting to compare how you implement this use case in OIM and TIM.

In OIM there is a large number of different ways to do AD group memberships but lets concentrate on the most standard and out of the box method: rules, groups and access policies. In the use case that we are dealing with OIM's standard functionality actually works great. If the rules that governs which AD group is given to which group of users would be slightly different i.e. give everyone whose cost center is between 1200 - 1299 AD group X and 1300-1399 AD group Y then the OIM standard functionality basically stops working and you will have to bring an entity adapter based approach to bear (see Role based group memberships in OIM for more details on how to solve this problem)

In TIM the OIM groups are basically called Roles. The TIM role basically contains it's own OIM rule definition. The TIM role membership definition is done through an LDAP filter which of course is a much more flexible mechanism than OIM's rules. as you have access to wildcards and everything else an LDAP filter can offer you.

In TIM you use a provisioning policy to implement the mapping of TIM role (OIM group) to entitlement. A TIM provisioning policy more or less is equivalent to an Access Policy in OIM. The TIM provisioning policy contains more configuration as some of the things that is configured in pre pop adapters and the process form in OIM is controlled by the provisioning policy in TIM. The configuration in TIM is done through Javascript while you usually tend to use Java code in OIM.

To implement the use case in TIM you would:
  1. Create a TIM role for each AD group that you want to provision. 
  2. Configure each TIM role to only include the correct users using an LDAP filter.
  3. Attach a provisioning policy to each TIM role that gives the specific AD group.
  4. Done!
Overall I think that TIM is the winner in this specific battle as you can do more things without having to resort to coding in TIM. You can do the same things in OIM as in TIM but in many cases you will have to resort to coding at an earlier stage in OIM as TIM has a more flexible configuration interface.

No comments:

Post a Comment