• Wascou Software Edition
wascou > Blog > eZPublish SSO Handler or not...

eZPublish SSO Handler or not...

Maxime THOMAS on 30 of Jan 2010 - 12pm

Tags : sso , ezpublish

On my last eZPublish project, i have developped a SSO handler which aim was to automatically log out a user if a session cookie is set. This experience allowed me to clarify the process which is not or hardly documented on ez.no.

Back to the roots

Little recall, the SSO(Single Sign On) is a fonctionnality very powerfull which allows the user of a heterogen applications set to log in once and be authentified on the application set without giving again his login / passsword couple.

This need appear soon enough in companies wich were installing applications for their intranet without thinking about technology or authentication management. The consequency was desastrous because the user had to handle a different login and password for each application. In order to insure the minimum consistency, the establishment of directories allowed to centralized connection data but the user had to enter it for each application.

This type of mechanism inevitably leads to one or more exchanges between a client (the application where the user is located in) and a server (the server that determines whether the user is authenticated or not). Many tools exist to manage the server side with a more or less similar approach, but I shall mention only one: CAS.

The advantage of such a service is to manage a set of authentication sources (backends) on one side (eg a MySQL database, a flat file, a LDAP, a web service ...) and an application set (frontend) on the other side. The CAS server only ensure that the application has the right to authenticate and make available all or part of the authentication sources.

The SSO established can do two things

  • First to authenticate. The user arrives at website A, authenticates, gets on site B, he is automatically authenticated.
  • In addition to disconnect. The user disconnects from the website, it returns to the site B where he was authenticated, he is automatically disconnected.

In summary, for a company concerned about the comfort of its users, SSO is a real revolution because it gives access to all resources with a single pair username / password and enables unified management of authentication methods.

eZPublish SSO Handler

Out of respect for my client, I do not disclose their sources even if they are a very good example of SSO management by eZPublish. We will study the integration of an SSO-type CAS or equivalent.

eZPublish has a handler that is integrated with the traditional authentication mechanism which is triggered at two points:

  • When the user is not logged on any pages.
  • Only when the user has authenticated through the user module and its function loginafter login authentication via a Login Handler.

I think that this feature was designed to serve as a eZPublish SSO server and not be a client of an SSO server. This means that eZPublish serves as a reference for other applications and once logged in eZPublish the SSO Handler must allow to authenticate the user directly within each application.
The SSO mechanism positions a SSO token that allows third party applications to detect whether they should contact the SSO server to check if the user is already authenticated or not. After analysis it is found to handle the following 4 cases:

Action SSO token existing SSO token not existing
or invalid
Logged in user Nothing is done Case never reached
Logged out user The user is logged in Nothing is done

As you can see, the case of automatic disconnection is never reached in eZPublish since the SSO handler is hidden behind the Login Handler in the case of the connection and is not called when the user is already authenticated. The problem is that even if you have a token out of date or even better invalid in the current application, you're never disconnected.

A palliative

The implemented solution is quite simple since it is to disconnect the user eZPublish for him to trigger again the SSO Handler. This is done simply by setting a SessionTimeoutbelow the validity of the token in the SSO configuration file site.ini. This maneuver forces eZPublish to disconnect the user . At the next page display, the user triggers the SSO handler that evaluate the invalid token and removes it.
The idea being that is that in later versions of eZPublish, eZSystems functionally correct this point.

Comments 2

1 SSOn != SSOff by Gaetano on 30 of Jan 2010 - 12pm
Thanks for the very detailed and informative post, as always.

Just a quibble: SSO stands in fact for Single Sign ON. What you are asking for is Single Sign OFF.

The two are slightly different mechanisms, and using SSOn does not necessarily involve using SSOff. In fact I think you will find the majority of sso deployments does not.

There are a couple of reasons to this:
1 - performance
2 - business logic

In greater detail:
- in SSOn mode, whenever a user hits a participating server with no session cookie, or with an "anon_user" cookie, the server sends the user's browser to the SSO server via an http redirect, and the SSO server sends the browser back to the original page. This means basically 3 hits instead of one - not good for perfs unless you are on an intranet (plus your sso server should be able to scale when you add more participating servers)
- in SSOff mode, the same 'redirects game' is also done for every page view from an authenticated user, to check that his sso ticket is still valid. Which means even more general slowdown. Especially for intranet sites, where sso is usually deployed and most of the browsing is done in authenticated mode.

The business-logic mostly comes into play with session timeouts that might be different on different servers participating in the SSO ring: what happens when a user session times out on server A? Shall it end the SSO session globally or not? Also at many sites the extra-security implied by SSOff is not held in great value, whereas the commodity of SSOn is...
2 SSO and CAS by Maxime THOMAS on 30 of Jan 2010 - 12pm
You're right by annoucing that SSOn is different from SSOff : it corresponds to two different features and mostly depends on the chosen architecture of the SSO solution.
For the log out, I guess that the beahviour has to be centralized as it's done for the authentication handler and the user data, why not centralize the global session timeout ? If not, a simple idea is to rewrite the session cookie with the desired duration each time user moves from an application to another.