NetIQ Identity Manager uses a tool called Designer for Identity Manager to manage and design Identity solutions.

One neat feature added in past years is the ability to do online updates. The latest such release is Auto Update 4 for Designer 4.02.

With each release, it is nice to see what has been updated and changed, and things to keep in mind, that perhaps the docs, readme, and TID's might not make entirely clear.

I have tried doing these What's New articles for several of the past releases. Comment and let me know if they are helping, please!

• Designer 4.02 Refresh has Been Released

• What’s new in IDM 4.02 – Part 1

• What’s new in Designer 4.02 Auto Update 3

Once you install it (about a 150MB download) you can read the What's New page from the Help menu. Hard to do that in advance.

One nice thing linked to in this release is a TID with a list of Bugzilla entries fixed in each Auto Update release. You can read that here:
http://www.novell.com/support/kb/doc.php?id=7004198

I would like to discuss some of the interesting things I see in that list.

Resource containers are now supported. In the past, in the Role Catalog, you could make containers under the basic Level 10, Level 20, and Level 30 role containers. But you could not do the same thing in Resources, or more correctly, while the User Application did not entirely mind dealing with them, Designer could not do it. That has been resolved in this build, which is a nice extra feature. I know from projects I have worked on that Role sub-containers are very helpful.

A number of the fixes listed in the TID revolve around the same basic issue, that of packages, and how it handles linkages. A number of interesting edge cases for package linkages turned out not to work so well, and this build is meant to fix a whole swath of them, by moving to a slightly different approach.

As a consequence, if you right click the Package Catalog there is an option "Migrate Linkage". This took me only 30 seconds on a project that has every single 4.01 and 4.02 Package, many Betas, and many custom packages in it. (I use this project to stress test Designer for memory leaks, so I do not mind the crazy level of packages, it is actually a feature for me). It is unclear if you can ever open this Project in a Designer 4.02 AU3 install after you run the Migrate Linkage process. But it seems unlikely. So be careful, if you are just testing, and not yet ready to commit. I have not tested what happens if you are sharing the project via SVN with folk using an older Designer build yet, so watch out there as well.

Part of this new linkage model is related to how they are stored in eDirectory. This has been an issue in the past, where a packaged driver is deployed by Designer which has the proper packages. Then you try to import into a fresh Designer missing one or some of the Packages, and while you get the policies imported, the information about Package Linkages is lost, and leads to all sorts of problems going forward.

To use this linkage model, you need to deploy new Schema changes to eDirectory. The object class DirXML-pkgItemAux needs a new attribute, DirXML-pkgLinkages. You can just use Designer to compare Schema for that attribute and push it out. The .SCH format would be:

"DirXML-pkgLinkages" ATTRIBUTE ::=
{
  Operation     ADD,
  SyntaxID      SYN_CI_STRING,
  Flags         {DS_SINGLE_VALUED_ATTR, DS_SYNC_IMMEDIATE, DS_STRING_ATTR},
  ASN1ObjID     {2 16 840 1 113719 1 14 4 1 96}
}
 

"DirXML-PkgItemAux" OBJECT-CLASS ::=
{
  Operation     MODIFY,
  MayContain    {"DirXML-pkgLinkages"}
}

Once the schema is in eDirectory, and you have Migrate your linkages, if you compare your drivers, you should see differences that can be pushed to eDirectory for the Package linkages.

Now when someone with D4.02 AU4 imports the project from the vault, even without the proper packages, you will get better results.

One of the most painful bugs they claim this will fix is related to package development, where the driver you developed on, is really screwed up in terms of linkage and you really need to build a fresh driver, once you are done. It was very annoying and directly related to the absence of these fixes. Thus I am very happy to see this fix make it in. Looking at the bug list, it is clear there were a fairly large number of issues tied to this change, which is nice to clear out those issues.

A side consequence of this, which is a huge feature improvement, is that in the Policy Set view, (Bottom left corner, usually) now has a column called Weight.

If you have ever built packages, then you will understand the pain of figuring out how to weight your policies, so that they arrive in the correct order, and interact properly with other packages. I had a set of three packages, that interacted with the SOAP driver, with 12 policy objects in the Output transform policy set. To see the Linkage setting for a packaged object, you have to right click, click on the Linkage side tab, and look at the results. I could not keep it straight in my head, and finally had to write it down on paper to manage it.

Now there is a column that will show you the weight value next to the policy name. Click on a driver in the Modeler view, then activate the Fishbone view, and select a Policy Set chevron (Subscriber Event, Publisher Command, or any of them with policies in it). You should see the names of the policies in their current order in the Policies window in the bottom left.

Packages can weight an object in several ways:
First policy
Last Policy
After a specified policy object
Before a specified policy object
Weight (0-1000)

The last one is obvious, you see the weight value (which by the way, defaults to 500 until you specify it) in the column.

First turns out to be the value of 0 (Zero). Last turns out to be the value of -1 (Negative one).

The way that Before and After weightings work, is interesting. I have reported this as a bug, and there is some discussion as to whether it actually is a bug at all. If you have a setting of After Policy X whose weight is 750, then your policy is shown as a weight of 750, which is not optimal. The same is true for Before weighting, you see the same weight value as the policy it is leading or trailing. I think it should somehow indicate it is using the Before or After setting, since two policies at the same weight will be ordered in a manner related to how the policies are added. But the Before and After will properly keep them in the desired order.

It was really easy to demonstrate these values, just by making a package with 6 policy objects and setting the Linkages to see an example of each.

To be fair, prior to these fixes, I found that Before and After linkages were buggy and did not work reliably as I wanted, so I stopped using them, which minimizes the impact of this issue in my life. But it is something to keep in mind if you are using this kind of linkage.

Overall this is a huge improvement, and I am very happy to see it. Alas, my secondary request on this feature was not incorporated, which was to allow the weight column values to be edited in the Policies view. That is, instead of multiple clicks to control the values, I thought it would be helpful to set it all in one view. (Of course, I also asked if they could use the current linkage locations, to just assign reasonable values to the existing policies being packaged, but that did not seem to get added either. I like to dream big.)

In order to see these linkage weight values in the Policy Set view, you actually do need to Migrate the linkages. I was surprised by that, thinking it should have worked on existing drivers, but it did not. When I added a new driver, in an existing project the weights showed up. Once I did the Migrate Linkage step, they appeared on all my packaged drivers.

Another big change, that is REALLY under the covers is a Package Prompts fix, to handle more complex GCV values. If you look at the GCV objects Package prompt, you will see there is XSLT that copies the existing values (if any) into the selector boxes, to allow customization at the time of installation or downgrade. However, I found that for complicated GCV types (everything that is not a simple single value) this was not working. It seems they fixed it for List GCV's and in earlier updates fixed it for Structured GCV's (My favorite type!).

This is a pretty complex problem, since a structured GCV can have many instances, of a pattern of GCVs. That is, I could make a Structured GCV, that had a DN type (To reference an object), a String GCV (To give it a name), a List GCV (perhaps a list of actions to take), and maybe even a password reference. But then I could have 4 such instances configured, for 4 different cases. As you can imagine, reading each value in each part, copying that in XSLT, and handling the case where there were three instances and now four, is quite tricky.

This is the default template for the Package Prompts object, with the GCV Prompt setting selected. If you have your own package and want to update it, go make a sample package, generate the prompt, copy the XML, and paste it into your package. If you need to do a bunch of them, there is a way... Ask me... It is kind of neat.

Another interesting add on that I know was bugging me, was when you compare two policies with the very new cool Compare policies feature added in AU3, it would show you the name of the Policy in each compare window. But what if the two policies were named the same? Oops, how did you know which was which? I used to have to go make a change in one to identify it, a sort of silly work around. That has been changed now to have the full name of the policy, including where it is installed, so you can see which driver it is coming from and decide which one is which easily. A simple UI fix, that is very helpful.

Another nice little tweak that is fixed was buried deep in policy things. If you have a condition that has an equality test, like If Local Variable, and you change the type of compare from equal to not-equal, if you had specified Case Sensitive, or Regular Expression, it will not be lost. Before when you swapped from equal to not-equal, you would get the type of compare reset to Case Insensitive. This burned me a couple of times, when I would forget to set back the Regular Expression mode. Glad to see it fixed.

There are some other bug fixes listed, like being able to have a Role in two different containers (which eDirectory allows, since their DN's are unique) but Designer would not allow it. Which can be a real problem with large role environments.

Amusingly, one of my favorite fixes (ok, I like the column of Package Linkage weights the best, but second favorite) is simply the fact, that when you hit Check for Updates from the Help menu in Designer, it tells you that the update is actually Auto Update 4, before you apply it! I believe there is even a link to the TID with all the updates as well!

I am very glad to see that, where before it was just, there is an update with very little information.

I hope this article will help others decide if they are ready to upgrade. Please comment if you find any interesting new features I missed, or bugs. I know there are couple of silly UI glitches reported already. Hopefully that will be it.