Sergiu -- I am in no way tied to my "hack" so no offense taken ... I just saw Asiri's message of being "stuck" and I thought I'd mention a potential way of getting un-stuck. The second approach I suggested as "non-hack" and supersedes some of the limitations&stupidities of my first attempt. I was just throwing out an idea, not trying to challenge the world :-) However, since this would largely be a hack into the existing authentication system, why not just "plug-in" an authentication system that is more appropriate ... which brings me to the following: Is there any reason why you can't front Xwiki with Apache HTTPD running http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html ?? Combine that with what Ludovic suggested in http://n2.nabble.com/Using-Apache-Basic-Authentication-API-credentials-and-mod_auth_mda-for-Xwiki-single-sign-on---(was-Re%3A-urgent-regarding-Xwiki-building)-td661771.html<http://n2.nabble.com/Using-Apache-Basic-Authentication-API-credentials-and-mod_auth_mda-for-Xwiki-single-sign-on---%28was-Re%3A-urgent-regarding-Xwiki-building%29-td661771.html>and specify a custom authentication in Xwiki via: xwiki.authentication.authclass=com.xpn.xwiki.user.xwiki.impl.AppServerTrustedAuthServiceImpl Then write your own AppServerTrustedAuthServiceImpl, which gets the user-name (and potentially other credentials) from the mod_digest_auth Apache plugin.... For example, with Apache talking to Java via mod_proxy_ajp setting ProxyPass /davxwiki/ ajp://127.0.0.1:8009/xwiki/ setup mod_digest_auth to "protect" the web-accessible space 'davxwiki/' via digest-authentication. This allows a special digest-auth supporting xwiki at URL http://.../davxwiki/... for use w/ DAV. Here's a brief summary of mod_auth_digest: This module implements HTTP Digest Authentication (RFC2617<http://www.faqs.org/rfcs/rfc2617.html>), and provides a more secure alternative to mod_auth_basic<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html> . Using Digest Authentication Using MD5 Digest authentication is very simple. Simply set up authentication normally, using AuthType Digest and AuthDigestProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestprovider>instead of the normal AuthType Basic and AuthBasicProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html#authbasicprovider>. Then add a AuthDigestDomain<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestdomain>directive containing at least the root URI(s) for this protection space. Appropriate user (text) files can be created using the htdigest<http://httpd.apache.org/docs/2.2/programs/htdigest.html>tool. Example: <Location /private/> AuthType Digest AuthName "private area" AuthDigestDomain /private/ http://mirror.my.dom/private2/ AuthDigestProvider file AuthUserFile /web/auth/.digest_pw Require valid-user </Location> .... Sergiu Dumitriu said:
- We're trying hard to abstract the storage mechanism. There is no database, no table, no column. Currently there is no password column, it is just an xwiki property like any other. And as I said before, anything stored in the wiki is retrievable.
When i talk of "column" in the db .. I'm speaking generally and not of the specific implementation. The basic operation of adding another table of MD5passwords (session passwords) via the chosen abstraction mechanism shouldn't be an issue. - Changing the user's password is not acceptable. This means that he cannot
use both the webdav and the browser at the same time. And if he forgets to logout, he won't be able to access the wiki normally.
This wouldn't happen in the "non-hack" version I spoke of subsequently. Unless a dav-login was used, xwiki would see the exact same code-path for all operations. If a dav-login occurred, then authentication would occur through the separare "table" of MD5passwords. And certainly this wouldn't be needed w/ a mod_auth_digest-based implementation suggested above. - Disabling the feature for "Admin" is not good. There is nothing special
about the Admin account, it is just a name we chose for a default account. It could be called anyway, what matters is the rights set in the wiki.
This wouldn't be needed with the "non-hack" version suggested by my second email, nor with the mod_auth_digest-based implementation. ............ On Sun, Oct 26, 2008 at 5:22 PM, Sergiu Dumitriu <[email protected]> wrote:
Sergiu Dumitriu wrote:
Niels Mayer wrote:
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake < [email protected]> wrote:
As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server<
http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.h...
] and sends this to the client. The client in turn uses this nonce value when generating the RESPONSE hash in all following requests.
... Which is why you can have an external "HTTPS-accessible shadow-login program" invoked once per DAV session, to change Xwiki's password to the MD5Password computed from the nonce/session-key. In my previous email I called this DAV login service "davlogin" (e.g. https://.../davlogin?user=foo&md5pass=0x0123456789ABCDEF )
Of course, this would have side-issues like making web-login to a user account in Xwiki difficult since the password would be set to the last session's Md5Password. I guess you could have another program "davlogout" to restore the normal Xwiki password. And another table in the db to store the regular password.
Yes it's a hack.
The next question is there a way to accomplish the exact same thing in code to achieve the same goal, but without the hack.
For example, by adding a new special parameter to any DAV-originated request, to enable authentication based on a new MD5Password column in the database. The MD5Password would be used for authentication for any requests using the special-parameter (e.g. '?dav=true). Basically the same code used currently that looks up the regular password in Xwiki, should have a switch on if "?dav=true" to select lookup using the MD5Password column or the regular password column. (a pretty simple and trivial/scopable change).
Also needed, an external way of setting the user-associated entry in the new MD5Password column to the password for the current DAV session. (akin to https://.../davlogin mentioned above).
This new MD5Password db column represents the MD5Passwords for all active DAV sessions on a given wiki, while the rest of xwiki continues to work the same with the old password mechanism, as long as you don't give the new parameter ?dav=true.
This is getting totally out of control. I'm against this for many reasons:
- We're trying hard to abstract the storage mechanism. There is no database, no table, no column. Currently there is no password column, it is just an xwiki property like any other. And as I said before, anything stored in the wiki is retrievable. - Changing the user's password is not acceptable. This means that he cannot use both the webdav and the browser at the same time. And if he forgets to logout, he won't be able to access the wiki normally. - Disabling the feature for "Admin" is not good. There is nothing special about the Admin account, it is just a name we chose for a default account. It could be called anyway, what matters is the rights set in the wiki. There is nothing special in XWiki, everything is a document, and all documents are equal (except those with programming rights). We should not have special cases in our code. - This is not going to work anyway, since we still can't store HA1 and be able to read it back, and storing RESPONSE is not practicle, since it depends on the visited URL. What I'm saying is that the only thing that can be done with a hashed value is to obtain a cleartext value from the client, hash it and compare it with what is stored in the wiki. Without the full, unencrypted text, there's no way we can make use use of the stored value. And since RESPONSE depends on the visited URL (and in a more secure version on the whole request body), this makes impossible this external "login" service. - Although some implementations do use the same nonce for a full session, this is wrong. The specification clearly states that the nonce should be uniquely generated for each authentication request (see http://tools.ietf.org/html/rfc2617#page-9 ), and by its name NONCE means that it should be used only once.
To clarify things a bit, the specification says that the nonce is generated whenever a 401 response is sent. This does not mean after every client request, but there are no strict rules for this. It could expire after a certain amount of time, or after a number of uses, or who knows. By default, Apache httpd is configured so that nonces expire after 5 minutes. Since we're making the server, we can decide our own strategy for this expiration, so we could make it behave like a session.
- The WebDAV component should be a component, and components don't have strong bounds to other components. So, making special cases for WebDAV is wrong. - And the most important reason for me is that this is ugly. The right code should be clean, simple and elegant, not a complete hack messing around all the platform, just so that we comply with the flawed Digest authentication mechanism. Requiring that the password is plainly available on the server is crazy. If any MS product fails because of this, then it is just another sign of their stupid vendor lock-in attempts, and I will not succumb to them.
I don't mean to offend anybody, I'm just speaking from a technical point of view.
-- Niels http://nielsmayer.com