Tuesday 18 May 2010

Trigger Happy Oracle Identity Manager - Part 5 - Trigger a task on another resource object

This is the fourth way to trigger a task in the Oracle Identity Manager (OIM).
Previous triggers and event generators have been discussed in post one, post two and post three.

In the previous (#4) post I explained how a task on the same resource object can be triggered after a task has finished with a certain response code. It is also possible to trigger a task on another resource object. This can be done by having the task on the first resource object set a User Defined Field value in the User object. The change of that field would trigger the lookup.usr_trigger explained in post . The task to be triggered for the second resource object would then automatically triggered. Because the exact task name defined in the lookup.usr_trigger is triggered in all resource object proces definitions that have this task defined.
It should be noted that the definition of the decode name in the lookup table must be exact the name of the task(s) to be triggered.




Tuesday 11 May 2010

Trigger Happy Oracle Identity Manager - Part 4 - Trigger a task on the same Resource Object process definition

This is the fourth way to trigger a task in the Oracle Identity Manager (OIM).
Previous triggers and event generators have been discussed in post one, post two and post three.

Suppose one tasks ends and one would want to start another task. A ugly and not very structured way would be to add the second task to the first task. Much more elegant is to trigger the second task after the first task is finished.
This can be defined in the responses tab of the process task definition. In that tab the response codes are set, but also based on the response codes the next task (of that resource object to be started.)


But it is also possible to trigger a task after another task has failed or half succeeded all depending on the response of the first task.
One must of course make sure there is no circular chain of tasks being triggered, because that would hangup the OIM.

Monday 10 May 2010

Trigger happy Oracle identity Manager - Part 3 - Delete User only works when defined as recovery task

One of the things not clearly described in the Oracle documentation is the triggering of processes and actions in the OIM. When you know how it works you can find the descriptions in the documentation supporting this functionality. But this is scattered over the documentation and needs trial and error testing to be user on how this works. This is due to the fact the documentation talks about "buttons that can be pressed" and the action that follows.
In the first post we discussed the start provisioning and the task triggers. In the second post we did a twist on this first post.
In this post the de-provision picture is complete and the failure trigger is explained.

One of the things not clearly described in the Oracle documentation is the triggering of processes and actions in the OIM. When you know how it works you can find the descriptions in the documentation supporting this functionality. But this is scattered over the documentation and needs trial and error testing to be user on how this works. This is due to the fact the documentation talks about "buttons that can be pressed" and the action that follows.

One of the "poorly" documented features of OIM is this tidbit for the task "Delete User". This is triggered with a deprovisioning, but only works when this task has been added as recovery task of the task "Create User".
The recovery task would be triggered when the "Create User" fails, that is clear, but why the delete only works when it has been added as a recovery task for the "Create User" is not clear to me.

Friday 7 May 2010

Trigger Happy Oracle Identity Manager - Part 2 - Provisioning with a twist

In the previous post on OIM we discussed how a process task is triggered when a resource in de OIM is provisioned or de-provisoned. The task "Create User" starts the java task that will create a user in the Resource object to be provisioned. The resource object could be a database, ldap server, file server or application.
Part of a process definition could also be a task that would add the user to a group within a ldap server. The standard way to resolve this using a "child table" with the process. But then the provisioning to this ldap group would not be seen in the OIM as a separate resource object provisioning for that user. This make all the resources this user has been provisioned too less transparent.
If one would want to see the provisioning to a ldap group as a separate resource provisioning, the process definition of this resource object must have the task "Create User", but in stead of creating the user in the ldap server this task would be linked to the java task that would add the user to the ldap group.

De-Provisioning that resource would result in the task "Delete User" being triggered that would remove the user from the ldap group.

Thursday 6 May 2010

Trigger Happy Oracle Identity Manager - Part 1

In the previous post I mentioned the number of undocumented or not clearly documented features of the Oracle Identity Manager (OIM).

One of the things not clearly described in the Oracle documentation is the triggering of processes and actions in the OIM. When you know how it works you can find the descriptions in the documentation supporting this functionality. But this is scattered over the documentation and needs trial and error testing to be user on how this works. This is due to the fact the documentation talks about "buttons that can be pressed" and the action that follows.
In this blog I'll try to explain the functionality more from a process view.

To start of simple I'll talk about how the provisioning process is triggered.
Processes in the OIM are defined in the "Process Definition" of the "Process Administration" in the Design Console. In the process definition tasks can be created. The tasks are linked to Java code (adapters) that will perform the actual action. An action could be the provisioning or de-provisioning of a user, group membership or update of an attribute like a password.
The question to be answered in this blog is how this task is triggered.
This is done very untidily based on the name of the task. When a resource is provisioned the task named "Create User" is triggered. The spelling should be exact like this, otherwise the nothing is triggered.
Similarly the task to be triggered in case of a de-provisioning should be called "Delete User", exact with this spelling.

Oracle Identity Manager or SUN Identity Manager

The Oracle Identity Manager (OIM) is a central product in the Oracle identity Management suite. It survived the merger with the SUN Identity Management suite which had a product doing similar things. The "core" task of OIM is the provisioning and de-provisining of account and entitlements to different applications, databases, ldap servers and other kinds of servers.
It has alot of functionality "around this" core functionality like self service account management, password resets, compliance auditing reporting, workflow etc.
For a number of people it was surprising the Oracle Identity Manager won the "battle" over the Sun product. This expectation was mainly because the idea/feeling that the Sun product was easier to use. But Oracle product development will not have had a biase for its "own" products, it saw that OIM has much more functionality and capabilities that the SUN product.
What needs to be done is make the OIM easier to use. Off course that will all be resolved in the next version 11g of the OIM :-), a rule that is true for all Oracle products. But until that time, and possibly even after, we will have to live with the issues in the current versions.
The biggest reason the OIM product is perceived not easy to use is because of the number of undocumented or not clearly documented features and functionalities of the OIM.
There are a number of good blog post and Oracle Metalink Notes on OIM functionality. In the coming posts I would like to shine my light on the way processes and actions are triggered in OIM.