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] -----Original Message----- From: Esbach, Brandon [mailto:Esbachb@tycoelectronics.com] Sent: Friday, March 02, 2007 7:03 AM To: xwiki-users(a)objectweb.org Subject: [xwiki-users] Single Sign On 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