INTERNET-DRAFT Eric Sedlar, Oracle Corporation
draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software
Expires November 1, 2000 May 1, 2000
Access Control Extensions to WebDAV
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a set of methods, headers, and resource-types
that define the WebDAV Access Control extensions to the HTTP/1.1
protocol.
Sedlar, Clemm [Page 1]
INTERNET-DRAFT WebDAV ACL May 1, 2000
Table of Contents
1 INTRODUCTION............................................3
1.1 Notational Conventions................................3
2 PRINCIPALS..............................................3
3 RIGHTS..................................................4
3.1 RIGHTS-DISCOVERY method...............................5
3.2 Rights defined by WebDAV..............................6
3.2.1 read Right........................................6
3.2.2 write Right.......................................6
3.2.3 readacl Right.....................................6
3.2.4 writeacl Right....................................6
3.2.5 all Right.........................................6
4 ACCESS CONTROL PROPERTIES...............................7
4.1 Example 1 - Retrieving Access Control information.....8
5 USING ACLS..............................................9
6 ACL METHOD.............................................10
6.1 Example 1 - Setting ACLs.............................10
7 ACL INHERITANCE / DEFAULT ACLS.........................11
8 XML SCHEMA FOR DEFINED ELEMENTS........................12
9 INTERNATIONALIZATION CONSIDERATIONS....................13
10 SECURITY CONSIDERATIONS..............................13
11 SCALABILITY..........................................13
12 AUTHENTICATION.......................................13
13 IANA CONSIDERATIONS..................................13
14 INTELLECTUAL PROPERTY................................13
15 ACKNOWLEDGEMENTS.....................................14
16 INDEX................................................14
17 REFERENCES...........................................14
18 AUTHORS' ADDRESSES...................................15
19 STILL TO DO :........................................15
Sedlar, Clemm [Page 2]
INTERNET-DRAFT WebDAV ACL May 1, 2000
1 INTRODUCTION
The underlying principle of access control is that who you are
determines how you can access a resource. The "who you are" is
defined by a "principal" identifier; users, client software,
servers, and groups of the previous have principal identifiers.
The "how" is determined by an "access control list" (ACL)
associated with a resource. An ACL contains a set of "access
control entries" (ACEs), where each ACE specifies a principal and
a set of rights that are either granted or denied to that
principal.
1.1 Notational Conventions
The augmented BNF used by this document to describe protocol
elements is described in Section 2.1 of [RFC2068]. Because this
augmented BNF uses the basic production rules provided in Section
2.2 of [RFC2068], those rules apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2 PRINCIPALS
A principal identifies an entity that can be given access rights
to HTTP resources. On many implementations, a user or a group
will be examples of principals, but other types of principals are
possible. For the most part, any classification or other
information about the entity identified by a principal is opaque
with respect to this specification, and is dependent on the
implementation.
Principals are manifested to clients as a HTTP resource,
identified by a URL. The set of properties exposed by that
resource are implementation dependent, although certain
properties are required by this specification. Those properties
include:
@ <dav:principalname>: A "live" property containing the
name used to authenticate this principal
(typically typed into a login prompt/dialog).
[OPTIONAL]
@ <dav:displayname>: A property containing a human-readable
description of this principal. This property
may be "live" and not settable via PROPPATCH.
[REQUIRED]
@ <dav:principal-type>: A "live" property containing a
classification word for this principal. The
values <dav:user/> and <dav:group/> are
choices for value of this property
recommended by this spec. The presence of
Sedlar, Clemm [Page 3]
INTERNET-DRAFT WebDAV ACL May 1, 2000
this property can be used to distinguish it
as a principal from other resources on a
WebDAV server. (Note that <dav:resourcetype>
may not be used, as all collections must use
the value "collection" for <resourcetype>,
which wouldn't distinguish normal collections
from principal collections.) [REQUIRED]
Server implementations may include any other descriptive
information for a principal via properties.
A principal resource may or may not be a collection. A
collection principal may only contain other principals (not other
types of resources). Servers that support aggregation of
principals (e.g. groups of users or other groups) MUST manifest
them as collection principals. The WebDAV methods for examining
maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used
to maintain collection principals. Membership in a collection
principal is recusive, so a principal in a collection principal A
contained by collection principal B is a member of both
collection principals. Implementations not supporting recursive
membership in principal collections can return an error if the
client attempts to bind collection principals into other
collection principals. Using WebDAV methods to alter the content
of a principal (e.g. using PROPPATCH or PUT) is outside the scope
of this specification, and is not required, recommended, or
forbidden by this spec.
3 RIGHTS
A right controls access to a particular set of HTTP operations on
a resource. The set of rights that apply to a particular
resource may vary with the <dav:resourcetype> of the resource, as
well as between different server implementations. To promote
interoperability, however, WebDAV defines a set of well-known
rights (e.g. <dav:read> and <dav:write>), which can at least be
used to set some context to the other rights defined on a
particular resource.
Rights may be aggregates of other rights. For example, one
implementation may split out a right controlling the ability to
BIND children into a collection from the right allowing a
resource to be removed from a collection. Since these rights
control the ability to write to a collection, these rights would
be aggregated by the <dav:write> right. The relationships
between atomic rights and aggregate rights can be discovered via
the RIGHTS-DISCOVERY HTTP method on a particular resource.
Servers may specify some rights as abstract, which means that it
may not appear in an ACL, but is described in the RIGHTS-
DISCOVERY method to aid in setting context. Server
implementations must return the same response to the RIGHTS-
DISCOVERY method on all of the resources with the same
<dav:resourcetype> value.
Sedlar, Clemm [Page 4]
INTERNET-DRAFT WebDAV ACL May 1, 2000
3.1 RIGHTS-DISCOVERY method
Rights discovery is a method with no arguments, that returns the
rights aggregation tree. Each right appears as an XML element,
where aggregate rights list all of their children as sub-
elements. Each right element can contain the following
attributes:
@ abstract (Boolean): "true" if this right cannot be used in
an ACL/ACE. Defaults to "false"
@ description (string): a human readable description of what
this right controls access to. Required.
For example, the following response might be generated to a
RIGHTS-DISCOVERY request on a WebDAV server implemented by a
relational database (where the resource in this case corresponds
to a table):
Request
RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length: 0
Response
HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx
<?xml version="1.0" encoding="utf-8" ?>
<?namespace href = "http://www.oracle.com/webdav/ AS = ORA"?>
<D:response>
<D:all abstract=true description="All access">
<D:write abstract=true description="Write any database row">
<ORA:insert abstract=false description="Insert a row"/>
<ORA:update abstract=false description="Update a row"/>
<ORA:delete abstract=false description="Delete a row"/>
</D:write>
<D:read abstract=false description="SELECT data from a row"/>
<D:readacl abstract=false description="Read the ACL"/>
<D:acadmin abstract=false description="Update the ACL and
owner"/>
</D:all>
</D:response>
It is envisioned that a WebDAV ACL-aware administrative client
would list the available in a dialog box, and allow the user to
choose non-abstract rights to apply in an ACE. The rights tree
is useful programmatically to map well-known rights (defined by
WebDAV or other standards groups) into rights that are supported
by any particular server implementation.
Sedlar, Clemm [Page 5]
INTERNET-DRAFT WebDAV ACL May 1, 2000
3.2 Rights defined by WebDAV
The rights defined by WebDAV access control MUST be present in
the response to the RIGHTS-DISCOVERY method, although they may be
abstract (and not usable within an ACE on a particular
implementation).
3.2.1read Right
Name: <dav:read>
Purpose: The read right provides and restricts access to
information regarding the state of the resource, including the
resource's properties. Affected methods include GET and PROPFIND.
The read right does not affect the OPTIONS method since it
reflects capabilities rather than state.
3.2.2write Right
Name: <dav:write>
Purpose: The <write> right affects the same methods as
the Write Lock. Please refer to [WEBDAV] section 5.3 for the list
of affected methods. Note however, that a write lock is a
different mechanism than a write access change, although they
affect the same methods, they have independent methods to set
them and independent error codes.
3.2.3readacl Right
Name: <dav:readacl>
Purpose: The <readacl> right provides and restricts
access to the <dav:acl> property of this resource, rather than
the <dav:read> right. If a user has the <readacl> right and not
the <read> right, the <dav:acl> property ONLY is accessible via
PROPFIND, and the GET method is not authorized. If a user has
the <read> right and not the <readacl> right, the <dav:acl>
property will not be included in any PROPFIND requests on the
associated resource.
3.2.4writeacl Right
Name: <dav:writeacl>
Purpose: The <writeacl> (Access Control ADMINistration)
right provides and restricts access to ACL method, which is the
only means of altering the <dav:acl> (and indirectly,
<dav:rights>) property of a resource.
3.2.5all Right
Name: <dav:all>
Sedlar, Clemm [Page 6]
INTERNET-DRAFT WebDAV ACL May 1, 2000
Purpose: The <dav:all> right controls all other rights on
this resource. If the <dav:all> right appears in an ACE, it is
an error to have any other right in that ACE. This right is
merely shorthand for all of the rights enumerated in the RIGHTS-
DISCOVERY method, and should not control access to rights not
exposed via that route.
4 ACCESS CONTROL PROPERTIES
This specification defines a number of new properties for WebDAV
resources. Access control properties may be retrieved just like
other WebDAV properties, using the PROPFIND method. An HTTP
resource on a WebDAV ACL-compliant server MUST contain the
following properties:
@ <dav:owner>: A property containing the principal
information identifying a particular user as
the owner of the resource. This property is
readable by anyone with read access to the
resource. There is no provision for a client
updating this property in this spec, however
it is recommended that any authenticated user
with appropriate administrative privileges be
allowed to issue a PROPPATCH to update its
value. Normally, an attempt to PROPPATCH this
property will result in a 401 (Not
Authorized) error. [REQUIRED]
@ <dav:owner-name>: A "live" property containing a human-
readable description of the <dav:owner>
[OPTIONAL]
@ <dav:rights>: A "live" property containing the list of
rights of the currently authenticated HTTP
user. Read access to this property is
controlled by the <read> right. This
property can NEVER be set directly.
[REQUIRED]
@ <dav:acl>: A "live" property containing one or more
<dav:ace> tags, which specify which
principals are to get access to what rights,
for the resource with this ACL property.
[REQUIRED]
The <dav:acl> element (property) contains 0 or more of the
following XML elements:
@ <dav:ace>: An access control entry, which specifies the
set of rights to be granted to a single
principal.
The <dav:ace> element contains the following XML elements:
Sedlar, Clemm [Page 7]
INTERNET-DRAFT WebDAV ACL May 1, 2000
@ <dav:grant>: Contains the set of XML elements
corresponding to the rights being granted via
this ACE. Must contain at least one right
@ <dav:deny>: Contains the set of XML elements
corresponding to the rights being denied via
this ACE. Must contain at least one right,
if present.
@ <dav:principal-id>: A URL of the principal resource this ACE
applies to, or one of the tags <dav:owner> or
<dav:all-principals>. Always present. The
value of this element must be unique within
an ACL.
@ <dav:principal>: Contains properties of the principal
resource (made available here to avoid the
need for a separate PROPFIND request).
Optional.
A PROPFIND on a resource on a WebDAV ACL server might produce the
following XML output:
4.1 Example 1 - Retrieving Access Control information
Request
PROPFIND /top/container HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length: 0
Depth: 0
<?xml version="1.0">
<D:propfind xmlns:D="DAV:">
<D:allprop/>
</D:propfind>
Response
HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx
<?xml version="1.0" encoding="utf-8" ?>
<?namespace href = "http://www.ietf.org/standards/webdav/ AS =
D"?>
<D:response>
<D:propstat>
<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
<D:displayname>Example collection</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock> XXXXX</D:supportedlock>
<D:owner>http://www.rational.com/principals/users/gclemm</d:owner
>
<D:owner-name>Geoffrey Clemm</d:owner-name>
Sedlar, Clemm [Page 8]
INTERNET-DRAFT WebDAV ACL May 1, 2000
<D:rights>
<D:read/><D:readacl/>
</D:rights>
<D:acl>
<D:ace>
<D:grant><D:read/><D:write/><D:readacl/></D:grant>
<D:principal-id>
<D:href>http://www.foo.com/users/esedlar</D:href>
</D:principal-id>
<D:principal>
<D:principal-type>User</D:principal-type>
<D:principalname>esedlar</D:principalname>
<D:displayname>Eric Sedlar</D:displayname>
</D:principal>
</D:ace>
<D:ace>
<D:grant><D:read/><D:readacl/></D:grant>
<D:deny><D:writeacl/></D:deny>
<D:principal-id>
<D:href>http://www.foo.com/groups/marketing</d:href>
</D:principal-id>
<D:principal>
<D:principal-type>Group</D:principal-type>
<D:displayname>Foo.Com marketing
department</D:displayname>
<D:principalname>mktdept</D:principalname>
</D:principal>
</D:ace>
<D:ace>
<D:grant><D:read/></D:grant>
<D:principal-id><d:all/></D:principal-id>
</D:ace>
</D:acl>
<D:propstat>
<D:response>
5 USING ACLS
By default, a principal has no access rights to an object
protected by an ACL. A particular ACE may either grant or deny a
set of rights to a single principal. It is illegal for an ACL to
have two ACEs applying to the same principal. However, since a
server may match the currently authenticated HTTP user with
multiple principals, it is possible for multiple ACEs to apply to
the current user. In this case, if a particular right is denied
to the current user by any ACE, this supercedes any ACE that
might grant that right. This is the case regardless if a ("more
specific") ACE granting access applied to a principal identifying
the user directly, while the ACE denying access applied to a
collection principal containing that user. The particular order
of the ACEs within an ACL is irrelevant. The <principal-id> tag
can also contain the following special tags: <owner>, <all>,
<unauthenticated>. These tags have the following meaning:
Sedlar, Clemm [Page 9]
INTERNET-DRAFT WebDAV ACL May 1, 2000
@ owner: The principal identified by the owner property on
this resource is granted or denied the rights specified in
this ACE.
@ all: The current user always matches this ACE, whether or
not s/he is authenticated.
@ unauthenticated: The current user matches this ACE if not
authenticated
Server implementations may limit the number of ACEs in an ACL.
However, ACL-compliant servers are required to support at least
one ACE granting rights to a single principal, and one ACE
granting rights to a collection principal. The server should
return an error "Too many ACEs" in this case.
6 ACL METHOD
The ACL Method provides a mechanism to set ACL information. Its
request body is used to define alterations to the ACL of the
resource identified by the request-URI. Its response body
contains the current ACL for that resource. The ACL method
replaces the <acl> and <owner> properties on the specified
resource with the properties in the request. All readable ACEs
previously stored in the ACL on the indicated resource are
removed, so an ACL method on a resource with an unreadable <acl>
property will be ignored. (If the server implements rights
outside of those defined in this specification, they might allow
only some ACEs to be visibleùin this case, only part of the ACL
will be replaced).
Change requests through the ACL method MUST be atomic. If any
part of the change request fails then all changes MUST fail. The
presence of an empty ACL causes all ACEs in the ACL, including
ACEs for associated properties, to be deleted. An empty request
body will cause no change to the ACL or associated values. If
the <principal> element (specifying properties of the resource
identified by the ACE's <principal-id>) is specified, it (and its
children) is ignored.
6.1 Example 1 - Setting ACLs
An ACL request body is an acl-info XML element. The <dav:acl-
info> element contains properties that can be set by the ACL
method (currently just <acl>).
Request
ACL /top/container HTTP/1.1
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx
<?namespace href = "http://www.ietf.org/standards/webdav/ AS =
D"?>
<D:acl-info>
Sedlar, Clemm [Page 10]
INTERNET-DRAFT WebDAV ACL May 1, 2000
<D:acl>
<D:ace>
<D:grant><D:read/><D:write/><D:readacl/></D:grant>
<D:principal-id>
<D:href>http://www.foo.com/users/esedlar</D:href>
</D:principal-id>
</D:ace>
<D:ace>
<D:grant><D:read/> </D:grant>
<D:principal-id>
<D:href>http://www.foo.com/groups/marketing</D:href>
</D:principal-id>
</D:ace>
</D:acl>
</D:acl-info>
Response
HTTP/1.1 200 Success
Content-Length: 0
This request changes the group ACE to disallow read access to the
ACL for the marketing group. The other information had to be
recopied from the ACL retrieved in the previous example.
7 ACL INHERITANCE / DEFAULT ACLS
To be added
Sedlar, Clemm [Page 11]
INTERNET-DRAFT WebDAV ACL May 1, 2000
8 XML SCHEMA FOR DEFINED ELEMENTS
<?xml version='1.0'?>
<!-- XML Schema for WebDAV ACLs -->
<!DOCTYPE schema PUBLIC "-//IETF//DTD WEBDAVACL 20000420//EN"
"WebDAVACL.dtd" >
<schema xmlns="http://www.w3.org/1999/XMLSchema"
targetNamespace="http://www.ietf.org/standards/webdav"
xmlns:dav="http://www.ietf.org/standards/webdav"
blockDefault="#all" elementFormDefault="qualified">
<element name="right" abstract="true">
<complexType content="empty">
</element>
<!--For those folks not familiar with XML Schema, minOccurs
defaults to 0, and maxOccurs defaults to 1 -->
<element name="dav:read" base="right" equivClass="right"/>
<element name="dav:write" base="right" equivClass="right"/>
<element name="dav:readacl" base="right" equivClass="right"/>
<element name="dav:writeacl" base="right"
equivClass="right"/>
<element name="dav:all" base="right" equivClass="right"/>
<complexType name="dav:rights-list">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="dav:right">
<element name="dav:unauthenticated" content="empty"/>
<element name="dav:all" content="empty"/>
<element name="dav:owner" content="empty"/>
</complexType>
<complexType name="dav:ace">
<element name="dav:grant" type="dav:rights-list"
minOccurs="0" maxOccurs="1">
<element name="dav:deny" type="dav:rights-list"
minOccurs="0" maxOccurs="1">
<element name="dav:principal-id" minOccurs="1"/>
<complexType>
<choice minOccurs="1">
<element name="dav:owner" content="empty"/>
<element name="dav:all" content="empty"/>
<element name="dav:unauthenticated" content="empty"/>
<element name="dav:href" type="uri"/>
</choice>
</complexType>
</element>
<element name="dav:principal" minOccurs="0" maxOccurs="1">
<complexType>
<element name="dav:principal-name" type="string"
minOccurs="1"/>
Sedlar, Clemm [Page 12]
INTERNET-DRAFT WebDAV ACL May 1, 2000
<element name="dav:principal-type" type="string"
minOccurs="1"/>
</complexType>
</element>
</complexType>
<element name="dav:acl">
<complexType>
<element name="dav:ace" type="dav:ace"
minOccurs="0" maxOccurs="unbounded"/>
</complexType>
</element>
<element name="dav:rights">
<complexType>
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="dav:right"/>
</choice>
</complexType>
</element>
</schema>
9 INTERNATIONALIZATION CONSIDERATIONS
To be supplied.
10 SECURITY CONSIDERATIONS
To be supplied.
11 SCALABILITY
To be supplied.
12 AUTHENTICATION
Authentication mechanisms defined in WebDAV will also apply to
WebDAV ACL.
13 IANA CONSIDERATIONS
This document uses the namespace defined by [RFC2518] for XML
elements. All other IANA considerations mentioned in [RFC2518]
also applicable to WebDAV ACL.
14 INTELLECTUAL PROPERTY
The following notice is copied from RFC 2026, section 10.4, and
describes the position of the IETF concerning intellectual
property claims made against this document.
Sedlar, Clemm [Page 13]
INTERNET-DRAFT WebDAV ACL May 1, 2000
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers
or users of this specification can be obtained from the IETF
Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to practice this standard. Please address the information to the
IETF Executive Director.
15 ACKNOWLEDGEMENTS
This protocol is the collaborative product of the WebDAV ACL
design team: xxx, yyy, zzz. We would like to acknowledge the
foundation laid for us by the authors of the WebDAV and HTTP
protocols upon which this protocol is layered, and the invaluable
feedback from the WebDAV working group.
16 INDEX
To be supplied.
17 REFERENCES
[RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
1996, <http://www.ietf.org/rfc/rfc2026.txt>.
[RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, U.C. Irvine, DEC, MIT/LCS, 1997,
<http://www.ietf.org/rfc/rfc2068.txt >.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Harvard, 1997,
<http://www.ietf.org/rfc/rfc2119.txt >.
[RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
"HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
U.C.Irvine, Netscape, Novell, 1999
<http://www.ietf.org/rfc/rfc2518.txt>.
Sedlar, Clemm [Page 14]
INTERNET-DRAFT WebDAV ACL May 1, 2000
18 AUTHORS' ADDRESSES
Eric Sedlar
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
Email: esedlar@us.oracle.com
Geoffrey Clemm
Rational Software
20 Maguire Road
Lexington, MA
Email: geoffrey.clemm@rational.com
19 STILL TO DO :
@ Describe the interactions with resource locking. I'm not
clear what the resolution was as far as locking the ACL
separately from locking the resource.
