What has Changed between Identity Manager versions part 1:

Recently Novell shipped Identity Manager 4.0 Advanced Edition. This is a great new release of Novell Identity Manager and has lots of fun new features.

The high level list of new stuff like a small list, but much of the functionality will have really powerful repercussions on how IDM is used in the future.

There are some high level things like two new drivers (well 4 actually, two are needed for the Reporting service) for Sharepoint and Salesforce,com. The Role Mapping Administrator tool is very useful and something that should be really interesting as it develops. The Reporting service will be a great help as well.

Of course there is a new and updated Designer, now at version 4. I started using Designer 4 on a new project I was working on (actually using IDM 3.6.1 since they are not yet licensed for IDM 4) and tried adding a feature that was not supported on a IDM 3.6.1 engine. A pop up box came up (which was a nice warning) with a link to some documentation on new features within IDM 4. You can find the HTML files in your Designer install (assuming you installed it to c:\Program Files\Novell\Designer) at:

file:///C:/Program Files/Novell/Designer4/plugins/com.novell.idm.doc_4.0.0.201009290717/html/app/appversions.html

What I found quite interesting though was this page:

file:///C:/Program Files/Novell/Designer4/plugins/com.novell.idm.doc_4.0.0.201009290717/html/app/appvkeydiffs.html

This listed the main new features added in the different IDM versions, starting with IDM 3.5, through 3.6 and on to 4.0. This I found quite interesting, as I often forget when a feature was added. This is most painful when I have to go back to IDM 3.0 installs and do work. This was so painful I wrote up a set of workarounds for some of the pain points I often encountered working in IDM 3 after using IDM 3.5 and higher in this article: Working in IDM 3.0.1 after using 3.5.1

I thought that the table of changed items was sufficiently interesting that it would be worth an article on the topic and take a trip down memory lane.

IDM 3.5 new features:

• New object types were added:
  
  
  
  • ECMAScript Objects
  
  
• Jobs

• Mapping Table Resource Objects

• Resource Libraries

• New Policy Linking capabilities where a policy can be in multiple lists

• Many new DirXML Script actions, conditions, tokens, and verbs

• Ability for DirXML Script to nest conditions

• Driver-scoped local variables in DirXML Script that let you refer to variables outside of the policy

IDM 3.6 new features:

• Support for 64-Bit operating systems

• New installation program

• New driver configuration files

• Driver health monitoring

• New ID Provider driver

• Reciprocal Attribute Mapping

• Additional DirXML Script elements

• Nested group support

• User Application

IDM 4 new features:

• Integrated installer

• Packages
  
  
  
  • Installation
  
  
• Management

• New Resource Objects
  
  
  
  • Global configuration resource objects
  
  
• Package prompt resource objects

• DS resource objects

• SharePoint driver

• Salesforce.com driver

• Identity Reporting Module

Lets talk about some of these features, starting with IDM 3.5 and work through till we are done.

Many of the new features are deeply integrated and require each other. For example for Library and new objects to be useful, the linkage model had to change. The old Policy linking approach before IDM 3.5 was that each step on the fishbone diagram, for each channel, there was an attribute pointer. That is, the Publisher container object had an attribute called DirXML-CommandTransformationRule that had the DN of the first policy in the Command Transform, for the Publisher channel. That referenced object had an attribute that pointed at the next policy called DirXML-NextTransformation, which was also a DN reference attribute.

Thus you could have the many Policy sets in the fishbone diagram, and have many policy objects linked together. The major downside was if you wanted to reuse a policy in say two drivers, or in both channels (Since you can test what channel you are in, you could have one policy object with a Subscriber version of a rule, and a publisher version.) or some other combination.

Due to the linked list nature of the linkage, this would mean that any following policy objects, referenced by the DirXML-NextTransformation would be linked in as well, making it pretty useless.

With IDM 3,5, the linkage model changed (iManager and Designer will convert from the old to the new format for you, if you are upgrading) to use a single attribute on the Driver object that is multivalued and lists all the links within the driver. The format is very different, as it is now Path syntax, and has an identifying integer so it can know which Policy set (Chevron on the fishbone diagram) the link is for, and also so it can order them correctly within that policy set.

Once they changed the model, suddenly a central place to store Policy (and other) objects, outside the Driver object container itself started to make sense. Once you can start adding interesting arbitrary objects, they added a couple of fun ones. Like ECMA Script objects, Jobs, and Mapping Tables.

What is clever, is that if you look at how the objects are defined, in fact several are DirXML-Resource objects, and they have a MIME type like attribute, DirXML-ContentType that specifies which type of Resource object the specific instance is. (As it turns out, Jobs have their own object class, DirXML-Job but you get the idea. This will get extended further in later IDM releases as we will see).

While ECMA Script objects are listed as a new object class, that is probably the least interesting of what they provide. That is, to call an ECMA function, you first create it in an ECMA Resource object, then you can call it via the es: namespace. In other words the important thing that was added was support for ECMA Script. That it happens to be stored in a new object type is somewhat of a boring detail. (In IDM 4, ECMA Resource objects can be linked to the User Application driver, which makes them available in the Provisioning workflow, which is a lovely and long awaited enhancement!)

I started an open call article to try and collect useful ECMA functions, for an IDM developer. You are welcome to contribute or use any there as needed: Open Call for useful ECMA functions to use in Identity Manager

Mapping tables also bring with them a great token, the Map token. This is what uses the Mapping table resource objects. I have come to greatly enjoy using mapping tables, they simplify so many things. You give it two parameters, the source column, and the destination column, and based on the value it gets passed (its a Verb, a lightning bolt icon, so you have to nest some Noun token to provide the input) it returns the destination columns corresponding piece of data. I leveraged this really heavily in a SOAP driver to SFDC that I had been working on. Stored lots and lots of configuration information in the mapping table. In IDM 3.61 this gets a minor enhancement, such that if you give a value as the source, but it is not found, it returns a predefined value. This is easier than trying to detect NULL as returned. But also lets you provide a default value if nothing is found.

The item "Many new DirXML Script actions, conditions, tokens, and verbs" is very true. I have seen a document, which I of course can no longer find that tried to show when each token was added and modified based on IDM versioning. In general not that interesting, but somewhat useful to know at times. Perhaps the best new tokens added are referenced in the next item, the ability to nest conditions. This is referring to the IF token.

Previous to IDM 3.5 if you had complex conditions, you ended up chaining a set of rules, so that you could use the Condition blocks to add additional conditions. You could also use a for each loop and XPATH as the nodeset to generate two different outcomes, allowing at least a simple form of nesting conditions. However, with IDM 3.5 came the wonderful IF token. When I have to go back and work on IDM 3 I cringe due to its absence. It is so much easier using a straightforward IF token, then trying to reinvent it otherwise. Of course, conditions were available in XSLT, but I much prefer using DirXML Script over XSLT whenever possible. You can read more about my thoughts on that in the article: Open Call: What Can You Do in XSLT that You Cannot Do in DirXML Script?

The Time and Convert Time tokens are some of my IDM 3.5 favorites as well. Before you had to call into the Java time library functionality. This was not too terrible, but you had to learn the syntax for using it. The IDM 3.5 tokens have a truly excellent wrapper interface on top of it. The iManager and Designer versions are mostly the same, except that Designer has one key extra feature. A Test button. You can define your formatting strings for the time values (source and destination, when using Convert Time) and then click Test, and it shows the current time in the formats you specified. Great stuff! You can read more about them here:

Using the Time Tokens in IDM 3.5

IDM 3.5 - Update on New Features

I am pretty sure that the Query token arrived in IDM 3.5 as well. The Query token, like the Time tokens is really a wrapper around an existing Java class. You could do almost everything in a Java call that the Query token can do, but the Query token does it so much better! The user interface makes it trivial to manage looking into the source vs the destination datasource. Doing an entry, subtree, or container search. You can use all the power of Argument Builder for filling in the needed data for most of the fields, instead of needing to have constructed an XML nodeset however you choose to do it. Of course this means I no longer remember any of the syntax for doing it the old way, and I do not mind! The Query token is a huge and positive improvement. You can read more of my thoughts on it in this article: The Query token in Identity Manager

I was surprised when I looked back in my notes to realize that the Split and Join tokens only arrived in DIM 3.5. These are great tokens that come in handy all the time for taking a delimited list and converting it into a nodeset of values (Join token), or taking a nodeset of values and splitting it into some kind of delimited list. You can read more of my thoughts on these tokens in this article: Join and Split tokens in Identity Manager 3.5 and higher

An intriguing use for these tokens might be for managing Structured GCV's (which were introduced in IDM 3.6) which have a very interesting property. If you treat the GCV in a string context, you get a delimited string with all the data in it. (Using the various delimiters you specified to separate instances of the Structured GCV, and then another separator to keep apart the various GCV's that make each instance). If you treat it in a node set context, you get a node set that looks much like the information stored in the GCV's definition in XML. If you have it as a node set, then you can XPATH out specific values as needed quite easily. But if you need a simpler case, you might find the ability to split a delimited string back into a node set, or perhaps series of node sets, you have that option.

The Unique Name token is a great enhancement, since most people had to write their own approach to generating unique names for object creation. Well the Unique name token just does it so nicely, and with a really clean and simple user interface. Read more about that in this article: Unique Name Token Functionality in IDM 3.5

There are many more tokens, but these are the interesting ones I remember.

Finally the last feature mentioned was driver scoped local variables. These turn out to be really useful, when you need to store, say a session key for your connection. (As in perhaps a SOAP driver). That is, one set of policy might login to get the session key, that is only valid for some time period. But many other policies need to use the session key to send events on. Or perhaps you might want to store the last time something happened, or a counter, so that different parts of the driver can use it under different circumstances.

Really a nice touch. Of course, I would like a little more granularity in scoping, but what else is new?

That covers much of the highlights of IDM 3.5. Stay tuned for the next part where I will focus on IDM 3.6 new features. The on to IDM 4 features, many of which I am still learning about!