The WebDAV Access Control Protocol is currently defined as an IETF Standard (RFC3744) and is an extension to the WebDAV protocol.
The WebDAV Access Control Protocol provides a facility for secure access control of content and properties under WebDAV control. Implementing a security mechanism can be just as simple as handling a file system.
In the WebDAV security context, users and groups are called "principals". Security is defined by access control lists (ACLs) on resources, where each ACL specifies relationships between principals and privileges that apply for that resource.
An ACL contains a set of access control entries (ACEs). Each ACE specifies a principal and a set of privileges that are either granted or denied to that principal. When a principal executes a WebDAV request on a resource, the server evaluates the ACEs in the ACL to determine if the principal has permission for that operation. If matching privileges are found which explicitly grant or deny the operation, they apply. If no matching privileges are found, the parent of the resource (the parent collection) is queried for privileges. If no matching privileges are found all the way up to the root folder, then the operation is denied.
The information in this document is organized under the following headings:
Tamino supports the privileges defined in RFC 3744 and adheres to the defined aggregation rules. Besides the standard privileges, Tamino also provides an additional privilege "security" which is in the namespace "http://namespaces.softwareag.com/tamino/response2". The aggregation is shown in the following diagram:
DAV:all | +- DAV:read | +- ino:security | | | +- DAV:read-acl | | | +- DAV:read-current-user-privilege-set | | | +- DAV:write-acl | +- DAV:write | | | +- DAV:write-content | | | +- DAV:write-properties | | | +- DAV:bind | | | +- DAV:unbind | +- DAV:unlock
The privilege names are qualified names (QNames). In the above diagram all privileges with prefix "DAV" are in the namespace "DAV:" and the prefix "ino" defines the above mentioned namespace.
Please refer to
RFC3744 for the exact semantics of the privileges.
The ino:security privilege is simply an aggregation
of all privileges related to ACL operations.
When an object is accessed via Tamino WebDAV, the server supports checks that correspond to the access control list definitions found in WebDAV ACL (RFC 3744). This functionality is provided by the request method ACL.
The WebDAV functionality distinguishes between authenticated and unauthenticated users, who are assigned to the groups DAV:authenticated and DAV:unauthenticated.
When Tamino authentication is deactivated (i.e. the XML property "Authentication" is not set to "web server" or "none") then all users accessing Tamino are assigned to the group DAV:unauthenticated, so the privileges assigned to that group apply for all users.
For more information on Tamino Security, see section Tamino Security in the Tamino Manager user documentation.
The WebDAV specifications do not define a new method for authenticating users. The mechanisms provided in HTTP are to be used.
Since Tamino allows for authenticating users via the HTTP basic authentication scheme, this mechanism is used for WebDAV access, as well as the users and groups known in the standard Tamino Security environment, which are also used for WebDAV security.
Resources are under control of access control lists (ACL) within Tamino, whereas access control elements (ACE) refer to a WebDAV principal.
Following the standard Tamino security
model, the WebDAV principals are defined in the
ino:security collection. The users are defined in
ino:security in the doctype
ino:user. The groups are defined inside
ino:group.
Tamino also allows group definitions obtained from
external authentication services (LDAP or the local operating system). The
element ino:group allows the addition of
user-defined properties, which are stored inside the element
ino:properties. These properties can be accessed and
modified when executing PROPFIND and
PROPPATCH on the principal URLs.
All principals in the WebDAV context are addressed via a URL. The following URL scheme applies when addressing users and groups:
http://<host:port>/tamino/<dbname>/ino:dav/ino:davPrincipal/ino:user/<userid>
where the <userid> corresponds to the
ino:userid attribute of the user definition in
ino:user
http://<host:port>/tamino/<dbname>/ino:dav/ino:davPrincipal/ino:group/<groupname>
where the <groupname> corresponds to
the ino:groupname attribute of the group definition
in ino:group.
In order to address users or groups associated to domains, the syntax appended to the URLs is illustrated in the following example:
http://<host:port>/tamino/<dbname>/ino:dav/ino:davPrincipal/ino:user/<domainid>\<userid or groupname>
The WebDAV ACL specification defines some optional functionality and also some variations, which are left at the disposal of the implementation of the server. The following section describes such special behavior:
The WebDAV ACL specification defines that principal resources are to be exposed via URLs. However, none of the WebDAV methods are required to be supported on such URLs.
The Tamino server allows for sending
PROPFIND requests on principal resources and also on
principal collections.
PROPPATCH is supported on a few of the
properties.
No other methods are allowed in principal resources. Attempts to use them will result in a 405 HTTP response code (Method Not Allowed).
The DAV:group property always returns an
empty result, since sources in Tamino do not have a group membership. This is in
conformance to the WebDAV ACL specification.
The Tamino server does not support the invert
functionality on ACEs. The DAV:acl-restrictions
property returns <no-invert>.
The acl-principal-prop-set report is not
implemented in the Tamino server. The evaluation of this report would
in many cases result in major parts of the database having to be read, which
could make the costs for executing such a report unreasonably high.
This example demonstrates that rights on certain properties can be inherited. A child node inherits the properties of its parent nodes and can contain further properties.
The following graphics demonstrate how access rights are granted. Arrows indicate the processing order.
All users can read and write the resource a.xml, caused by the inherited ACE of the root folder.
User1 is not allowed to read the resource a.xml. All other users can read this resource.
User 1 is allowed to read resource a.xml.
User1 is not allowed to read resource a.xml since the deny(read) is found before the grant(ALL) can be evaluated. As soon as a privilege is found which either grants or denies the requested operation, the ACE evaluation is finished and all subsequent ACEs are not evaluated.
User 1 is allowed to read resource a.xml. User 2 is not allowed to read resource a.xml.
User1 and User2 are not allowed to read resource a.xml and User3 is allowed to read resource a.xml.
User 1 is a member of Group 1: User1 is allowed to read the resource a.xml. User 2 is not allowed to read resource a.xml.
User 1 owns the role Role 1: User 1 is allowed to read resource a.xml. User 2 is not allowed to read resource a.xml.
For further information and background knowledge on this topic, we suggest visiting the following links: