Hi Niels, This should actually be possible using the AppServerThrustedAuthentication specific authentication.
xwiki.authentication.authclass=com.xpn.xwiki.user.xwiki.impl.AppServerTrustedAuthServiceImpl Ludovic Niels Mayer wrote: > It would be nice if there was a way of using Apache Basic Authentication > API, alongside w/ mod_ssl <http://www.modssl.org/>, > as a concrete way of implementing "single sign on" across multiple > applications fronted by Apache HTTPD. This would allow > Xwiki to coexist better alongside other existing web-apps or existing > websites; in the future, such flexibility would ease transition into more > extensive use of Xwiki infrastructure, while coexisting with existing > implementations based on the predominant webserver. > > This architecture further allows a simple partitioning of "static" and > "dynamic/java" content across servers and services, as well as the ability > to share logins across multiple web-apps (not all necessarily java) > integrated under one portal or website. The static/dynamic partitioning is > especially worthwhile for large content, say digital media, or software > distributions, where lots of long-running downloads translates to lots of > java memory churn and resulting bad performance... > > An example of interoperability between apache-basic auth and Java: > Crowd<http://confluence.atlassian.com/display/CROWD/Crowd+Documentation>has > an apache basic authentication module: > http://confluence.atlassian.com/display/CROWDEXT/Apache+Basic+Authentication+Module+written+in+cthat > allows the same logins used for "JIRA, Confluence and Bamboo" to also work > as a basic gating mechanism for the web-server fronting java. This > particular usage of the apache basic authentication API permits non-Java > webapps, or > static files, to be "gated" by the same credentials used for > jira/confluence/bamboo. > > The reason why I mention mod_ssl is because if you want to do real security, > or not be transmitting credentials in-the clear, you'll need it. A proper > security solution that is now becoming quite practical (and free) is the > use of X509 client certificates, for example, see > https://www.myopenid.com. Alongside mod_ssl's FakeBasicAuth ( > http://www.modssl.org/docs/2.8/ssl_reference.html#SSLOptions ) this uses the > API of apache basic authentication, using credentials coming directly from > the certificate (usually the full-email address, which is part of the client > certificate data that is "signed"). > > When this option is enabled, the Subject Distinguished Name (DN) of the > Client X509 Certificate is translated into a HTTP Basic Authorization > username. This means that the standard Apache authentication methods can be > used for access control. The user name is just the Subject of the Client's > X509 Certificate (can be determined by running OpenSSL's openssl > x509command: openssl > x509 -noout -subject -in *certificate*.crt). Note that no password is > obtained from the user. Every entry in the user file needs this password: `` > xxj31ZMTZzkVA'', which is the DES-encrypted version of the word `password''. > Those who live under MD5-based encryption (for instance under FreeBSD or > BSD/OS, etc.) should use the following MD5 hash of the same word: `` > $1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''. > > If there was an "Apache basic auth" gateway into Xwiki, then Xwiki could > also easily use such a solution to obtain the login credentials from the > certificate, or simply use existing Apache-Basic-Auth credentials for > consistency and single-sign-on in a "portal." The reason why this is > important is that some fortune-500 companies won't allow external access to > their data (extranet portal scenario) w/o the security guarantees available > in x509 client-certificates. In particular, corporate security likes the > ability to be able to instantly revoke or invalidate certificates that pose > a security threat, and "two-factor" access: something you have -- the x509 > cert, and something you know -- your password. > > I elaborate along the lines of this solution here: > http://n2.nabble.com/Using-Apache-BasicAuth-or-mod_ssl%27s-%22FakeBasicAuth%22-and-MyOpenID-(was-Re%3A-logout)-td515763.html > http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SingleSignOnAuthenticationIntegration?viewer=comments&; > > PS: another apache/java trick that is very useful -- using > mod_auth_mda<http://www.frogdot.org/mod_auth_mda/>for passing > time-limited temporary "fine-grained" access control credentials > (in the form of a specially signed cryptographic cookie) from Java to > apache. In other words, one might login to an Xwiki-based system; within an > Xwiki "app" one would construct a specially formatted cryptographic > cookie<http://www.frogdot.org/mod_auth_mda/cookie.html>. > That cookie would permit temporary access to a particular > file/directory/application hosted on the apache webserver (e.g. a static > file that you only want accessbile to logged-in people). Without the cookie, > or if the cookie expires, a user cannot access directories files or > applications specificallly protected by mod_auth_mda. The following > flowchart illustrates the process: > -- <http://www.frogdot.org/logintools/pab/scheme1.gif> > -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
