When ever I talk to customers and partners about single-sign-on (SSO) and the concepts of “authentication” I’m quite often baffled by the level of misunderstanding, misconception and lack of knowledge about just how “authentication” works. Now the reason I put “authentication” is quotes is that when we talk about authentication it’s really not just authentication we’re talking about. When we talk about confirming the identity of a user and confirming that the user is allowed to access a given resource we actually talk about two related concepts which are always performed – 1) authentication and 2) authorization.
Authentication is the process by which we authenticate the user i.e. find out that the user is authentic and is who he or she claims he or she is. This is most often done using a username and a password but there are numerous ways of doing this. The authentication step is most often followed immediately by authorizing the user to perform a certain task or access a certain resource. A user may be authenticated but not authorized i.e. we know who the user is with certainty but the user is not allowed to perform the operation or access the resource he or she set out to perform or access. A user may also be authorized without being authenticated in which case we allow an non-authenticated user (e.g. Anonymous in IBM Domino) to have certain rights in the system. The latter is the case where an Anonymous user is allowed to open a database, browse a web site etc.
The failure to distinguish between these two steps can lead to a lot of SSO issues and errors not being easily understood and/or debugged. Consider the case where a user signs into System A (i.e. authenticates and the user account authorized to perform the task at hand) and then moves on to System B to access another resource or perform a task which the user is “suddenly” unable to perform. Why? The user was able to work in System A so why not in System B?
This is the time where the person debugging this should stop and think…
Is the reason not because the user isn’t authenticated but because he or she isn’t authorized? Could it be that the user is authenticated both by System A and System B but that System B wasn’t able to authorize the user? Maybe because the username was in another format or the particular username permutation not listed in the ACL or group authorizing the user to work in System B. Knowing about the steps performed can make it a lot easier (or just possible) to diagnose.
Using a good old Notes database with a wide open ACL and a simple page displaying the username of the current user (i.e. using @UserName in a piece of computed text) can make all the difference. It easily shows issues with the user being known by a LDAP username (e.g. cn=Mikkel Flindt Heisterberg,ou=Users,dc=intravision,dc=dk) and not by a Domino distinguished name (CN=Mikkel Flindt Heisterberg/O=IntraVision) or SSO not working due to misconfigured domain names, no shared secrets etc. by the user being known as “Anonymous” because the LtpaToken(2) was never sent to the server due to the cookie rules not being fulfilled. Same goes for Websphere Application Server – a simple WAR based application with a servlet displaying the current username is great for debugging.
Hope it clarifies matters and is helpful to someone.
This morning I helped a customer because they couldn’t make the beta of the OnTime Group Calendar for IBM Connections work and it turned out to be a Single-Sign-On issue. For the OnTime widgets to work we require SSO between Websphere Application Server and Domino which is trivial to set up. Simply export the SSO keys from Websphere using the Integrated Solution Console (ISC) and import them into the SSO document in Domino Directory. In Websphere Application Server terms this is called cross-cell SSO and is very easy to set up.
After doing this SSO still didn’t work and right of the bat I suspected the good ol’ “multiple O= identifier” issue. The issue is when you incorrectly configure federated repositories and a username is reported by ISC with an extra organization identifier e.g. I would be “CN=Mikkel Flindt Heisterberg,o=IntraVision,o=IntraVision” and not simply “CN=Mikkel Flindt Heisterberg,o=IntraVision” the latter of course being correct. While WAS (and IBM Connections) will work just fine with that type of configuration is can cause SSO not to work correctly or only work when the user authenticates to Domino first the problem being that the DN that WAS sticks into the LtpaToken isn’t valid in Domino.
Verifying the names is easy using “Users and Group/Manage Users” in the left hand menu in ISC.
After reconfiguring federated repositories and restarting Websphere Application Server SSO functioned and the customer was back to using the OnTime Group Calendar widgets.
Just stumbled over this new article on the developerWorks site on how to configure SPNEGO for Lotus Connections to allow SSO for Windows users. Should be an interesting read. For more information see Configuring single sign-on for IBM Lotus Connections in the Kerberos environment on the site.
This morning I configured single-sign-on (SSO) between Lotus Connections and Lotus Domino and was again surprised by how easy it is. The steps are simple:
- Open the WAS server administration interface and go to Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration.
- Select “Authentication mechanisms and expiration” in the “Authentication” section on the right hand side.
- Now in the “Cross-cell single sign-on” section specify a set of passwords and export the keys to a file on the file system.
- Move the file to your local file system.
- Now follow the guidelines in the Domino Administrator help for importing the keys into Domino LTPA configuration.
So the new abbreviation you have to learn is SPNEGO. SPNEGO is a stadardized protocol for single-sign-on (SSO) between diverse systems. The purpose of the protocol is to provide SSO between the operating system and the services you use whether they be on the web or client applications. Basically it means that the credentials of your Windows logon is automatically used and you are logged transparently into any services that are SPNEGO aware (of cause there are provisions for mapping credentials between systems as well).
So what does this mean for you as a Lotus professional?
An easier life is what it will eventually mean. For now SPNEGO can be configured with Lotus Connections since it runs on Websphere Application Server. In fact there was an article on this just recently on developerWorks (SPNEGO TAI: Using single sign-on from Windows to WebSphere Application Server). In the near future you will start laughing as it will be the SSO protocol for Notes 8.5 and maybe even for the Domino HTTP server as well.
This will mean better ease-of-use for users and it will mean a dramatically lowered TCO for Lotus technology as all Lotus products will be able to use industry standard SSO technologies probably even without additional costly SSO software.
How do you like them apples? 🙂