Overview#This is about an DirXML Example for the SOAP DSML DirXML Driver
Things to Note#These were some of the notable issues we encountered.
The XSLT Style sheets make some assumptions that may not be assumed by the DSML Service. These are what I found in build="20070918_0808 " instance="DSML" version="3.5.2">Identity Manager Driver for SOAP. Your mileage on other builds may vary.
We are not real sure what the DSML specifications say but this is what we see in the driver.case-insensitive and I do not know about DSML, but the XSLT style sheets supplied with the driver are case-sensitive. We tried to identify what we ran into below but if you see some strange results, check the case. We are accustomed to using camel-case for LDAP names like ObjectClass instead of "objectclass". This caused us issues with the SOAP driver. Output Transformation Policy Set XSLT and have modified it to accommodate the following:
<instance> Element Not Removed#On Searches, the <instance> elements were not removed form the output.
matchedDN xml Attribute#Do not know the DSML specs in great detail, however, as we understand them there should or could be a matchedDN attribute applied to the the response of almost all operations. In out particular implementation, the driver generated the naming attribute for the users, and without this, we would be unable to determine the naming attribute that the user was created under.
LDAP Names and Formats#AS DSML is an XML dialect that represents directory services, DSML utilizes:
- LDAP attribute names. Be sure you put them in the Schema Mapping Policy for the driver.
- LDAP formats for things like DNs. You will need to reformat the DNs that you use.
Driver Specifics#We cover items that were implemented within the driver for our implementation.
Driver Derived Values#The Driver determines the following items:
Publishes from Connected Application to IDV only.#In our implementation, the driver only listens for requests and will never initiate any communication. The driver works on a requests-response system and handles requests in sequence. The Driver will supply a response to every request sent by the application. The driver is capable of performing two-way communication, but for our purposes, this was not required or even desired.
On operations that are initiated as one request and spawn additional XDS operations, only the response for the original request will be seen by the application.
- searchRequest - The objectclass of the searchRequest is derived by the driver to be the value supplied in the search filter. The XSLT looks for "objectclass" and is case sensitive.
- add Request - The LAST value passed as the objectClass is used to create the entry.
Publisher Create#We set some AuxClasses here that will not work on your system. You will need to adjust the values to work in your environment. NDS Groups with the multiple attributes that need set on both the Group and the User entry can be tedious. As our implementation of the driver can not query the application, handling of groups we found best to be done like:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policy PUBLIC "policy-builder-dtd" "...\DTD\dirxmlscript.dtd"> <policy> <rule> <description>Add GroupMemberShip</description> <conditions> <and> <if-op-attr name="Group Membership" op="available"/> <if-op-attr name="Group Membership" op="changing"/> </and> </conditions> <actions> <do-reformat-op-attr name="Group Membership"> <arg-value> <token-parse-dn dest-dn-format="dest-dn" src-dn-format="ldap"> <token-local-variable name="current-value"/> </token-parse-dn> </arg-value> </do-reformat-op-attr> <do-clone-op-attr dest-name="Security Equals" src-name="Group Membership"/> </actions> </rule> </policy>This will set all the attributes on both the Group and user and has appeared to work in may combinations of adding and deleting groups, even within the same operation. SOAP-DSML Driver and SOAP-DSML Client to show how you could use the SOAP DSML Driver with an application.