Oracle Diagnostic Logging - getting deeper into OIM11gR2

Going deeper into OIM is a little different using ODL instead of the old log4j.properties file in OIM 9.1.0.2

If you have read my previous post on how to set up and hand modify the ODL files for your server, you will be able to perform these tasks.

Here are some interesting logging points I have tried:

  <logger name='oracle.iam.provisioning' level='TRACE:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='oracle.iam.identity' level='TRACE:1'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='Thor.API.Operations' level='TRACE:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.DATABASE' level='NOTIFICATION:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.SERVER' level='NOTIFICATION:1'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.SCHEDULER' level='NOTIFICATION:1'>
   <handler name='odl-handler'/>
  </logger>
 
The handler name was changed back to odl-handler, but I use my own handler that segregates the parts I am interested in.  I put all of the parts I am interested in, into a handler I call edu-handler, so in my logging.xml file, all of the above odl-handler references actually are edu-handler.  I just want someone who wants to copy/paste to not have a failure because they haven't defined an edu-handler.

OIM11gR2 Testing Access Policies

When developing and testing access policies, the following guidelines are good advice to follow:

In the Scheduler, typically the Evaluate User Policies scheduled job runs every 10 minutes.

When testing access policies, it is a good idea to click the Disable button so that the job does not run on its schedule.  The job can then be executed using the Run Now button.

When modifying an Access Policy, if the Retrofit Access Policy flag is set to Yes, then every user will be re-evaluated, and if the user fits the policy, that user will have their POLICY_EVAL_NEEDED flag set to 1 in the USER_PROVISIONING_ATTRS table.  If you don't want every single user to be re-evaluated, then after modifying the access policy, execute an update query such as:

UPDATE USR_PROVISIONING_ATTRS SET POLICY_EVAL_NEEDED=0

and then when you are prepared to test a user, use a similar query such as:

UPDATE USR_PROVISIONING_ATTRS SET POLICY_EVAL_NEEDED=1 WHERE USR_KEY=2023

It's a good idea to review and document the user that you chose to test before and after the test.  To execute the access policy logic, just go back and run the Evaluate User Policies scheduled job.