28 Oct
2008
28 Oct
'08
1:59 a.m.
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-…
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>)l>),
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.…
of the normal AuthType
Basic and
AuthBasicProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.ht…er>.
Then add a
AuthDigestDomain<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.ht…
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>toolt;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 <sergiu(a)xwiki.com> wrote:
Sergiu Dumitriu wrote:
reasons:
--
Niels
http://nielsmayer.com
Niels Mayer wrote:
> On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake <
> asiri.rathnayake(a)gmail.com> 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.…
>>> ]
>> 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
- 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.