Security

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:


Privileges

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.

Behavior

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.

Users and Groups

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:

For Users:

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

For Groups:

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.

Domains

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>

Unsupported Features and Special Behavior

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:

Principal Resources

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).

DAV:group Property

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.

DAV:acl-restrictions/no-invert

The Tamino server does not support the invert functionality on ACEs. The DAV:acl-restrictions property returns <no-invert>.

REPORT

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.

Access Control Lists: Examples

Examples

graphics/acl_inherit.png

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.

graphics/acl_intro1.png

All users can read and write the resource a.xml, caused by the inherited ACE of the root folder.

graphics/acl_intro2.png

User1 is not allowed to read the resource a.xml. All other users can read this resource.

graphics/acl_intro3.png

User 1 is allowed to read resource a.xml.

graphics/acl_intro4.png

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.

graphics/acl_intro5.png

User 1 is allowed to read resource a.xml. User 2 is not allowed to read resource a.xml.

graphics/acl_intro6.png

User1 and User2 are not allowed to read resource a.xml and User3 is allowed to read resource a.xml.

graphics/acl_intro7.png

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.

graphics/acl_intro8.png

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 link: