[OIM] Automate AD provisioning with multiple custom rules.

Question

I am working on setting up provisioning automation and I'm very confused about the best way to do it.
I need to have OIM do the following when creating an Active Directory Account
If the user is an employee put them in container X
if they are a contractor put them in container Y
If they are a warehouse worker, do not give them an account
If they are in NY, give them an account with group A
if they are in Denver, give them group B
and so on
So I need to have multiple rules checked and for certain fields to get certain things based on which rules are true. Do I need separate groups and Access policies for each rule?
Is there a way to make one collection of rules with multiple outcomes leading to multiple mappings?
rkimbal45
Edited by: rkimball on Jul 27, 2010 4:19 PM

Answer 1

Great question but unfortunately there is no straight answer.
Exactly what you can and should do varies depends on what tradeoffs you are ready to make in your configuration. It is very hard to give a condensed and straight answer that covers all possible configurations and gives you an overview of pros and cons.
I wrote up a paper on this a while ago that discusses this issue at quite some length. I am posting the excerpt that discusses this specific point below but it really helps if you have the rest of the context in the document.
Feel free to contact me through linked if you want a copy of the doc.
Hope this helps
/Martin
Role based group memberships
In some cases you have a requirement that users who fit a certain profile should be given a certain target system role. One common example would be that employees should be added to the employee group and contractors should be added to the contractor group. OIM supports this scenario through the rule, group and access policy system.
A rule lets you specify that a user that fits a certain profile (i.e. whose userType attribute on the user form is “employee”) should become a member of a certain group. The group membership in turn triggers execution of an access policy. The policy specifies that the user should be given a certain resource object with specific configuration of process form and child form. This in turn can trigger a target system group membership update.
This works great as long as the specifications for the rules are simple and doesn’t require usage of wildcards. If you have more advanced requirements, i.e. users with department 6200-6500 excluding 6345 should go in this group, you will end up with a lot of rules (299 to be exact). Likewise if you have more advanced requirements around what target system memberships should be given you end up with a lot of access policies. Even if you manage to implement this you can easily end up in a management nightmare with hundreds or even thousands of rules, groups and access policies.
Another weakness is that access policies can only be used to grant one instance of a specific resource object to a specific user. This is often a crippling limitation.
One way to escape the limitations of the rules is to use entity adapters attached on insert and update on the user form. This makes it possible to replace large number of explicit rules with a single logical expression. The downside is that the business logic is now defined in code rather than configuration. You could of course write code that loads configuration from a text file, a lookup table or an XML file but that only takes you so far.
Likewise you can replace the access policies with entity adapters that gives out ROs according to business rules defined in the code. Eliminates some of the limitations but makes the system harder to implement and manage.