|By Patrick Correia||
|June 5, 2006 04:00 PM EDT||
How to Implement Basic Authentication with ColdFusion
The first time a Web browser requests a page that's protected by Basic authentication, the Web server needs a way to tell it that it should stop and ask the user for login information. It does this by sending a response to the initial request with the status code 401 ("Access Denied"). In this response, it also sends information about what types of authentication it's willing to accept (this is the "WWW-Authenticate" header). In this article, we're only discussing Basic Authentication, but other more complex (and more secure) methods exist such as Digest authentication and Microsoft's proprietary NTLM authentication. Along with the 401 response the server also sends a user-friendly (or at least user-readable) explanation of why access is being denied.
When the browser gets the 401 response, before showing the user the "Access Denied" message, it prompts for a user name and password. If the user provides credentials, the browser repeats the request and includes the user name and password in an "Authorization" request header. If the credentials are sufficient, the server then sends the requested page with a 200 ("OK") status code. If the credentials aren't acceptable to the server, it simply sends back the same 401 response, which makes the browser prompt the user again. If the user declines to provide credentials (by clicking a "Cancel" button on the password prompt, for example), or fails to provide acceptable credentials a certain number of times (usually three, although it's up to the Web browser to decide), the browser stops prompting the user and shows the user the "Access Denied" message provided by the server.
Listing 1 shows the code needed to implement Basic Authentication. This code should be included at the top of any page that needs to be protected by authentication (an Application.cfm file is a good place, for example).
The first lines use the built-in ColdFusion function GetHttpRequestData() to retrieve complete information on the request headers sent by the client and ensure that our session-level user variable is initialized. Then the code checks to see if the client has provided the "Authorization" header that contains the login and password. The "Authorization" header consists of two parts separated by a single space: first, the authentication scheme (in this case "Basic"); and second, the user name and password separated by a colon and Base64-encoded to protect them from character set issues during transmission. The user name and password are decoded using the ToBinary() and ToString() functions, and the application verifies that they're correct (obviously this part will vary from application to application). If the user hasn't been logged in either by providing incorrect credentials or by not providing any at all, the response code is set to 401 and the "WWW-Authenticate" response header is added. Finally, a user-friendly "Access Denied" message is added to the response and execution is stopped so the server sends only the "Access Denied" message back to the client.
Even if the user has cookies disabled, so the user's session doesn't persist from request to request, the user won't be prompted again for a login and password. However, in this case, you won't be able to store any other data in the session scope without resorting to passing session identifiers as URL parameters.
Since the browser is getting accurate response codes throughout the transaction, there's no need to write code to redirect the user after a successful login. This is an additional benefit of using Basic authentication and means that your application fully supports deep linking and bookmarking without any extra code.
The Authentication Realm
There's one additional piece of information that the server sends in the "WWW-Authenticate" header: the authentication realm. The realm is defined as a string that uniquely identifies the set of resources on the server that all use the same user account source. The browser assumes that if it has prompted the user for a login and password for a resource on a given server, it can reuse the same credentials for another resource in the same realm on the same server.
Although the specification for Basic authentication discourages the use of the realm for any purpose other than matching it for equality against other realm values, in practice the realm actually has another important function. When most browsers prompt the user for login credentials, they show the realm as a description of the application the user is logging in to. So it's a good idea to set the realm in your authentication code to a brief description of your application (this description would replace the string "MyApplication" in Listing 1).
Caching of Credentials: The End of Session Expiration
When a browser gets a 401 ("Access Denied") message in response to a request for a given resource, it checks to see if the realm specified in the "WWW-Authenticate" header matches any realms it has already authenticated against on the current server for the current browser session. If it finds credentials that have been accepted for that realm, it retries the request using those credentials (prompting the user for credentials only if the cached credentials are rejected by the server). The browser also assumes that resources in subdirectories below the resources for which it has already been prompted to authenticate will be part of the same realm and preemptively sends the cached credentials the first time it requests these resources. These two facts contribute to one of the biggest advantages of Basic authentication: the end of session expiration messages.
Examine Listing 1 again and consider what happens if the user has been previously authenticated but has been inactive enough that the session expired. On the next request, a new session is initiated by the ColdFusion server and SESSION.loggedInUserName is set to an empty string. If the browser has previously requested the page, it will have preemptively sent the login credentials; if not, it will check its cache and see that it already has credentials for the specified realm and it will repeat the request, providing the cached credentials. In either case, the user has been automatically logged back into the application without being prompted! This provides a much smoother and less confusing experience for the user.
Keep in mind that this may have some affect on your application architecture. If you're using the session scope only to cache information that's already stored in a database somewhere, your application can probably be converted to Basic authentication with no issues. However, if you store temporary data in the session scope (such as shopping cart information), you may have to consider a different approach since the user may have multiple ColdFusion sessions over the course of what they consider a single session of interacting with the Web application. Just remember that a user session might be initialized on any page of your application.
Limitations of Basic Authentication
Basic authentication isn't without its limitations. First and foremost, it's important to realize that the user name and password is transmitted from the browser to the Web server in unencrypted clear text. (The Base64 encoding isn't a security measure - it's designed to be easily reversible.) If you consider the data in your application to be sensitive, you should definitely use an additional security layer such as SSL to protect the transmission of the user name and password (as well as the data). That being said, this lack of encryption is a limitation that's common to both forms-based and Basic authentication.
The other significant limitation of Basic authentication, and the only major drawback to using it over forms-based authentication, is that it provides much less opportunity for context around the login and password. A forms-based solution can show information around the login box explaining the format of the login and, in the case of password errors, can provide detailed information about what went wrong. Additionally, the login prompt can be customized to match the look-and-feel of the rest of the application. When implementing HTTP Basic authentication, you should provide an entry page that isn't authenticated that provides this information so the user is prepared to enter the appropriate login and password information.
Basic authentication provides an alternative to traditional forms-based authentication methods. By sticking closely to the HTTP specification, this method leverages features built in to the Web browser to prevent confusing session expiration problems and the need to code around other limitations in non-standard forms-based authentication methods.
|MikeR 06/08/06 11:43:56 PM EDT|
Interesting article but it failed to mention the huge flaw with basic auth.
Basic authentication can't be used for most real-world sites because:
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Passing Parameters to Flex That Works