Three paths to an authenticated session, Part 3: Delegated Authentication

If you’re just joining this topic, take a peek at:
Part 1: Introduction
Part 2: Built-In Authentication

If Built-In Authentication doesn’t strike your fancy, then you’re in luck. Click Commerce Extranet provides the flexibility for you to roll your own using an External Authentication Data Source. The two most common approaches are to use LDAP or Active Directory, though nothing prevents you from using any other source, such as an external database, your HR system, etc.

The Extranet Authentication Process

As mentioned in the last post, all access to an authenticated page must first go through a login page. This doesn’t mean, however, that the user will ever see the login page. At the heart of this page is the Login Component. On that component exists logic that is executed as the login page is being rendered to facilitate both Delegated The following steps are performed:

1. Check to see if the user is externally authenticated
   
2. If not, present the Login form and collect username and password
3. Authenticate the user externally
4. If unsuccessful, authenticate the user locally
5. Create authenticated session

In delegated authentication, the user is presented the Extranet login screen and asked to provide their credentials. These credentials are then validated against an external data source, such as LDAP. All Extranet does, however, is call a method that is intended to be overridden to contain whatever you need to do to authenticate the user.

If you launch Entity Manager, you will be able to find an Entity Type named “ExternalConnector”. This is an abstract EType.
Customizations should subtype this to implement single-signon
and other forms of external or delegated login authentication.

The method that Extranet calls to allow you to externally validate the provided credentials is “authenticateUser(userID, pwd)”. This method needs to return either true or false. If the return value is false, the authentication fails and an intentionally generic message is displayed to the user to communicate this fact. If the method returns true, the caller retrieves the logged in user now associated with the current session; if there is one, it presumes a successful login has been accomplished, otherwise it proceeds to perform the login itself, validating the credentials as a standard Extranet user.

You can see a basic template for the method here. The ExternalConnector Entity Type also includes an excellent description of the authenticateUser method.

Once you have created your subtype, you need to inform Extranet which subtype to use. This is done by setting the value of a shared attribute named “externalConnectionType” on CustomUtils. This attribute contains a string which is
the name of the EType which subtypes ExternalConnector.  By default the value is “ExternalConnector”.

To enable delegated authentication, perform the following steps:

1. Locate the Entity Type named Customutils in Entity Manager
2. Right click CustomUtils and ‘Edit Entities‘ change the externalConnectionType to be the name of your new subtype of ExternalConnector instead of ExternalConnector
3. Save your changes

Once complete, your Delegated Authentication implementation should be able to handle the following cases:

• User in Extranet but not in external authentication source
• User in Extranet and in external authentication source
• User not in Extranet and in external authentication source
• User not in Extranet and not in external authentication source

Of course, there are a few details left out in this post such as the specifics of how you connect to your external authentication source and validate the user credentials. Those details vary by implementation. By far, the most common external source is LDAP or Active Directory. Click Professional Services has plenty of experience in implementing Delegated Authentication and can get you up and running quickly. If you’re interested in enhancing your site in this way, just let us know. We’ll be glad to help.

Cheers!

Three paths to an authenticated session, Part 2: Built-In Authentication

If you’re just joining this topic, take a peek at: 
Part 1: Introduction

By default, Click Commerce Extranet based sites allow a user to sign in using built-in authentication. This means that the site presents its own login screen and all user account information, including user ID and password, are maintained within the site’s database. The user will be presented the login screen in one of two cases:

• When browsing a public page, the user clicks the login link in the upper right corner.
• The user attempts to access a secured page directly. For example, they click a link to a project workspace in an email notification.

In both cases, the user next sees a page with the user ID and password prompts.

Did you know that you can make your own login page? The login fields themselves are presented as part of the Login component which you can place on any page. In the starter site, there is an entire page dedicated to login, but that’s just a configuration choice. Other sites have also put the login component directly on their home page.

When an anonymous user requests access to a secured page, Extranet will redirect them to the page where they can login. The page they are sent to is configured on the secured page or one of the pages up the page hierarchy from there. One of those pages must have a login page defined for it. The settings are found on the Properties dialog for the page.

At a minimum the root page in your site needs to have a login page configured for use by all pages, but you have the option of creating additional login pages for use in different sections if you wish. Extranet will redirect the user to the configured login page whenever authentication is required and will look something like this:

With built-in authentication, the user is required to enter a valid user id and password. Extranet then uses this information to authenticate the user against the local database. If authentication fails, a message is displayed, otherwise, the user is redirected to the page they were originally trying to reach. If the original URL is the default URL for the site, or the user clicked the login link themselves, they will be directed to their default page once authenticated. In most cases this would be their personal page.

At the time the login page is rendered, there are a couple of additional checks that are made to determine which authentication approach is to be used. As built-in authentication is the default, you don’t have to do any additional configuration to allow your users to login (other than to make sure they have accounts, of course).

Use of Built-In Authentication also makes it easy to use several other built-in features that you can configure via Login Policy administration or the Login Component including:

• Remember Me
• Password Policies
• Forgot User ID and Forgot Password feature
• Account Lockout Policies
• Terms and Conditions
• Legal Notification

In the next post, I’ll explain what is required to enable delegated authentication.

Cheers!

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!