Wikis - Page

Working in IDM 3.0.1 after using 3.5.1

Geoffrey Carman Super User

0 Likes

over 3 years ago

Working in IDM 3.0.1 after using 3.5.1 for a while:

The changes between Novell Identity Manager 3.0.1 and 3.5.1 while mostly minor, turn out to be more important than you might imagine.

I recently was working at a client using Identity Manager 3.0.1, after being immersed in a bunch of Identity Manager 3.5.x projects.

I found myself time and again saying, "Thats easy, I will just use the token.." and trailing off as I realize, IDM 3.0 does not have that token available.

I felt almost crippled back in 3.0. How ever did we get things done in that version. Makes me scared to try and think how we managed to work in IDM 2.x!

Having just gone through that issue myself, I thought it would be useful to review options to work around some of these issues, for people who experience the same situation as I just did. But almost as important, as an important nudge to locations still using IDM 3.01 to consider upgrading to 3.5 or 3.6. (At this exact moment in time, (please note the date of the article, since in the near future I expect this to change) I would NOT recommend IDM 3.6 for most users. That is, before the release of eDirectory 8.8.4. Currently IDM 3.6 is only supported on eDirectory 8.8.3. It is supported in a migration configuration, but not beyond that, for earlier versions of eDirectory 8.8.x. eDirectory 8.8.4 is coming as part of the OES 2 SP1 release sometime soon. When that happens, I expect my recommendation to change.)

If you have read any of my other articles, you will have seen a series I wrote on new tokens in Identity Manager 3.5. That sums up some of my favorite tokens.

Query: The Query token in Identity Manager

Unique Name: Unique Name Token Functionality in IDM 3.5

Time/Convert Time: Using the Time Tokens in IDM 3.5

Map and Mapping Tables; Mapping tables and Render browsed DN relative to policy option

There are many other new tokens in Identity Manager 3.5 that are really helpful as well.

It is amazing how much you can miss the little things. Probably the most important token that is in IDM 3.5 and not in 3.0 is the IF token. The ability to test a condition and nest the tests inside a policy is so powerful, I have no idea how we lived without it. In fact, as I was trying to build a rule, I really felt crippled without it. I have been building utility rules to fix data in the tree, which basically lives and dies by the if-then token.

Probably the best work around, is to use a series of rules, each one testing the condition. This gets bulky very quickly.

The query token is something I miss a great deal. I can do it via calls to the Java srcCommandProcessor and destCommandProcessor, but the nice wrapper token is so much nicer to use.

An example would be to Query the destination data store (lets say its Active Directory, and we are in the Subscriber channel) for an attribute, actually lets look for the destination DN. This is one of pet peeves with the way DirXML Script is built, that you cannot ask (even in IDM 3.5) for the source or destination DN directly. You need to get a query result document, and then use the XPATH of -dn ($VAR-NAME/@src-dn if you store the node set in a variable) to get the value.

In IDM 3.5, I would use a Query token to find the specific object, say by DN, or Association value, and then use XPATH to get the value out of the returned document.

In IDM 3.0 you need to use one of the Java command processors. Here is a snippet that assumes you have the variable $Assoc assigned to the Association value for the object in AD. Alternatively you could specify the DN in the third field and leave the second one blank.

Please note: This particular snippet, is trying to get the DN of the object being referenced, more of a resolve Association to DN function (It is the /@src-dn at the end of the XPATH that does it). Someone found this article, but did not notice that distinction, and got frustrated that it was not working to query in general. Please chop off the /@src-dn in the XPATH in the sample below, if you want to entire result document in your local variable. (Also set the local variable to a type of node set as well!)

<do-set-local-variable name="Dest-DN">
	<arg-string>
		<token-xpath expression="query:readObject($destQueryProcessor,$Assoc,'','User','')/@src-dn"/>
	</arg-string>
</do-set-local-variable>

Do note that you will need to add the Java name space declaration to the policy object, either by editing the XML and editing the <policy> node to add the name space declaration, so that it looks something like:

<policy xmlns:query="http://www.novell.com/nxsl/java/com.novell.nds.dirxml.driver.XdsQueryProcessor">

One major downside of using the Java query functions is that the results are not stored in the cache for the lifetime of the policy object. See the articles about the Source/Destination Attribute tokens:

The different attribute options in Identity Manager

More thoughts on Source/Destination/Operation attribute tokens in Identity Manager

This means if you are trying to work on large amounts of data, then being forced to use this route means you loose efficiency of caching. Of course the flip side is something I ran into elsewhere, where the user was moving underneath me, while the event was running. In that case, I was very happy that the Java Query (and Query token) did not read from cache, so that I could loop and test until the value I was looking for changed, or arrived.

I used to think the Unique Name token was missing in 3.0, but I recently realized it was actually there. It just gets better in 3.5.

The absence of the Time/Convert Time token is quite painful for me. I never bothered learning how to use the Java Time class, since the syntax seemed complex and obscure. Besides, the first time the issue came up was at a 3.5 client, and Time/Convert Time tokens are such nice wrappers to the class, why ever would you want to use anything else? I submitted an Enhancement Request to ask that in Designer, where there is a Test button (Lovely feature by the way! Should be there for most any token that it makes sense for!) they should add a button that shows the Java Time equivalent command. We shall see if that ever happens, but that would make life easier.

To compare the usage of the two options (Time token vs Java time) compare these two sites:
An article about using the Time token:

Using the Time Tokens in IDM 3.5

Sun's Java Time documentation: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Time.html

Doing time conversions in IDM 3.5 is a pleasure. Doing it in IDM 3.0 via Java Time is a chore.

Mapping tables are one of those things that once you have them, you never want to go back to not having them. In hindsight however, if you wanted to get much the same functionality out of IDM 3.0.1, you can fairly easily handle certain cases.

For example, I would consider using a custom attribute, multi valued, that I specify syntax type of Postal Address. Postal Address syntax has 6 strings, 30 characters long, allowed as part of a structured attribute. eDirectory has a bunch of really interesting attribute syntaxes, some are really useful, and can be reused in really neat ways.

One interesting syntax type is Backlink. It has two fields, a DN syntax field and a 32 bit integer field. Any time you see a 32 bit integer field, you should think, that can be a timestamp! eDirectory's native time format is CTIME, which is seconds since 1970. Of course it has the Y2K-37 problem. Since it is a signed integer, about 2 billion seconds is sometime right at the end of 2036. I dunno what we will do when that date comes. Like most of the people in the Y2K issue, I am taking the approach of "Not my problem". Not just eDirectory but a bunch of databases do the same thing. Interestingly Active Directory uses a 64 bit integer field for time syntax attributes, which is milliseconds since 1601 or some such. 64 bit is such a big number, that even signed, (so I guess 63 bits long usable) gives enough range to specify time WAY into the future, (and via negative values, into the past!). Backlink syntax thus give you a timestamp, and a DN. You can use this in many different ways, but a fun one is to track events on specific objects.

Say you want to track the last time an object was touched by your IDM solution. Well just make sure that anytime you do something to an object in a driver, you add a an attribute, using the built in GCV, auto.dirxml.drivername to get the DN of the driver, and then the CTIME value for time, (easy in the Time token, not too hard in Java Time).

Anyway, back to our example of mapping tables. One feature that a mapping table has over the solution I am proposing is that a mapping table is basically as extensible as you want. That is, you can have as many columns as you need, and each value in the column is not limited in length. My notion is limited by the number of fields the syntax type has. Postal address is the syntax type with the most string fields, so lets use that, as we get 6 columns, of up to 30 characters each, which is more that most cases of mapping tables need.

Pick some object, add your custom attribute of syntax type Postal Address, that is multi valued. Now just add values with a key in one of the fields (first is easiest, but sort of immaterial), and then matching values in each additional field.

Now when you need to use it in a rule some where, you would set a local variable, say LOC-TABLE, of type node set, to the object you are using, and then you can pick out your values using XPATH. The six attribute fields are available in the node set, inside the <value> node, as <component ="string"> nodes, six of them. What is interesting about this syntax type is that all six fields are named 'string', unlike say Path syntax, which is a three part structured attribute, with an integer called nameSpace, a DN called volume, and a case ignore string component called path.

Lets assume you know the index value, say we are using location codes from your HR system, and thus in the first field is the value of the location code, and then the next column should store something useful, say container path, so that you can place the users in the correct location. Maybe the third column holds the DN of a group object they should be made users of.

To get the second column value via XPATH, set the location code value into a local variable (You could use an explicit string, but it is a more general solution if you use a variable), say LOC-CODE. Then set local variable LOC-CODE-TABLE to the XPATH of $LOC-TABLE/value[component[0]="$LOC-CODE"] to store the entire 6 columns. Then you can pick out the columns you need with $LOC-CODE-TABLE/component[1] and $LOC-CODE-TABLE/component[2] and so on, since you can use the positional notation (like specifying the location with an array in some languages) as all the component names are the same in Postal Address syntax. You could probably do all that in one variable and a single XPATH select statement, but I personally find that harder to read, debug, and understand. Thus do it in two, since it is not hugely more inefficient. I asked if you needed to use the same result a couple of times in a rule, if it was more efficient to store it in a local variable via a single XPATH statement, and reuse the local variable, or to use the XPATH select statement several times. The response I got was that they are about the same in efficiency, so do not worry too much about it. I asked it in the context of a for-each loop, that looped 10,000 times over a huge node set, and it was thought that I would not notice the difference, even over that large a loop.

No where near as nice as just using a simple Map token to get the value, nor is this as extensible as a Mapping table. But workable in the short term, till you can get around to upgrading! Also note there is a 30 character limit per field in the Postal Address syntax which can be a real short coming.

While it is possible to work around some of the features that Identity Manager 3.5 includes, it is not that easy, nor does it work quite as well.

The good news is that the upgrade between Identity Manager 3.0 and 3.5 is pretty straight forward, and should not cause many problems for you, but as always, test in the lab before doing it in production.

There are some articles about some of the issues with the upgrade, and as you can see, they are mostly minor.