The I2A2 LDAP Bind Operation
The LDAP bind operation in its simplest form, called simple password authentication, converts to a simple authentication
request for the I2A2 authenticator DBM.
The Relative Distinguished Name (RDN) component of the LDAP Distinguished Name (DN) identifies the PUID or its alias for
which simple authentication is to be done. The base DN identifies the authenticator DBM. Here's the complete assembly for
authenticating PUID 10284869:
puid=10284869,ou=authenticate,dc=purdue,dc=edu
I2A2 LDAP Attributes
The I2A2 LDAP attributes are described here.
The Password
How the password is specified to the client application depends on its conventions. Once the client application has acquired the password, it is transmitted to the I2A2 LDAP protocol converter in an authentication field of the LDAP bind request.
SSL|TLS is Mandatory
The LDAP authentication field is a plain text field. Sending it a plain text connection would expose the password to
interception. Consequently the I2A2 LDAP protocol converter requires that
SSL|TLS be used for all bind requests. In fact, I2A2 LDAP won't even
examine the authentication field if the connection mode is not SSL|TLS; it will abort the connection immediately upon receipt
of a bind request to the plain text port.
Use this URI for bind requests:
ldaps://dbm.i2a2.purdue.edu
Optional I2A2 Authentication Realm
The RDN component of the DN may optionally be followed by an "at" sign ('@') and a realm name. The realm name is an
I2A2 authentication realm and defaults to "purdue", so it is not usually
necessary to follow a PUID or alias in the RDN with "@purdue".
If that were done, the above sample DN would look like this:
puid=10284869@purdue,ou=authenticate,dc=purdue,dc=edu
Blind Reply
A successful LDAP bind operation leaves behind as an implicit identity the entity that was bound -- e.g., the specific PUID.
That implicit identity can be exploited in a subsequent search (in the same connection to the I2A2 LDAP protocol converter)
that itself names no identity.
For example, if the sample bind request listed above is successful, it may be followed (in the same LDAP connection)
by a search request without an RDN, only the base DN for an I2A2 DBM. The following DN would search for information on the
bound PUID and return in appropriate attributes information about the PUID.
ou=identify,dc=purdue,dc=edu
More information on the attributes that the I2A2 LDAP protocol converter returns may be found in I2A2 LDAP Attributes
MacroMedia ColdFusion MX Binding The I2A2 LDAP protocol converter's bind operation may be used with Macromedia ColdFusion MX. Here are some sample (but not complete) ColdFusion MX statements, provided by John R. Mitchell of Botany and Plant Pathology and Grant Wei of Agriculture Information Techology, that may be useful.
...
<cfscript>
servername = "dbm.i2a2.purdue.edu";
attributes = "uid,dn,puid";
root = "dc=purdue, dc=edu";
uid = ...
password = ...
</cfscript>
...
<cfldap action="query"
name=...
attributes="#attributes#"
start="ou=authenticate, #root#"
server="#servername#"
secure="CFSSL_BASIC"
port=636
username="uid=#uid#, ou=authenticate, #root#"
password="#password#"
>
(The password and the uid values are generally acquired through a dialog.)
In order for the secure="CFSSL_BASIC" statement to complete an SSL connection to the I2A2 LDAP protocol converter, the Purdue
public certificate must be installed in ColdFusion's client cacerts keystore. (Doing that requires administrative privileges
on the ColdFusion server and familiarity with ColdFusion certificate installation.) The simplest way to install the certificate
is to download it in PEM format and use the Java run-time environment
keytool command to install it.
International Programs has put together some
instructions for using keytool and configuring ColdFusion MX to use a keystore.
Binding in ColdFusion Versions before MX
ColdFusion versions before MX will NOT send proper bind requests to the I2A2 LDAP protocol converter, because those ColdFusion
versions don't support LDAPv3. (The I2A2 LDAP protocol converter only supports LDAPv3.)
There is a solution to the ColdFusion LDAP version problem. Tim LeMaster of Purdue's Internet Services Group has produced a
ColdFusion Java CFOBJECT which issues proper LDAPv3 bind requests to the I2A2 LDAP protocol converter and properly handles the
replies. Tim's CFOBJECT is a bit too complex to present here, but if you contact Tim, he is willing to share information about it.
Tim's CFOBJECT requires a Java Virtual Machine (JVM), and that makes the keytool application available for installing the
Purdue public certificate, as described in the ColdFusion MX binding section above. Consult with Tim about what needs to be done
to install a JVM for ColdFusion use.
OpenLDAP Binding
Versions of OpenLDAP past 2.0.27 require an additional configuration step to enable their libraries (e.g., libldap) and clients (e.g., ldapsearch) to locate the Purdue public certificate. That is done with this statement, which must appear in the home directory ~/.ldaprc configuration file or in OpenLDAP's global ldap.conf configuration file:
TLS_CACERTDIR <path>
The path that follows TLS_CACERTDIR specifies the oath to the directory where the Purdue public certificate is stored.
(Often that is /opt/openssl/certs.)
The I2A2 LDAP Unbind Operation
In general the LDAP unbind request reverses a bind request's results. Specifically for the I2A2 LDAP protocol converter the
unbind request does nothing more than erase any implicit identity a successful bind might have left behind. The I2A2 LDAP
protocol converter always gives a successful reply to the unbind request.