[xwiki-devs] Using Apache Basic Authentication API/credentials and mod_auth_mda for Xwiki single-sign-on?? (was Re: urgent regarding Xwiki building)
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... 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%... http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SingleSignOnAuthentic... 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> -- Niels http://nielsmayer.com
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... 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%... http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SingleSignOnAuthentic...
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
participants (2)
-
Ludovic Dubost -
Niels Mayer