Options for Securing Your Application

This section briefly outlines the topics to consider if you need to secure access to your ColdFusion templates. You can use more than one of these options at the same time if you want.

• SSL encryption

• HTTP basic authentication

• Application-based security

• ColdFusion's <cflogin> framework

• ColdFusion Sandbox Security

• Operating System Security

SSL Encryption

Most of today's Web servers allow you to make a connection between the browser and the server more secure by using encryption. After encryption has been enabled, your ColdFusion templates and related files become available at URLs that begin with https:// instead of http://. The HTML code your templates generate is scrambled on its way out of the Web server. Provided that everything has been set up correctly, browsers can unscramble the HTML and use it normally. The framework that makes all of this possible is called the Secure Sockets Layer (SSL).

Browsers generally display a small key or lock icon in their status bar to indicate that a page is encrypted. You probably have encountered many such sites yourself, especially on pages where you are asked to provide a credit card number.

This topic isn't discussed in detail here because encryption is enabled at the Web-server level and doesn't affect the ColdFusion Application Server directly. You don't need to do anything special in your ColdFusion templates for it to work properly. The encryption and decryption are taken care of by your Web server and each user's browser.

You might want to look into turning on your Web server's encryption options for sections of your applications that need to display or collect valuable pieces of information. For instance, most users hesitate to enter a credit card number on a page that isn't secure, so you should think about using encryption during any type of checkout process in your applications.

TIP

If you are working on a company intranet project, you might consider enabling SSL for the entire application, especially if employees will access it from outside your local network.

The steps you take to enable encryption differ depending on which Web server software you are using (Apache, Netscape/iPlanet, Microsoft IIS, and so on). You will need to consult your Web server's documentation for details. Along the way, you will learn a bit about public and private keys, and you will probably need to buy an annual SSL certificate from a company such as VeriSign. VeriSign's Web site is also a good place to look if you want to find out more about SSL and HTTPS technology in general. Visit the company at http://www.verisign.com.

TIP

If you want your code to be capable of detecting whether a page is being accessed with an https:// URL, you can use one of the variables in the CGI scope to make this determination. The variables might have slightly different names from server to server, but they generally start with HTTPS. For instance, on a Microsoft IIS server, the value of CGI.HTTPS is on or off, depending on whether the page is being accessed in an encrypted context. Another way to perform the test is by looking at the value of CGI.SERVER_PORT; under most circumstances, it will hold a value of 443 if encryption is being used, and a value of 80 if not. We recommend that you turn on the Show Variables debugging option in the ColdFusion Administrator to see which HTTPS-related variables are made available by your Web server software.

HTTP Basic Authentication

Nearly all Web servers provide support for something called HTTP basic authentication. Basic authentication is a method for password-protecting your Web documents and images and usually is used to protect static files, such as straight HTML files. However, you can certainly use basic authentication to password-protect your ColdFusion templates. Users will be prompted for their user names and passwords via a dialog box presented by the browser, as shown in Figure 211. You won't have control over the look or wording of the dialog box, which varies from browser to browser.

Figure 21.1. Basic authentication prompts the user to log in using a standard dialog box.

Basic authentication isn't the focus of this chapter. However, it is a quick, easy way to put a password on a particular folder, individual files, or an entire Web site. It is usually best for situations in which you want to give the same type of access to everyone who has a password. With basic authentication, you don't need to write any ColdFusion code to control which users are allowed to see what. Depending on the Web server software you are using, the user names and passwords for each user might be kept in a text file, an LDAP server, an ODBC database, or some type of proprietary format.

To find out how to enable basic authentication, see your Web server's documentation.

NOTE

One of the shortcomings of HTTP Basic Authentication is that the user's entries for username and password are sent to the server with every page request, and the password isn't scrambled strongly. Therefore you may want to consider enabling SSL Encryption (discussed in the previous section) when using HTTP Basic Authentication, which will cause all communications between server and browser to be scrambled.

TIP

When basic authentication is used, you should be able to find out which user name was provided by examining either the #CGI.AUTH_USER# variable or the #CGI.REMOTE_USER# variable. The variable name depends on the Web server software you are using.

NOTE

Microsoft's Web servers and browsers extend the idea of basic authentication by providing a proprietary option called Integrated Windows Authentication (also referred to as NTLM or Challenge/Response Authentication), which enables people to access a Web server using their Windows user names and passwords. For purposes of this section, consider Windows Authentication to be in the same general category as basic authentication. That is, it isn't covered specifically in this book and is enabled at the Web-server level.

Application-Based Security

The term application-based security is used here to cover any situation in which you give users an ordinary Web-based form with which to log in. Most often, this means using the same HTML form techniques you already know to present that form to the user, then using a database query to verify that the user name and password they typed was valid.

This method of security gives you the most control over the user experience, such as what the login page looks like, when it is presented, how long users remain logged in, and what they have access to. In other words, by creating a homegrown security or login process, you get to make it work however you need it to. The downside, of course, is that you must do a bit of extra work to figure out exactly what you need and how to get it done. That's what a large portion of this chapter is all about.

ColdFusion's <cflogin> Framework

ColdFusion provides a set of tags and functions for creating login pages and generally enforcing rules about which of your application's pages can be used by whom. The tags are <cflogin>, <cfloginuser>, and <cflogout>. For basic web applications, the framework provides the same kind of user experience as Session-Based security. The main purpose of the new framework is to make it easier to secure more advanced applications that make use of ColdFusion Components and Flash Remoting.

NOTE

For details and examples, see the "Using ColdFusion's <cflogin> Framework," below.

ColdFusion Sandbox Security

ColdFusion MX provides a new set of features called Sandbox Security (also called Resource Security), which takes the place of the Advanced Security system present in previous versions of Cold Fusion. Advanced Security attempted to provide a unified system that could be used internally by CFML developers in their applications, and also by hosting companies needing to be able to turn off certain parts of ColdFusion for individual developers. It included the <cfauthenticate> and <cfimpersonate> tags, and a number of specialized CFML functions. Many people complained that this system, while very powerful, was too complex.

Aimed mostly at Internet Service Providers and hosting companies, the Sandbox Security system in ColdFusion is simpler, while still remaining flexible and powerful. It is now possible to use the ColdFusion Administrator to designate which data sources, CFML tags, and other server resources can be used by which applications. For instance, if a single ColdFusion server is being used by several different developers, they can each feel confident that the others won't be able to access the data in their data sources. Also, if an ISP doesn't want developers to be able to create or read files on the server itself via the <cffile> tag (discussed in Chapter 34, "Interacting with the Operating System"), it's easy for the ISP to disallow the use of <cffile> while still allowing developers to use the rest of CFML's functionality.

NOTE

Because it is designed primarily for ISPs and hosting companies that administer ColdFusion servers, Sandbox Security isn't covered in detail in this book. If you have an interest in what the Sandbox Security system can allow and disallow, please refer to the Cold Fusion documentation, the online help for the Sandbox Security page in the ColdFusion Administrator, or our companion volume, Advanced Macromedia ColdFusion MX 7 Application Development (Macromedia Press, ISBN 0-321-29269-3).

Operating System Security

Included in the latest version of ColdFusion is a new <cfntauthenticate> tag. This allows you to integrate your ColdFusion code directly with the operating system's security (as long as your operating system is Windows). The tag, <cfntauthenticate>, allows you to not only check a username and password against a Windows domain. You can optionally also return the list of groups a user belongs to.