|
|
|
|
|
|
Forget everything you know about advanced security in Macromedia
ColdFusion. It no longer applies in Macromedia ColdFusion MX.
Let me run through a couple significant changes ColdFusion MX
has made in its philosophy on implementing advanced security.
First, ColdFusion MX separates security into two distinct categories:
resource security and user security. The days of creating complicated
security contexts with users, rules, and policies in the ColdFusion
Administrator are over. You'll now control authentication and
authorization programmatically from within your ColdFusion applications.
Coincidently, most developers are already building their applications
this way.
Secondly, ColdFusion MX does not use Netegrity SiteMinder for
advanced security, and therefore no longer has built-in support
for authenticating and authorizing against user directories. This
leaves you looking for another way to get to your user information.
Not to worry, though. This article explains the main differences
in implementing security in ColdFusion MX and how to authenticate
and authorize against NT domains, LDAP directories, and databases
because this is no longer built-in.
But before you go any further, here is a brief explanation of
advanced security in ColdFusion MX.
Advanced security in ColdFusion MX
The fact that ColdFusion MX Application Server is a Java-based
application is itself a significant change for ColdFusion. While
designing the new version, Macromedia tried to eliminate some
of the difficulties in implementing ColdFusion advanced security
found in the previous versions.
As I mentioned, ColdFusion MX separates security into resource
and user security. You use resource security to lock down available
system resources. You use user security for two reasons:
- Authentication: identifying an individual usually based on
a username and password
- Authorization: granting or restricting access to system objects
based on a user's identity
Defining resource security
Resource security (also called "Sandbox Security") opens
up many easy options for securing your applications. You use resource
security to secure access to ColdFusion resources. For instance,
based on the CFML page location, you can apply a set of access rules
to all CFML pages in a directory. The directory or directories to
which a set of rules applies is called a "sandbox." Please
note that Sandbox Security is only available in ColdFusion Server
Enterprise editions.
The ColdFusion Administrator Sandbox Security Settings page enables
resource security (see Figure 1). |
| |
 |
| Figure 1 ColdFusion
MX Administrator Sandbox Security Settings page |
| |
| By default, resource
security rules apply to the specified directory and all of its subdirectories,
unless you specify a set of rules for a subdirectory. If you create
a set of rules for a subdirectory of another sandbox, the subdirectory's
rules override the parent directory's rules. If you add a Security
Sandbox, you can click on it and drill down to secure various resources
(see Figure 2). |
| |
 |
| Figure 2 Security
Permissions for a specific Sandbox. |
| |
|
Here are some ways in which you can establish resource security:
- Apply different sets of rules to different directory structures.
- Partition a shared hosting environment so that a number of
applications with different purposes, and possibly different
owners, run securely on a single server.
- Set up a separate directory structure for each application,
if multiple applications share a host, and apply rules that
allow each application to access only its own data sources and
files.
Put simply, a Sandbox is a designated directory structure on
which you apply grants or restrictions to ColdFusion. ColdFusion
Sandbox security makes ColdFusion access secure and determines
what ColdFusion Server can perform in a specific directory (and
subdirectories). You can restrict access to data sources, tags,
functions, files/directories, and IP or ports. You no longer use
policies or security contexts. In short, resource security determines
whether ColdFusion is allowed or not allowed to perform a specific
action in a specific directory.
Defining user security
User security is the single most significant change to advanced
security in ColdFusion MX. You no longer associate users and rules
in policies to control authentication and authorization. Instead,
you must programmatically control who has access in each application.
With the introduction of several new features in ColdFusion MX,
you'll see that this is not as difficult as it seems.
Simply put, ColdFusion MX Server does not determine a user's file
access as it did in the past (where you created security contexts,
user directories, policies, and rules in ColdFusion Administrator).
Users are assigned permissions to execute the ColdFusion code
separately through either the web server or programmatically using
CFML tags and functions.
There are some new tags and functions available to help enable
this new security model. Table 1 shows the tags and functions
demonstrated in this article, as well as a few items deprecated
in ColdFusion MX.
| New
Tags and Functions |
Other
Useful Tags |
Deprecated
Tags and Functions |
CFLOGIN
CFLOGOUT
GetAuthUser( )
IsUserInRole( )
|
CFARGUMENT
CFCOMPONENT
CFCOMPONENT
CFFUNCTION
CFLDAP
CFQUERY |
CFAUTHENTICATE
CFIMPERSONATE
AuthenticatedContext( )
AuthenticatedUser( )
IsAuthenticated( )
IsAuthorized( )
IsProtected( ) |
|
|
| |
There are some examples
of securing applications in Chapter 16: Securing Applications, in
the ColdFusion MX documentation, "Developing ColdFusion MX
Applications with CFML." This chapter also explains how to
use the new security tags and functions. Additionally, you can use
ColdFusion
MX LiveDocs, the HTML version of the ColdFusion MX documentation,
to see this information.
Implementing advanced security in ColdFusion MX
While many developers dealt with the challenges of using, Netegrity
SiteMinder, the third-party security software in ColdFusion Server
versions 5 and 4, many developers decided to create security solutions
without it. Some developers preferred using security functionality
that was not hidden within a third-party product. Without SiteMinder,
the built-in user directories that were part of advanced security
are no longer available. Everyone must now authenticate through
the web server or programmatically. Therefore, if you are using
an NT domain, an LDAP directory, or a database as a user directory,
you must now decide how to implement security programmatically.
The remainder of this article explains and demonstrates security
options. The first security option described below, explains how
to implement web server authentication with IIS and your NT Domain,
and only accomplishes authentication, not authorization. Following
that, each section will describe a programmatic security option
that authenticates and authorizes a user. You will select one of
the programmatic security options and insert it into the sample
application you will build, in the section "Using
the new security tags and functions."
|
| |
|
|
|
|
Sample files
Download the source files for this tutorial:
|
|
|
|
| |
|
|
|
|
|
|
|
About the author
Rob Rusher is Chief Technology Officer at AYC Limited, an Internet
consulting and training company focused on planning, building, and
integrating rich applications and e-business services to enhance
knowledge sharing, e-commerce and business communications initiatives.
Rob is an active member of the Northern Colorado ColdFusion User
Group, Denver Java Users Group, and XP Denver. He also gives free
talks at user groups and presents topics at various developer conferences.
Recently, Rob co-authored "Hack
Proofing ColdFusion" (Syngress Media Inc., 2002) with ColdFusion
gurus David An, Daryl Banttari, and Sarge (Sheldon Sargent). He
has also written several articles for AllColdFusion.com.
|
|
|
|
|
