Shibbolising Plone 3 - some experiences

In a previous posting I listed two (and a half) options for Shibbolising Plone 3. What follows is a comparison based on what I found when I actually tried installing them into default Plone instances.

[The 'and a half' option was Liberty Alliance / SAML 2 Authentication Plugin for PAS. I'm discounting it for the time being because a) it doesn't look as if it will work with Shib 3, b) there hasn't been a release since December 2008, and c) the most recent release gives '404 Not found' on the Plone web site]

The two remaining options were WebServerAuth and a set of products from Ithaka (AutoUserMakerPASPlugin, ShibbolethLogin, ShibbolethPermissions). They have quite a lot in common (which is not surprising since they share a common ancestor).

Common features

• Both depend on the Apache Shibboleth module to perform authentication, and so require connections to Plone to be proxied through Apache.


• For this to work, server variables provided by the Shib module have to be converted to headers in the proxied request - doing so is a matter of Apache configuration. It is important to ensure that unauthenticated users can't spoof any such headers used for anything related to security.


• Both will allow Plone access by anyone who can successfully authenticate - if this isn't appropriate then Apache access controls could be used to limit this further (and WebServerAuth has an additional option).


• Both require a unique user identifier. Easiest to use the value in REMOTE_USER which is set by default by the Shib module to the first non-blank value in eduPersonPrincipleName or the SAML 2 or SAML1 versions of eduPersonTargetedID. This leads to some unwieldy userIDs - both products can strip domain names from IDs, but this removes any guarantee of uniqueness.


• Both force authentication for an https: version of the site while allowing unauthenticated access to the http: version. While Shib's 'Lazy Session' features might make this unnecessary, both products will in principle work with other webserver-based authentication schemes that may not support anything similar.


• For both, it's advisable to suppress the default 'login' portlet that is displayed to unauthenticated users.

WebServerAuth features

• WebServerAuth doesn't create users in the database - by default they just get assigned the 'Authenticated' role (not 'Member') when they log in. It uses userID (so eduPersonPrincipleName or eduPersonTargetedID, optionally with domains stripped) as the user's Full Name - it doesn't use any other Shib attributes even if they are available.


• Users requiring additional rights can be created in the Plone database and appropriate rights will be assigned when the corresponding users authenticate. Creating Plone users with IDs containing '@' and '.' requires a long-winded hack.


• WebServerAuth can be configured only to authenticate users who have corresponding Plone accounts, but the user interface is sub-optimal: people will log in and apparently succeed, only to be greeted with a Plone page that still has a "Log In" link.


• By default, WebServerAuth redirects to the https: version of the current page when authentication is required (and modifies the standard 'log in' link to achieve this). This will cause the Apache module's default Sessioninitiator to be used for authentication. Optionally WebServerAuth can redirect to a customised URL which could perhaps be used to implement a local WAYF service (e.g. simplified login for local users; redirect to federation WAYF for others). Essentially WebServerAuth takes over all login access to the site (which can be problematic if it fails...).


• WebServerAuth is under current development - its author contacted me within hours of my posting my earlier article to point out an error with it.


• Need to set the standard logout link (ZMI --> Plone --> postal_actions --> user --> logout --> URL) to something apropriate (or perhaps suppress the link altogether?)

Ithica product features

• AutoUserMakerPASPlugin creates real Plone users as new people authenticate. It can use configurable Shib attributes to initialise full name, email, location, roles and group membership. This only applies to user creation - once created, changes to attributes are not propagated and the users need to be managed on Plone. It seems necessary to configure full name to fall back to userID if nothing else is available to avoid all such users ending up with a full name of '(null)'.


• AutoUserMakerPASPlugin can be configured to strip either all or selected domains from userIDs - one approach might be to strip just a local domain, giving local users short userIDs while ensuring against name clashes with anyone else.


• AutoUserMakerPASPlugin supports a configurable 'logout' URL that can invoke the local Shib module logout function. This may be confusing in a wider single sign-on context (but is handy for testing).


• ShibbolethPermisisons adds the ability to add local (per page or per container) access rights based on configurable Shib attributes. Again, this only applies at account creation time, after which rights have to be managed manually within Plone as usual.


• ShibbolethLogin installs a replacement for the standard login page. This includes configurable links either to local SessionInitiator URLs or direct to Shib 1 IdPs or WAYFs. So for example it's possible to have a 'Log in with a Raven (University of Cambridge) user id' link for local users and a more general 'Log in with a different UK Federation user id' link for everyone else. Local Plone user authentication (with username/password) remains available. ShibbolethLogin appears to be targeted at Shib 1 functionality, with no obvious support for new Shib 2 functionality, such as the Discovery Service.


• The maintenance status to the Ithica products is unclear. Documentation reports the most recent tests to have been with "Zope 2.10.5 and Plone 3.0.6"; files in the distribution appear to have been modified most recently in May 2008.

Federated AUTH is less than half the battle

Federated web authentication, as provided by Shibboleth, OpenID, Pubcookie, Cambridge's Ucam WebAuth (a.k.a. Raven), etc., is less than half the battle of adapting an application to work in a federated environment. Much the harder part involves the related issues of authorisation and account provision.

Most existing applications assume that they have some sort of account for every users who can authenticate, not least because traditionally they need somewhere to store user names and passwords. In the federated authentication world this won't always be true, since lots of people will be able to authenticate that the application has never heard of.

Approaches to dealing with this include:

Require an account to exist locally before a user can authenticate

If handled manually, this can impose an administrative overhead which will only be manageable for a small user base. Alternativly accounts could be provisioned automatically, but only if the expected set of users can be identified in advance. It is often hard to adapt existing software to not fail badly when presented with an authenticated user who doesn't have an account.

Users may have to tell administrators how their identity provider will identify them and this could be a problem - in Shib's case it is currently unlikely that users will know their eduPersonPrincipleName (even if it is available), and they can't predict their eduPersonTargetedID. An authenticated 'Application' page that captures available attributes might be a way around this.

Automatically provision an account when a user first authenticates

Doing this entirely automatically assumes that information is available about the user, and so assumes either Shib-like attribute provision or access to additional data in something like an LDAP directory. It also assumes that enough information is available to create accounts - some existing applications positively require things like forename and surname which is problematic if these are not available. Alternativly or additionally, users can be prompted for additional information, though obviously this is less reliable and implementing such prompting can be difficult.

However it is also necessary to decide who will get such accounts, since it's unlikely that you will actually want to provision an account for everyone who can successfully authenticate, especially if such accounts come with some basic privileges. So some sort of rule engine will be needed to define who does and doesn't get an account, and perhaps what default privileges they get. This will have to be driven by Shib-like attributes or information from directories. For obvious (I hope) reasons, such decisions probably can't be taken based on information supplied by the users themselves.

Dynamically log users in without creating accounts for them

In some applications it's possible for a user to appear 'logged-in' without having a corresponding user account. One example I happen to know about s Plone using the WebServerAuth product. This simplifies things somewhat, though you still need to address the question of who gets what access by default. You probably need some way to manually grant additional access to a limited number of people where the people and the access that they need can't be established based on attribute or directory data - for them, some sort of local account bound to their federated identity will probably still be needed.

Shibbolising Plone 3 - a review

There are lots of Google references to shibolising Plone, but it's not clear how many of them apply to Plone 3 (rather than Plone 2 or earlier). All seem to rely on getting Apache to implement the Shibboleth protection, and then passing identity information over to Plone for it to use.

It looks as if the options include

• ApachePASS
• Auto Member Maker

which seem to have been replaced by

• WebServerAuth

all from (or at least related to) the WebLion project at Penn State. There's a useful page on WebServerAuth on the WebLion site.

Alternativly there are three extensions from Ithaka

• AutoUserMakerPASPlugin
• ShibbolethLogin
• ShibbolethPermissions

which are described in this this slide set and this article.

It looks as if the Ithica solutions actually provision Plone accounts for Shib-authenticated visitors, while the WebLion products give such users 'authenticated' state without creating accounts for them. I can see pros and cons for both approaches. WebServerAuth is being actively developed (last release August 2009); none of the others look as if they are very actively maintained. The Ithica products apparently work with at least Plone 3.0.6; apachepass only claims to work with Plone 2.5; Auto Member Maker and WebServerAuth apparently work with Plone 3.

Note: updated 2009-09-15 to correct the development status of WebServerAuth in the light of comments by Erik Rose.

Note also that the Liberty Alliance / SAML 2 Authentication Plugin for PAS might be relevant, if it's sufficiently flexible to talk Shib.

See also Shibbolising Plone 3 - some experiences