draft-ietf-webdav-acl-02.txt | draft-ietf-webdav-acl-03.txt | |||
---|---|---|---|---|
INTERNET-DRAFT Geoffrey Clemm, Rational Software | INTERNET-DRAFT Geoffrey Clemm, Rational Software | |||
draft-ietf-webdav-acl-02 Anne Hopkins, Microsoft Corporation | draft-ietf-webdav-acl-03 Anne Hopkins, Microsoft | |||
Corporation | ||||
Eric Sedlar, Oracle Corporation | Eric Sedlar, Oracle Corporation | |||
Jim Whitehead, U.C. Santa Cruz | ||||
Expires January 14, 2001 July 14, 2000 | Expires May 24, 2001 November 24, 2000 | |||
Access Control Extensions to WebDAV | WebDAV Access Control Protocol | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with all | ||||
provisions of Section 10 of RFC2026. | This document is an Internet-Draft and is in full conformance with | |||
Internet-Drafts are working documents of the Internet Engineering Task | all provisions of Section 10 of RFC2026. | |||
Force (IETF), its areas, and its working groups. Note that other | ||||
groups may also distribute working documents as Internet-Drafts. | Internet-Drafts are working documents of the Internet Engineering | |||
Internet-Drafts are draft documents valid for a maximum of six months | Task Force (IETF), its areas, and its working groups. Note that | |||
and may be updated, replaced, or obsoleted by other documents at any | other groups may also distribute working documents as Internet- | |||
time. It is inappropriate to use Internet- Drafts as reference | Drafts. | |||
material or to cite them other than as "work in progress." | ||||
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 | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Abstract | 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. | ||||
This document specifies a set of methods, headers, and message | ||||
bodies that define the WebDAV Access Control extensions to the | ||||
HTTP/1.1 protocol. This protocol permits a client to remotely read | ||||
and modify access control lists that instruct a server whether to | ||||
grant or deny operations upon a resource (such as HTTP method | ||||
invocations) by a given principal. | ||||
This document is a product of the Web Distributed Authoring and | ||||
Versioning (WebDAV) working group of the Internet Engineering Task | ||||
Force. Comments on this draft are welcomed, and should be addressed | ||||
to the acl@webdav.org mailing list. Other related documents can be | ||||
found at http://www.webdav.org/acl/, and | ||||
http://www.ics.uci.edu/pub/ietf/webdav/. | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 1] | ||||
Table of Contents | Table of Contents | |||
1 INTRODUCTION............................................3 | 1 INTRODUCTION............................................3 | |||
1.1 Notational Conventions................................3 | 1.1 Terms .................................................3 | |||
1.2 Notational Conventions ................................4 | ||||
2 PRINCIPALS..............................................3 | 2 PRINCIPALS ..............................................4 | |||
3 RIGHTS..................................................4 | 3 PRIVILEGES ..............................................5 | |||
3.1 DAV:access-rights property............................5 | 3.1 DAV:read Privilege ....................................5 | |||
3.2 Rights defined by WebDAV..............................6 | 3.2 DAV:write Privilege ...................................6 | |||
3.2.1 read Right........................................6 | 3.3 DAV:read-acl Privilege ................................6 | |||
3.2.2 write Right.......................................7 | 3.4 DAV:write-acl Privilege ...............................6 | |||
3.2.3 readacl Right.....................................7 | 3.5 DAV:all Privilege .....................................6 | |||
3.2.4 writeacl Right....................................7 | ||||
3.2.5 all Right.........................................7 | ||||
4 ACCESS CONTROL PROPERTIES...............................7 | 4 PRINCIPAL PROPERTIES ....................................6 | |||
4.1 Retrieving Access Control Information................11 | 4.1 DAV:is-principal ......................................6 | |||
4.1.1 Example: Retrieving Access Control information...11 | 4.2 DAV:authentication-id .................................6 | |||
4.2 Setting Access Control Information...................12 | ||||
4.2.1 Example: Setting Access Control information......13 | ||||
5 USING ACLS.............................................14 | 5 ACCESS CONTROL PROPERTIES ...............................7 | |||
5.1 System Controlled Rights.............................14 | 5.1 DAV:owner .............................................7 | |||
5.2 Special Principal Identifiers........................15 | 5.2 DAV:supported-privilege-set ...........................7 | |||
5.3 ACL Semantics Options................................15 | 5.3 DAV:current-user-privilege-set ........................8 | |||
5.3.1 FirstSpecific....................................16 | 5.4 DAV:acl ...............................................8 | |||
5.3.2 ExplicitDenyPrecedence...........................16 | 5.4.1 ACE Principal .....................................8 | |||
5.4.2 ACE Grant and Deny ................................9 | ||||
5.4.3 ACE Protection ...................................10 | ||||
5.4.4 ACE Inheritance ..................................10 | ||||
5.5 DAV:acl-semantics ....................................10 | ||||
5.5.1 first-match Semantics ............................14 | ||||
5.5.2 all-grant-before-any-deny Semantics ..............14 | ||||
5.5.3 no-deny Semantics ................................14 | ||||
5.6 DAV:principal-collection-set .........................10 | ||||
5.7 Example: PROPFIND to retrieve access control properties11 | ||||
6 ACL INHERITANCE........................................18 | 6 ACCESS CONTROL AND EXISTING METHODS ....................14 | |||
6.1 Inheritable ACEs.....................................18 | 6.1 OPTIONS ..............................................15 | |||
6.2 Propagate ACE but do not use for Access Check on this resource....19 | 6.1.1 Example - OPTIONS ................................15 | |||
6.3 Propagate to immediate children only.................19 | ||||
6.4 Protect ACL from inheritance.........................19 | ||||
7 XML SCHEMA FOR DEFINED ELEMENTS........................20 | 7 ACCESS CONTROL METHODS .................................16 | |||
7.1 ACL ..................................................16 | ||||
7.1.1 ACL Preconditions ................................16 | ||||
7.1.2 Example: the ACL method ..........................17 | ||||
7.1.3 Example: ACL method failure ......................17 | ||||
8 INTERNATIONALIZATION CONSIDERATIONS....................21 | 8 INTERNATIONALIZATION CONSIDERATIONS ....................18 | |||
9 SECURITY CONSIDERATIONS................................21 | 9 SECURITY CONSIDERATIONS ................................19 | |||
10 SCALABILITY..........................................21 | 10 AUTHENTICATION .......................................20 | |||
11 AUTHENTICATION.......................................21 | 11 IANA CONSIDERATIONS ..................................20 | |||
12 IANA CONSIDERATIONS..................................21 | 12 INTELLECTUAL PROPERTY ................................20 | |||
13 INTELLECTUAL PROPERTY................................21 | 13 ACKNOWLEDGEMENTS .....................................21 | |||
14 ACKNOWLEDGEMENTS.....................................22 | Clemm, Hopkins, Sedlar, Whitehead [Page 2] | |||
14 REFERENCES ...........................................21 | ||||
15 INDEX................................................22 | 15 AUTHORS' ADDRESSES ...................................22 | |||
16 REFERENCES...........................................22 | ||||
17 AUTHORS' ADDRESSES...................................23 | 16 STILL TO DO ..........................................22 | |||
18 STILL TO DO :........................................23 | 1 INTRODUCTION | |||
19 OPEN ISSUES:.........................................25 | The goal of the WebDAV access control extensions is to provide | |||
an interoperable mechanism for handling discretionary access | ||||
control for content in WebDAV servers. WebDAV access control | ||||
can be implemented on content repositories with security as | ||||
simple as that of a UNIX file system, as well as more | ||||
sophisticated models. 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 a single "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. | ||||
When a principal submits an operation (such as an HTTP or | ||||
WebDAV method) to a resource for execution, the server | ||||
evaluates the ACEs in the ACL to determine if the principal | ||||
has permission for that operation. | ||||
1 INTRODUCTION | This specification has intentionally omits discussion of | |||
authentication, as the HTTP protocol already has a number of | ||||
authentication mechanisms[RFC2617] . Some authentication | ||||
mechanism (such as HTTP Digest Authentication, which all | ||||
WebDAV compliant implementations are required to support) must | ||||
be availableto validate the identity of a principal. | ||||
The underlying principle of access control is that who you are | In the interests of timeliness, the following set of security | |||
determines how you can access a resource. The "who you are" is | mechanisms is currently viewed as out of scope of this | |||
defined by a "principal" identifier; users, client software, | document: | |||
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 | * Access control that applies only to a particular property | |||
on a resource, rather than the entire resource. | ||||
* Role-based security (where a role can be seen as a | ||||
dynamically defined collection of principals) | ||||
* Specification of the ways an ACL on a resource is | ||||
initialized | ||||
* Specification of an ACL that applies globally to a | ||||
method, rather than to a particular resource | ||||
1.1 Terms | ||||
This draft uses the terms defined in HTTP [RFC2616] and WebDAV | ||||
[RFC2518]. In addition, the following terms are defined: | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 3] | ||||
principal | ||||
A "principal" is a distinct human or computational actor that | ||||
initiates access to network resources. In this protocol, a | ||||
principal is an HTTP resource that represents such an actor. | ||||
privilege | ||||
A "privilege" controls access to a particular set of HTTP | ||||
operations on a resource. | ||||
aggregate privilege | ||||
An "aggregate privilege " is a privilege that comprises a set | ||||
of other privileges. | ||||
access control list (acl) | ||||
An "acl " is a list of access control elements that define | ||||
access control to a particular resource. | ||||
access control element (ace) | ||||
An "ace " either grants or denies a particular set of | ||||
privileges for a particular principal. | ||||
inherited ace | ||||
An "inherited ace " is an ace that is shared from the acl of | ||||
another resource. | ||||
1.2 Notational Conventions | ||||
The augmented BNF used by this document to describe protocol | The augmented BNF used by this document to describe protocol | |||
elements is described in Section 2.1 of [RFC2068]. Because this | elements is described in Section 2.1 of [RFC2616]. Because | |||
augmented BNF uses the basic production rules provided in Section | this augmented BNF uses the basic production rules provided in | |||
2.2 of [RFC2068], those rules apply to this document as well. | Section 2.2 of [RFC2616], those rules apply to this document | |||
as well. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described | |||
[RFC2119]. | in [RFC2119]. | |||
2 PRINCIPALS | 2 PRINCIPALS | |||
A principal identifies an entity that can be given access rights | A principal is an HTTP resource that represents a distinct | |||
to HTTP resources. On many implementations, a user or a group | human or computational actor that initiates access to network | |||
will be examples of principals, but other types of principals are | resources. On many implementations, users and groups are | |||
possible. For the most part, any classification or other | represented as principals; other types of principals are also | |||
information about the entity identified by a principal is opaque | possible. Although an implementation MAY support PROPFIND | |||
with respect to this specification, and is dependent on the | and PROPPATCH to access and modify information about a | |||
implementation. | principal, it is not required to do so. | |||
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 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 | ||||
DAV:resourcetype, which wouldn't distinguish normal | ||||
collections from principal collections.) [REQUIRED] | ||||
Server implementations may include any other descriptive | Clemm, Hopkins, Sedlar, Whitehead [Page 4] | |||
information for a principal via properties. | ||||
A principal resource may or may not be a collection. A | A principal resource may or may not be a collection. A | |||
collection principal may only contain other principals (not other | collection principal may only contain other principals (not | |||
types of resources). Servers that support aggregation of | other types of resources). Servers that support aggregation | |||
principals (e.g. groups of users or other groups) MUST manifest | of principals (e.g. groups of users or other groups) MUST | |||
them as collection principals. The WebDAV methods for examining | manifest them as collection principals. The WebDAV methods | |||
maintaining collections (e.g. DELETE, PROPFIND) may be used to | for examining and maintaining collections (e.g. DELETE, | |||
maintain collection principals. Membership in a collection | PROPFIND) MAY be used to maintain collection principals. | |||
principal is recursive, so a principal in a collection principal | Membership in a collection principal is recursive, so a | |||
A contained by collection principal B is a member of both | principal in a collection principal GRPA contained by | |||
collection principals. Implementations not supporting recursive | collection principal GRPB is a member of both GRPA and GRPB. | |||
membership in principal collections can return an error if the | Implementations not supporting recursive membership in | |||
client attempts to bind collection principals into other | principal collections can return an error if the client | |||
collection principals. Using WebDAV methods to alter the content | attempts to bind collection principals into other collection | |||
of a principal (e.g. using PROPPATCH or PUT) is outside the scope | principals. | |||
of this specification, and is not required, recommended, or | ||||
forbidden by this spec. | ||||
3 RIGHTS | 3 PRIVILEGES | |||
A right controls access to a particular set of HTTP operations on | Ability to perform a given method on a resource SHOULD be | |||
a resource. The set of rights that apply to a particular | controlled by one or more privileges. Authors of protocol | |||
resource may vary with the DAV:resourcetype of the resource, as | extensions that define new HTTP methods SHOULD specify which | |||
well as between different server implementations. To promote | privileges (by defining new privileges, or mapping to ones | |||
below) are required to perform the method. A principal with | ||||
no privileges to a resource SHOULD be denied any HTTP access | ||||
to that resource. | ||||
Privileges may be aggregates of other privileges. If a | ||||
principal is granted or denied an aggregate privilege, it is | ||||
semantically equivalent to granting or denying each of the | ||||
aggregated privileges individually. For example, an | ||||
implementation may define add-member and remove-member | ||||
privileges that control the ability to add and remove an | ||||
internal member of a collection. Since these privileges | ||||
control the ability to update the state of a collection, these | ||||
privileges would be aggregated by the DAV:write privilege on a | ||||
collection, and granting the DAV:write privilege on a | ||||
collection would also grant the add-member and remove-member | ||||
privileges. | ||||
The set of privileges 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 | interoperability, however, WebDAV defines a set of well-known | |||
rights (e.g. DAV:read and DAV:write), which can at least be used | privileges (e.g. DAV:read and DAV:write), which can at least | |||
to set some context to the other rights defined on a particular | be used to classify the other privileges defined on a | |||
resource. | particular resource. | |||
Rights may be aggregates of other rights. For example, one | ||||
implementation may split out a right controlling the ability to | ||||
add children to 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 | ||||
DAV:access-rights property on a particular resource. Servers may | ||||
specify some rights as abstract, which means that it MUST not | ||||
appear in an ACL, but is described in the DAV:access-rights | ||||
property to aid in setting context. Server implementations must | ||||
return the same response to the DAV:access-rights property on all | ||||
of the resources with the same DAV:resourcetype value. | ||||
3.1 DAV:access-rights property | 3.1 DAV:read Privilege | |||
The DAV:access-rights property is a live property that contains | The read privilege controls methods that return information | |||
the rights aggregation tree. The DAV:access-rights property MUST | about the state of the resource, including the resource's | |||
be available on every resource available via a WebDAV Access | properties. Affected methods include GET and PROPFIND. The | |||
Control-compliant server. Each right appears as an XML element, | read privilege does not control the OPTIONS method since the | |||
where aggregate rights list all of their children as sub- | OPTIONS method returns capabilities rather than state. | |||
elements. Each right element can contain the following | ||||
attributes: | ||||
. abstract (Boolean): 'true' if this right MUST NOT be used in | ||||
an ACL/ACE. Defaults to 'false.' Note: an abstract right need | ||||
not be an aggregate right. | ||||
. Description (string): a human-readable description of what | Clemm, Hopkins, Sedlar, Whitehead [Page 5] | |||
this right controls access to. [REQUIRED]. The server MAY | 3.2 DAV:write Privilege | |||
localize this description, based on the Accept-Language header | ||||
of the request. | ||||
For example, the following response might be generated to a | The write privilege controls methods that modify the state of | |||
request on a WebDAV server. | the resource, such as PUT and PROPPATCH. Note that state | |||
Request | modification is also controlled via locking (see section 5.3 | |||
PROPFIND /file HTTP/1.1 | of [WEBDAV]), so effective write access requires that both | |||
Host: www.foo.bar | write privileges and write locking requirements are satisfied. | |||
Content-type: text/xml; charset="utf-8" | ||||
Accept-Language: en-us | ||||
Depth: 0 | ||||
Content-Length: xxx | ||||
<?xml version="1.0" encoding="utf-8"?> | 3.3 DAV:read-acl Privilege | |||
<D:propfind xmlns:D="DAV:"> | ||||
<D:prop> | ||||
<D:access-rights/> | ||||
</D:prop> | ||||
</D:propfind> | ||||
Response | The DAV:read-acl privilege controls the use of PROPFIND to | |||
HTTP/1.1 207 Multi-Status | retrieve the DAV:acl, and DAV:current-user-privilege-set | |||
Content-Type: text/xml | properties of the resource. | |||
Content-Length: xxx | ||||
<?xml version="1.0"?> | 3.4 DAV:write-acl Privilege | |||
<D:multistatus xmlns:D="DAV:" | ||||
xlmns:A="http://www.foo.bar/schema/"> | The DAV:write-acl privilege controls use of the ACL method to | |||
<D:response> | modify the DAV:acl property of the resource. | |||
<D:href>http://www.foo.bar/file</D:href> | ||||
<D:propstat> | 3.5 DAV:all Privilege | |||
<D:status>HTTP/1.1 200 OK</D:status> | ||||
<D:prop> | The DAV:all privilege controls all privileges on the resource. | |||
<D:access-rights> | ||||
<D:all> | 4 PRINCIPAL PROPERTIES | |||
<D:write abstract="true" description="Write any | ||||
object"> | Principals are manifested to clients as an HTTP resource, | |||
<A:create abstract="false" description="Create an | identified by a URL. A principal MUST have a DAV:displayname | |||
object"/> | property. This protocol defines the following additional | |||
<A:update abstract="false" description="Update an | properties for a principal. | |||
object"/> | ||||
<A:delete abstract="false" description="Delete an | 4.1 DAV:is-principal | |||
object"/> | ||||
<D:write/> | This property indicates whether this resource is a principal. | |||
<D:read abstract="false" description="Read any | A resource MUST have a non-empty DAV:is-principal property if | |||
object"/> | and only if it is a principal resource. (Note: If we can | |||
<D:readacl abstract="false" description="Read the | just add a DAV:principal element to the DAV:resourcetype | |||
ACL"/> | property, then we do not need a DAV:is-principal property.) | |||
<D:writeacl abstract="false" description="Write the | ||||
ACL"/> | <!ELEMENT is-principal (#PCDATA)> | |||
</D:all> | PCDATA value: any non-empty value ("T" is suggested) | |||
</D:access-rights> | ||||
</D:prop> | 4.2 DAV:authentication-id | |||
</D:propstat> | ||||
</D:response> | A property containing the name used to authenticate this | |||
</D:multistatus> | principal (typically typed into a login prompt/dialog). | |||
<!ELEMENT authentication-id (#PCDATA)> | ||||
PCDATA value: any string | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 6] | ||||
5 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. | ||||
Some access control properties (such as DAV:owner) MAY be | ||||
updated with the PROPPATCH method. | ||||
HTTP resources that support the WebDAV Access Control Protocol | ||||
MUST contain the following properties: | ||||
5.1 DAV:owner | ||||
This property identifies a particular principal as being the | ||||
"owner" of the resource. | ||||
<!ELEMENT owner (href prop?)> | ||||
<!ELEMENT prop (see [RFC2518], section 12.11)> | ||||
An implementation MAY include a list of selected properties of | ||||
that principal resource. Which properties (if any) are | ||||
included is implementation defined. An implementation MAY | ||||
allow the use of PROPPATCH to update the DAV:owner field. | ||||
5.2 DAV:supported-privilege-set | ||||
This is a read-only property that identifies the privileges | ||||
defined for the resource. | ||||
<!ELEMENT supported-privilege-set (supported-privilege*)> | ||||
Each privilege appears as an XML element, where aggregate | ||||
privileges list as sub-elements all of the privileges that | ||||
they aggregate. | ||||
<!ELEMENT supported-privilege | ||||
(privilege, abstract?, description, supported-privilege*)> | ||||
<!ELEMENT privilege ANY> | ||||
An abstract privilege is used to classify the non-abstract | ||||
privilege elements. An abstract privilege of a resource MUST | ||||
NOT be used in an ACE for that resource. Servers MUST fail an | ||||
attempt to set an abstract privilege. | ||||
<!ELEMENT abstract EMPTY> | ||||
A description is a human-readable description of what this | ||||
privilege controls access to. | ||||
<!ELEMENT description #PCDATA> | ||||
It is envisioned that a WebDAV ACL-aware administrative client | It is envisioned that a WebDAV ACL-aware administrative client | |||
would list the available rights in a dialog box, and allow the | would list the supported privileges in a dialog box, and allow | |||
user to choose non-abstract rights to apply in an ACE. The | the user to choose non-abstract privileges to apply in an ACE. | |||
rights tree is useful programmatically to map well-known rights | The privileges tree is useful programmatically to map well- | |||
(defined by WebDAV or other standards groups) into rights that | ||||
are supported by any particular server implementation. | ||||
3.2 Rights defined by WebDAV | Clemm, Hopkins, Sedlar, Whitehead [Page 7] | |||
known privileges (defined by WebDAV or other standards groups) | ||||
into privileges that are supported by any particular server | ||||
implementation. The privilege tree also serves to hide | ||||
complexity in implementations allowing large number of | ||||
privileges to be defined by displaying aggregates to the user. | ||||
The rights defined by WebDAV access control MUST be present in | 5.3 DAV:current-user-privilege-set | |||
the DAV:access-rights property, although they may be abstract | ||||
(and not usable within an ACE on a particular implementation). | ||||
Ability to perform a given method on a resource MUST be | ||||
controlled by some right. Authors of Internet drafts that define | ||||
new methods must specify which right (by defining a new right, or | ||||
mapping to one below) is required to perform the method. A | ||||
principal with no rights to a resource should be denied any HTTP | ||||
access to that resource. | ||||
3.2.1read Right | This is a read-only property containing a list of privileges | |||
granted to the currently authenticated HTTP user. The current | ||||
user has no access privileges to an object protected by an ACL | ||||
unless that user matches one or more of the principals | ||||
specified in the ACEs. | ||||
Name: DAV:read | <!ELEMENT current-user-privilege-set (privilege*)> | |||
Purpose: The read right provides and restricts access to | <!ELEMENT privilege ANY> | |||
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 | Each element in the DAV:current-user-privilege-set property | |||
MUST identify a privilege from the DAV:supported-privilege-set | ||||
property. | ||||
Name: DAV:write | 5.4 DAV:acl | |||
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 | This property specifies the list of access control entries | |||
(ACEs), which define what principals are to get what | ||||
privileges for this resource. | ||||
Name: DAV:readacl | <!ELEMENT acl (ace*)> | |||
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 and DAV:access-rights properties MUST be | ||||
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 and DAV:access-rights properties will not be included in | ||||
any PROPFIND requests on the associated resource. | ||||
3.2.4writeacl Right | Each DAV:ace element specifies the set of privileges to be | |||
either granted or denied to a single principal. If the | ||||
DAV:acl property is empty, no principal is granted any | ||||
privilege. | ||||
Name: DAV:writeacl | <!ELEMENT ace (principal, (grant|deny), protected?, | |||
Purpose: The writeacl right provides and restricts access | inherited?)> | |||
to the DAV:acl and DAV:owner properties. | ||||
3.2.5all Right | An attempt to update the DAV:acl property with a PROPPATCH | |||
MUST fail. | ||||
Name: DAV:all | 5.4.1 ACE Principal | |||
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 access-rights | ||||
property, and should not control access to rights not exposed via | ||||
that route. | ||||
4 ACCESS CONTROL PROPERTIES | The DAV:principal element identifies the principal to which | |||
this ACE applies. | ||||
This specification defines a number of new properties for WebDAV | <!ELEMENT principal ((href, prop?) | |||
resources. Access control properties may be set and retrieved | | all | authenticated | unauthenticated | |||
just like other WebDAV properties, using the PROPFIND and | | property | self)> | |||
PROPPATCH method (subject to permissions and 'liveness.' An HTTP | ||||
resource on a WebDAV Access Control-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 | The current user matches DAV:href only if that user is | |||
resource. [REQUIRED] | authenticated as being (or being a member of) the principal | |||
identified by the URL contained by that DAV:href. An | ||||
implementation MAY include a DAV:prop element after the | ||||
DAV:href element, containing a list of selected properties of | ||||
that principal resource. Which properties (if any) are | ||||
. DAV:rights: A 'live' readonly property containing the list of | Clemm, Hopkins, Sedlar, Whitehead [Page 8] | |||
rights of the currently authenticated HTTP user. The read | included in the DAV:prop element is implementation defined. | |||
right controls read access to this property. [REQUIRED] | The DAV:prop element is primarily intended for implementations | |||
that do not support PROPFIND requests on the principal URL. | ||||
. DAV:acl: A 'live' property containing one or more DAV:ace | <!ELEMENT prop (see [RFC2518], section 12.11)> | |||
tags, which specify which principals are to get access to what | ||||
rights, for the resource with this ACL property. [REQUIRED] | ||||
. DAV:aclsemantics: A readonly property indicating the ACL | The current user always matches DAV:all. | |||
semantics model supported by the system. [REQUIRED] | ||||
. DAV:protectaclfrominheritance: A "live" property indicating | <!ELEMENT all EMPTY> | |||
that the ACL does not inherit any ACEs. If this property is | ||||
present, the ACL should contain no ACEs with the DAV:inherited | ||||
element present. If this property is not present and the | ||||
system supports ACL inheritance, then the ACL will contain | ||||
inheritable ACEs from its parent resource. If a resource | ||||
without this property present is updated with this property, | ||||
it is a client choice whether to remove the inherited ACEs or | ||||
retain them but remove the DAV:inherited element from the | ||||
ACEs. [OPTIONAL] | ||||
The DAV:owner element contains one or more of the following XML | The current user matches DAV:authenticated only if | |||
elements: | authenticated. | |||
. DAV:href: This contains the URI to the principal resource | ||||
that is the 'owner' of the resource. Normally, an attempt to | ||||
PROPPATCH this property will result in a 401 (Not Authorized) | ||||
error. The principal indicated by the owner property is | ||||
implicitly granted readacl and writeacl rights. This enables | ||||
the owner to restore an appropriate ACL in the case that it | ||||
becomes maliciously or accidently corrupted such that no | ||||
principal is granted the writeacl right by any ACE. | ||||
[REQUIRED] | ||||
. DAV:principalname, DAV:displayname, DAV:principal-type: These | <!ELEMENT authenticated EMPTY> | |||
are the same as the properties that can exist on the principal | ||||
URI. In this context they are considered 'live.' [OPTIONAL] | ||||
The DAV:acl element (property) contains 0 or more of the | The current user matches DAV:unauthenticated only if not | |||
following XML elements: | authenticated. | |||
. DAV:ace: A "live" property representing an access control | ||||
entry, which specifies the set of rights to be either granted | ||||
or denied to a single principal. | ||||
The DAV:ace element contains the following XML elements: | <!ELEMENT unauthenticated EMPTY> | |||
. DAV:grant: Contains the set of XML elements corresponding to | ||||
the rights being granted via this ACE. MUST contain at least | ||||
one right. MUST NOT be present if the DAV:deny element is | ||||
present. | ||||
. DAV:deny: Contains the set of XML elements corresponding to | DAV:all is the union of DAV:authenticated, and | |||
the rights being denied via this ACE. MUST contain at least | DAV:unauthenticated. For a given request, the user matches | |||
one right, if present. MUST NOT be present if the DAV:grant | either DAV:authenticated, or DAV:unauthenticated, but not | |||
element is present. | both. | |||
. DAV:principal: Contains information about the principal | The current user matches a DAV:property principal in a DAV:acl | |||
resource this ACE applies to. [REQUIRED]. | property of a resource only if the identified property of that | |||
resource contains a DAV:href that identifies a principal, and | ||||
the current user is authenticated as being (or being a member | ||||
of) that principal. For example, if the DAV:property element | ||||
contained <DAV:owner/>, the current user would match the | ||||
DAV:property principal only if the current user is | ||||
authenticated as matching the principal identified by the | ||||
DAV:owner property of the resource. | ||||
. DAV:acepropertytypes: A "live" property containing one or more | <!ELEMENT property ANY> | |||
elements, each of which is an XML tag identifying either a | ||||
property on this resource or a property on a child resource | ||||
that may inherit this ACE. Presence of DAV:acepropertytypes | ||||
distinguishes this ACE as a "Property ACE." The rights | ||||
associated with a "Property ACE" control access to only the | ||||
property(ies) contained in DAV:acepropertytypes, and do not | ||||
control access to the resource as a whole. The set of access | ||||
rights supported on Property ACEs may be all or a subset of | ||||
the DAV:access-rights present on this resource. This spec | ||||
does not provide a mechanism to specify a different set of | ||||
access-rights for a property, than for the resource. An | ||||
implementation that supports a different set of access-rights | ||||
for a property than for the resource, must return an error | ||||
"Unsupported Right" on an attempt to write a Property ACE with | ||||
rights not supported by the server. [OPTIONAL] | ||||
. DAV:inherittochildtype: A "live" property containing one or | The current user matches DAV:self in a DAV:acl property of the | |||
more elements, each of which is an XML tag identifying the | resource only if that resource is a principal object and the | |||
type of child object that will inherit this ACE. This | current user is authenticated as being that principal. | |||
property is only present if DAV:inheritanceflags contains at | ||||
least one of the following: DAV:inheritonly, | ||||
DAV:containerinherit, or DAV:objectinherit. A child of the | ||||
current resource will only inherit this ACE if the type of the | ||||
child object is present in DAV:inherittochildtype. | ||||
. DAV:inheritanceflags: A "live" property containing flags | <!ELEMENT self EMPTY> | |||
indicating the inheritance features of this ACE. For an ACE | ||||
that is neither inherited, nor inheritable, this element may | ||||
be either not present, or present but empty. [OPTIONAL] | ||||
. DAV:inheritancesource: A readonly property containing the URL | 5.4.2 ACE Grant and Deny | |||
of the resource from which this ACE was inherited (contained | ||||
within an DAV:href element). In other words, the ACL on the | ||||
resource referred to by this URI contains the inheritable | ||||
explicit ACE which, when propagated to the current resource, | ||||
resulted in the current ACE. This element may contain the | ||||
special value of DAV:system-ace to indicate that the ACE is | ||||
read-only and represents rights granted implicitly by the | ||||
system. This element may contain the special value of | ||||
DAV:unknown if the server is unable to generate a valid URI to | ||||
the resource from which this element was inherited. This | ||||
element MUST be present if DAV:inheritanceflags contains the | ||||
DAV:inherited flag for inherited ACEs and MUST NOT be present | ||||
for explicit ACEs. | ||||
The DAV:principal element contains the following elements: | Each DAV:grant or DAV:deny element specifies the set of | |||
. DAV:href: This is a URI representing the resource to which | privileges to be either granted or denied to the specified | |||
the ACE applies, or one of the special principal identifier | principal. A DAV:grant or DAV:deny element of the DAV:acl of | |||
tags (e.g., DAV:owner) described in the "Special Principal | a resource MUST only contain elements specified in the | |||
Identifiers" section of this spec. [REQUIRED] | DAV:supported-privilege-set of that resource. | |||
. DAV:principalname, DAV:displayname, DAV:principal-type: These | <!ELEMENT grant (privilege+)> | |||
are the same as the properties that can exist on the principal | <!ELEMENT deny (privilege+)> | |||
URI. In this context they are considered 'live.' [OPTIONAL] | <!ELEMENT privilege ANY> | |||
The DAV:inheritanceflags element contains 0 or more of the | Clemm, Hopkins, Sedlar, Whitehead [Page 9] | |||
following XML elements: | 5.4.3 ACE Protection | |||
. DAV:inherited: This flag indicates the ACE is inherited from | ||||
the ACL on a different resource, identified in | ||||
DAV:inheritancesource. This flag MUST be present for an | ||||
inherited ACE and MUST NOT be present for an explicit ACE. | ||||
This flag must not be present if the | ||||
DAV:protectaclfrominheritance element is present on this | ||||
resource unless the DAV:inheritancesource element contains the | ||||
special value DAV:system-ace, indicating that this ACE wasn't | ||||
really inherited, but reflects implicit system-granted rights. | ||||
[REQUIRED] | ||||
. DAV:inheritonly: This flag indicates the ACE should be ignored | If an ACE contains a DAV:protected element, an ACL request | |||
during access check. The ACE is present for the purposes of | without that ACE MUST fail. | |||
inheritance only and does not affect the security of the | ||||
current resource. [OPTIONAL] | ||||
. DAV:containerinherit: This flag indicates that container | <!ELEMENT protected EMPTY> | |||
objects inherit this ACE as an effective ACE. The | ||||
DAV:inheritonly flag, if also present on this ACE, will be | ||||
removed from the inherited effective ACE on the container. If | ||||
the DAV:nopropagateinheritance flag is present on the current | ||||
ACE, the DAV: containerinherit flag is removed from the | ||||
inherited ACE on the container. [REQUIRED] | ||||
. DAV:objectinherit: This flag indicates that non-container | 5.4.4 ACE Inheritance | |||
resources inherit this ACE as an effective ACE. The | ||||
DAV:inheritonly flag, if also present on this ACE, will be | ||||
removed from the inherited effective ACE on the non-container | ||||
resource. If the DAV:nopropagateinheritance> flag is not | ||||
present, then container resources will also inherit this ACE | ||||
with the addition of the DAV:inheritonly> flag. [REQUIRED] | ||||
. DAV:nopropagateinheritance: This flag indicates the ACE should | The presence of a DAV:inherited element indicates that this | |||
be inherited one level only. If an object inherits this ACE, | ACE is inherited from another resource that is identified by | |||
the DAV:containerinherit and DAV:objectinherit flags are | the URL contained in a DAV:href element. An inherited ACE | |||
removed from the resultant inherited ACE, preventing further | cannot be modified directly, but instead the ACL on the | |||
propagation of this ACE. [OPTIONAL] | resource from which it is inherited must be modified. | |||
The DAV:aclsemantics element MUST contain exactly one of the | ||||
following XML elements: | ||||
. DAV:firstspecific: This element is present if the ACL | ||||
conforms to the FirstSpecific semantics described in this | ||||
spec. | ||||
. DAV:explicitdenyprecedence: This element is present if the ACL | Note that ACE inheritance is not the same as ACL | |||
conforms to the ExplicitDenyPrecedence semantics described in | initialization. ACL initialization defines the ACL that a | |||
this spec. | newly created resource will use (if not specified). ACE | |||
inheritance refers to an ACE that is logically shared - where | ||||
an update to the resource containing an ACE will affect the | ||||
ACE of each resource that inherits that ACE. The method by | ||||
which ACLs are initialized or by which ACEs are inherited is | ||||
not defined by this document. | ||||
4.1 Retrieving Access Control Information | <!ELEMENT inherited (href)> | |||
Retrieving Access Control information is done via PROPFIND on the | 5.5 DAV:acl-semantics | |||
resource in question. All ACL properties are also returned as | ||||
part of the response to PROPFIND allprop request. | ||||
4.1.1Example: Retrieving Access Control information | This is a read-only property that defines the ACL semantics. | |||
These semantics define how multiple ACEs that match the | ||||
current user are combined, what are the constraints on how | ||||
ACEs can be ordered, and which principals must have an ACE. | ||||
Since it is not practical to require all implementations to | ||||
use the same ACL semantics, the DAV:acl-semantics property is | ||||
used to identify the ACL semantics for a particular resource. | ||||
The DAV:acl-semantics element is defined in section 6. | ||||
5.6 DAV:principal-collection-set | ||||
Often a versioning implementation constrains where a principal | ||||
can be located in the URL space. The DAV:principal- | ||||
collection-set enumerates which collections may contain | ||||
principals. | ||||
<!ELEMENT principal-collection-set (href*)> | ||||
Since different servers can control different parts of the URL | ||||
namespace, different resources on the same host MAY have | ||||
different DAV:principal-collection-set values . The | ||||
collections specified in the DAV:principal-collection-set MAY | ||||
be located on different hosts from the resource. | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 10] | ||||
5.7 Example: PROPFIND to retrieve access control properties | ||||
The following example shows how access control information can | ||||
be retrieved by using the PROPFIND method to fetch the values | ||||
of the DAV:owner, DAV:supported-privilege-set, DAV:current- | ||||
user-privilege-set, and DAV:acl properties. | ||||
>> Request << | ||||
The following example shows how access control information could | ||||
be retrieved using PROPFIND method. | ||||
Request | ||||
PROPFIND /top/container/ HTTP/1.1 | PROPFIND /top/container/ HTTP/1.1 | |||
Host: www.foo.bar | Host: www.foo.org | |||
Content-type: text/xml; charset="utf-8" | Content-type: text/xml; charset="utf-8" | |||
Content-Length: 0 | Content-Length: xxx | |||
Depth: 0 | Depth: 0 | |||
Authorization: Digest username="ejw", | ||||
realm="users@foo.org", nonce="...", | ||||
uri="/top/container/", response="...", opaque="..." | ||||
<?xml version='1.0'> | <?xml version="1.0" encoding="utf-8"> | |||
<D:propfind xmlns:D='DAV:'> | <D:propfind xmlns:D="DAV:"> | |||
<D:allprop/> | <D:owner/> | |||
<D:supported-privilege-set/> | ||||
<D:current-user-privilege-set/> | ||||
<D:acl/> | ||||
</D:propfind> | </D:propfind> | |||
Response | >> Response << | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxx | Content-Length: xxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:multistatus xmlns:D="DAV"> | <D:multistatus | |||
<D:response> | xmlns:D="DAV" | |||
<D:propstat> | xmlns:A="http://www.acl.org/"> <D:response> <D:propstat> | |||
<D:status>HTTP/1.1 200 OK</D:status> | <D:status>HTTP/1.1 200 OK</D:status> | |||
<D:prop> | <D:prop> | |||
<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> | <D:owner> | |||
<D:href>http://www.foo.bar/users/gclemm | <D:href>http://www.foo.org/users/gclemm</D:href></D:owner> | |||
<D:displayname>Geoffrey Clemm</D:displayname> | <D:supported-privilege-set> | |||
</D:owner> | <D:supported-privilege> | |||
<D:rights> | <D:privilege> <D:all/> </D:privilege> | |||
<D:read/><D:readacl/> | <D:abstract/> | |||
</D:rights> | <D:description>Any operation</D:description> | |||
<D:supported-privilege> | ||||
<D:privilege> </D:read> </D:privilege> | ||||
<D:description>Read any object</D:description> | ||||
</D:supported-privilege> | ||||
<D:supported-privilege> | ||||
<D:privilege> <D:write/> </D:privilege> | ||||
<D:abstract/> | ||||
<D:description>Write any object</D:description> | ||||
<D:supported-privilege> | ||||
<D:privilege> <A:create/> </D:privilege> | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 11] | ||||
<D:description>Create an object</D:description> | ||||
</D:supported-privilege> | ||||
<D:supported-privilege> | ||||
<D:privilege> <A:update> </D:privilege> | ||||
<D:description>Update an object</D:description> | ||||
</D:supported-privilege> | ||||
<D:supported-privilege> | ||||
<D:privilege> <A:delete> </D:privilege> | ||||
<D:description>Delete an object</D:description> | ||||
</D:supported-privilege> | ||||
</D:supported-privilege> | ||||
<D:supported-privilege> | ||||
<D:privilege> <D:read-acl/> </D:privilege> | ||||
<D:description>Read the ACL</D:privilege> | ||||
</D:supported-privilege> | ||||
<D:supported-privilege> | ||||
<D:privilege> <D:write-acl/> </D:privilege> | ||||
<D:description>Write the ACL</D:privilege> | ||||
</D:supported-privilege> | ||||
</D:supported-privilege> | ||||
</D:supported-privilege-set> | ||||
<D:current-user-privilege-set> | ||||
<D:privilege> <D:read/> </D:privilege> | ||||
<D:privilege> <D:read-acl/> </D:privilege> | ||||
</D:current-user-privilege-set> | ||||
<D:acl> | <D:acl> | |||
<D:ace> | <D:ace> | |||
<D:grant><D:read/><D:write/><D:readacl/></D:grant> | ||||
<D:principal> | <D:principal> | |||
<D:href>http://www.foo.bar/users/esedlar</D:href> | <D:href>http://www.foo.org/users/esedlar</D:href> | |||
<D:principal-type><DAV:user/></D:principal-type> | <D:prop> | |||
<D:principalname>esedlar</D:principalname> | <D:authentication-id>esedlar</D:authentication-id> | |||
<D:displayname>Eric Sedlar</D:displayname> | <D:displayname>Eric Sedlar</D:displayname> | |||
</D:principal> | </D:prop> </D:principal> | |||
<D:grant> | ||||
<D:privilege> <D:read/> </D:privilege> | ||||
<D:privilege> <D:write/> </D:privilege> | ||||
<D:privilege> <D:read-acl/> </D:privilege></D:grant> | ||||
</D:ace> | </D:ace> | |||
<D:ace> | <D:ace> | |||
<D:grant><D:read/><D:readacl/></D:grant> | ||||
<D:principal> | <D:principal> | |||
<D:href>http://www.foo.bar/groups/marketing</d:href> | <D:href>http://www.foo.org/groups/marketing/</d:href> | |||
<D:principal-type><DAV:group/></D:principal-type> | ||||
<D:displayname>Foo.Bar marketing | ||||
department</D:displayname> | ||||
<D:principalname>mktdept</D:principalname> | ||||
</D:principal> | </D:principal> | |||
</D:ace> | <D:deny> | |||
<D:privilege> <D:read/> </D:privilege> </D:deny> | ||||
<D:ace/> | ||||
<D:ace> | <D:ace> | |||
<D:deny><D:writeacl/></D:deny> | ||||
<D:principal> | <D:principal> | |||
<D:property> <D:owner/> </D:property> </D:principal> | ||||
<D:href>http://www.foo.bar/groups/marketing</d:href> | <D:grant> | |||
<D:principal-type><DAV:group/></D:principal-type> | <D:privilege> <D:read-acl/> </D:privilege> | |||
<D:displayname>Foo.Bar marketing | <D:privilege> <D:write-acl/> </D:privilege></D:grant> | |||
department</D:displayname> | ||||
<D:principalname>mktdept</D:principalname> | ||||
</D:principal> | ||||
<D:ace/> | <D:ace/> | |||
<D:ace> | <D:ace> | |||
<D:grant><D:read/></D:grant> | ||||
<D:principal><d:all/></D:principal> | Clemm, Hopkins, Sedlar, Whitehead [Page 12] | |||
</D:ace> | <D:principal> <D:all/> </D:principal> | |||
</D:acl> | <D:grant> | |||
<D:privilege> <D:read/> </D:privilege> </D:grant> | ||||
<D:inherited> | ||||
<D:href>http://www.foo.org/top/</D:href></D:inheritied> | ||||
</D:ace> </D:acl> | ||||
</D:prop> | </D:prop> | |||
<D:propstat> | </D:propstat> </D:response> </D:multistatus> | |||
<D:response> | ||||
<D:multistatus> | ||||
4.2 Setting Access Control Information | The value of the DAV:owner property is a single DAV:href XML | |||
element containing the URL of the principal that owns this | ||||
resource. | ||||
An ACL is set by executing a PROPPATCH against the resource that | The value of the DAV:supported-privilege-set property is a | |||
contains the DAV:acl property. An ACL must be written in its | tree of supported privileges: | |||
entirety. All ACEs (readable by the current user) previously | ||||
stored in the ACL on the indicated resource are removed. (If the | ||||
server implements rights outside of those defined in this | ||||
specification, they might allow only some ACEs to be visible=97 | ||||
behaviour on a PROPPATCH is undefined with respect to this | ||||
specification). | ||||
Setting an empty ACL property causes all ACEs in the ACL, | ||||
including ACEs for associated properties, to be deleted. | ||||
Since permission to set an ACL is typically controlled by a | ||||
different right from permission to set other properties, it is | ||||
recommended that ACL-setting PROPPATCHes be executed | ||||
independently from PROPPATCHes of other properties. PROPATCH as | ||||
defined in [WEBDAV] is an atomic operation, so failure to set the | ||||
ACL will result in a failure to set all other properties. | ||||
[WEBDAV] also defines that operations must be performed from top | ||||
to bottom, so multiple instances of the DAV:acl element in a | ||||
single PROPPATCH result in only the last being set. | ||||
Changing ownership of a resource requires setting the DAV:href | ||||
element of the DAV:owner property. | ||||
4.2.1Example: Setting Access Control information | DAV:acl (abstract) | |||
| | ||||
+-- DAV:read | ||||
+-- DAV:write (abstract) | ||||
| | ||||
+-- http://www.acl.org/create | ||||
+-- http://www.acl.org/update | ||||
+-- http://www.acl.org/delete | ||||
+-- DAV:read-acl | ||||
+-- DAV:write-acl | ||||
The following example follows from the previous example and | The DAV:current-user-privilege-set property contains two | |||
changes the group ACE to disallow read access to the ACL for the | privileges, DAV:read, and DAV:read-acl. This indicates that | |||
marketing group. The other information had to be copied from the | the current authenticated user only has the ability to read | |||
ACL retrieved in the previous example. | the resource, and read the DAV:acl property on the resource. | |||
Request | ||||
PROPPATCH /top/container HTTP/1.1 | ||||
Host: www.foo.bar | ||||
Content-Type: text/xml | ||||
Content-Length: xxxx | ||||
<?xml version="1.0"?> | The DAV:acl property contains a set of four ACEs: | |||
<D:propertyupdate xmlns:D="DAV:"> | ||||
<D:set> | ||||
<D:prop> | ||||
<D:acl> | ||||
<D:ace> | ||||
<D:grant><D:read/><D:write/><D:readacl/></D:grant> | ||||
<D:principal> | ||||
<D:href>http://www.foo.bar/users/esedlar</D:href> | ||||
</D:principal> | ||||
</D:ace> | ||||
<D:ace> | ||||
<D:grant><D:read/></D:grant> | ||||
<D:principal> | ||||
<D:href>http://www.foo.bar/groups/marketing</D:href> | ||||
</D:principal> | ||||
</D:ace> | ||||
</D:acl> | ||||
</D:prop> | ||||
</D:set> | ||||
</D:propertyupdate> | ||||
Response | ACE #1: The principal identified by the URL | |||
HTTP/1.1 207 Multi-Status | http://www.foo.org/users/esedlar is granted the DAV:read, | |||
Content-Type: text/xml | DAV:write, and DAV:read-acl privileges. | |||
Content-Length: xxx | ||||
<?xml version="1.0"?> | ACE #2: The principals identified by the URL | |||
<D:multistatus xmlns:a="DAV:"> | http://www.foo.org/groups/marketing/ are denied the DAV:read | |||
<D:response> | privilege. In this example, the principal URL identifies a | |||
<D:href>http://www.foo.bar/top/container/</D:href> | group, which is represented by a collection principal. | |||
<D:propstat> | ||||
<D:status>HTTP/1.1 200 OK</D:status> | ||||
<D:prop> | ||||
<D:acl/> | ||||
</D:prop> | ||||
</D:propstat> | ||||
</D:response> | ||||
</D:multistatus> | ||||
5 USING ACLS | ACE #3: In this ACE, the principal is a property principal, | |||
specifically the DAV:owner property. When evaluating this ACE, | ||||
the value of the DAV:owner property is retrieved, and is | ||||
examined to see if it contains a DAV:href XML element. If so, | ||||
the URL within the DAV:href element is read, and identifies a | ||||
principal. In this ACE, the owner is granted DAV:read-acl, and | ||||
DAV:write-acl privileges. | ||||
An ACL contains zero or more ACEs that express the rights granted | ACE #4: This ACE grants the DAV:all principal (all users) the | |||
or denied to the principal specified in the ACE. An ACL with | DAV:read privilege. This ACE is inherited from the resource | |||
zero ACEs implies that no principal is granted any rights. A | ||||
particular ACE may either grant or deny a set of rights to a | ||||
single principal. However, since a server may match the | ||||
currently authenticated HTTP user with multiple principals (for | ||||
instance, in the case where one principal refers to the user and | ||||
another principal refers to a group to which the user belongs), | ||||
it is possible for multiple ACEs to "match" the current user. A | ||||
user has no access rights to an object protected by an ACL unless | ||||
that user matches one or more of the principals specified in the | ||||
ACEs. | ||||
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. If a client tries to | ||||
write an ACL containing more ACEs than the server supports, the | ||||
server should return an error "Too many ACEs." | ||||
5.1 System Controlled Rights | Clemm, Hopkins, Sedlar, Whitehead [Page 13] | |||
http://www.foo.org/top/, the parent collection of this | ||||
resource. | ||||
Some implementations may grant certain rights implicitly. For | 6 ACL SEMANTICS | |||
example, some systems grant the resource owner DAV:readacl and | ||||
DAV:writeacl implicitly to prevent an ACL from becoming | ||||
irrevocably locked by an update that grants no one the | ||||
DAV:writeacl right. Any rights granted implicitly by the system | ||||
should be reflected as standard ACEs in the ACL returned to the | ||||
client. Since these implicit permissions are read-only, they | ||||
should be reflected as "system controlled" ACEs where | ||||
DAV:inheritanceflags contains DAV:inherited and the | ||||
DAV:inheritancesource element contains DAV:system-ace. | ||||
5.2 Special Principal Identifiers | The ACL semantics define how multiple ACEs that match the | |||
current user are combined, what are the constraints on how | ||||
ACEs can be ordered, and which principals must have an ACE. | ||||
The DAV:principal element in an ACE may contain, instead of a | <!ELEMENT acl-semantics ANY> | |||
specific security principal identifier, one of the following | ANY value: zero or more of the ACL semantic elements | |||
special tags: | ||||
. DAV:owner: The principal identified by the owner property on | ||||
this resource is granted or denied the rights specified in | ||||
this ACE. | ||||
. DAV:all: The current user always matches this ACE, whether or | 6.1 ACE Combination | |||
not s/he is authenticated. | ||||
. DAV:authenticated: The current user matches this ACE if | The DAV:ace-combination element defines how privileges from | |||
authenticated. | multiple ACEs that match the current user will be combined to | |||
determine the access rights for that user. Multiple ACEs may | ||||
match the same user because the same principal can appear in | ||||
multiple ACEs, because multiple principals can identify the | ||||
same user, and because one principal can be a member of | ||||
another principal. | ||||
. DAV:unauthenticated: The current user matches this ACE if not | <!ELEMENT ace-combination | |||
authenticated | (first-match | all-grant-before-any-deny | no-deny)> | |||
. DAV:selfprincipal: The current user matches this ACE if the | 6.1.1 DAV:first-match ACE Combination | |||
resource (for example, a user information object or security | ||||
principal account) associated with this ACL is a | ||||
representation of the current user. | ||||
5.3 ACL Semantics Options | The ACEs are evaluated in the order in which they appear in | |||
the ACL. If the first ACE that matches the current user does | ||||
not grant all the privileges needed for the request, the | ||||
request MUST fail. | ||||
In order to accommodate the different semantics of multiple | <!ELEMENT first-match EMPTY> | |||
existing server implementations, we define a number of ACL | ||||
Semantics options. The tag associated with each option is used | ||||
to indicate what semantics to apply to the ACL. A client may use | ||||
this tag to display information that helps an ACL author | ||||
understand the implications of his updates. The client must also | ||||
use this tag to determine the legal semantics for ordering ACEs | ||||
prior to updating the ACL property. | ||||
The following ACL Semantics options have been defined to | ||||
indicate: | ||||
. restrictions, if any, on the ordering of ACEs within a stored | ||||
ACL, | ||||
. how to determine during access check which ACE(s) apply to a | 6.1.2 DAV:all-grant-before-any-deny ACE Combination | |||
user that matches multiple principals, | ||||
. how to combine the rights granted or denied by multiple | The ACEs are evaluated in the order in which they appear in | |||
matching ACEs during access check. | the ACL. If an evaluated ACE denies a privilege needed for | |||
the request, the request MUST fail. If all ACEs have been | ||||
evaluated without the user being granted all privileges needed | ||||
for the request, the request MUST fail. | ||||
Additional ACL models may be accommodated by defining and | <!ELEMENT all-grant-before-any-deny EMPTY> | |||
registering additional ACL Semantics tags. [How is this done? | ||||
TBD]. | ||||
Requested Rights: Some access check algorithms are based on not | ||||
just the user identity and the ACEs, but also on the "requested | ||||
rights," which is the set of rights required by the operation for | ||||
which the access check is being performed. | ||||
Effective Rights: The "effective rights" of a user is the set of | 6.1.3 DAV:no-deny ACE Combination | |||
all rights that would be granted to a user by a given ACL. This | ||||
set, which is exposed via the DAV:rights property, is independent | ||||
of any operation "requested rights" and may be generated by a | ||||
different algorithm than the access check algorithm that | ||||
determines whether a user has specific requested rights. Each | ||||
right in the Effective Rights set applies to the user whether the | ||||
right is requested individually, or in combination with other | ||||
rights, in the requested rights for an operation. | ||||
5.3.1FirstSpecific | All ACEs in the ACL are evaluated. An "individual ACE" is one | |||
whose principal identifies the current user. A "group ACE" is | ||||
one whose principal is a collection that contains a principal | ||||
that identifies the current user. A privilege is granted if | ||||
it is granted by an individual ACE and not denied by an | ||||
individual ACE, or if it is granted by a group ACE and not | ||||
denied by an individual or group ACE. A request MUST fail if | ||||
any of its needed privileges are not granted. | ||||
The FirstSpecific semantic model has the following | <!ELEMENT no-deny EMPTY> | |||
characteristics: | ||||
Order of ACEs: ACEs are ordered from "most specific" to "least | ||||
specific." Typically, the "most specific" ACEs identify | ||||
principals that refer to a single user. ACEs with "intermediate" | ||||
specificity have principals that refer to a collection or group | ||||
of users or other entities. The "least specific" ACEs contain | ||||
principals, like "World" or "Everyone," that indicate an | ||||
unbounded set of users. If multiple ACEs with the same level of | ||||
specificity are present, their order relative to each other is | ||||
not defined here. Implementations of the FirstSpecific model are | ||||
unlikely to have multiple ACEs in the intermediate and least | ||||
specific categories (where multiple ACE matches are possible), | ||||
making it unimportant to define a rule for relative ordering of | ||||
ACEs within these two specificity levels. | ||||
ACE Matching Algorithm: ACEs are evaluated in the order in which | ||||
they appear in the ACL, from first to last. When a match is | ||||
found, the algorithm is complete. This first matching ACE alone | ||||
is used to determine the effective rights of the user. If it is | ||||
a Grant ACE, then the user is granted all rights in the ACE. If | ||||
it is a Deny ACE, then the user is denied all rights in the ACE. | ||||
Requested rights may be compared with the effective rights to | ||||
determine if access should be granted. | ||||
ACE Combining Algorithm: The FirstSpecific model never matches | ||||
more than one ACE to a user, thus there's no need to combine the | ||||
rights of multiple ACEs. | ||||
Example Implementation: UNIX rights (rwx for user:group:world) is | ||||
an example of the FirstSpecific model. | ||||
5.3.2ExplicitDenyPrecedence | Clemm, Hopkins, Sedlar, Whitehead [Page 14] | |||
6.2 ACE Ordering | ||||
The ExplicitDenyPrecedence model has the following | The DAV:ace-ordering element defines a constraint on how the | |||
characteristics: | ACEs can be ordered in the ACL. | |||
Order of ACEs: All Explicit ACEs must precede all Inherited ACEs. | ||||
Within the group of Explicit ACEs, all Deny ACEs must precede all | ||||
Grant ACEs. Inherited ACEs are placed in the order in which they | ||||
are inherited. ACEs inherited from the resource's parent come | ||||
first, then ACEs from the grandparent, and so on. | ||||
ACE Matching and Combining Algorithm: The ACE matching and | 6.2.1 DAV:deny-before-grant ACE Ordering | |||
combining algorithms are not distinct in this model and must be | ||||
described together. A set of "Granted rights" and a set of | ||||
"Denied rights", both initialized with zero rights, are | ||||
maintained in the algorithms to check for Requested Rights and to | ||||
calculate Effective Rights. In both cases, ACEs are evaluated in | ||||
the order in which they appear in the ACL, from first to last. | ||||
Checking for Requested Rights: For each ACE evaluated, if the ACE | ||||
matches the current user, then: | ||||
. if it is a Grant ACE, any rights in the ACE that are not | ||||
already in the "Granted rights" or "Denied rights" sets are | ||||
added to the "Granted rights" set | ||||
. if it is a Deny ACE, any rights in the ACE that are not | This element indicates that all deny ACEs must precede all | |||
already in the "Granted rights" or "Denied rights" sets are | grant ACEs. | |||
added to the "Denied rights" set | ||||
If the "Granted rights" set now contains all rights in the set of | <!ELEMENT deny-before-grant EMPTY> | |||
"requested rights," then no more ACEs are evaluated and the | ||||
algorithm completes with "Requested Access Granted." | ||||
If the "Denied rights" set now contains any right that is in the | ||||
set of "requested rights," then no more ACEs are evaluated and | ||||
the algorithm completes with "Requested Access Denied." | ||||
If neither of these cases is true, then the next ACE is | ||||
evaluated. If there are no more ACEs present in the ACL, then | ||||
the algorithm completes with "Requested Access Denied" since the | ||||
accumulated Granted rights did not contain all of the requested | ||||
rights. | ||||
Calculating the effective rights of a user: As in the check for | ||||
requested rights, for each ACE evaluated, if the ACE matches the | ||||
current user, then: | ||||
. if it is a Grant ACE, any rights in the ACE that are not | ||||
already in the "Granted rights" or "Denied rights" sets are | ||||
added to the "Granted rights" set | ||||
. if it is a Deny ACE, any rights in the ACE that are not | 6.3 Required Principals | |||
already in the "Granted rights" or "Denied rights" sets are | ||||
added to the "Denied rights" set | ||||
If the union of the "Granted rights" and "Denied rights" now | The required principal elements identify which principals must | |||
contains all possible rights, then no more ACEs are evaluated and | have an ACE defined in the ACL. | |||
the algorithm returns the Granted rights as the set of Effective | ||||
Rights. | ||||
Otherwise, the next ACE is evaluated. If there are no more ACEs | ||||
present in the ACL, then all rights present in the "Granted | ||||
rights" set are returned as Effective Rights. | ||||
Example Implementation: Microsoft Windows NT canonical ACLs are | ||||
an example of this model. | ||||
6 ACL INHERITANCE | <!ELEMENT required-principal | |||
(href | all | authenticated | unauthenticated | property | | ||||
self)> | ||||
To support a more scalable administration model for configuration | For example, the following element requires that the ACE | |||
of access control information, the spec defines an ACL | contain a DAV:owner property ACE: | |||
inheritance model that enables an ACL, or elements of an ACL, to | ||||
be inherited and reused by other resources. An ACL-compliant | ||||
implementation is not required to support inheritance. | ||||
Typically, an ACL defined on a container resource may be | ||||
inherited by children of that container, grandchildren if they | ||||
exist, and so on down the tree. Although this hierarchical tree | ||||
model of inheritance is popular, this spec does not require an | ||||
implementation's ACL inheritance model to follow a tree structure | ||||
where child resource inherits from parent resource. Nonetheless, | ||||
for convenience, this description of inheritance assumes that a | ||||
child resource would inherit access control information from its | ||||
parent. | ||||
6.1 Inheritable ACEs | <D:required-principal xmlns:D="DAV:"> | |||
<D:property> <D:owner/> </D:property> | ||||
</D:required-principal> | ||||
Access control information is inherited at the granularity of an | 7 ACCESS CONTROL AND EXISTING METHODS | |||
ACE. An inherited ace is identified by the presence of the | ||||
DAV:inherited element in the DAV:inheritanceflags property. An | ||||
"Explicit" ACE is an ACE defined directly on a resource, rather | ||||
than inherited from a different resource. An ACE without the | ||||
DAV:inherited element is by definition an Explicit ACE. Only | ||||
Explicit ACEs may updated by the client. | ||||
To indicate that an ACE should be inherited by child resources, | ||||
the DAV:inheritanceflags should contain: | ||||
. DAV:objectinherit to indicate that non-container children | ||||
should inherit the ACE, | ||||
. DAV:containerinherit to indicate that container children | This section defines the impact of access control | |||
should inherit the ACE, or | functionality on existing methods. | |||
. both to indicate that all child resources should inherit the | 7.1 OPTIONS | |||
ACE. | ||||
6.2 Updating an inherited ACE | If the server supports access control, it MUST return "access- | |||
control" as a field in the DAV response header from an OPTIONS | ||||
request on any resource implemented by that server. | ||||
When a child resource ACL inherits an ACE, the DAV:inherited | 7.1.1 Example - OPTIONS | |||
flag is present on the ACE to indicate that this ACE is read- | ||||
only (it may only be edited on the resource where the ACE was | ||||
explicitly defined). To assist users who want to make changes | ||||
to the rights that appear in an inherited ACE, the resource from | ||||
which the ACE was inherited (and therefore, on which the | ||||
explicit ACE is defined and editable) is identified in the | ||||
DAV:inheritancesource property. If the inheritance source | ||||
cannot be determined or if the system is unable to generate a | ||||
valid URI to the resource from which the ACE was inherited, | ||||
DAV:inheritancesource contains the special tag DAV:unknown. | ||||
6.3 Propagate ACE but do not use for Access Check on this resource | >>REQUEST | |||
In some cases, an ACE (whether explicit or inherited) may be | OPTIONS /foo.html HTTP/1.1 | |||
present on a container ACL purely for the sake of propagating | Host: www.webdav.org | |||
the ACE to child objects and NOT to be used for access control | Content-Length: 0 | |||
on the container itself. In this case, the optional | ||||
DAV:inheritonly flag is present on the ACE to indicate it should | ||||
not be used for access check on this container. | ||||
6.4 Propagate to immediate children only | >>RESPONSE | |||
To indicate that an ACE should be inherited by children, but not | HTTP/1.1 200 OK | |||
by grandchildren or any further down the tree, the optional | DAV: 1, 2, access-control | |||
DAV:nopropagateinheritance flag is present on the ACE. This | ||||
flag indicates that when this ACE is inherited by child objects, | ||||
the DAV:objectinherit and/or DAV:containerinherit elements must | ||||
be removed from the inherited ACE. | ||||
6.5 Protect ACL from inheritance | Clemm, Hopkins, Sedlar, Whitehead [Page 15] | |||
Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL | ||||
To prevent an ACL from inheriting any ACEs, the optional | In this example, the OPTIONS response indicates that the | |||
DAV:protectaclfrominheritance property is set on the resource. | server supports access control and that /foo.html can have its | |||
If this property is present on a resource, the DAV:inherited | access control list modified by the ACL method. | |||
element must not be present on any ACEs in that resource's ACL. | ||||
Other inheritance flags may be present on the ACEs of this | ||||
resource, since this ACL may be the source of inheritable ACEs | ||||
for the subtree under this resource. | ||||
7 XML SCHEMA FOR DEFINED ELEMENTS | 8 ACCESS CONTROL METHODS | |||
<?xml version='1.0'?> | 8.1 ACL | |||
<!-- 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" | A DAV:acl property of a resource is modified by the ACL | |||
xmlns:dav="http://www.ietf.org/standards/webdav" | method. A new DAV:acl value must be written in its entirety, | |||
blockDefault="#all" elementFormDefault="qualified"> | including any inherited ACEs. Unless the DAV:acl property of | |||
the resource can be updated to be exactly the value specified | ||||
in the ACL request, the ACL request MUST fail. If a server | ||||
restricts the set of ACEs visible to the current user via the | ||||
DAV:acl property, then the ACL request would only replace the | ||||
set of ACEs visible to the current user, and would not affect | ||||
any ACE that was not visible. | ||||
<element name="right" abstract="true"> | In order to avoid overwriting DAV:acl changes by another | |||
<complexType content="empty"> | client, a client SHOULD acquire a WebDAV lock on the resource | |||
</element> | before retrieving the DAV:acl property of a resource that it | |||
intends on updating. | ||||
<!--For those folks not familiar with XML Schema, minOccurs | 8.1.1 ACL Preconditions | |||
defaults to 0, and maxOccurs defaults to 1 --> | ||||
<element name="DAV:read" base="right" equivClass="right"/> | An implementation MAY enforce one or more of the following | |||
<element name="DAV:write" base="right" equivClass="right"/> | constraints on an ACL request. If the constraint is violated, | |||
<element name="DAV:readacl" base="right" equivClass="right"/> | a 403 (Forbidden) response MUST be returned and the indicated | |||
<element name="DAV:writeacl" base="right" | XML element MUST be returned in the response body. | |||
equivClass="right"/> | ||||
<element name="DAV:all" base="right" equivClass="right"/> | ||||
<complexType name="DAV:rights-list"> | <DAV:protected/>: An implementation MAY protect an ACE from | |||
<choice minOccurs="1" maxOccurs="unbounded"> | modification or deletion. For example, some implementations | |||
<element ref="DAV:right"> | implicitly grant the DAV:owner of a resource DAV:read-acl and | |||
<element name="DAV:unauthenticated" content="empty"/> | DAV:write-acl privileges, and this cannot be changed by a | |||
<element name="DAV:all" content="empty"/> | client. | |||
<element name="DAV:owner" content="empty"/> | ||||
</complexType> | ||||
<complexType name="DAV:ace"> | <DAV:too-many-aces/>: An implementation MAY limit the number | |||
<element name="DAV:grant" type="DAV:rights-list" | of ACEs in an ACL. However, ACL-compliant servers MUST | |||
minOccurs="0" maxOccurs="1"> | support at least one ACE granting privileges to a single | |||
<element name="DAV:deny" type="DAV:rights-list" | principal, and one ACE granting privileges to a collection | |||
minOccurs="0" maxOccurs="1"> | principal. | |||
<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"/> | ||||
<element name="DAV:principal-type" type="string" | ||||
minOccurs="1"/> | ||||
</complexType> | ||||
</element> | ||||
</complexType> | ||||
<element name="DAV:acl"> | <DAV:non-inherited-must-precede-inherited/>: All non-inherited | |||
<complexType> | ACEs MUST precede all inherited ACEs. | |||
<element name="DAV:ace" type="DAV:ace" | ||||
minOccurs="0" maxOccurs="unbounded"/> | ||||
</complexType> | ||||
</element> | ||||
<element name="DAV:rights"> | <DAV:deny-must-precede-grant/>: All non-inherited deny ACEs | |||
<complexType> | MUST precede all non-inherited grant ACEs. | |||
<choice minOccurs="1" maxOccurs="unbounded"> | ||||
<element ref="DAV:right"/> | ||||
</choice> | ||||
</complexType> | ||||
</element> | ||||
</schema> | ||||
8 INTERNATIONALIZATION CONSIDERATIONS | <DAV:acl-requires-lock-token/>: If a resource is locked, the | |||
lock token MUST be specified in the ACL request. | ||||
To be supplied. | Clemm, Hopkins, Sedlar, Whitehead [Page 16] | |||
8.1.2 Example: the ACL method | ||||
9 SECURITY CONSIDERATIONS | In the following example, user "fielding", authenticated by | |||
information in the Authorization header, grants the principal | ||||
identified by the URL http://www.foo.org/users/esedlar (i.e., | ||||
the user "esedlar") read and write privileges, grants the | ||||
owner of the resource read-acl and write-acl privileges, and | ||||
grants everyone read privileges inherited from the parent | ||||
collection http://www.foo.bar/top/. | ||||
To be supplied. | >> Request << | |||
10 SCALABILITY | ACL /top/container HTTP/1.1 | |||
Host: www.foo.org | ||||
Content-Type: text/xml; charset="utf-8" | ||||
Content-Length: xxxx | ||||
Authorization: Digest username="fielding", | ||||
realm="users@foo.org", nonce="...", | ||||
uri="/top/container/", response="...", opaque="..." | ||||
To be supplied. | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:acl xmlns:D="DAV:"> | ||||
<D:ace> | ||||
<D:principal> | ||||
<D:href>http://www.foo.org/users/esedlar</D:href> | ||||
</D:principal> | ||||
<D:grant> | ||||
<D:privilege> <D:read/> </D:privilege> | ||||
<D:privilege> <D:write/> </D:privilege> </D:grant> | ||||
</D:ace> | ||||
<D:ace> | ||||
<D:principal> | ||||
<D:property> <D:owner/> </D:property> </D:principal> | ||||
<D:grant> | ||||
<D:privilege> <D:read-acl/> </D:privilege> | ||||
<D:privilege> <D:write-acl/> </D:privilege> </D:grant> | ||||
<D:ace/> | ||||
<D:ace> | ||||
<D:principal> <D:all/> </D:principal> | ||||
<D:grant> | ||||
<D:privilege> <D:read/> </D:privilege></D:grant> | ||||
<D:inherited> | ||||
<D:href>http://www.foo.org/top/</D:href> </D:inherited> | ||||
</D:ace> </D:acl> | ||||
>> Response << | ||||
HTTP/1.1 200 OK | ||||
8.1.3Example: ACL method failure | ||||
In the following request, user "fielding", authenticated by | ||||
information in the Authorization header, attempts to grant | ||||
principal identified by the URL | ||||
http://www.foo.org/users/esedlar (i.e., the user "esedlar") | ||||
read privileges, but fails because an implicit ACE has been | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 17] | ||||
omitted (e.g. the ACE granting the DAV:owner DAV:read-acl and | ||||
DAV:write-acl privileges). | ||||
>> Request << | ||||
ACL /top/container HTTP/1.1 | ||||
Host: www.foo.bar | ||||
Content-Type: text/xml; charset="utf-8" | ||||
Content-Length: xxxx | ||||
Authorization: Digest username="fielding", | ||||
realm="users@foo.org", nonce="...", | ||||
uri="/top/container/", response="...", opaque="..." | ||||
<?xml version="1.0" encoding="utf-8" ?> | ||||
<D:acl xmlns:D="DAV:"> | ||||
<D:ace> | ||||
<D:principal> | ||||
<D:href>http://www.foo.bar/users/esedlar</D:href> | ||||
</D:principal> | ||||
<D:grant> | ||||
<D:privilege> <D:read/> </D:privilege> </D:grant> | ||||
</D:ace> | ||||
</D:acl> | ||||
>> Response << | ||||
HTTP/1.1 403 Forbidden | ||||
Content-Type: text/xml; charset="utf-8" | ||||
Content-Length: xxx | ||||
<?xml version="1.0" encoding="utf-8" ?> | ||||
<DAV:cannot-change-implicit-ace/> | ||||
9 INTERNATIONALIZATION CONSIDERATIONS | ||||
In this specification, the only human-readable content can be | ||||
found in the DAV:authentication-id property, found on | ||||
principal resources. This property contains the name used to | ||||
authenticate a principal, typically by a user entering this | ||||
name into a password entry screen. As a result, the | ||||
authentication-id must be capable of representing names in | ||||
multiple character sets. Since DAV:authentication-id is a | ||||
WebDAV property, it is represented on-the-wire as XML [REC- | ||||
XML], and hence can leverage XML's language tagging and | ||||
character set encoding capabilities. Specifically, XML | ||||
processors must, at minimum, be able to read XML elements | ||||
encoded using the UTF-8 [UTF-8] encoding of the ISO 10646 | ||||
multilingual plane. XML examples in this specification | ||||
demonstrate use of the charset parameter of the Content-Type | ||||
header, as defined in [RFC2376], as well as the XML "encoding" | ||||
attribute, which together provide charset identification | ||||
information for MIME and XML processors. | ||||
For properties other than DAV:authentication-id, it is | ||||
expected that implementations will treat the property names | ||||
and values as tokens, and convert these tokens into human- | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 18] | ||||
readable text in the user's language and character set when | ||||
displayed to a person. Only a generic WebDAV property display | ||||
utility would display these values in their raw form. | ||||
For error reporting, we follow the convention of HTTP/1.1 | ||||
status codes, including with each status code a short, English | ||||
description of the code (e.g., 200 (OK)). While the | ||||
possibility exists that a poorly crafted user agent would | ||||
display this message to a user, internationalized applications | ||||
will ignore this message, and display an appropriate message | ||||
in the user's language and character set. | ||||
Further internationalization considerations for this protocol | ||||
are described in the WebDAV Distributed Authoring protocol | ||||
specification [RFC2518]. | ||||
10 SECURITY CONSIDERATIONS | ||||
Applications and users of this access control protocol should | ||||
be aware of several security considerations, detailed below. | ||||
In addition to the discussion in this document, the security | ||||
considerations detailed in the HTTP/1.1 specification | ||||
[RFC2616], the WebDAV Distributed Authoring Protocol | ||||
specification [RFC2518], and the XML specification (discussed | ||||
in [RFC2376]) should be considered in a security analysis of | ||||
this protocol. | ||||
10.1 Increased Risk of Compromised Users | ||||
In the absence of a mechanism for remotely manipulating access | ||||
control specifications, if a single user's authentication | ||||
credentials are compromised, only those resources for which | ||||
the user has access permission can be read, modified, moved, | ||||
or deleted. With the introduction of this access control | ||||
protocol, if a single compromised user has the ability to | ||||
change ACLs for a broad range of other users (e.g., a super- | ||||
user), the number of resources that could be altered by a | ||||
single compromised user increases. This risk can be mitigated | ||||
by limiting the number of people who have write-acl privileges | ||||
across a broad range of resources. | ||||
10.2 Authentication-id Property and Dictionary Attacks | ||||
Every principal has a DAV:authentication-id property defined | ||||
on it, which provides the name used to authenticate this | ||||
principal, typically the username portion of a | ||||
username/password authentication scheme. An attacker can use | ||||
the information in this property when attempting either a | ||||
brute-force, or a dictionary attack to guess the principal's | ||||
identifying password. By providing the username in | ||||
DAV:authentication-id, the scope of an attack can be reduced | ||||
to a single, valid username. Furthermore, it is possible that | ||||
principals can potentially belong to a collection. In this | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 19] | ||||
case, it is possible to use the PROPFIND method to retrieve | ||||
the DAV:authentication-id property from all of the principals | ||||
in a collection, thus providing multiple usernames that can be | ||||
the focus of attack. | ||||
To reduce this risk, the DAV:authentication-id property should | ||||
not be world-readable. Which principals are granted default | ||||
read permission for DAV:authentication-id should be carefully | ||||
considered in any deployment of this protocol. | ||||
10.3 Risks of the read-acl Privilege | ||||
The ability to read the access permissions (stored in the | ||||
DAV:acl property), or the privileges permitted the currently | ||||
authenticated user (stored in the DAV:current-user-privilege- | ||||
set property) on a resource may seem innocuous, since reading | ||||
an ACL cannot possibly affect the resource's state. However, | ||||
if all resources have world-readable ACLs, it is possible to | ||||
perform an exhaustive search for those resources that have | ||||
inadvertently left themselves in a vulnerable state, such as | ||||
being world-writeable. Once found, this vulnerability can be | ||||
exploited by a denial of service attack in which the open | ||||
resource is repeatedly overwritten. Alternately, writeable | ||||
resources can be modified in undesirable ways. | ||||
To reduce this risk, read-acl privileges should not be granted | ||||
to unauthenticated principals, and restrictions on read-acl | ||||
privileges for authenticated principals should be carefully | ||||
analysed when deploying this protocol. | ||||
11 AUTHENTICATION | 11 AUTHENTICATION | |||
Authentication mechanisms defined in WebDAV will also apply to | Authentication mechanisms defined in WebDAV will also apply to | |||
WebDAV ACL. | WebDAV ACL. | |||
12 IANA CONSIDERATIONS | 12 IANA CONSIDERATIONS | |||
This document uses the namespace defined by [RFC2518] for XML | This document uses the namespace defined by [RFC2518] for XML | |||
elements. All other IANA considerations mentioned in [RFC2518] | elements. All other IANA considerations mentioned in | |||
also applicable to WebDAV ACL. | [RFC2518] also applicable to WebDAV ACL. | |||
13 INTELLECTUAL PROPERTY | 13 INTELLECTUAL PROPERTY | |||
The following notice is copied from RFC 2026, section 10.4, and | The following notice is copied from RFC 2026, section 10.4, | |||
describes the position of the IETF concerning intellectual | and describes the position of the IETF concerning intellectual | |||
property claims made against this document. | property claims made against this document. | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of | |||
intellectual property or other rights that might be claimed to | any intellectual property or other rights that might be | |||
pertain to the implementation or use other technology described | claimed to pertain to the implementation or use other | |||
in this document or the extent to which any license under such | technology described in this document or the extent to which | |||
rights might or might not be available; neither does it represent | any license under such rights might or might not be available; | |||
that it has made any effort to identify any such rights. | ||||
Information on the IETF's procedures with respect to rights in | Clemm, Hopkins, Sedlar, Whitehead [Page 20] | |||
standards-track and standards-related documentation can be found | neither does it represent that it has made any effort to | |||
in BCP-11. Copies of claims of rights made available for | identify any such rights. Information on the IETF's | |||
publication and any assurances of licenses to be made available, | procedures with respect to rights in standards-track and | |||
or the result of an attempt made to obtain a general license or | standards-related documentation can be found in BCP-11. | |||
permission for the use of such proprietary rights by implementers | Copies of claims of rights made available for publication and | |||
or users of this specification can be obtained from the IETF | 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. | Secretariat. | |||
The IETF invites any interested party to bring to its attention | The IETF invites any interested party to bring to its | |||
any copyrights, patents or patent applications, or other | attention any copyrights, patents or patent applications, or | |||
proprietary rights that may cover technology that may be required | other proprietary rights that may cover technology that may be | |||
to practice this standard. Please address the information to the | required to practice this standard. Please address the | |||
IETF Executive Director. | information to the IETF Executive Director. | |||
14 ACKNOWLEDGEMENTS | 14 ACKNOWLEDGEMENTS | |||
This protocol is the collaborative product of the WebDAV ACL | This protocol is the collaborative product of the WebDAV ACL | |||
design team: xxx, yyy, zzz. We would like to acknowledge the | design team: Bernard Chester, Geoff Clemm (Rational), Anne | |||
foundation laid for us by the authors of the WebDAV and HTTP | Hopkins (Microsoft), Barry Lind (Xythos), Sean Lyndersay | |||
protocols upon which this protocol is layered, and the invaluable | (Microsoft), Eric Sedlar (Oracle), Greg Stein (Apache.org), | |||
feedback from the WebDAV working group. | and Jim Whitehead (UC Santa Cruz). Prior work on WebDAV access | |||
control protocols has been performed by Yaron Goland, Paul | ||||
15 INDEX | Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. 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. | ||||
To be supplied. | 15 REFERENCES | |||
16 REFERENCES | 15.1 Normative 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 | [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate | |||
Requirement Levels", Harvard, 1997, | Requirement Levels." RFC 2119, BCP 14, Harvard, March, 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>. | ||||
17 AUTHORS' ADDRESSES | [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, | |||
"Extensible Markup Language (XML)." World Wide Web Consortium | ||||
Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml- | ||||
19980210.[RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. | ||||
Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext | ||||
Transfer Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq, | ||||
Xerox, Microsoft, MIT/LCS, June, 1999. | ||||
[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. | ||||
Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP | ||||
Authentication: Basic and Digest Access Authentication. " RFC | ||||
2617. Northwestern University, Verisign, AbiSource, Agranat, | ||||
Microsoft, Netscape, Open Market, June, 1999. | ||||
Clemm, Hopkins, Sedlar, Whitehead [Page 21] | ||||
[RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D. | ||||
Jensen, "HTTP Extensions for Distributed Authoring _ WEBDAV." | ||||
RFC 2518. Microsoft, U.C.Irvine, Netscape, Novell, February, | ||||
1999. | ||||
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode | ||||
and ISO 10646." RFC 2279. Alis Technologies. January, 1998. | ||||
15.2 Informational References | ||||
[RFC2026] S.Bradner, "The Internet Standards Process _ | ||||
Revision 3." RFC 2026, BCP 9. Harvard, October, 1996. | ||||
[RFC2396] E. Whitehead, M. Murata, "XML Media Types." RFC | ||||
2376. U.C. Irvine, Fuji Xerox Info. Systems. July, 1998. (This | ||||
RFC will soon be superseded by <draft-murata-xml-09.txt>, | ||||
which has been approved by the IESG as a Proposed Standard, | ||||
but not yet issued as an RFC.) | ||||
16 AUTHORS' ADDRESSES | ||||
Geoffrey Clemm | Geoffrey Clemm | |||
Rational Software | Rational Software | |||
20 Maguire Road | 20 Maguire Road | |||
Lexington, MA | Lexington, MA 02421 | |||
Email: geoffrey.clemm@rational.com | Email: geoffrey.clemm@rational.com | |||
Anne Hopkins | Anne Hopkins | |||
Microsoft Corporation | Microsoft Corporation | |||
One Microsoft Way | One Microsoft Way | |||
Redmond, WA | Redmond, WA 98052 | |||
Email: annehop@microsoft.com | Email: annehop@microsoft.com | |||
Eric Sedlar | Eric Sedlar | |||
Oracle Corporation | Oracle Corporation | |||
500 Oracle Parkway | 500 Oracle Parkway | |||
Redwood Shores, CA 94065 | Redwood Shores, CA 94065 | |||
Email: esedlar@us.oracle.com | Email: esedlar@us.oracle.com | |||
18 STILL TO DO : | Jim Whitehead | |||
U.C. Santa Cruz | ||||
. Describe the interactions with resource locking. I'm not | Dept. of Computer Science | |||
clear what the resolution was as far as locking the ACL | Baskin Engineering | |||
separately from locking the resource. | 1156 High Street | |||
Santa Cruz, CA 95064 | ||||
. Add a section defining new error codes/messages? Or should we | Email: ejw@cse.ucsc.edu | |||
make a pass through the doc and ensure all possible error | ||||
conditions are mapped to existing errors? | ||||
. Articulate that the required DAV:principal property should be | ||||
able to be used for equality checks. Equality checks were | ||||
mentioned as one reason why this property should be mandatory, | ||||
even if the URI is fake. | ||||
. Update "Setting Access Control Information" and to address | ||||
whether read-only (ie, inherited) ACEs should be stripped out | ||||
by the client prior to PROPPATCH. Fix, if necessary, comments | ||||
on editing inherited ACEs in ACL Inheritance section. | ||||
. Renaming DAV:rights to DAV:effectiverights? and update sample | ||||
. Revisit description of Property ACEs to reflect group | 17 STILL TO DO | |||
agreement. Add sample code. Anne will need to update | ||||
Semantics descriptions to address property ACEs. | ||||
. Update the self, ownergroup stuff according to eventual | * If we can add more elements to DAV:resourcetype, we can | |||
agreements. | eliminate DAV:is-principal. | |||
. Make document consistent: | Clemm, Hopkins, Sedlar, Whitehead [Page 22] | |||
* Add back the XML schema if provides info not in the DTD's. | ||||
o Ensure all property descriptions indicate whether the | * Consider adding a DAV:matching-principals, which identifies | |||
property is: | all ACL principals that match the current user. | |||
. "live" or "dead" | * Add DAV:ordering-constraints, DAV:required-principals, and | |||
. read-only or writable | DAV:ace-combination-semantics as sub-elements of DAV:acl- | |||
. REQUIRED or OPTIONAL | semantics. | |||
o Ensure sample XML exists for all new properties, tags, | ||||
etc. | ||||
o Complete empty sections, like Scalability | ||||
19 OPEN ISSUES: | ||||
Issue Description Status | Clemm, Hopkins, Sedlar, Whitehead [Page 23] | |||
1. Aggregate a right, if granted, that Now addressed in | ||||
rights grants access to a set of spec. | ||||
subsidiary rights | ||||
2. Rights How do we find out what Now addressed in | ||||
discovery rights are applicable to a spec. | ||||
given resource? Can this be | ||||
done by resource type, to | ||||
avoid the need to ask each | ||||
resource this question? | ||||
3. Defined Should we define a 'group' Collection | ||||
list of principal type which principals will | ||||
"principal- specifically requires that have semantic | ||||
types" principal membership be meaning (recursive | ||||
recursive? This might make membership applies) | ||||
administrative client | ||||
implementation easier. | ||||
Should this be a | ||||
recommendation rather than a | ||||
requirement? | ||||
4. Reserved Is the list of 'reserved' Discussed in 4/28 | ||||
principals principals complete ( conference call. | ||||
'owner', 'all', or Still Open. | ||||
'unauthenticated', 'all- | ||||
authenticated', etc.) | ||||
5. Standard Is the list of standard Discussed on | ||||
rights rights complete? conference call and | ||||
updated once in | ||||
draft. | ||||
6. XML Do we need to scope the Use DAV namespace, | ||||
namespace namespace of our XML like other working | ||||
for ACL elements via <?namespace groups. Closed. | ||||
href = | ||||
"http://www.ietf.org/standar | ||||
ds/acl/ AS = "A"?>, or can | ||||
we use the regular DAV | ||||
namespace (shared by both | ||||
versioning and RFC 2518)? | ||||
7. Rights What is the method for Not a method. | ||||
discovery figuring out the list of DAV:Access-Rights | ||||
rights? property available. | ||||
Closed. | ||||
8. Multiple Are we sure we don't want to Requires an | ||||
principals/A allow multiple explicit vote | ||||
CE [CKNIGHT] principals/ACE? | ||||
9. Grant & Are we sure we don't want to Added to spec. | ||||
Deny allow grant & deny in the Decision reversed | ||||
[CKNIGHT] same ACE? Note that this per 6/23 call and | ||||
simplifies the ACE rule to added to spec 01.3. | ||||
disallow two ACEs for the Closed. | ||||
same principal. | ||||
10. Semantic Do we need to specify stuff Yes. Added to | ||||
meaning of like whether or not spec. | ||||
principal collection principal | ||||
colls. membership is recursive? | ||||
[GCLEMM] | ||||
11. principa The semantic meaning of Added to spec=97 | ||||
l-name vs. principal-name should be principal-name | ||||
display-name defined, or display-name holds | ||||
[GCLEMM] should be used "authentication" | ||||
string and | ||||
displayname holds | ||||
readable string | ||||
12. ChangeOw Can servers disallow PROPPATCH support | ||||
ner [GCLEMM/ changing the owner? for owner is | ||||
CKNIGHT] optional in the | ||||
spec. | ||||
13. Local What text is needed Open | ||||
principal regarding principal URLs | ||||
URLs without hostname:port | ||||
14. ACL as To what extent should ACLs ACLs are | ||||
properties be treated as properties? properties. Closed. | ||||
15. Semantic Would it be more appropriate Open | ||||
s Model to identify these semantic | ||||
names models by their | ||||
[ANNEHOP] implementation names, ie, | ||||
UNIX, NT Canonical? Could | ||||
be easier for developers and | ||||
users. Neither of these | ||||
models is likely to be re- | ||||
used by another | ||||
implementation. | ||||
16. Addition Do we need to include Open | ||||
al Semantics additional ACL semantics | ||||
models models? What other systems | ||||
[ANNEHOP] (.htaccess?) do we need to | ||||
support? | ||||
17. Detectin How are WebDAV Access Open | ||||
g a WebDAV Control compliant servers | ||||
Access detected? Define acl | ||||
Control extension for the DAV: | ||||
server header? | ||||
[SEANLYND] | ||||
18. DAV:user If we're going to be Open | ||||
/group or treating users as resources, | ||||
DAV:resource then we should go all the | ||||
/collection way. | ||||
[SEANLYND] | ||||
19. Per- ability to specify rights on Open | ||||
property a per-property basis could | ||||
ACEs be very useful for webdav. | ||||
[ANNEHOP] consider adding an optional | ||||
propertytype-id to the ace? | ||||
20. Register Need to describe process for Open | ||||
ing registering a new ACL | ||||
Semantics semantics model option. | ||||
Models | ||||
[ANNEHOP] | ||||
21. Strip Should the client strip all Agreed to strip | ||||
Inherited Inherited (read-only) ACEs inherited ACEs in | ||||
ACEs? prior to setting an ACL? Do 6/23 call. Anne | ||||
[ANNEHOP] we need a flag that re-opening issue. | ||||
indicates whether the server | ||||
accepts a client update of | ||||
inherited ACEs (to support | ||||
client-side propagation of | ||||
inheritance)? And/or a flag | ||||
to indicate that the client | ||||
WANTs to set inherited ACEs? | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |