The release of Identity Manager 4.02 while a minor update brings with it a number of changes. I think it is worthwhile to discuss some of them.

Of course included in this release are bug fixes that have accumulated since the 4.01 release but it is the new features or else well known bugs that I think are of interest that I intend to discuss.

At a high level at least the list of fixes for 4.02 seems to include:

• Digital Signature support re-introduced (Integration with Crypto Vision)

• Improve the revocation process when deleting a Role with Resources or Removing a Resource from a Role - Performance improvement

• Option to require approval for a user to remove an assigned Role (Same approval during the granting of role)

• 64-bit SAML methods for Windows

• Ability to purge historical data in reporting database

• Support for EAS on RHEL

• New reports as part of Content update

• Better Analyzer scalability (currently it support 50K entries, this limit will be enhanced)

• Improved Designer performance

• Designer optimization for optional sync of roles/resource catalog

• Integration of RMA & RBPM code map tables

• In RMA, option to include connected system name for auto-generated resources

• Password policy enhancements to catch with the latest MS complexities

• Bi-directional eDirectory driver

• Updated drivers & driver content

For this first article I would like to focus on the Engine and Designer side changes. As you can see from the list a fair bit of the improvements are focussing on the User Application, Roles Based Provisioning Management (RBPM), Reporting, and RMA.

From a driver side, there are at several new drivers included in IDM 4.02 (there were three in 4.01, RSA, Blackboard, and Google Apps) the Bidirectional eDirectory driver and a Banner driver. On top of those two, the JDBC driver configuration, that used to be one config file for multiple database types has been broken out into packages, one set of packages per database type. This will probably be grist for many many more articles dissecting all the policies in the packages.

• DB2

• Informix

• MySQL

• Oracle

• PostGresSQL

• SQL Server

• Sybase

The Banner driver is used to connect to a Student Information System that is commonly used, known as Sunguard Banner. Usually when called in as a consultant we end up doing database drivers to connect to Banner, but with this driver, you are able to use a SOAP like driver, which talks to the Banner system. This was technically released a little before the IDM 4.02 release, but lets just call it part of it since I have yet to review this driver otherwise.

The Bidirectional eDirectory driver is something they talked about 2 years ago at BrainShare and is finally here. It is a single driver, that basically treats eDirectory as an LDAP server, and uses much the same approach to connect. For this to work, in fact it was eDirectory that had to change, and there is an additional piece for eDirectory needed, called changelog, that once installed tracks changes in the remote eDirectory to send to the driver. I have a series of articles on this driver that should come out around the same time as this, walking through the packages that make up this driver configuration. This should be a big improvement since the footprint on the connected eDirectory is much smaller (a single eDir 8.8.6 (or maybe 8.8.7, we will see what is supported at release time, and then the changelog module installed) than the previous model which was install IDM in the second tree, and have half a driver in each tree with the amusing certificate issues (two Certificate Authorities involved), and complexity of coding since half of the driver is one tree, and the other half in the other tree. Thus the eDirectory driver was actually the most complex of all drivers to wrap your head around as a beginner.

From an engine perspective, like IDM 4 itself, very little changed on the engine side. Following bugs, a colleague (Thanks Will!) found that there will be two new tokens, Add Resource and Remove Resource, which will be helpful. Like the Add and Remove Role tokens we already have they will really be wrappers around a SOAP call to the User Application endpoint. That means when they are called, the event is submitted to the User App queue, and processed when it gets around to it. But like other calls of this type (Add/Remove Role, Start Workflow, Send Email) there will be error variables to detect if the call to the User app fails at least.

IDM 4 introduced a single new GCV as far as I could tell (dirxml.auto.localserverdn which is the DN in LDAP format where this driver instance is running, something very hard to determine in the past). Alas, Designer has a bug that it showed it in the list when your vault was set to IDM 3.6.1. This one is fixed in Designer 4.02.

The second point in my list, is a performance increase for the Roles and Resource Service Driver (RRSD) which is important since it can get quite backlogged. The RRSD driver watches for nrfRequest objects appearing under the User App drivers AppConfig container. When you click Assign Role (or call the token, or use a workflow, etc) what actually happens is an nrfRequest object is created with all the information needed.

The RRSD driver sees it and implements the results. This means added nrfAssignedRole and possibly Group or OU similarly styled Role and Resource assignments. However in a properly implemented RBPM model it would be expected that a single Level 30 Role Assignment (Perhaps Job code out of SAP/Peoplesoft) would indicate a hierarchy of Level 20 Roles, each of which has one or many Level 10 Roles and possibly one or many Resources assigned to those Roles. Thus a single Role assignment could conceivably imply dozens if not hundreds of changes. Now imagine you bulk loaded in (via a driver or just plain LDIF) a stack of Role assignments. You can see how the expansion of simple things to complex things could overload the RRSD driver. The specific fix listed is related to removing a Role but you can see how it might apply in both directions.

Other than that there does not seem to be much new in terms of features of the engine.

I have been following bugs that either I or someone I know has submitted and they often reveal a fair bit of information about changes made. There are a number I have been involved in that are nice changes in 4.02 so I will try and cover some of them now.

From a Designer perspective, I have been nagging the development team to fix memory leaks on a regular basis. They have found many such leaks, and over the Designer 4 to 4.01 to 4.02 (with Auto Updates in between) timeframe they have done a lot of cleanup. Alas, memory leaks are a death by thousand paper cuts issue, so there are always more. The benefit to these fixes is that the garbage collector in Java has less work to do on each pass, as it can clean up the memory once, instead of having to look at it each pass, and decide to leave it alone. This leads directly to performance increases. Often in Designer when the whole thing freezes it is the Garbage collector running that is freezing things up. (But not always). I know there was a memory leak in Document Generation which was leaking about thirty megs on each run, for a standard Active Directory driver. This was fixed but alas, Doc Gen is still a memory hog, and for large projects just plain won't work. Designer still uses a 32 bit JVM so I find I cannot get more than 1.2 GB of RAM out of it, which severely limits how big a project can be doc genned.

Switching between open tabs has really improved performance. Part of the core issue is that each tab or editor open in Designer keeps its own copy of the entire project in memory. Thus really big projects are slower than smaller projects across the board. Alas, the Package Catalog counts as part of that, and if you import every Package into your catalog you will a reasonably large project before you even start your drivers. I did not manage to find out the details but there was some change made that the penalty is still there on the first tab switch, but switches after that should be much faster. I tested this with my torture project (Every Package, and every version of them I have, and 100 drivers) and it really was much faster which is a pleasure.

On the topic of too many Packages, once you have them imported into a Project you could go delete unused packages if you had the time, but the default (Import all) would leave you with a LOT of mouse clicking to do it, since you have to expand all the way down to the version level to delete. The good news is there is a new menu option at the Package Catalog level that is Remove Unused Packages. I have not experimented to see its definition of unused, but it is a great first step.

Perhaps my favorite change, especially as I write my driver walk throughs, is a new preferences setting, that hides the silly "This is packaged content" warning you get every time you open packaged content. It appears to default to off as well, which is nice. (Windows, Preferences, Novell, Package Manager, Package Based Policies). I really appreciate this change.

Alas, on the downside if you are often building packages there is a change that is generally positive in terms of Package versioning but it breaks backwards compatibility. The version number of a Package in 4.0 and 4.01 was in the format of x.y.z (1.0.7 or the like). But now there is a datestamp appended to the end of the version. This solves an important issue where you build a JAR, test it realize it has a mistake, build again, but now the same JAR, the same version, different contents and this can cause all sorts of pain. By appending a date stamp so that 1.0.7.20120514121212 is the version string, I can basically build a new package every second without running into issues. Alas packages made with this version number show up for Designer 4.01 but cannot be used, you get a flash of a screen and it fails, no error. Also if you have two 1.0.7 builds with different datestamps only one shows up in the catalog with Designer 4.01 and when you delete one, the other suddenly appears.

Until you are ready to switch the whole team over to Designer 4.02 you will have to keep this in mind if you are building Packages.

There are by my last count 126 new or updated packages in Designer 4.02 (My last count was well before release, but close to code freeze, so probably pretty close). Some of the updates have notes in the Readme explaining what has changed by referencing a bug number. But alas, that is a small subset of the packages. Many will be versioned up to 2.0.0.datestamp builds, for reasons that escape me. (I would have gone with 1.2.x instead of 2.x.x to keep in step with the 4.02 release, but that is just me, I hate wasting version numbers, there are only a million combinations so it feels cramped)

Since Novell/NetIQ is not going to do it, I am hoping to organize folk to help out and do it ourselves, since realistically we all need to know, so might as well pool our efforts. \

The good news is there are two types of changes possible, one is easy to detect and the other not so easy. The easy ones are Policy and object changes that are represented in eDirectory. Just push a 1.0.1 driver build to an eDirectory/IDM server. Then in Designer 4.02 upgrade the packages to the latest build (say 2.0.0.datestamp) and then do a Compare. It will show you all the changes very nicely, and you can reproduce the compare at will.

The second category has to do with changes that relate to Package prompts, where the results are represented in eDirectory (Different prompt values, Remote Loader values, etc) after an upgrade. These are trickier, and I have no good solution. I know that all the base packages that can use a Remote Loader have one such change like this, since I reported the problem. I will discuss those in the next article.

My hope is to convince folk to tackle one or two of the upgraded packages, and if we can get enough people it will not be that onerous a task. Just write it up, submit to Cool Solutions. I will do as many as I can, but I could sure use some help from the group.

The other good news is that of that 126, there are about 50 or more that are new for the new drivers, so it is not entirely as bad as it looks at first, still a lot of work.