Delegated Role Administration

While setting up our first delegated role administrator, we came across some items to keep an eye out for. We created a new role and assigned the Role Owner as the person we wanted to manage that role. This is non-administrator in the system, but they need to be able to add anybody to the role as needed. The built-in Role Owner policy allows them to see the role, however two issues appeared. First the role owner was not able to see the members of the role, in fact an error came up in the UI. Second, they could click on the add button but no results would ever come back in the user select box. (FYI: This search box is strange in that it is searching only on Display Name, but it does accept wild cards. Since our display names have middle initials, I have to search for Eric*Fisher to find me if I didn't know the MI.)

We fixed these by creating a new role called ROLE_OWNER, a new authorization policy for ROLE_OWNERS that granted them Search User and View User Details (Just the default attributes), and added the role owner to this group. This will fix the issue with the role owner not being able to search in the box for new users to add to the group.

The other problem was more complicated and is related to the XL.EnableOrgPermissionCheck which is set to TRUE and enables 9.x style Org Permission checking. As some of you 9.x'ers may recall you have to add Administrative Roles to the Organization to allow a Role to manage users in that Org. So we went to our root Organization and granted the ROLE_OWNER role, READ permissions on that Org. Problem solved.

OIM 11g in Production!

We cut-over earlier this week and now have OIM 11.1.1.5 running in full production, replacing our previous 9.1 version. I'll post some more useful code snippets as things settle down.

Requestable Role Configuration

We wanted to limit which roles a person was able to request via the user interface, but the default Request Template "Self Assign Roles" was allowing all roles to the Role ALL_USERS. So we simply added the "ALL_USERS" role as the only Allowed Role in the Template, since everyone is already in this role they now by default see no requestable roles. Now we can create additional Request Templates for different groups to allow them to request only the roles we want.

New UserManager API and User Login reuse

If you have your new OIM11g install configured to allow reuse of User Logins, be aware that any custom code that utilizes the UserManager.changePassword or UserManager.getDetails methods will potentially return the old, deleted account if you use User Login as your search key. If you make use of these functions in any custom code, you will want to first do a UserManager.search with the User Login to get the Entity ID/usr_key and then use this value in your changePassword or getDetails call. The search method does not return deleted accounts unless you explicitly search for them.

OAM11g and OIM11g Integration

Came across some confusion in the configuration documentation for integrating OIM with OAM11g. We noticed after the integration that all of our user modify orchestrations were failing at the UpdateUserNotification step. This is an eventhandler that is part of the OAM installation that sends a message to the OAM server to invalid the user cache. After some testing we figured out the issue, the documentation indicates in your oim-config.xml that you need to set the accessServerHost and accessServerPort to the OAM Loadbalancer VIP address. The documents seem to indicate this as sso.mycompany.com and 443. If you do this the UpdateNotification will fail as it is trying to contact the Access Server with a message and not an HTTP-type call.

Instead these values should point to the same host and port that the WebGates connect. To determine this, open one of the WebGate configurations in the /oamconsole. Look in the Server Lists section, this has the hostname and port that you should use instead in the oim-config.xml file. In our case the port is 5575 which seems to be the default.

So to repair, update your oim-config.xml in the ssoConfig section and import into MDS.

Self Service User Profile Modifications

As we are completing our configuration for deployment, we noticed the the attributes that a person can modify on their profile by default is more than we wanted to allow. For example since we use our HR system as our system of record for names, we did not want a person being able to change their name through OIM. The OOTB policy allows all users to edit their Name, Email Address, and Display Names. All of which we did not want them to be able to do.

Since this is an OOTB authorization policy, it can't be edited in the OIM UI nor overridden. By creating another policy we were able to add attributes to edit, but not disallow those already permitted. In looking around we located where the OOTB policies are defined and the ant scripts that load the policies into the embedded OES server. By commenting out the unwanted attributes and running the appropriate ant target we were able to remove the ability to self modify the attributes.

This is not a supported solution and you will need to be careful each time you patch the server to ensure the policy is updated correctly. (FYI: We have filed an enhancement request to have this changed to be the default policy.)

With that caution here goes:

In the ORACLE_HOME/server/seed_data/Seed/OESPolicies directory, you can locate the SelfServiceUserManagementPolicies.xml file. Make a copy of this for posterity and open it for editing in your favorite tool.

The offending section is right at the top, simply comment out the attributes you don't want to be editable.





Next, setup your environment as you would for patching by exporting the WL_HOME, ANT_HOME, OIM_ORACLE_HOME, and ORACLE_HOME paths.

In the ORACLE_HOME/server/bin directory make a copy of the weblogic.profile and patch_weblogic.sh files. Edit your copies and change the profile to that of your copy and the ant target to update-oes-ootb-polices. I had to add an additional entry to the profile for the OIM DB password in order to get it to work, hence the copy. So in your profile copy add the entry OIM.DBPassword=. Run the script, it does take some time to update the OES policies. Once done, you can go into the UI and verify that it removed those attributes.

Preprocess EventHandler Example

Here is a basic example of an User Pre-Process EventHandler. This handler looks for either new or changed first and last name values and recomputes a Display Name and Initials attribute. It lacks proper error handling for missing values, but should give you a good idea how to work with the Eventhandlers.

Download as File

Bundle Patch 1 for OIM 11.1.1.3 is now Available

The first bundle patch for OIM 11.1.1.3 has been released on My Oracle Support. Has quite a number of fixes listed.

Entity Adapters on the USR Data Form

Just received word from Oracle that Entity Adapters/Rule Generators in OIM 11g are no longer usable on the USR form, you must create these using the new EventHandler mechanism.

Trusted Reconciliations

There have been some important changes in the Trusted Reconciliation processes for bringing in new accounts/changed accounts from some system of record such as an HR system using the Generic Technology Connector or custom reconciliation connectors.

The default mechanism for reconciliations is now a batched reconciliation, this processes many changed records much faster than before but also has some limitations. If you were previously using pre-insert or pre-update entity adapters, these will NOT fire in a batched reconciliation. The GTC in trusted reconciliation uses the batched mode exclusively and I have not yet identified a way to switch it to one-off events. This is important in that if you use pre adapters to calculate or modify certain values on the User form such as login, email address, expiration dates, etc. they won't trigger. You either have to switch these to a post operation which may cause a potential infinite loop condition or avoid batched mode.

If you use the APIs and/or a connector that creates reconciliation records then you have the ability to use a non-batched operation. In this mode, the pre entity adapters DO fire. Additionally pre adapters DO trigger on manual operations through the UI. In order to force a non-batched recon event. You must call the API method processReconciliationEvent after creating and/or finishing your event.

As in:

tcReconciliationOperationsIntf reconObj = Platform.getService(Thor.API.Operations.tcReconciliationOperationsIntf.class);

long rceKey = createReconciliationEvent("Resource Object Name", HashMap of attributes, true);
processReconciliationEvent(rceKey);

UPDATE:
You also need to close the event with a:
closeReconciliationEvent (rceKey);
or the batch will attempt to redo the linking when it executes. This will cause a failed orchestration task to linger out there.

In the next post, I'll give a concrete example of how to do a pre-modify EventHandler to compute some attributes.

Changes in Reconciliations

OIM 11g has brought many changes in the reconciliation engine. Many of the changes are to improve performance and streamline the recon process. For those of us familiar with or using OIM 9.1 some of these changes will require some thought as to how to migrate processes over. I will be detailing some of the differences and how we have tackled them in the next few posts.

User Defined Attributes and GTC

When creating UDFs for the User form, Don't use spaces in the Name. Instead of Student Expiration Date, use Student_Expiration_Date for example. The GTC seems to have a hard time making the translation to the actual DB column name if you don't. I tried working with the customResource bundles in order to fix this, but no combination I tried seemed to work. I also tried editing the Process using the design console, but that just caused other issues. Only way I could get it to recon properly was with UDFs names without spaces.

If you do this, you will have ugly names on your User forms in the UI. Additionally if you need to localize for other languages, the way to add the localizations is somewhat obscure. You need to locate the IdentityTaskFlow.jar in your ORACLE_HOME/server/apps/oim.ear/admin.war/WEB-INF/lib directory. Inside this jar you will find the various language resource bundles at oracle/iam/identitytaskflow/resources/UserAttributes_en.properties and so on.

Extract this file. Add your UDF Names to Localization mappings to the file. The key should be in all lower case to work properly.

For example the above item would be added as:
student_expiration_date=Student Expiration Date

Update the jar and restart the OIM instance. Your UI should now reflect the localized names for your UDF fields!

Default SOA Workflows

I'm not sure if we ran into an installer thing, or something else, however while testing the approval workflows we were getting consistent failures. When we looked into it, the default SOA composites for the out of box workflows were not deployed to the SOA instance.

These are located in your ORACLE_HOME for OIM at ORACLE_HOME/server/workflows/composites. They are already registered with OIM, just not deployed into SOA. You can either extract the jar files from the zips in the above directory and deploy via the Enterprise Manager console or extract the zips and open with JDeveloper and deploy that way. Which ever you are more comfortable with. We used JDeveloper so we would have the defaults available to extend for our own purposes.

Useful Script to Automatically Start NodeManager at Boot-up

Found this excellent post with a script to start the NodeManager as a service.

http://weblogicserver.blogspot.com/2010/01/node-manager-as-unix-startup-process.html

Adding additional User Defined Attributes (UDF) to the User form - Part II

After we created all of the additional UDFs required on our OIM/Xellerate User form, we thought we were home-free. We created a test user using some of our new fields and the were properly created and the attributes set in the directory as mapped. However we ran into a bit of a head-scratcher. When we went to the modify user form, we could see none of our new attributes.

After fooling around with properties files and verifying settings, we finally figured out that the 'Authorization Policy' that was granting xelsysadm the ability to modify forms did not automatically include all the new attributes. We tried to edit the 'User Management Adminstration Policy' to check the additional attributes as allowed, however it seems you can't edit the built-in policies. So we created a new policy based on this policy and selected all of the new attributes. Problem solved!

Purging Cache

The PurgeCache script works a bit differently than it does in 9.1, it took me a few tries to figure out what it was asking. The script is located in your IAM_HOME/server/bin directory and the easiest thing to do is bring the setWLSEnv.sh environment into your shell before running.

Initially I thought it was asking for the weblogic administrator information (Port 7001) as the export/import scripts did. It is actually looking for the OIM instance information.

[Enter the admin username:]xelsysadm
[Enter the admin password:]
[Enter the service url : (i.e.: t3://oimhostname:oimportno)]t3://oimmidtierhostname:14000

I created a little script on my path to run this without going into the directory.

export OIM_ORACLE_HOME=/oracle/product/fmw/iam
. /oracle/product/fmw/wlserver_10.3/server/bin/setWLSEnv.sh
pushd /oracle/product/fmw/iam/server/bin

./PurgeCache.sh $1

User Attributes and Categories

While managing user attributes, I have noticed a few things to keep an eye out for. If you move or delete an attribute from a category, re-order it to the highest numbered position first (Farthest away from 1). If you don't you will likely be missing some of the other attributes from the list in the category after the move/delete. This is relatively easy to repair.

1) Export the /file/User.xml metadata using the export utility.
2) Look for the metadata-attachment section of the xml. This section lists the ordering of the attributes in the categories. When you find the category in question, it will likely be missing entries for the affected attributes.

They look like this:

<metadata>
<name>2</name>
<value>SIS Affiliation</value>
<category>categories.Internal Attributes</category>
</metadata>

3) Re-add metadata sections for the missing attributes.
4) Import the /file/User.xml
5) I had to restart the OIM instance in order to see the changes, it doesn't seem to refresh this metadata on the fly. UPDATE: PurgeCache All worked.

LDAP Sync Config - Part 2

As part of our implementation of OID, we use several different object classes of our own creation as well as the eduPerson object class. Additionally we don't use cn as our RDN for user accounts, we use a custom unique ID. We were able to change the LDAP Sync configuration in OIM to support all of this quite easily.

1) Add the custom attributes to the User Attributes in OIM.
2) Export the /metadata/iam-features-ldap-sync/LDAPUser.xml metadata from the repository.
3) To add additional object classes to be added on create, add additional <value> entries to the <parameter name="objectclass"> node .

Ex:
<parameter name="objectclass">
<value>orclIDXPerson</value>
<value>eduPerson</value>
</parameter>

4) Add your custom attributes to the three sections as noted in 13.4 of the OIM System Administrators guide.

5) To change your RDN from cn to another attribute, update the <parameter name="rdnattribute"> tag to the new directory attribute name.

Ex:
<parameter name="rdnattribute">
<value>companyid</value>
</parameter>

6) Reimport the metadata and test!

</parameter></parameter>

LDAP Sync Config Gotcha

Ran into a small gotcha while configuring the LDAP Sync for OIM. In step 13.7 of the Enterprise Deployment guide you are setting the LDAPSync parameters while running the OIM configuration utility. The docs seem to indicate that you are only entering a relative DN for the users and roles containers, that the rest of the DN root is defined elsewhere. We were getting errors creating new users after configuring it this way, we realized it must not be building the full correct DN for new users.

To repair, export /db/LDAPContainerRules.xml from the metadata repository and change the containers from just the 'cn=Users' to the full dn root 'cn=Users,dc=company,dc=com' and likewise for the Roles. Reimport and you should be all set.

Looking for OIM xlconfig.xml in 11g?

The new OIM stores its metadata config files in the database so you have to export it, edit, and re-import the file.

I found documentation on how to accomplish this in section 17.5.6 in the Enterprise Deployment Guide via command line. You can also perform the operation using Enterprise Manager by following section 18.2 in the OIM System Administration guide.