With the release of Novell (NetIQ now) Identity Manager 4 SP1, in addition to the release of the Standard edition license, three new drivers an RSA Driver, a Blackboard driver, and a Google Apps driver.

I discussed some of the new features and bugs fixed in IDM 4.01 in this series of articles: New features in IDM 4 and 4.01.

I have been working on a series of articles walking through driver configurations, policy by policy to try and understand what the driver is doing, under the covers.

You can see more of these walk throughs on a Wiki page I maintain to keep them all together:

Having done SIF, Google Apps, and Blackboard driver walk throughs, it seems like the obvious next driver is the RSA driver, so as to complete the IDM 4 SP1 set of new drivers. I suppose at some point I should do the Sharepoint and Salesforce.com drivers that came with IDM 4 base, but that is for another day. Doing things out of order is more fun anyway.

The RSA driver is meant to provision users onto an RSA ACE server. I dunno what any of that means, its all just letters to me. But you know those key fob thingies with the random seeming number on them that changes every 60 seconds, that they use for VPN access? You need an RSA ACE server to use them, and this lets you provision users onto it automatically.

Like the Blackboard and Google Apps drivers, the RSA driver is contributed by a partner TriVir, who do very good work. If you have not seen their automated testing tool for IDM called IDMUnit that runs inside Designer, you should probably stop and go take a look at http://www.idmunit.org/

This driver comes with two packages only, RSA Base, and RSA Default Configuration. This sort of makes sense as many of the other features that come in packages like Password Synchronization are not really relevant since there are not quite any passwords in RSA per se. There is a PIN but you cannot sync a regular password.

There is a 1.01 build of the packages, that was released after the first release of the Packages, alas there is no Readme on any of them, so it is hard to know what they might have fixed between versions. One approach to figure out what changed would be to deploy a 1.0 build to an eDirectory server with the IDM engine on it. Do not start it unless you want too. Then in Designer, upgrade the package to 1.01 and then do a compare. This will show all the changes between the deployed 1.0 build and the Designer 1.01 build.

However I admit I have not tried that to see, but will suffice with reviewing the latest package build at the time, 1.01.

This is another one of those Subscriber channel only drivers. That is, you can send events into RSA's server, but you will not get events out of it, nor can you synchronize users out of the RSA server. But that would probably not be a good model, to use the RSA server as a source of users.

Starting at the filter, we see that there is one class, User, and it supports three attributes, CN, Given Name, and Surname. These are set to bidirectional synchronization, but I imagine that there are no real events generated on the publisher channel in this regard.

Next lets look at the Subscriber Channel, the Event Transformation policy set has but a single Policy object with one rule.

TRVRSADCFG-sub-ep-DefaultFilter

The rule is Filter Events and it blocks move and rename events. I suppose since the user in RSA is more about the token than a user name that sort of makes sense.

The Matching Policy Set has a single policy object.

TRVRSADCFG-sub-mp-MatchUser

     Exit if not user

First it scopes this to User events, which since this drivers filter is just for User objects is probably not neccessary. If the class is not User, then break.

     Exit if CN not available

This rule looks for the operation attribute CN and if not available skips the match process.

     Execute User Match

This rule calls the Find Matching Object, using CN as the match attribute.

Of course they could have consolidated this all into one simple rule with two conditions. If Class name equals User and if operation attribute CN is available.

But there is minimal difference between these two approaches.

TRVRSADCFG-sub-cp=CreateUser

The create policy set has one policy object and two rules in it.

     Exit if not user

This breaks if the class is not user.

     Require attributes

This rule is a classic Create rule, and looks for CN, GIven Name, and Surname in the operational event document. If the operational attributes are not available it vetoes the event.

The Command Transform is empty, and there is no Output or Input transform rules. Which is interesting. It seems like this driver is not really scoped to use entitlements or anything else. A very simple driver, very basic.

The Schema Map maps an extra attribute, accessCardNumber to TokenSerialNumber, which is interesting as it is not in the filter, so seems like it would never quite make it through. CN maps to DefaultLogin and the name parts map to obviously similar name parts.

Publisher channel:

There is but a single policy object on the entire publisher channel, that is in the Event Transformation policy set.

TRVRSADCFG-pub-epEventFilter

There is a single rule in this policy object.

     Filter Events

This rule vetos add, move, and rename events. This is interesting as I would not expect to get such events out of the RSA system. If the shim can generate such events that it needs to be vetoed it would be nice to be able to do something with them.

Reading the documentation, it almost seems like you can get events out of the driver on the Publisher channel, but that is more of a hint than a clear statement. Additionally there is nothing in the driver configuration to imply this would work. I am left wondering, after reading this configuration how complete it is. This is of course a real topic to discuss. Some drivers are more mature, and more complete than others. The Active Directory is probably the most commonly used driver and thus likely the most looked over and complete, and yet bugs are still being found in the default configurations! (I know several new packages will be released for the AD driver in IDM 4 SP2 since I reported some of them, and have been following the others).

That is about it for the entire driver. Really a very simple driver, more so than I actually expected, to the point I went looking to be sure I did not miss any packages to add to the driver!

There are a couple of things I do not see nor understand about this driver though. It looks like a very minimal config where everything is left up to you to provide. I think that adding the TokenSerialNumber attribute (aka accessCardNumber in eDirectory) to the filter would be wise as it would allow a form, a workflow, or the like to modify the eDirectory object to set the value in ACE.

Also, how you disable a user is unclear, but having looked at the docs, I suspect you would have to set a End attribute with todays date. That would be easy enough to do.

The downside is, it looks like pretty much every user in your Identity Vault would get provisioned by this driver into the RSA server. You would almost certainly want to add some scoping into the Match and Create policies to veto if the user is not in an appropriate subtree.

You could implement entitlements fairly easily for this driver I would think. Like many things in IDM there is no hard and fast rule, and you could approach this from several directions. My approach would probably mirror the Active Directory approach, since that has three different entitlements (UserAccount, Group, and ExhangeMailbox), of two basically different types. There you have UserAccount which is valued, but the value is the placement DN. This is the sort that adds an account. The Exchange and Group entitlements are meant to pretty much add an attribute (Group Membership or homeMDB) when they are assigned.

I think it would have to follow something like this, to add an entitlement.

You would define an Entitlement object probably unvalued since there seems to be no information to send along specific to this user. I would also define a GCV to control the use of the entitlement functionality. I wonder if a valued entitlement, where the value is the TokenSerialNumber might be of interest.

In the Subscriber Matching rule, check a GCV to see if Entitlement support is enabled. If it is, then check for the availability of the entitlement. If entitlement support is enabled and there is no entitlement, veto.

By doing this in the Subscriber Match rule, it means every synthetic add will end as quickly as possible if the entitlement is not set.

It would be nice to include an entitlementsConfiguration object that already has the information defined for Resource to Entitlement mappings as described in these two articles:

Convert Driver Entitlements to New RBPM 3.7 Resource Model
Converting Entitlements to Resources, more details

Having recently reviewed how the Resource to Entitlement support rules work, to add a Boolean valued entitlement at a client, it seemed the suggested model is really a less than optimal approach (I was going to use a harsher word, but I guess I know why they did it this way) since it regenerates the object on every driver start which is really silly. Of course, I realized as I did this, that since the XML contained in that object has a DN reference (in LDAP DN format no less) to the Entitlement object it is a pain to include in a package. Thus I think I will include the text in a readme, but not actually include the object in the package for this release.

Thus I see why they want to regenerate the object, but I do not see why it has to be done very driver start. Regardless I think creating it by hand, is almost a simpler and better solution than the one provided in the article, mainly because you have to update the policy to support your Entitlement case anyway, so what value is the rule? It is functionally hard coded, and does not dynamically support additional entitlements well. (It does add new ones it finds, but with no configuration information, since there is no policy to handle them explicitly, and no GCV's to provide settings, and no mapping table to provide alternate localized names, so how helpful is that?)

I would probably look into enhancing this approach to try and disable the user in RSA ACE when they get Login Disabled, or perhaps when the Entitlement is removed. That would mean translating a remove entitlement event into a set of the attribute End to the CTIME value of now. Probably would add a GCV to control this behavior, that is on a remove of an entitlement decide whether to delete, disable, or do nothing with the user in RSA.

But other than that, it does not seem like you would have to do very much to enable entitlement processing.

To support the Reporting module and its Data Collection Service driver, you might want to add in the Data Collection common base packages, and probably a MSysInfo object into the Package. To understand what all this means or implies, try my series on the Data Collection Service and Managed System Gateway drivers.

Data Collection Service:
Data Collection Service Driver Walkthrough

Managed System Gateway:
Trying to understand the Managed System Gateway driver in IDM 4

This is a cop out I know, but it really is complicated. I should write an article trying to explain what I think Reporting support means, since I have a basic Package I think should be sufficient to back port to older drivers. But I have yet to validate that it suffices.