I spent the majority of today working on non-technology related projects (lots of face time with people) though I did spend some time looking how I handle SSO and different SSO options in Joomla!. Now my definition of SSO usually differentiates from most people because I offer two different authentication options. To me I define “Single Sign On” (SSO) as when you sign on once, and that then gets used everywhere else. A great example of this is Microsoft’s Integrated Windows Authentication where you sign onto your computer once and then everything authenticates you from there without having you to enter your username or password for the entire session (Microsoft achieves this by using “Kerberos” which is available for all platforms in various solutions). This is then juxtaposed with “Single Sign In” where you use the same username and password but type it into each service individually. The reason for creating this distinction was for when I was working in Joomla! 1.0 on two plugins: one that would allow you to just login using details stored in LDAP and another that would automatically log you in from LDAP – historically both identified as “SSO”, however two plugins called “LDAP SSO” gets a tad confusing especially since the LDAP SSO solution was in fact tied strongly to eDirectory, so one became SSI since you had to redivulge your credentials to it and the other became SSO since it automatically worked you out using other details.

In Joomla! 1.5, my LDAP SSI plugin became the “Authentication – LDAP” plugin and I wrote an updated version of the SSO system now splitting it into two parts: one for identifying the user (the SSO part which returns a username) and one for user sources (e.g. finding details about a given username). So far the SSO system is bootstrapped off a system plugin and the user source system is subservient to it. This allows a disconnect between the parts of the system that work out who the person is and finding their details. Of course, not all systems handle this well – some SSO systems also find out details useful for the user source system (e.g. where information is stored in the SSO packet) so there is also a session based user source plugin that allows the SSO system to provide details without requiring an extra user source plugin. In the next release of JAuthTools there will be a new authentication plugin that features the ability to do everything the built in plugin does as well as integrating with the user source system and providing the ability to require that a user existing in Joomla!. Another new feature is a SSO bootstrap module instead of the system plugin but today is something that I’m trying to work out how to do well: build a generic SSO component.

Now at one point the organisation that pays me money (yay!) needed the ability to transition users automatically between two Joomla! sites. I found an older system that did this for Joomla! 1.0 (though it didn’t work properly, it was only a minor modification to get it to work) and at the time the requirement was actually between a Joomla! 1.0 and 1.5 site so I fixed it up to work with both Joomla! 1.0 and 1.5 legacy mode. Now I haven’t done much with that since I built it, but I’d like to take it and update it to something that is 1.5 native and integrates a lot better. So I’m looking at rethinking the way that it works at the moment and redesigning some of the other systems that I have floating around (such as the SimpleSSO system that I wrote to handle Google authentication better). The thought I’m having is making two categories of SSO system (perhaps finding a name for each): one of the more traditional ones based on Kerberos and others based on OpenID, the SOAP SSO tool I’ve co-opted along the way and my own SimpleSSO system. The difference is that one system can authenticate the user easily in one request or a second request (issuing an authentication challenge, potentially handled at the server level above PHP) and the other typically involves the user bouncing around the web testing if the user is authenticated, if the user trusts the site and then authenticating the user to the site probably with another request sent by the server to the remote site. So I’m working out how to integrate those systems in an effective manner. Some of them are just a matter of generating links to the authentication source and others require some nominal user input (e.g. OpenID). I think I’m going to hijack the plugin infrastructure’s XML files to handle stuff and work from there. Now time to build the entire system!