Part 1: Introduction
Part 2: Built-In Authentication
Part 3: Delegated Authentication
Your users interact with more than one online application within your institution. To do otherwise is just plain unusual these days. Perhaps you have one application for IRB processes and another for Grants. Then there’s your information portal, ordering system, Accounting System, HR system and a whole host of other possible applications. This is the reality of today’s world. While the universal goal is to put everything a user needs within arms reach, the unfortunate truth is that the Swiss Army knife approach to life in a research Institution is difficult to achieve in a single application. Next best thing is integrating different applications.
Click Commerce Extranet certainly is a great step in that direction because it enables you to put many Research related activities under one roof, but there will always be other systems. Once we accept this, the real question is how do we make this easier on the users? One pain point is the need to continually have to identify yourself to each system by logging in. Thankfully this is a very easy problem to solve by implementing Enterprise Single Sign-On (ESSO).
There are several excellent ESSO solutions and, even better, many of them are Open Source. Examples include Shibboleth, Pubcookie, CAS, and Cosign. There are also excellent commercial products that provide greater administrative control such as Computer Associates Siteminder or IBM Tivoli Access Manager. What’s nice about all of these solutions is that they all operate in the same fundamental way and Click Commerce Extranet offers a simple interface to plug right in.
All of the most common ESSO solutions work in a very similar way by providing two major parts...
Central Authentication This is the heart of any SSO implementation. It’s the layer that includes the login page and the back end authentication process. This is entirely external to Extranet or really any single enterprise application. Most packages allow you to configure which authentication source you want to use, such as LDAP, Active Directory, or even something you built in-house. The actual process is completely hidden from the Enterprise Application.
The “Guard at the Door”
Access to all Enterprise applications that are a part of the SSO environment is enforced by a layer in front of each application that monitors access and enforces the fact that the user must first be authenticated to enter. If this criteria isn’t met, the user is immediately redirected to the central login screen. For web-based applications, this “guard” is typically an IIS filter so all HTTP requests can be intercepted. You have options over what exactly is protected when configuring the filter. If you require that all users must first be centrally authenticated before they can get to the Extranet site at all, then the filter should be configured to secure the entire virtual root. If, on the other hand, you wish to allow anonymous users to view your “public” pages, then the filter needs to be configured to protect a specific directory in the site.
Combined, these two parts implement the “Intercept, Authenticate, and Redirect” process I described in Part 1.
This is an incredibly simplistic description and, if you’re wanting to know more, I encourage you to read up. All the SSO products have a wealth of documentation where all the finer points are explained.
Configuring Extranet for SSO
In the last post, I described how Click Commerce Extranet supports a delegated authentication model which allows you use an external authentication data source. While there are some good reasons for doing this, such as making it easier for the user to maintain the same user ID and password across all enterprise applications, it doesn’t allow for a seamless experience for the user as they navigate between the various applications because they still have to login to each individually. This is where ESSO becomes a big win because it allows the user to login once and have access to all applications in the enterprise without having to log in again for each.
Let’s review the steps Extranet goes through to authenticate a user:
- Check to see if the user is externally authenticated
- If not, present the Login form and collect username and password
- Authenticate the user externally
- If unsuccessful, authenticate the user locally
- Create authenticated session
This method returns no value. If this method wants to do nothing and just have the user presented with the standard Extranet login form, it merely returns. Otherwise it must redirect the browser to an appropriate page to involve the external login server. More information on this method can be found in the ExternalConnector entity type via Entity Manager.
When considering your SSO implementation, one of the decisions that needs to be made is whether or not you wish to support anonymously accessible pages within the site. Do you have a public facing section that you want to make visible to anyone and not just those who can log in? Or do you want all users to authenticate before any site content can be viewed? The answer to this question will drive the configuration of your SSO implementation. When setting up SSO on the application server, you have the option to secure access at any point within the Site’s hierarchy.
If you want to secure all access to the site, you put the “guard” at the front door (i.e. the virtual root). When doing this, all HTTP requests are handled in this way:
If you want some of your content visible to anonymous visitors, then you need to post your guard at a subdirectory within the site and redirect requests to authenticated pages through a utility page placed in that secured directory. This adds a bit to the implementation but in the end gives you a lot more control over when to invoke SSO. In this case the requests are handled this way:
Simple, right? Actually, in my experience, SSO is far easier to implement than Delegated Authentication and provides a better user experience because the user only has to log in once to gain access to all Enterprise applications rather than once per application in the Delegated Authentication model.
Other Considerations When considering your SSO implementation, one question you should ask yourself is “Will all of the users of my site be able to login via SSO?” Unlike the Delegated model where it’s easy to have the user login using their locally stored credentials if the attempt to authenticate externally fails, it not practical to do this in an SSO model. This is because SSO intercepts the request to the site and immediately redirects the user to a login screen far away from Extranet. It will only redirect the user back to the Extranet site if they successfully authenticate via SSO Authentication. There isn’t an opportunity to intercede so there’s no practical way to authenticate locally, though there may be some impractical ways ;-). This is an important consideration because many sites need to support the needs of users external to the institution which means they need to be added to your central authentication source in order to log in.
There are a few details you’ll need to learn beyond this but in general, that’s all there is to it.
This wraps up my series on the different authentication approaches supported by Extranet. I hope you found it helpful and please know that my team and I are here if you need assistance.
For those of you in the US, have a great 4th of July and for our Canadian friends, enjoy your weekend.
Cheers!
No comments:
Post a Comment