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!