Trigger Happy Oracle Identity Manager - part 8 - OIM user triggers part A

This is part 8 of the Oracle Identity Manager trigger saga.

Creating a user in the OIM can trigger tasks, before and after insert, before and after update, before and after delete. The tasks are like other tasks and they start process task. The process form they use, use the standard form for creating OIM users, which includes the User Defined Field.

The data of these forms can be mapped to the input fields of the adapters behind the tasks triggered.

Risk Management by obscurity works

The old adage is that security by obscurity doesn't work to protect against security threats. This is true. A solution that uses propriety solutions known only to a small community, doesn't remove the vulnerability. It does though, lower the probability that somebody is able to exploit the vulnerability.
The less people know the technology the less likely it is somebody is able to exploit the vulnerability. The economics of the exploits also work in favour of the obscurity. Since the investment of the hacker in learning the ins and outs, specially the outs of the vulnerability are not likely to payoff in large amounts.
That means obscure solutions do lower the overall risk since that is a combination of the vulnerability and the probability together with the impact. For instance for cases where the Impact for the user has a limited amount of payback for hacker.
A defense in depth approach could for parts of the solution include obscure solutions when there are no other solution or standard solutions (e.g. non obscure) are too expensive or complex.

Trigger Happy Oracle Identity Manager - part 7 - enable user or disable user

When a user is enabled all the tasks that have the attribute "Enable Process or Access to application" are triggered. The attribute is set with a special drop down list box in the task definition form of the process definition.
All the tasks in all the resource objects linked to this OIM user are triggered. One could question why Oracle development hasn't chosen the construction with the lookup.usr triggers like has been described in an other post. But that is the wonderful world of OIM.
For this series is good, yet another way to trigger tasks in the Oracle Identity Manager world.

The drop down list box also contains the option "Disable Process or Access to application" and the "No effect" option.
This is a trigger just setup for the enabling the user.

Insider threat, look at what is left lying around and not used anymore

Suppose a company does a little project. It is kind of successful, money is made staff is paid.
It is so successful one might try it again in four years time. But that will be another project in another country, with different customers.
In many companies the information used in the old project will be discarded or left in a corner without anybody looking at is. The database with the data of the project will still be on a server or just in a couple of backup's. But nobody will be looking at it since the project has ended anyway.
I suppose that is what happened to the FIFA.
http://www.guardian.co.uk/football/2010/sep/05/fifa-passports-claims

Same Triggers in window dressed Oracle Identity Manager 11g

Oracle Identity Manager 11g came out in 21st of July. This new version has a lot of improvements among them: BPEL workflow, Reporting, ADF integration and performance.
Some things stayed the same though like the Design console fat client. Also all the triggers we have discussed in the blog (and more are to follow) stil kick start the provisioning, reconciliation or workflow engines of the OIM.
The windows are dressed differently, but the core is the same.

Trigger happy Oracle Identity Manager - Part 6 - Fine granulair OIM user attribute

When an attribute of an OIM user is changed a trigger can be started. The first thing that is triggered is the post update trigger of the Data Object. This will trigger a check of the LOOKUP.USR.TRIGGER lookup tables.
When a field defined in this lookup table is changed the process defined in the decode field of this table is triggered. This means all the processes on all the resource objects exactly named as in the decode field are triggered. This way a password change on the OIM user atribute could change password change processes be triggered on all resource objects. As long as the resource objects tasks are exactly named like in the lookup table is defined.


Watch out for circular triggers in the post update trigger. When the post update trigger makes an update of the attribute it will recursively trigger itself. When no end point in this trigger process is defined the application server will go down because all the resources will be used in this process.

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.