The majority of ColdFusion applications live far away, hidden, in enterprise fortresses as applications that small-to-large organizations depend on. In these organizations, especially the medium-to-large ones, there are well-established network infrastructures to manage the users, workstations, servers, etc.

Organizations usually implement LDAP as a directory services infrastructure but, for the purposes of this article, I will only be discussing Active Directory.

Active Directory, AD, is an LDAP implementation from Microsoft that was introduced with the Windows 2000 environment. This implementation is based on the X.500 LDAP standards. The AD is a giant database that can store as much as 16 terabytes or 1 billion objects ranging from users, printer locations, security policies, and, also important, user-defined data.

Every application that interacts with users usually has restrictions based on profiles and must also implement security. These are especially important for applications in financial organizations. Based on my experience, building user and profile management into applications, which is not a trivial matter, take considerable time and effort in the software development cycle. It doesn't stop with this; users don't like to have multiple security credentials across many applications. There is nothing more frustrating for these users than having to remember which username and password work with which application.

One of the beauties of Microsoft's Web-based/enabled applications is the ease at which they plug in to its existing network infrastructure. Outlook Web Access (OWA) users use their network security credentials to log in. Not only that, OWA knows when a user is logged into a computer, so it automatically loads the user's profile from the AD.

ColdFusion has support for LDAP, which includes AD. Using CFLAP, the ColdFusion tag for interacting with LDAP servers, you could leverage on AD for user management and profiling.

In the next few paragraphs, I'll show how you can use CFLAP to authenticate and load user profiles in AD for use in your application.

Step 1: Preparation
For the sake of this article, imagine you are writing an application for a financial institution called Bank X Inc. Bank X has implemented its AD as bankx.com. To write your application, you must know the name or IP of an AD server (Domain Controller, DC) that will authenticate your users. You must also know the structure of your AD. Please consult with your Domain Administrator for documentations.

Step 2: Login
The following is a simple login form to be used by Bank X users to log in to their financial applications:

<form action="loginADUser.cfm" method="post">
   <label for="username" accesskey="u">Username:</label>
   <input name="username" type="text" id="username" />
   <br />
   <label for="password" accesskey="p">Password</label>
   :
   <input name="password" type="password" id="password" />
   <br />
   <input name="Submit" type="submit" value="Submit" />
   <br />
</form>

Step 3: Authentication
The loginADUser.cfm page contains code to authenticate the user against the AD server (see Listing 1).

Explanation
In AD, any valid user can bind to the service, which is accessible on port 389 and port 636 for a secured connection. For more on secured connections, please see the security section. The bind will work only if the security credentials are correct but will throw an error if the credentials are wrong.

The isLoggedIn variable holds a Boolean value that determines if a user's security credentials are valid on the domain or not. Now, when authentication is attempted, the try-catch combination catches the error that is thrown with wrong security credentials.

The code in Listing 1 kills two birds with one stone by authenticating and retrieving certain records at the same time.

A user's groups are stored in the memberof field. The membership information is stored in DN form, which you may have to parse to extract out. It's usually in this form:

CN=Support Team,OU=Distribution List,DC=bankx,DC=com,
CN=InfoTech,OU=Distribution List,DC=bankx,DC=com,
CN=Administrators,CN=Builtin,DC=bankx,DC=com,
CN=Domain Admins,CN=Builtin,DC=bankx,DC=com

The login code can be wrapped with a CFLOGIN tag and the parsed roles passed to CFLOGINUSER as roles. Otherwise, you can implement your own role system with session management.

Extending the AD
The AD, implementing the LDAP specifications, has default fields that hold information that is important to your users and applications. However, you might want to store some application-specific data along with the default information. AD has 15 blank fields that you can use: extensionAttribute1 to extensionAttribute15. You can also use some fields that are not important to your organization such as IPPhone.

If you use these fields, documentation of what you have done is very important. Also, note that the AD can be delicate; kindly consult with your Domain Administrator before writing anything to the database. An error could bring down the whole AD forest.

Tools
You can't do much with AD without using the ADSI Edit. Install this from the Windows Support Tools. The ADSI Edit allows you to peruse the attributes and data types of the objects in the AD. The AD has data types such as Integer, Integer8, DN, OID, Boolean, DirectoryString, and PrintableString. Consult documentations for what these stand for.

Security on AD/CF Integration
Implementing a real-life application requires that transmission of sensitive data between the servers should be encrypted. The AD supports the interchange of data between ColdFusion and itself via the Secured Socket Layer, SSL on port 636.

To use SSL, you must install an Enterprise Certificate Authority on any of the domain controllers in your organization. This forces the DCs to request certificates from ColdFusion whenever you use CFLDAP.

The next step is to install your security certificate on the ColdFusion server using the keytool. Go to the command prompt and navigate to <cfroot_install>\runtime\jre\bin directory and run the following command:

keytool -import -keystore cacerts -alias ldap -file ldap.crt -keypass bl19mq

Please refer to the Sun JDK for full documentation.

With the certificates in place, you must add the secure = "CFSSL_BASIC" attribute to your CFLDAP.

Summary
Your application can be much more elegant if you leverage on the AD. Not only will you deliver faster, you also future-proof your application so that it can effectively connect to other sources of user security profiles.

Ultimately, the users find life easier if they can always use your applications with just a single set of universal security credentials.

Important Links

• Securing AD Servers: http://support.microsoft.com/kb/q247078/, http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/ldap28.htm
• Macromedia Tutorial on LDAP: www.macromedia.com/devnet/server_archive/articles/ integrating_cf_apps_w_ms_active_directory.html
• Active Directory Services Interface: www.microsoft.com/windows2000/techinfo/howitworks/ activedirectory/adsilinks.asp