All major web servers support basic HTTP authentication. Some web servers also support other authentication methods, including Digest HTTP authentication and Microsoft NTLM authentication.

In web server authentication, the web server requires the user to log in to access pages in a particular directory, as follows:

1. When the user first requests a page in the secured directory, the web server notifies the browser that the requested page requires credentials (a user ID and password).

   Basic HTTP authentication sends the user ID and password in a base64-encoded string with each request. Use SSL (Secure Sockets Layer) for all page transactions, to protect the user ID and password from unauthorized access. For more information on SSL and the keytool utility, see About LDAP Server Security.

2. The browser prompts the user for the credentials.

3. The user supplies the credentials and the browser send the information back to the web server along with the original request.

4. The web server checks the user ID and password, using its own user authentication mechanism.

5. If the user logs in successfully, the browser caches the authentication information and sends it in an HTTP Authorization header with every subsequent page request from the user.

6. The web server processes the requested page and all future page requests from the browser that contain the HTTP Authorization header, if it is valid for the requested page.

You can use web server authentication without using any ColdFusion security features. In this case, you configure and manage all user security through the web server’s interfaces.

You can also use web server authentication with ColdFusion application authentication, and thus use ColdFusion security for authorization. If the web server uses basic HTML authentication, the ColdFusion cflogin tag provides access to the user ID and password that the user entered to log in to the web server. If the web server uses Digest or NTLM authentication, the cflogin tag normally gets the user ID, but not the password.

As a result, your application rely on the web server to authenticate the user against its user and password information, and does not have to display a login page. You use the cflogin and cfloginuser tags to log the user into the ColdFusion user security system, and use the IsUserInAnyRole and GetAuthUser functions to ensure user authorization. For more information on this form of security, see A web server authentication security scenario.

With application authentication, you do not rely on the web server to enforce application security. The application performs all user authentication and authorization. The application displays a login page, checks the user’s identity and login against its own authorization store, such as an LDAP directory or database, and logs the user into ColdFusion using the cfloginuser tag. The application then uses the IsUserInAnyRole and GetAuthUser functions to check the user’s roles or identity for authorization before running a ColdFusion page or specific code on a page. For an example of application authentication use, see An application authentication security scenario.

How ColdFusion application authentication information is maintained by the browser and ColdFusion, and therefore how long it is available, depends on the following:

• Whether the user’s browser enables cookies

• Whether the application supports the Session scope for login storage

Because HTTP is connectionless, a login can last beyond a single web page viewing only if the browser provides a unique identifier that software on the server uses to confirm that the current user is authenticated. Normally, this is done by using memory-only cookies that are automatically destroyed when the user closes all open browser windows. The specific cookies and how they are used depend on whether the application supports the Session scope for login storage.

If you do the following, ColdFusion maintains login information in the Session scope instead of the Cookie scope:

• Enable the Session scope in the ColdFusion Administrator and the Application.cfc initialization code or cfapplication tag.

• Specify loginStorage="Session" in the Application.cfc initialization code or cfapplication tag.

  When ColdFusion maintains login information in the Session scope, it stores the authentication details in a Session.cfauthorization variable, and ColdFusion uses the session cookie information to identify the user. Session-based authentication has the following advantages over less persistent login storage:

• After the user logs in, the user ID and password are not passed between the server and the browser.

• The login information and the session share a single time-out. You do not have to manually synchronize sessions and logins.

• If you use server clusters, the Session scope login ID is available across the cluster. For more information on server clustering, see Configuring and Administering ColdFusion.

If you do not enable the Session scope, the authentication information is not kept in a persistent scope. Instead, the detailed login information is placed in a memory-only cookie (CFAUTHORIZATION_applicationName) with a base64-encoded string that contains the user name, password, and application name. The client sends this cookie to the web server each time it makes a page request while the user is logged-in. Use SSL for all page transactions to protect the user ID and password from unauthorized access.

Implement a limited-lifetime form of ColdFusion security if the user’s browser does not support cookies. In this case you do not use the cflogin tag, only the cfloginuser tag. It is the only time you should use the cfloginuser tag outside a cflogin tag.

Without browser cookies, the effect of the cfloginuser tag is limited to a single HTTP request. Provide your own authentication mechanism and call cfloginuser on each page on which you use ColdFusion login identification.