Hi all,

Thanks for discussing on this so far. Both simple and digest authentication
are password based http auth schemas. There is at least a third - which I
was talking about - called client-cert. It is supported by almost all app
servers/web browsers, but not many dav clients (one is MS WebFolders). Some
companys even use it for intranet authentication, having the client keys
stored on a hardware token (chipcard). Normally all is done by the browser
and the app server - your webapp only needs to ask for the user name (usualy
a DN in this case) and maybe check the certificate supplied be the client. 

When I look at the Slide source I come to the conclusion that the Slide
server side may be able to support this, but slide client webdavlib has'nt
any support for client-cert authentication. So if I would use webdavlib on
server side, there would be no clean way to implement the security.
I would have to handle extra passwords internally on server side, which the
user does'nt even know of, as he only uses a password to access his key
store on client side.

In my understanding having the webdavlib interface on server side, but with
the added possibility to use it inside the current session by somehow
forwarding the app server supplied auth context to the slide webapp would be
what I need (-: This would have solved the problem Daniel described -
forwarding simple/digest auth - too, he would'nt be forced to use form
authentication and 'juggling' with the users password afterwards inside the
server.

Any hints if this could be easily achieved with the current Slide
architecture? Otherwise I tend to use the extra password solution described
before, maybe by generating the passwords (I guess that would be called
"security through obscurity" (-:).

Kolja

-- 
Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to