With the release of Novell's Role Based Provisioning Module (RBPM) version 3.7 there was a new driver added, the Roles and Resources driver. This is actually a newer version of the Roles driver that the Identity Manager 3.6.1 RBPM module used, but still it is a different driver.

What is also newer in the RBPM 3.7 and RBPM 4.0 since the IDM 4 Roles Based Provisioning Module is basically an updated and tweaked RBPM 3.7 is how much the User Application relies on the Roles and Services driver. Basically the request is made to grant a Role or access to a Resource it actually creates an object that has all the request information in it. These are stored in the ReqDef container under the AppConfig container, which is stored inside the User Application IDM driver. The IDM driver for User Application is used for a couple of things, but one of the main reasons it has to be deployed before you start the User Application web application, is that the configuration information for the web application is stored and retrieved from the AppConfig container, which is created inside the Driver object. Basically at the simplest level, you need somewhere to put the information, and by deciding to store it in the driver object and requiring the driver object to be created, you solve the chicken and egg problem for getting started. This decides it is the Egg that must be created first, then the chicken will read it and populate it with information. Ok that metaphor was a bit strained, but you get the idea.

The Roles and Services driver events on this object create (and I think polls periodically as well) and tries to process the Role or Resource request as it receives them. I know it polls for certain events, because you can put a begin and end date on a Request, and therefore every heartbeat or so, the driver will go looking for any Requests that have either become valid or expired since the last poll and process them. What I do not know is if it will catch an unprocessed request at that point. I suppose if the start date is in the past and it is unprocessed the query ought to find it, just like it would be if the driver had been turned off for a while.

In fact even the Roles that define access to the User Application roles themselves are granted this way. What that means is, during configupdate.sh, you can assign all the Roles to one user (by specifying the same LDAP DN of the user for all the different security roles that are listed) or you can choose individual users.

The Roles are:

• Compliance Administrator

• Provisioning Administrator

• RBPM Configuration Administrator

• Resource Administrator

• Roles Administrator

• Security Administrator

IDM 4 has a Reporting Administrator as well and possibly one more Role.

As it turns out, there are a couple of cases where you need to be two Roles at least to do something, and if you do not have any single user with both of those Roles it is a pain to fix that, without a single user having sufficient rights. If you wanted to grant the Resource Role to someone else you need to go in as a Role Administrator grant the Role Admin right to a Resource Admin then that Resource Admin (who is also a Role Admin) can now grant the Resource role to someone else. Very annoying the first time, but once you have a couple of users set up it is not a problem. Additionally the Roles Mapping Administrator utility in IDM 4 runs through the User Application's security model, and therefore requires that any one using it have Roles and Resources Administrator rights before they can do much of anything in it. This makes some kind of sense since they will be defining Resources or Roles in the process of using the RMA tool.

Interestingly enough, the Role requests are not issued when you would expect. It is not the first time you start Jboss, nor the first time you login to the User Application. Rather the Role Requests are issued the first time a web browser requests the JBoss server to display any of the User Application user interface (like the login page) which requires JBoss to unpack and instantiate the IDMProv.war file. This is the key event. Which is somewhat surprising to me, I would have expected either of the two times I suggested at the beginning of this paragraph. Different strokes for different folks I guess.

Granting all the rights to one user or each right to a separate user is usually just an issue at first, so I now take to following John DaSilva's advice and make your User App Admin user the Domain administrator for all the various things, then later grant the specific rights to specific users. It just makes things much easier across the board.

As it turns out the User Application Administrator account is stored in the User Application database, and the first one granted cannot be deleted, though additional ones can be added. This is NOT processed via the Roles model, but is rather set via configupdate.sh.

These two sets of rights, the User Application Administrator, and a bunch of domain administrators Roles (7 or more) and they are independent and annoying to fix if you are missing any.

There is a very common case where the Roles you set up in configupdate.sh are just plain not set. There are actually a couple of issues that work together to cause this problem, and of course they can be a problem independent of each, which just makes it even better.

There are two main root causes:

1. Not enough memory when you first run UA in Jboss (start-jboss.sh) causes it to die midway through issuing roles.

• Designer bug with the first GCV of type DN not working. Check the Roles and Services Driver, driver config, for the User container. It probably has the User App DN not the ou=users,dc=test,dc=com

For whatever reason, the JBoss installation that comes with Novell Identity Manager, defaults (or did default) to use 256 MB of Java heap. In theory this used to be enough, but with the RBPM module my experience is that most times, on startup of the User Application it will run out of memory midway through issuing the security roles. This is a lousy situation to be in, since they are issued, but not completely, leaving to bizarre results. I have a trace from the server of this happening, and was lucky I caught it, otherwise I would have had no clue why some stuff was working and others were not.

The server.log from your JBoss will show a long series of events something like this one, as it issues the Role Request.

2010-09-16 12:31:21,761 INFO  [com.novell.idm.nrf.service.RoleManagerService] (http-0.0.0.0-8080-2) [Role_Request] Requested by cn=admin,ou=admins,o=acme,dc=com, Target DN: cn=securityadmin,ou=Security,ou=admins,o=acme,dc=com, Source DN:cn=secAdmin,cn=System,cn=Level20,cn=RoleDefs,cn=RoleConfig,cn=AppConfig,cn=User Application,cn=IDM,ou=Drivers,o=acme,dc=com, Request DN:cn=20100916123121-e080d05cee9f4df3801bb878e315a402-0,cn=Requests,cn=RoleConfig,cn=AppConfig,cn=User Application,cn=IDM,ou=Drivers,o=acme,dc=com, Request Category: 10, Request Status: 0, Original Request Status: 0, Correlation ID: 5443c88adc2642a38417434a6c6a73d3

You can see a number of things from this request, and it is worth picking apart to better understand. It is tagged [Role_Request] which makes it easier to find in trace. (Which is why I paste it into this article so the Google cache will be able to find that string!) Note the requestor is there, the target objects DN (who is getting the Role) is listed, the Role DN is listed as the Source DN for some reason, which you can see is buried in the AppConfig container under the User Application driver container.

What is more interesting to me, is you can see the Request DN, that is the object that holds the request so you can go look at it. You will see dozens of these requests generated the first time. If you do not have enough Java heap for JBoss then it will die midway through the process.

The second error is even stranger. I have seen other people report it, but none of us seem able to reliably reproduce it to get Novell to fix it. If you have a way to reproduce it report it. Anyway, there seems to be something wrong with how the Designer history for DN configuration attributes works. It seems to only affect the first item on each page in Designer (and not all of them, which is so frustrating!) I have seen it with Global Configuration Variables (GCV) before, and this time it is on the Driver Configuration page. The first item on the page is the User Container. This should be something like ou=Users,o=idv, and you probably even typed it! However Designer for some reason decided to set it to the value of the User Application drivers DN. If you start typing in the field you will see it jumps to some somewhat strange values in the history buffer and won't accept much else.

When it is a GCV, what I usually do is change the GCV type from DN to string, and just type the right value. When it is a Driver Configuration value, you are not supposed to directly edit them, but the good news is you can click on the Edit XML button and just edit the underlying XML. Change the type='dn' to type='string' and you should be fine after that.

It is quite annoying, and trivial to fix, once you know it is about to happen. I wish I could force it to happen on demand, so I could report it to get fixed.

The reason this matters, is that the Roles and Services driver will see the Role requests issued, if you had just fixed the first problem, look at the Target DN, say, oh that user object is not in the User Application driver container (the nonsense value Designer has erroneously added to the value) and declare it out of scope. So the rights get requested, and then ignored. By fixing this setting you can then get the Roles and Services driver to work and process such requests.

Now once you fix these two issues, you are still goofed up, since the User Application only ever happens at the first time the WAR is unpacked. This is somewhere a button in the User Application to do it would be helpful, and once you read the steps you need to take to fix it, you will see why I say that!

For IDM 4.02 and 4.5 the good news is that this is much easier. Configudpate.sh now has an option to Reinitialize RBPM Security, which does the same thing as all the work detailed below. Thus if you are using IDM 4.02 or 4.5 do not try the steps below, use configupdate.

In 4.5, you just launch configupdate.sh (or .bat if you are running Winders) which looks like this.



Then you can click on the Advanced Settings and at the bottom you will see the Reinitialize RBPM Security.



With 4.02, you might have to edit the configupdate.sh script, and at the end, when it calls the actual command, there is an edit_admin="false" that has to be set, before the button is visible. (Also the use_console="true" option can be set here to avoid using the GUI).

For IDM 4.0 and 4.01, it is a lot more work, but the steps are all documented in the docs, (Section 2.13 of the User App Admin guides):

For IDM 4 (which is the same exact approach as in RBPM 3.7) check this link: http://www.novell.com/documentation/idm40/agpro/data/bncio25.html

You need to find the Configuration object, that is in the AppDefs container, under the AppConfig container, which is where the User Application configuration information is stored inside the User App Driver object. The docs describe it as:

%DriverSet% -> %userApplication Driver% -> AppConfig -> AppDefs -> Configuration. 

You need to look at the XMLData attribute, which is a very long XML blob of data, and look for the entry:

<property>
        <key>com.novell.idm.security.domain-admin.initialized</key>
        <value>20090831124642Z</value>
</property>

Then you need to delete this node of data. This is what tells the User Application that it has issued the first rights grants, and what is preventing it from doing it again. Not the entire XMLData attribute, just the one small nodeset within it. I have used Console1 and an LDAP browser to do this. Both work, and iManager should work as well. It is usually easier to copy the entire text into a real text editor, find the node, delete it (from <property> to </property>) and then paste the text back in. But whatever way you want to approach it should work.

Now the docs say you need to have JBoss stopped, the driver stopped, wave a chicken over your head. But in my experience it is sufficient to just restart JBoss after doing this change.

Next time you hit the WAR file with a web browser after a JBoss start, and the WAR unpacks itself, it will issue the roles again. Then you should be able to login as one of the users you assigned and see the appropriate set of Roles.

This is one of those really annoying things to fix, as until you update the Configuration object's XMLData attribute by remove the domain-admin.initialized setting, no matter what you do in configupdate.sh will not make a smidgen of a difference. Personally I think, if the data in configupdate.sh is changed, then the User Application should reinitialize the roles again by default to save all the pain of this process.