10G Database Flashback, a must have!

I would highly recommend when installing the database for your OIM implementations that you enable, configure, and test the Flashback point-in-time recovery system within your 10g database. The import process, while an incredible time-saver for managing multiple environments, has a tendency to corrupt things from time to time. Specifically we have noticed that importing an updated process form that contains child forms tends to not function properly and can cause loss of the entire form configuration.

Flashback will allow your DBA to quickly recover your OIM database to the point just prior to your import attempt, saving you much heartache, pain, tears, and other such issues.

Primer: IT Resource Types and IT Resources

IT Resource Types and IT Resources are related, an IT Resource Type defines the template for specific IT Resources. Think of it like a JavaBean with its various member variables and IT Resources as specific instances of that Bean. There are a couple of built-in types, Mail Server for example which provides the template for a specific Mail Server IT Resource that will be used to send various emails.

When importing a connector, you will get the IT Resource Type definition as well as be prompted for the specific values to create an IT Resource.

Each Type may have many specific IT Resources, for example you may have three different OID servers for each of your regional facilities. One Type 'LDAP Server' would provide the base for each of these 3 IT Resources.

Basically IT Resource Types and IT Resources define the physical connection to a specific resource, hostname, passwords, and so on. They are linked with Resource Objects which in conjunction with Resource Process Forms define the details of a managed object on the physical IT Resource, for example user accounts. One provisions a Resource Object on a specific IT Resource.

Primer for Provisioning Flows: Xellerate User/User Defined Fields

So I realized when I first started working with OIM that the documentation is somewhat lacking in detail and does little to help build a conceptual understanding of the how it works. Once you understand it, it is fairly intuitive. Just many moving parts. So I will share what I have learned in the next few posts about the basic flow of information through the system and how stuff works.

OIM/Xellerate User - User Form
The User Form/Xellerate User is the basic record that all entities have within the system. It start with a few basic fields, User ID, Password, First & Last Names, and a few date fields and some others. Like I said, basic. This "Form" is where you build up a profile of your user and the store the various bits of information that define your user and will be used to provision additional resources. The Xellerate User is one of the special 'system' resource objects defined when you install the system. Additional resource objects will be defined as you develop provisioning resources etc. The Xellerate User resource object is similar but slightly different that other resource objects.

You can extend the information you can store on this form by adding User Defined Fields (UDFs) through the design console. Maybe its a telephone number, or a department name, whatever. Add the fields that are appropriate to define your identity.

Within the Web Console, when you edit an user you are editing the User Form and its basic fields and UDFs.

These values are either updated manually through the Web Console, or more commonly updated through a trusted reconciliation process.

Caching == 'good'

We have been looking for all possible updates to improve perfomance of our reconcilation passes. Lo and behold, the "Best Practices Guide" in the OIM Doc set. In there it references enabling caching of various objects and definitions for best performance. Do it! We saw over 50% per user performance just by turning these setting on as recommended in the docs.

Building Rules for OIM Group Determination

For each rule defined that is linked to an OIM Group for Membership determination, the recon engine runs it tests. So if you have 100 groups with 100 rules, it will run through all 100 rules for each person reconciled. This can get painful in terms of perfomance. After experimentation we found that defining all conditions on a rule with the most restrictive condition first gives the best performance. The rule engine stops checking conditions at the first failed condition on an 'AND' rule.

For example:

Person is Location:X, Dept: 2, Gender: M

Your organization has 5 Locations, 100 Departments, obviously I hope 2 Genders.

The best way to organize your rules is:

Department == 5
Location == X
Gender == M

Department == 5
Location == X
Gender == F

This way when the determination engine runs through the rules more people will fall out at the first rule and prevent testing of the subsequent rules.

Also Rule Caching as configured in xlconfig.xml greatly improves performance on rules processing as it cuts down on the DB read for each and every rule for each and every person.

This Blog

As we work to implement the Oracle Identity Manager product to handle our account provisioning and security, I have learned and continue to learn a great deal about this somewhat poorly documented but very powerful tool. This blog will be my attempt to provide some of the insights and knowledge I have learned to help others better understand and implement this system.