Using LDAP to Login

Here's a practical example from a different world...

I once wrote a fairly restricted application which would let second-line customer-support folks look at customer orders, and which would allow their managers to do certain things and their gods to do (of course...) anything they wanted.

• The web-server used LDAP to enforce the basic rule of "you may come in."  Therefore, upon arrival at my application, the user was already authenticated ("we know who you are..."), and known to be authorized at least sufficiently enough to be there at all.  ("You are, at least, inside the moat.")  Since an LDAP query had already been performed by the web server, known-good LDAP credentials were available and trustworthy.

• Because the entire application was "surrounded by a moat," the application did not have to be concerned with "intrusion."  Since it relied upon LDAP, it needed no authentication mechanism of its own.  It had no need to pose any further challenges on its own.  This is much simpler, and much more secure, than the other alternatives which are typically used on the open Internet.
  

• LDAP allows you to define "groups" and "attributes" and to pose various (rather XPATH-like) "queries" which it will answer.  Based on business rules established by the company, the app made group-membership queries to determine what a particular user could do, and set internal application variables accordingly.  Throughout the application (and back-end services), appropriate tests were inserted to restrict various displays and controls to "only persons who are in this-or-that role."  It is very easy and natural to express the result of those decisions in terms of "roles," as CF does (and this of course being why it does it).  Hence my comment that "CF provides a very well-thought-out framework for authorization."  Various things that my (non-CF...) app had to do for itself, CF will do for you. "Sweet!"
  

• The user did not have to do anything special:  "click on the icon and go... we know who you are."  The IT personnel didn't have to do anything special either, because the application, being LDAP-aware, already conformed to the user-administration console that they were accustomed to using.  (Microsoft's "management console" scheme is very shrewdly designed, too.)

ColdFusion is designed with this sort of scenario in mind, and to make that scenario very easy to implement.  It already takes care of the issue of knowing about "users" and "what they can do," and it also takes care of knowing when these decisions need to be made..  It provides a well-designed set of tags to let you insert your own logic ... LDAP-based or otherwise ... for use at that time.

Thinking about this a little while...

I would more-or-less categorically say that, if you are dealing with an application where LDAP could be used for authentication, then you are certainly dealing with an intra-net situation where the only people who can get to the web-site are already known to be "logged-on users."  Presumably that login has already been handled through LDAP (nee Active Directory).  So, we already know who the user is and that he is authenticated.  Therefore such an app really does not need, and should not even have, its own "login" mechanism per se.

The existing (Windows) login process, therefore, has already handled authentication, and the web and/or the application server will also have handled the basic level of authorization by consenting to give the user access to the site "at all."

When the user reaches the site for the first time, ColdFusion will use its own mechanisms to realize that it does not yet know that the user is authorized (and the extent of that authorization...) for its own purposes.  ("Now that he's here, what can he (not) do?")  ColdFusion will magically invoke the <cflogin> tag at the appropriate time, but you really don't need to ask the user anything at this point.  All you need to do is to issue an LDAP query (you already know the user's identity and his credentials have already been approved) to find out what groups he's in, to make your own determination as to the proper ColdFusion "roles."  This maps the LDAP-provided information to your own business and security rules, so that the ColdFusion logic within your application can carry out the appropriate "if/then" decisions within your code.

So...

1. Users who are not logged-in to the network don't make it to your app.
2. Users who aren't supposed to get to your app don't make it. either.,
3. Users who do make it are already known to be who they claim to be, and you can transparently determine what choices to offer them.
4. ColdFusion automagically knows when to ask you to make that determination, and provides (through "roles") a well-thought-out mechanism for implementing your decision.

I just want to say, as politely but as forcefully as I can (while still being polite), go and review the <cflogin> tag documentation.  If you have "already got that," then go back and very-carefully read the description of this tag again, along with all of the associated information in the concepts manuals.

"Logins" are not the same as "sessions" or "application variables."

ColdFusion has the means to detect that login has not yet been accomplished, and it will invoke this tag under those circumstances ... circumstances which can vary considerably, and from which this tag is designed to insulate you.

Go to the Adobe documentation section Securing Applications, take a deep breath and read this section entirely.  Do not "skim it" looking for what you think you are looking for.  You must understand the "big picture" of what CF is doing and why it is doing it.  Particularly read About User Security and the three short sections which follow.

It's right here:

     http://livedocs.adobe.com/coldfusion/8/htmldocs/appSecurity_01.html#1100022

This is n-o-t intended as an "RTFM brush-off."  There are many scenarios that can happen, some obvious and some not.

Start by reviewing the <cflogin> tag.

ColdFusion provides the basic framework of an authentication architecture in an easy-to-use way, but it relies upon the content of this tag to actually implement the desired scheme ... calling the <cfloginuser> tag when acceptable authentication (whatever that is to you) has been achieved.

In this tag, then, you will need to issue the appropriate LDAP queries to validate the user's credentials and to assemble a suitable list of roles for that user.  Exactly how you do this is up to you... but the Internet is stuffed with examples, so don't feel like you are the first one to do this.

Depending on exactly how you have set up CF at your site, authentication can be something that the web-server checks for you before even allowing access to your site.  So, "if you are here, you are authenticated."  This can be very convenient, and it has become the strategy that I vastly prefer to use with intranets.  It eliminates the need to implement a "login" system on your own.