As
noted in an earlier posting, I have created a servlet filter that implements
Tivoli Access Manager (TAM)'s cookie-based SSO solution. I could, as I
have done before, simply re-implement the XWiki authentication interface, but
didn't for two reasons: first, because (like a directory service) it provides
other user information than just an identifier, which we use to support XWiki
group memberships, and it would require getting deeper into the bowels of XWiki
than I had done to date (or felt that I had time for); second, a servlet filter
has the advantage of working for any J2EE servlet
application.
Other
reasons influenced my choice, such as the fact that I hate doing the same thing
more than once. More importantly, though, allowing the XWiki
administrators control over group memberships that were not dictated by
enterprise policy and should thus not require them to go through the TAM
administrative user interface.
The
filter reads and validates the cookies, redirecting if it can't, parsing the
data into named attributes which it places in a custom implementation of
java.security.Principal, which it then places in the servlet context where a
custom subclass of HttpServletRequestWrapper gets it so that it can return it
with its getUserPrincipal() method, and its isUserInRole(String) method uses the
data to determine its answer.
Because this isn't enough for most applications (XWiki included), of
which it seems that no two make use of the security APIs in the same way, the
method that composes the custom wrapper from the request and the parsed cookie
data and the one that determines whether authentication is required (in other
words, whether to redirect when valid cookies aren't present) are called through
a public interface. The implementation I created for XWiki does two
things that are necessary to keep XWiki clueless: first, it sets the
Principal's name field by prepending "XWiki." to the authenticated name
(muttering imprecations under my breath against Mssrs Dubost, D and all
things French), and sets that Principal in a session attribute keyed by the
string
org.securityfilter.filter.SecurityRequestWrapper.PRINCIPAL_SESSION_KEY.
In
addition, in the spirit of a true SSO solution, the custom XWiki adapter
implementation auto-registers users it hasn't seen before, by calling createUser
unconditionally because it's easier than trying to figure out beforehand if the
user is already registered. It also determines which of several groups the
user belongs in by consulting a special XWiki document that contains a
collection of XWiki objects, each of which specifies a group name, the name of
the cookie field to inspect, and a regular expression that must be matched by
that field. It then adds the user to groups to which he should belong and
doesn't, and removes him from those to which he does belong and
shouldn't.
This
solution was driven from the perspective of providing a servlet
filter specific to our enterprise SSO with an adapter interface, which
is a valid approach; another would be to create an XWiki-specific filter
which generalized the SSO interface to something like a wrapper factory.
Even better would be a generic filter that approached it from the servlet API
perspective, abstracting away both how to get the authentication data and what
the application needed to do with it.
brain[sic]
Hmm, probably more directed at the
xwiki dev team; and anyone out there who's using LDAP for
authentication.
I
was looking over a few of my listed user requests this morning, and it struck
me just how often folks are having problems with user passwords. To
combat that, LDAP is most likely going to be our priority implementation
(don't think there will be many problems with that, it's quite nicely
documented).
HOWEVER,
This got me to thinking about the single
sign-on (SSO) which is practically a given for users that are on any sort of
directory service when considering major applications - for example, Outlook,
Google's office suite, etc.
I was wondering if anyone had
given some thought to how this may work with Xwiki? Granted, it's not a
critical issue, but surely there is some benefit to users having an automatic
logon based on their already-authenticated network
authentication?
Brandon
Esbach
Software Engineer
Tyco Electronics
LoughMahon Technology
Park,
Skehard Road,
Blackrock,
Cork, Ireland
Tel +353 21
4808305