Three paths to an authenticated session, Part 1:Introduction

Very little of what Click Commerce Extranet is used for is done without first knowing who the user is. Anonymous access to the site, if allowed at all, is typically restricted to a small amount of general information from the Office of Sponsored research that is intended to be public information. All the real work done in the site requires that you first identify who you are. It’s only by the site knowing the identity of the current user that it can apply security policies, present pertinent information, and guide them along their unique path through the workflow processes.
So, given that, how does a user uniquely identify themselves? Click Commerce directly supports three paths:

1. Built-In Authentication
2. Delegated Authentication
3. Enterprise Single-Sign-On

Built-In Authentication

Click Commerce Extranet includes integrated authentication which involve the user being presented with a login form where they provide their User ID and Password. These credentials are then verified against the user information stored locally within the site’s database. To use this all you have to do is define your users in the site and the rest is already in place.

Delegated Authentication

As an enterprise application, Extranet also supports the mode where the authentication is performed by validating credentials against an external source. Common examples of this are LDAP and Active Directory but need not be limited to those. The real difference with this approach is that passwords are not maintained in Click Commerce. Instead they are maintained as part of an external user authentication data source. The user is still presented the Extranet login screen so that the User ID and Password can be provided but this information is then delegated to an external authentication service. Once authenticated externally, the user is allowed into the site.

Enterprise Single-Sign-On

Taking advantage of ESSO means that all elements of authentication are performed external to Click Commerce Extranet. While there is no standard approach that all implementations use, the most common approach involves a technique I call “Intercept, Authenticate, and Redirect”

• Intercept – Any request for a secured page within the site is intercepted by an IIS Filter installed as part of ESSO. The user is then presented with a login form owned by the ESSO implementation. This is not the Extranet login screen.
• Authenticate - The user provides their credentials into the ESSO Login screen which is then authenticated against the authentication source. This source can be anything, including Active Directory, LDAP, or a facility provided by the SSO vendor. From the perspective of Extranet, it really doesn’t matter.
• Redirect - Once the user is authenticated, the ESSO product will insert a unique identifier for the user into the HTTP Request Header then redirect the user back to where they were originally trying to go in the first place. This time, Extranet will be allowed to handle the request. At this point the user has been authenticated externally but that doesn’t mean that they have already established an authenticated session within the Extranet site. This is handled in Extranet by retrieving that unique identifier from the HTTP Header and using it to look up the user in the local Extranet database. If there is a match, Extranet will create an authenticated session for the user and allow them in.

This may seem like a lot but the Extranet portion of the implementation is accomplished in a single method which extranet automatically calls during the authentication process.
Some examples of ESSO packages include Shibboleth, Pubcookie, Cosign, Computer Associates Site Minder, and Tivoli TIM/TAM.
All three approaches have advantages and disadvantages but as a set of options, cover all of the authentication approaches we’ve seen to date. The decision to use a particular approach is often made for you by institutional policy or your central IT group.
This was just a high level introduction. In subsequent posts, I’ll be digging into how to leverage the integration points provided by Click Commerce Extranet to allow your site to easily plug into to any of these authentication approaches.

Part 2: Built-In Authentication

Cheers!