Author: ts
Date: Thu Jan 24 16:04:38 2008
New Revision: 7242
Log:
- Updated section about authentication after discussion with Kore.
Modified:
trunk/Webdav/design/locking.txt
Modified: trunk/Webdav/design/locking.txt
==============================================================================
--- trunk/Webdav/design/locking.txt [iso-8859-1] (original)
+++ trunk/Webdav/design/locking.txt [iso-8859-1] Thu Jan 24 16:04:38 2008
@@ -228,23 +228,39 @@
The problem
-----------
-We currently do not support any authentication mechanism in the Webdav
-component. To realize locking, we need to support at least 1 authenticattion
-model in the component.
-
-Solution attempts
------------------
-
-A possibility to integrate this would be a WebdavAuthenticationTiein, while
-supporting certain mechanisms like OpenID and TypeKey could be impossible
-(WebDAV clients usualy don't support standard HTTP browsing). However,
-realizing this tie-in is a dedicated task and will consume quite some ammount
-of time.
-
-An intermediate solution could be to rely on certain client-provided data, like
-the client IP address. This is a very insecure authentication theme, but it
-will at least help us to identify the owner of a lock in some way. Another
-problem here are users which perform WebDAV operations through a proxy server.
+The WebDAV RFC specifies that lock tokens are not secure for authentication
+since the can be obtained by every client with access to the repository through
+the lockdiscovery property. Therefore, a server must provide its own
+authentication scheme. We currently do not support any authentication mechanism
+in the Webdav component. To realize locking, we need to support at least 1
+authenticattion model in the component.
+
+Solution attempt
+----------------
+
+The only possible authentication scheme provided through the HTTP protocol is
+HTTP-Auth. Therefore the HTTP-Auth information should be integrated into every
+request object, if provided. To check this information, an interface should be
+provided that provides the following capabilities:
+
+- Information of the assignement of a new lock token to a specific HTTP-Auth
+ user.
+- Removal of a lock token.
+- Answer to the question if a certain user may perform an action with a given
+ lock token.
+
+In addition we should provide a basic implementation of this class, which does
+actually not do anything but discard the given information and return true on
+authentication question. This will not provide any security, but allow users to
+plug their own authentication mechanisms into the lock facilities.
+
+Further thoughts
+----------------
+
+In future it might be possibly that a WebdavAuthenticationTiein is implemented,
+which might then be plugged into the described mechanism, too. This could in
+addition be used for a "plugin" that performs authentication (and possibly
+authorization?) in general on the transport/server level.
Lock null resources
===================
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
