Hi Diaga, On Jul 4, 2007, at 2:24 PM, diaga(a)nomade.fr wrote: Could you be more specific? - XWiki can export any page in XML and it can import XML (in a certain format). - There's also an XML-RPC interface Either you develop it from scratch or better you integrate an existing one. See http://www.nabble.com/forum/Search.jtp?query=xwiki+forum Short answer: yes Longer answer: http://www.nabble.com/forum/Search.jtp?query=xwiki+SSO Thanks -Vincent

I have one narrow answer to only one of your questions, the third one. We have IBM's TIM/TAM (Tivoli [Access|Identity] Manager), which supports a cookie-based SSO approach, which we utilize via a servlet filter (see the Java Servlet API 2.4) that checks for, verifies, and parses the cookies into a Map of values that it places into an HttpSession attribute, and creates an HttpServletRequestWrapper that implements HttpServletRequest.getUserPrincipal() to return a custom Principal that implements Principal.getName() to return the name set by the cookie, and HttpServletRequest.isUserInRole(String rolename) to return true if the requested rolename is one of the values set in the appropriate field in the cookie. If the required cookies are not found (and the particular servlet path requires authentication), the HttpResponse.sendRedirect(String url) method is invoked with the URL of the SSO login page, which typically takes a parameter naming the requested page (URL-encoded, so as not to present any parameters of its own to the SSO page) so that when the SSO authentication form is satisfied, it redirects again to the originally requested page, and the filter will now be satisfied and pass the request on to the servlet application. So far, I've described nothing that would allow XWiki to work with it unmodified; that's because it's meant to allow any web application that uses the standard Servlet API security features (of which I have, to date, seen exactly zero, though I can always hope that new apps would like to use my filter out-of-the-box) to take advantage of the SSO solution. To get XWiki to work unmodified with the filter, I created an interface with a method that returns an HttpServletRequestWrapper, and for XWiki I implemented it with a class that adds an attribute to the session (accessible by calling getSession() on the request object) whose name is specified by org.securityfilter.filter.SecurityRequestWrapper.PRINCIPAL_SESSION_KEY and whose value is the Principal object described above. This satisfied the default XWikiAuthService (com.xpn.xwiki.user.impl.xwiki.XWikiAuthServiceImpl) so that it never checks for a password, because it takes the Principal that it finds in the session as proof of having validly logged in. The only modification to XWiki was not to any of the Java code, but to the login.vm template, whose form input was no longer needed, so I modified it so that does nothing but redirect to the originally-requested page. I then deployed the filter in two versions, one optioned to require authentication and one not, and mapped the first one to all url-patterns that do updates and the second to those that don't. It was really only necessary to map the authentication-required version to the /bin/login/* path, however, because XWiki itself would redirect to that path any time that authentication was required. I did other things that you may not find necessary, such as automatically creating a user if he wasn't already registered, and putting him into any XWiki groups that were indicated by values found in the cookie data (by consulting an XWiki object that mapped the values to group names). This was considerably more involved, because it required recreating the XWiki context that a request would be using, but it works great, and without changing any XWiki code except the login template. And as others have said in the interim, there's always LDAP... brain[sic]