LDIF Connector

The LDIF connector implements the DirX Identity Java Connector Integration Framework’s DxmConnectorCore, DxmRequestor and DxmContext interfaces and writes and reads LDIF files using the Netscape LDIF classes. Like all framework-based agents, it gets SPML requests from the Identity side by the join engine as part of the workflow engine hosted by the Java-based Server. It converts the SPML requests in order to read from and write to LDIF files.

The LDIF connector provides the functionality to:

Add any kind of object - especially user, account or group - to an LDIF content file.
Perform searches on an LDIF content file to import the objects to Identity.

Overview

The connector implements the API methods "add(…)" and "search(…)". They represent the corresponding SPML requests "AddRequest" and "SearchRequest".

Limitations

It is not currently possible to read and write LDIF change files. Only LDIF content files are supported.

Request and Response Handling

This section describes the supported requests and attributes for the LDIF connector.

AddRequest

In an add request, the identifier is mandatory. Any kind of object and attribute can be passed in an add request to the LDIF connector, which writes it as LDIF content record to the file name retrieved from the connector’s export_file property or if not specified there from the framework context variable ts.*channelName.env.export_file*, where channelName is retrieved from the operational attributes of the AddRequest. The default channel name is users. There might be other channels configured under the LDIF file connected directory in order to read and write other objects than users to an LDIF file.

Example request:

<?xml version="1.0" encoding="UTF-8" ?>
<spml:batchRequest xmlns="urn:oasis:names:tc:SPML:1:0"
 xmlns:spml="urn:oasis:names:tc:SPML:1:0"
 xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"
requestID="batch-1"
 processing="urn:oasis:names:tc:SPML:1:0#sequential"
execution="urn:oasis:names:tc:SPML:1:0#synchronous"
 onError="urn:oasis:names:tc:SPML:1:0#exit">
 <spml:addRequest requestID="add-1">
    <spml:identifier type="urn:oasis:names:tc:SPML:1:0#DN">
       <spml:id>cn=my class,cn=supplier groups,cn=groups,cn=Extranet Portal,cn=TargetSystems,cn=my-company</spml:id>
    </spml:identifier>
    <spml:attributes>
       <spml:attr name="objectclass" xmlns="urn:oasis:names:tc:DSML:2:0:core">
           <dsml:value>dxrTargetSystemGroup</dsml:value>
       </spml:attr>
       <spml:attr name="uniqueMember" xmlns="urn:oasis:names:tc:DSML:2:0:core">
          <dsml:value>cn=my-company</dsml:value>
       </spml:attr>
       <spml:attr name="dxrState" xmlns="urn:oasis:names:tc:DSML:2:0:core">
          <dsml:value>ENABLED</dsml:value>
       </spml:attr>
    </spml:attributes>
    <spml:operationalAttributes>
       <dsml:attr name="channelName">
          <value>users</value>
       </dsml:attr>
    </spml:operationalAttributes>
 </spml:addRequest>
</spml:batchRequest>

Search Request

In an SPML search request, the LDIF connector supports the elements searchBase and filter and the operational attributes scope, pageSize, noattrs (if set to FALSE or not existing all attributes are retrieved) and channelName.

The join engine sets the operational attribute channelName only in a Java server workflow context. channelName is used to get the name of the source file for the SearchRequest if no file name was specified in the LDIF connector’s <connection> filename property. The file name is then obtained from the framework context variable ts.*channelName.env.import_file*.

If the join engine calls the LDIF connector’s search method in the context of a workflow running from Identity to the connected system (export mode), the LDIF connector returns an empty search result (if contentType is not specified or set to LDIF-CONTENT) to make the join engine produce an AddRequest resulting in writing an LDIF content record.

If the LDIF connector is extended to be able to write LDIF change records, the connection property contentType must be set to LDIF-CHANGE. This setting makes the LDIF connector return the search result based on the specified import file to the join engine. The join engine then - as usual - calculates the changes compared to the original modify requests and passes the modify requests containing only the changes to the LDIF connector, which writes them as LDIF change records to the specified export file.

Example request:

<?xml version="1.0" encoding="UTF-8" ?>
<spml:searchRequest  xmlns="urn:oasis:names:tc:SPML:1:0"
     xmlns:spml="urn:oasis:names:tc:SPML:1:0"
     xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"
     requestID="search_01"
     >
<spml:searchBase type = "urn:oasis:names:tc:SPML:1:0#DN">
   <spml:id>cn=users,cn=My-Company</spml:id>
</spml:searchBase>
   <spml:filter>
     <dsml:and>
       <dsml:equalityMatch name="ou">
       <dsml:value>Sales</dsml:value>
       </dsml:equalityMatch>
       <dsml:not>
       <dsml:present name="assistant" />
       </dsml:not>
     </dsml:and>
   </spml:filter>

<spml:operationalAttributes>
   <dsml:attr name="scope">
      <value>subtree</value>
   </dsml:attr>
   <dsml:attr name="pageSize">
      <value>0</value>
   </dsml:attr>
   <dsml:attr name="channelName">
      <value>users</value>
   </dsml:attr>
</spml:operationalAttributes>
<spml:attributes>
</spml:attributes>
</spml:searchRequest>

Configuration

Here is a sample configuration snippet for the LDIF connector:

<connector
 role="connector"
 className=" siemens.dxm.connector.framework.ldif.LdifConnector "
 name="LDIF Connector" version="1.00">
 <connection type="file"
   filename="import1.ldif,import2.ldif,import3.ldif"
   <property name="binaryAttributes" value="dxmMgrlayout, dxmContent,dxmCompiled"/>
   <property name=" export_file" value="export.ldif"/>
   <property name="contentType" value="LDIF-CONTENT"/>
   <property name="namingAttribute" value=""/>
 </connection>
</connector>

Supported Connection Parameters

The following standard properties of the XML configuration file’s <connection> element are supported:

filename - (optional); one or more comma-separated filenames used as the source file for the search request (import file). The wildcards * and ? are supported. For example, import.ldif* specifies any file beginning with import and ending with .ldif and import?.ldif specifies any file beginning with import followed by the character 0 or 1 and ending with .ldif. In a Java-based workflow context, the framework context variable ts.*channelName.env.import_file* specifies the import file name if filename property is not specified.

Non-standard supported properties include:

binaryAttributes - (optional); if configured, binaryAttributes handles the specified attributes as binary ones regarding the correct setting of the appropriate SPML request attribute types.

export_file - (optional); the name of the file the LDIF records are written to. If not specified, in a Java server export workflow context the framework context variable ts.*channelName.env.export_file* specifies the file name.

contentType - (optional); The default is LDIF-CONTENT. LDIF-CHANGE is not yet supported.

namingAttribute - (optional); only relevant for add request handling. If the naming attribute is specified and if the Identifier of the add request is not of type DN (usually the type is DN, which is also the default), but of type OID, the DN value written to the LDIF file is built up by namingAttribute_value + RDN_of_Identifier.