Welcome!

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion

ColdFusion: Article

Understanding Anonymous and Windows Authentication, and Applying It to Fusebox

Understanding Anonymous and Windows Authentication, and Applying It to Fusebox

This article applies to developers and site administrators working in an environment using Macromedia ColdFusion running on a Windows server using Internet Information Server 4.0 or better. Those who work in an intranet environment will be especially interested. It will conclude with information on specific Fusebox applications, though non-Fusebox users may find that it's applicable to them as well.

Anonymous Access vs Integrated Windows Authentication
With Internet Information Server 5.0, the built-in Web server provided with Windows 2000 Server, there are several user authentication schemes available. The ones we are interested in are Anonymous Access and Integrated Windows Authentication. These controls can be set at the Web site, virtual directory, and file levels, which can be useful for controlling access to any of these resources.

With Anonymous Access, all incoming requests to the Web site in question are mapped to a specific Windows user account designated for anonymous Web access. All interactions with the Web server then inherit whatever permissions are assigned to that anonymous account. Typically, this account is named "IUSR_{webserver name}," and is set with a limited set of permissions. Anonymous Access is typically used in a public Web server environment.

With Integrated Windows Authentication, when an Internet Explorer user browses a Web site that uses Integrated Windows Authentication, their current logon credentials are passed to the Web server, and all subsequent interactions with the Web server use those credentials. Thus, it is possible to make use of existing permissions within a Windows domain. Typically, Integrated Windows Authentication is used in an intranet environment, where an organization knows that all internal Web browsers will be Internet Explorer, and users log on to their Windows workstation with a specific username.

Why Have Both?
You may have a Web application in which the main portion of the site is for everybody, but certain sections require user authentication. Many applications fall into this category, where anybody can read, but only registered users can post messages, update records, etc. As we'll see later, you can have parts of your site set for anonymous authentication and others secured.

ColdFusion and User Authentication
You probably know that ColdFusion has had the capability to do user authentication since version 4.0 or so, using the <CFAU THENTICATE> tag. With the release of CFMX, <CFAUTHENTICATE> has been eliminated in favor of a new family of tags that provide somewhat similar functionality.

For whatever reason, many developers find that the built-in user authentication functions in ColdFusion do not meet their needs. The method described in this article does not make use of any of the built-in user authentication tags in ColdFusion.

ColdFusion, IIS and User Authentication
Many corporate intranets make use of the Microsoft family of products, and have an existing domain user authentication model in place. Typically, in the Microsoft-based intranet environment, user authentication is handled by setting IIS to use Integrated Windows Authentication instead of Allow Anonymous Access. All Web page requests by the current user then use that user's credentials.

When a Web browser requests a ColdFusion template, and that template (or directory or entire site) is marked as Allow Anonymous Access in IIS, the value of CGI.AUTH_USER is null. When that same CF template is called with Integrated Windows Authentication active, the value of CGI.AUTH_USER will be set to the DOMAIN\username of the current user (see Figure 1).

Fusebox - A Framework, Not a House
Newcomers and veterans to Fusebox find that much online discussion occurs over just what Fusebox is, or what is expected of it. As the official Fusebox Web site (www.fusebox.org) states, "Fusebox is a standard framework for building Web-based applications."

Because it's a framework, Fusebox provides the developer with a fantastic way of organizing a Web application, and that's it. Folks often get disappointed that Fusebox does not handle forms validation, wash the dishes, or milk the cow, but remember, Fusebox is a framework, nothing more. Many developers out there have come up with a cornucopia of components that do expand on the Fusebox framework, including components for handling user authentication. The technique described here doesn't require any specific components, just a rearranging of what already exists.

Fusebox Makes It Easy
One of the "rules" of Fusebox is that all browser requests point to index.cfm. You could have a thousand templates in a Fusebox application, with dozens of nested subdirectories, but all the end user will ever see is a URL pointing to "index.cfm" at the root as the target template. Many Fusebox developers wisely prevent users from accessing any other template in the application by adding code to Application.cfm to test for any .cfm template call other than index.cfm (see Listing 1).

In order to get what we want, an application that honors both Anonymous Access and Authenticated Access, we need to think outside the box - the Fusebox, that is. Instead of having all requests point to a single template, index.cfm, we will create a new template, indexsecure.cfm, for all requests requiring Authenticated Access:

  • All requests where Anonymous Access is desired will point to index.cfm
  • All requests where user authentication is desired will point to indexsecure.cfm

    Putting It All Together -
    Modifying an Existing Fusebox Application
    to Use Both Authentication Modes

    The following work with both older Fusebox 2.x and Fusebox 3 apps.

    Changes in Your Fusebox Application

  • First and foremost, make a backup copy of your existing Fusebox application before proceeding!
  • Make a copy of index.cfm and save it as indexsecure.cfm. There should now be index.cfm and indexsecure.cfm at the root level of your Fusebox application (see Figure 2).
  • Throughout the entire Fusebox application, change any index.cfm referrals to indexsecure.cfm where user authentication is desired.
  • Leave any referrals to index.cfm alone where anonymous access is desired.
  • Modify application.cfm so it will allow both index.cfm and indexsecure.cfm (see Listing 2).

    To prevent sneaky users from changing a call to indexsecure.cfm back to index.cfm in order to execute an unauthorized fuseaction, it is necessary to modify your Fusebox application so that only the appropriate fuseaction may be called. In a Fusebox application, actions - called fuseactions - are called by traversing a CFSWITCH which determines what action to take.

    With Fusebox 2.x applications, securing which fuseactions get called is easy. Simply delete the fuseactions requiring user authentication from index.cfm and add them to indexsecure.cfm.

    With Fusebox 3.x applications, this is a bit trickier, since index.cfm no longer houses the big CFSWITCH, which resides in FBX_Switch.cfm.We instead modify that file to control which fuseactions are secured and which are not (see Listing 3).

    Changes in File Level Permissions
    You may need to make some changes to permissions at the file level. In order to allow both the anonymous account and authenticated domain users access to your application, it is necessary to ensure that both the anonymous account and authenticated users have Read access. The images here show a "Before" and "After" of file-level permissions settings on a folder. This example works if your Anonymous Access account is a member of the "Domain Users" group. Consult with your domain security specialist before making changes to file-level permissions (see Figures 3 and 4).

    Changes in IIS
    For the directory holding the Fusebox application, select both Allow Anonymous Access and Integrated Windows Authentication. Why turn them both on? When a user passes from a user-authenticated template back to an Anonymous-Access template, they will be denied, since the browser session is now mapped to the current user's credentials instead of the anonymous account. By turning both options on, IIS will use either the anonymous user credentials, or authenticated user credentials (see Figures 5 and 6).

    Those familiar with Fusebox will see that this technique can be modified to work in a variety of ways, but the basic idea remains:

  • All requests where Anonymous Access is desired will point to index.cfm
  • All requests where user authentication is desired will point to indexsecure.cfm

    Note: The technique outlined here represents a deviation from accepted standard Fusebox technique. For more details on Fusebox, please visit www.fusebox.org.

  • More Stories By Alan McCollough

    Alan McCollough is a Web programmer at the Alaska Native Medical center in Anchorage and a recently certified ColdFusion (4.5) developer.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.