Some more advanced techniques enable you to use LDAP directories more effectively.

LDAP attribute values can contain commas. The cfldap tag normally uses commas to separate attribute values in a value list. Similarly, an attribute can contain a semicolon, which  cfldap  normally uses to delimit (separate) attributes in an attribute list. To override the default separator and delimiter characters, you use the  cfldap  tag separator and delimiter attributes.  For example, assume that you want to add the following attributes to an LDAP entry:

Use the cfldap tag in the following way:

You can create a searchable collection from LDAP data. The ability to generate queries from other queries is useful when cfldap queries return complex data. For more information on querying queries, see Using Query of Queries.

LDAP v3 exposes a directory's schema information in a special entry in the root DN. You use the directory root subschemaSubentry attribute to access this information. The following ColdFusion query shows how to get and display the directory schema. It displays information from the schema's object class and attribute type definitions. For object classes, it displays the class name, superior class, required attribute types, and optional attribute types. For attribute types, it displays the type name, type description, and whether the type is single- or multivalued. The example does not display all the information in the schema. For example, it does not display the matching rules. It also does not display the object class IDs, attribute type IDs, attribute type syntax IDs, or the object class descriptions. (The object class description values are all "Standard Object Class.")

This example does not work on iPlanet Directory Server 5.0. It does work on a 4.x server.

Create a file that looks like the following:

Change the server from ldap.mycorp.com to your LDAP server. You might also need to specify a user ID and password in the cfldap tag.

Save the template as ldapschema.cfm in  myapps  under your web root directory and view it in your browser.

The following table describes the code and its function:

Code

Description

<cfldap  name="EntryList"  server="ldap.mycorp.com"  action="query"  attributes="subschemaSubentry"  scope="base"  start="">

Gets the value of the subschemaSubentry attribute from the root of the directory server. The value is the DN of the schema.

<cfldap  name="EntryList2"  server="ldap.mycorp.com"  action="query"  attributes="objectclasses, attributetypes"  scope="base"  filter="objectclass=*"  start=#entryList.subschemaSubentry#>

Uses the schema DN to get the objectclasses and attributetypes attributes from the schema.

<h2>Object Classes</h2>  <table border="1">  <tr>  <th>Name</th>  <th>Superior class</th>  <th>Must have</th>  <th>May have</th>  </tr>  <cfloop index = "thisElement" list = #Entrylist2.objectclasses#>  <cfscript>  thiselement = Trim(thisElement);  nameloc = Find("NAME", thisElement);  descloc = Find("DESC", thisElement);  suploc = Find("SUP", thisElement);  mustloc = Find("MUST", thisElement);  mayloc = Find("MAY", thisElement);  endloc = Len(thisElement);  </cfscript>

Displays the object class name, superior class, required attributes, and optional attributes for each object class in a table.The schema contains the definitions of all object classes in a comma delimited list, so the code uses a list type cfloop tag.The thisElement variable contains the object class definition. Trim off any leading or trailing spaces, then use the class definition field keywords in Find functions to get the starting locations of the required fields, including the Object class ID. (The ID is not displayed.) Gets the length of the thisElement string for use in later calculations.

<tr>  <td><cfoutput>#Mid(thisElement, nameloc+6, descloc-nameloc-8)#  </cfoutput></td>  <cfif #suploc# NEQ 0>  <td><cfoutput>#Mid(thisElement, suploc+5, mustloc-suploc-7)#  </cfoutput></td>  <cfelse>  <td>NONE</td>  </cfif>  <cfif #mayloc# NEQ 0>  <td><cfoutput>#Replace(Mid(thisElement, mustloc+6,  mayloc-mustloc-9), " $ ", ", ", "all")#</cfoutput></td>  <td><cfoutput>#Replace(Mid(thisElement, mayloc+5, endloc-mayloc-8),  " $ ", ", ", "all")#</cfoutput></td>  <cfelse>  <td><cfoutput>#Replace(Mid(thisElement, mustloc+6,  endloc-mustloc-9), " $ ", ", ", "all")#</cfoutput></td>  <td>NONE</td>  </cfif>  </tr>  </cfloop>  </table>

Displays the field values. Uses the Mid function to extract individual field values from the thisElement string.The top object class does not have a superior class entry. Handles this special case by testing the suploc location variable. If the value is not 0, handles normally, otherwise, output "NONE". There might not be any optional attributes. Handles this case similarly to the superior class. The calculation of the location of required attributes uses the location of the optional attributes if the field exists; otherwise, uses the end of the object class definition string.

<h2>Attribute Types</h2>  <table border="1" >  <tr>  <th>Name</th>  <th>Description</th>  <th>multivalued?</th>  </tr>  <cfloop index = "thisElement"  list = #ReplaceNoCase(EntryList2.attributeTypes, ", alias", "<br> Alias",  "all")# delimiters = ",">  <cfscript>  thiselement = Trim(thisElement);  nameloc = Find("NAME", thisElement);  descloc = Find("DESC", thisElement);  syntaxloc = Find("SYNTAX", thisElement);  singleloc = Find("SINGLE", thisElement);  endloc = Len(thisElement);  </cfscript>  <tr>  <td><cfoutput>#Mid(thisElement, nameloc+6, descloc-nameloc-8)#  </cfoutput></td>  <td><cfoutput>#Mid(thisElement, descloc+6, syntaxloc-descloc-8)#  </cfoutput></td>  <cfif #singleloc# EQ 0>  <td><cfoutput>Yes</cfoutput></td>  <cfelse>  <td><cfoutput>No</cfoutput></td>  </cfif>  </tr>  </cfloop>

Does the same types of calculations for the attribute types as for the object classes. The attribute type field can contain the text ", alias for....". This text includes a comma, which also delimits attribute entries. Use the REReplaceNoCase function to replace any comma that precedes the word "alias" with an HTML <br> tag. The attribute definition includes a numeric syntax identifier, which the code does not display, but uses its location in calculating the locations of the other fields.

An LDAP database can be distributed over multiple servers. If the requested information is not on the current server, the LDAP v3 standard provides a mechanism for the server to return a referral to the client that informs the client of an alternate server. (This feature is also included in some LDAP v2-compliant servers.) ColdFusion can handle referrals automatically. If you specify a nonzero referral attribute in the cfldap tag, ColdFusion sends the request to the server specified in the referral.  The referral attribute value specifies the number of referrals allowed for the request. For example, if the referral attribute is 1, and server A sends a referral to server B, which then sends a referral to server C, ColdFusion returns an error. If the referral attribute is 2, and server C has the information, the LDAP request succeeds. The value to use depends on the topology of the distributed LDAP directory, the importance of response speed, and the value of response completeness. When ColdFusion follows a referral, the rebind attribute specifies whether ColdFusion uses the  cfldap  tag login information in the request to the new server. The default, No, sends an anonymous login to the server.

When you consider how to implement LDAP security, consider server security and application security.

The cfldap tag supports secure socket layer (SSL) v2 security. This security provides certificate-based validation of the LDAP server. It also encrypts data transferred between the ColdFusion server and the LDAP server, including the user password, and ensures the integrity of data passed between the servers. To specify SSL v2 security, set the  cfladap  tag secure="cfssl_basic" attribute.

ColdFusion uses Java Native Directory Interface (JNDI), the LDAP provider, and an SSL package to create the client side of an SSL communication. The LDAP server provides the server side. The LDAP server that the cfldap tag connects to using SSL holds an SSL server certificate, a certificate that is securely "signed" by a trusted authority and identifies (authenticates) the sender. During the initial SSL connection, the LDAP server presents its server certificate to the client. If the client trusts this certificate, the SSL connection is established and secure LDAP communication can begin.  ColdFusion determines whether to trust the server by comparing the server's certificate with the information in the jre/lib/security/cacerts keystore of the JRE used by ColdFusion. The ColdFusion default cacerts file contains information about many certificate granting authorities. If you must update the file with additional information, you can use the keytool utility in the ColdFusion jre/bin directory to import certificates that are in X.509 format. For example, enter the following:

The keytool utility initial keypass password is "change it". For more information on using the keytool utility, see the Sun JDK documentation.  Once ColdFusion establishes secure communication with the server, it must provide the server with login credentials. You specify the login credentials in the  cfldap  tag username and password attributes. When the server determines that the login credentials are valid, ColdFusion can access the directory.

To use security, first ensure that the LDAP server supports SSL v2 security.  Specify the cfldap tag secure attribute as follows:

For example:

The port attribute specifies the server port used for secure LDAP communications, which is 636 by default. If you do not specify a port, ColdFusion attempts to connect to the default, nonsecure, LDAP port 389.

To ensure application security, prevent outsiders from gaining access to the passwords that you use in cfldap tags. The best way to do this is to use variables for your username and password attributes. You can set these variables on one encrypted application page. For more information on securing applications, see Securing Applications.