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