Category Archives: idm

IDM – using an XPath counter

Using an XPath counter is not really that difficult, but due to the way dirxml script was implemented, one have to split the whole thing in two rules.

First setup a rule which initializes the variable which is used for the counter:


<rule>
<description>setVariables</description>
<conditions>
<and/>
</conditions>
<actions>
<do-set-local-variable name="lv_counter" scope="driver">
<arg-string>
<token-xpath expression="number(0)"/>
</arg-string>
</do-set-local-variable>
</actions>
</rule>

Notice the scope is set to driver, otherwise it will be local to the rule.

Then a rule which is using the counter:

...
<do-for-each>
<arg-node-set>
<token-text xml:space="preserve">//input/*</token-text>
</arg-node-set>
<arg-actions>
<do-set-local-variable name="lv_counter" scope="driver">
<arg-string>
<token-xpath expression="number($lv_counter) + 1"/>
</arg-string>
...

Then for each loop in the do-for-each loop it will count one up.

IDM – success or not success

Ones in a while one would actually like to know if the result of a operation is successful.

If one does something, one would see something like:

<nds dtdversion=”3.5″ ndsversion=”8.x”>
<source>
<product version=”3.6.10.4747″>DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<instance class-name=”Group” qualified-src-dn=”O=Novell\OU=groups\CN=test-manages” src-dn=”\VAULT\Novell\groups\test-manages” src-entry-id=”32931″/>
<status level=”success”></status>
</output>
</nds>

We know that the root node is <output>, and the result is store in $current-op, the result can then be tested with:


<token-xpath expression=”self::status[@level = 'success']“/>

or if used in an condition block:


<if-xpath op=”true”>self::status[@level = 'success']</if-xpath>

Kind of simple, but annoying difficult to figure out.

IDM – loop query result

To loop through a nodeset (objects, attributes) one can use for-each.

To do this one first have to have a nodeset, in this case I’ll use a query to find a list of users:

<do-set-local-variable name=”lv_manages” scope=”policy”>
<arg-node-set>
<token-query class-name=”User” datastore=”src”>
<arg-dn>
<token-text xml:space=”preserve”>$dit.idv.user$</token-text>
</arg-dn>
<arg-match-attr name=”manager”>
<arg-value type=”string”>
<token-text xml:space=”preserve”>$lv_userdn$</token-text>
</arg-value>
</arg-match-attr>
</token-query>
</arg-node-set>
</do-set-local-variable>

This will find all users in dit.idv.users which have manager set to $lv_userdn, and store it in lv_managers:

<nds dtdversion=”3.5″ ndsversion=”8.x”>
<source>
<product version=”3.6.10.4747″>DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<instance class-name=”User” qualified-src-dn=”O=Novell\OU=users\CN=test2″ src-dn=”\VAULT\Novell\users\test2″ src-entry-id=”32882″/>
<instance class-name=”User” qualified-src-dn=”O=Novell\OU=users\CN=test1″ src-dn=”\VAULT\Novell\users\test1″ src-entry-id=”32881″/>
<status level=”success”></status>
</output>
</nds>

Not the interesting part about XPath and nodeset’s is that the root of the nodeset will always point at <output>/instance … meaning that anything you need to look at in this case will be $lv_managers, which will have a list of instances.

Now to do anything interesting with the result, we have to use for-each (do-for-each):

<do-for-each>
<arg-node-set>
<token-local-variable name=”lv_manages”/>
</arg-node-set>
<arg-actions>
<do-trace-message>
<arg-string>
<token-xpath expression=”$current-node/@src-dn”/>
</arg-string>
</do-trace-message>
</arg-actions>
</do-for-each>

Now there to two interesting things in this:

– normally we just address a local variable as $<variable name>, in this case we have to use <token-local-variable name=”<variable name>”/> as we need the reference and not the value.

Also do-for-each will put the resulting node set (it will always return a node set) in $current-node, which means that looping through the above result (nodeset), will return:

1) <instance class-name=”User” qualified-src-dn=”O=Novell\OU=users\CN=test2″ src-dn=”\VAULT\Novell\users\test2″ src-entry-id=”32882″/>
2) <instance class-name=”User” qualified-src-dn=”O=Novell\OU=users\CN=test1″ src-dn=”\VAYKT\Novell\users\test1″ src-entry-id=”32881″/>

So to get the src-dn from this we need to get the value from $current-node/@src-dn

Unfortunately DirXML-Script does not have functions/procedures, or templates known from XSLT – I’m yet to get a reasonable explanation for this, and will not hold my breath till it happens. This means that one have to write the same code over and over again, or setup lots of variables, and then write library policies/rules which are then linked into the driver, which of cause would would, but it’s kind of ugly. More about that later.

IDM – does object exist

Some times one need to know if an object exist, that could be a group, container, or what ever. There is a very easy way to do this using XPath and the query processor:

<do-if>
<arg-conditions>
<and>
<if-xpath op=”true”>query:readObject($srcQueryProcessor,”,$lv_objectDN,”,”)</if-xpath>
</and>
</arg-conditions>
<arg-actions>
<do-set-local-variable name=”lv_objectExist” scope=”policy”>
<arg-string>
<token-text xml:space=”preserve”>TRUE</token-text>
</arg-string>
</do-set-local-variable>
</arg-actions>
<arg-actions>
<do-set-local-variable name=”lv_objectExist” scope=”policy”>
<arg-string>
<token-text xml:space=”preserve”>FALSE</token-text>
</arg-string>
</do-set-local-variable>
</arg-actions>
</do-if>

Remember that if you want to query the destination, then you have to use $destQueryProcessor.

IDM – LDAP Driver and binary attributes

Having issues with binary attributes and the LDAP Driver; by default the LDAP Driver is set to “LDAP Server Supports Binary Attribute Option”, which means that it will use the ‘binary’ keyword for every octet string it sends to the LDAP Server.

If you see something like this:


DirXML Log Event -------------------
Driver: DriverDN
Channel: Subscriber
Object: ObjectDN
Status: Error
Message: LDAPException: Undefined Attribute Type (17) Undefined Attribute Type
LDAPException: Server Message: jpegPhoto;binary: option "binary" not supported with type

Then you need to tell the driver that your LDAP Server does not support binary attributes, that is attributes which have the binary keyword – it will still accept octet strings.

You can change that in Driver Options -> Subscriber Options -> “LDAP Server Supports Binary Attribute Option”, and set it to ‘No’.

IDM – remove type from add-attr

One of the more interesting things with IDM (Novell Identity Manager) is that it more or less works out of the box, and most of the issue being see is with the applications (ie. what we are either receiving or sending data to).

Once in a while one have to do silly things; like remove the type declaration from from XDS, which is “easy” to do with XPath.


<rule>
<description>StripTypeAtribute</description>
<conditions>
<and>
<if-attr name="<attribute>" op="available"/>
</and>
</conditions>
<actions>
<do-strip-xpath expression="*[@attr-name='<attr-name>']/add-value/value/@type"/>
</actions>
</rule>

This should be put somewhere in the Command Transformation.