User security lets your application use security rules to determine what it shows. It has two elements:

Authentication: Ensures that a valid user is logged-in, based on an ID and password provided by the user. ColdFusion (or, in some cases if you use web server authentication, the web server) maintains the user ID information while the user is logged-in.

Authorization: Ensures that the logged-in user is allowed to use a page or perform an operation. Authorization is typically based on one or more roles (sometimes called groups) to which the user belongs. For example, in an employee database, all users could be members of either the employee role or the contractor role. They could also be members of roles that identify their department, position in the corporate hierarchy, or job description. For example, someone could be a member of some or all of the following roles:

• Employees
• Human Resources
• Benefits
• Managers

Roles enable you to control access in your application resources without requiring the application to maintain knowledge about individual users. For example, suppose you use ColdFusion for your company's intranet. The Human Resources department maintains a page on the intranet on which all employees can access timely information about the company, such as the latest company policies, upcoming events, and job postings. You want everyone to be able to read the information, but you want only certain authorized Human Resources employees to be able to add, update, or delete information.

Your application gets the user's roles from the user information data store when the user logs in, and then enables access to specific pages or features based on the roles. Typically, you store user information in a database, LDAP directory, or other secure information store.

You can also use the user ID for authorization. For example, you might want to let employees view customized information about their salaries, job levels, and performance reviews. You certainly would not want one employee to view sensitive information about another employee, but you would want managers to be able to see, and possibly update, information about their direct reports. By employing both user IDs and roles, you can ensure that only the appropriate people can access or work with sensitive data.

The following image shows a typical flow of control for user authentication and authorization. Following sections expand on this diagram to describe how you implement user security in ColdFusion.

Authenticating users

You can use either, or both, of the following forms of authentication to secure your ColdFusion application:

• Web server authentication, where the web server authenticates the user and does not allow access to the website by users without valid login IDs
• Application authentication, where the ColdFusion application authenticates the user and does not allow access to the application by users without valid login IDs

About web server authentication

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 you can 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 can 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.

About application authentication

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 can then use 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.

ColdFusion authentication storage and persistence

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

Authentication and cookies

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 can use 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.

Using the Session scope

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. There is no need to manually synchronize sessions and logins.
• If you use server clusters, the Session scope login ID can be 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 put 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.

Using ColdFusion security without cookies

You can 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. You must provide your own authentication mechanism and call cfloginuser on each page on which you use ColdFusion login identification.