INTERNET-DRAFT P. J. Leach
Expires: March 1998 Y. Y. Goland
Standards Track Microsoft Corporation
WebDAV Working Group October 18, 1997
WebDAV ACL Protocol
draft-ietf-webdav-acl-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This memo specifies the format and manipulation mechanisms for
access control lists (ACLs) for WebDAV objects.
Contents
Status of this Memo................................................1
Abstract...........................................................1
Contents...........................................................1
1. Introduction....................................................2
2. Granting and Denying Rights.....................................2
3. ACL Inheritance.................................................4
4. Properties and ACLs.............................................4
5. Owner Property..................................................4
6. AclInheritance Property.........................................5
7. Rights Definitions..............................................5
8. ACL Property....................................................7
9. Default Principal Types.........................................8
10.Examples........................................................8
11.Authors' Addresses.............................................12
12.Bibliography...................................................12
Leach and Goland [Page 1]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
1. Introduction
The basic model for access control, informally expressed, is that
who you are determines how you can access a resource. The "who you
are" is defined by a "principal name"; users, client software, and
servers have principal names. The "how" is determined by an "access
control list" (ACL) associated with a resource.
An ACL contains Access Control Elements (ACE). An ACE specifies a
set of principals, a set of granted rights, and a set of denied
rights.
Rights may be generic, such as "read", "write", or "delete", or they
might be specific to the kind of resource protected by that ACL,
such as (perhaps) "send-to", "unsubscribe", and "administer" for
mailing lists.
When a resource is created it inherits a set of default ACL
properties from a designated resource, referred to as an ACL source.
The inheritance can be "static", so that subsequent changes to the
ACL source do not effect the new resources ACL properties; or it can
be "dynamic", so that subsequent changes are reflected in the new
resource's ACL properties.
Properties on a resource have, by default, the same ACL as the
resource. However individual properties can be given their own ACLs.
The ACL property on the resource also contains information regarding
the ACLs of any properties on the resource, if those ACLs are
different from the resource's.
[Ed Note. This draft deserves the name "rough draft". It is being
released for consideration of the ACL model it proposes. The
intention is to replace the property based model defined herein with
an ACL method. The reasoning being that it is a bad design decision
to define any mechanism based on "side-effects." In this case, by
setting the ACL property to a certain value the ACL on the resource
gets set to the same value. The new ACL method based version should
be out in a week or two.]
2. Granting and Denying Rights
An ACL can both grant and deny rights. The reason both types of
grants are required is because of compound principals. A compound
principal is a principal that represents a number of other
principals. For example, a user group in UNIX.
The consequence of the existence of compound principals is that
there are times when a compound principal may be granted a right but
a particular member of the compound principal may need to be denied
access. In order to make this possible an ACL must be able to list
principals both allowed and denied a right.
Leach and Goland [Page 2]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
By default all rights for a principal MUST be denied. Rights MAY
only be granted to a principal by an explicit listing of that
principal in a "grant" section of an ACL.
Additionally it is possible for access rights to collide in scope.
For example, a container may have an access right which specifies
the ability of principals to delete the children of that container.
This would effect a principal's ability to use the DELETE method.
However a particular internal child may have granted access rights
to DELETE. As such, the two rights could collide.
The following rules, processed in order, MUST be used to resolve
scope conflicts between rights.
1) In a conflict between a right granted by a parent and a right
granted by a child, the right specified by the child MUST override.
2) In a conflict between a right granted or denied to a compound
principal and a right granted or denied to a member of the compound
principal, the reference to the member of the compound principal
MUST override.
Note that rule 2 is conceptually identical to rule 1. The concept
represented by rules 1 and 2, stated generally, is that a specific
references always overrides a more general reference.
2.1. Examples
The following examples demonstrate a situation where the specified
conflict resolution rule would be applied.
2.1.1. Rule 1
A resource specifies that principal A is granted the right the
resource. A property on the resource specifies that principal A is
denied the right to delete the property. The conflict is resolved by
rule 1, the resource is the parent and the property is the child. As
such the child's declaration overrides and principal A is denied the
right to delete the resource.
Note, however, that if other properties do not deny principal A the
right to delete them then principal A could delete all properties
but the one mentioned above and could PUT an empty body to the
resource. However it could not successfully execute a DELETE on the
resource, as this would have the effect of deleting the property
along with the resource.
Leach and Goland [Page 3]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
2.1.2. Rule 2
A resource specifies that principal A is denied the read right. The
same resource also specifies that principal B is granted the read
right. Principal B is a member of principal A. Rule 1 does not apply
because the rights in question are defined on the same resource. The
conflict is resolved by rule 2 as the conflict is between a compound
principal and one of its members. In that case principal B has the
right to read the resource.
3. ACL Inheritance
When a new resource is created it may inherit its ACL from its
containing resource. This inherited ACL MUST be applied to the
resource before it is available for manipulation. Thus the resource
will never be in a state where it does not have access control
protection.
Inheritance can either be static or dynamic.
Static inheritance means that the ACL specified by the parent will
be used to define the ACL for the child. Any subsequent changes made
to the parent will not cause the child's ACL to be altered.
Dynamic inheritance means that the ACL specified by the parent is
used to define the ACL for the child but any changes on the parent's
ACL MUST automatically be made to any inheriting children. The child
is still allowed to define its own ACL values that MUST override any
conflicting inherited ACL.
4. Properties and ACLs
Properties MAY have their own ACL independent of the associated
resource. By default a property's ACL MUST be dynamically inherited
from the associated resource.
For purposes of applying scoping conflict resolution rules the
resource is the parent and the property is the child.
Compliant resources are not required to support setting ACLs
directly on properties.
5. Owner Property
Name: owner
Namespace: http://www.ietf.org/standards/acl/
Purpose: Specifies the owner of the resource.
Values= Principal
Description: The owner property specifies the principal who owns
the resource. The default value for this property is the principal
who created the resource. The owner always retains the right to
alter the ACL. So, for example, an owner who was not granted the
Leach and Goland [Page 4]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
right to read the resource could not read the resource. However the
owner could alter the ACL so as to grant the read right to himself.
A principal MUST have the writeowner right to change the owner
property's value. All compliant resources MUST support the owner
property.
6. AclInheritance Property
Name: aclinheritance
Namespace: http://www.ietf.org/standards/acl/
Purpose: The aclinheritance property identifies the type of
inheritance to be used with children of this resource. This property
has no meaning on non-collections. However, collections MUST provide
this property.
Values= ("Dynamic" | "Static" | "None" | RFCToken | URL)
;RFCToken is defined, somewhere in DAV. URL is defined, someplace,
somewhere.
7. Rights Definitions
The following define different types of rights. A compliant resource
MUST support all of the following right.
7.1. All Right
Name: all
Namespace: http://www.ietf.org/standards/acl/
Purpose: The all right provides all rights and overrides all
other rights.
Values: None
7.2. Read Right
Name: read
Namespace: http://www.ietf.org/standards/acl/
Purpose: The read right provides and restricts access to
information regarding the state of the resource, including the
resource's properties. Effected methods are GET, INDEX, and
PROPFIND. OPTIONS is not covered by a Read ACL as it reflects
capabilities more than state.
Values: None
7.3. Write Right
Name: write
Namespace: http://www.ietf.org/standards/acl/
Purpose: The Write right has the exact same behavior as the
Write Lock. Please refer to [WEBDAV] section 5.3 for details.
Values: None
Leach and Goland [Page 5]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
7.4. Delete Right
Name: delete
Namespace: http://www.ietf.org/standards/acl/
Purpose: The delete right controls access to the DELETE
method. This method does not effect the ability to remove
properties.
Values: None
7.5. CreateChild Right
Name: createchild
Namespace: http://www.ietf.org/standards/acl/
Purpose: This right controls the ability to PUT internal
members of a collection and ADDREF external members of a collection.
This ACL has no effect if set on non-collections.
Values: None
7.6. DeleteChild Right
Name: deletechild
Namespace: http://www.ietf.org/standards/acl/
Purpose: The deletechild right controls the ability to the
DELETE internal members of a collection and DELREF external members
of a collection. This ACL has no effect if set on non-collections.
Values: None
7.7. WriteOwner Right
Name: writeowner
Namespace: http://www.ietf.org/standards/acl/
Purpose: The writeowner right controls the ability to change
the value of the owner right.
Values: None
7.8. ReadACL Right
Name: readacl
Namespace: http://www.ietf.org/standards/acl/
Purpose: The readacl right controls the ability to read the
ACL property.
Values: None
7.9. WriteACL Right
Name: writeacl
Namespace: http://www.ietf.org/standards/acl/
Purpose: The writeacl right controls the ability to alter
the ACL property.
Values: None
Leach and Goland [Page 6]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
8. ACL Property
The ACL property defines the ACL for the resource and can provide
information about ACLs on properties. ACL information for properties
MUST NOT be included in the ACL property value if the resource only
supports dynamic inheritance for properties.
By its very nature the ACL property is a live property. As such its
value may be changed by the server without first having been
instructed to do so by a client.
8.1. ACL Property Definition
Name: acl
Namespace: http://www.ietf.org/standards/acl/
Purpose: Defines the ACL for a resource and its properties.
Values= (Dynamic | *ACE *Property)
8.2. Principal XML Element
Name: principal
Namespace: http://www.ietf.org/standards/acl/
Purpose: To identify a principal.
Values= *cdata
8.3. Dynamic XML Element
Name: dynamic
Namespace: http://www.ietf.org/standards/acl/
Purpose: Specifies that the ACL for this resource is
dynamically inherited from the resource's container.
Values: None
8.4. ACE XML Element
Name: ace
Namespace: http://www.ietf.org/standards/acl/
Purpose: Contains access right information for a single
principal.
Values= 1*Principal Allow Deny
8.5. Grant XML Element
Name: grant
Namespace: http://www.ietf.org/standards/acl/
Purpose: Identifies the rights the associated principal is
granted.
Parent: ACE
Values: Right Identifiers
Leach and Goland [Page 7]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
8.6. Deny XML Element
Name: deny
Namespace: http://www.ietf.org/standards/acl/
Purpose: Identifies the rights the associated principal is
denied.
Parent: ACE
Values: Right Identifiers
8.7. Property XML Element
Name: property
Namespace: http://www.ietf.org/standards/acl/
Purpose: Provides ACEs for properties.
Parent: ACL
Values= Prop *ACE
Description: The properties in the Prop XML element MUST be
empty.
9. Default Principal Types
The following two XML elements are defined principal types.
9.1. AllPrincipals XML Element
Name: allprincipals
Namespace: http://www.ietf.org/standards/acl/
Purpose: The allprincipals XML element represents all
principals. It is used to specify rights belonging to all
principals, regardless of authentication.
Values: None
9.2. AllAuthPrincipals XML Element
Name: allauthprincipals
Namespace: http://www.ietf.org/standards/acl/
Purpose: The allauthprincipals XML element represents all
authenticated principals. It is used to specify rights belonging to
all authenticated principals.
Values: None
10. Examples
10.1. Example 1 - Retrieving an ACL
PROPFIND /top/container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "D"/>
Leach and Goland [Page 8]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
<?XML:Namespace href = "http://www.ietf.org/standards/acl/" AS =
"A"/>
<D:PROPFIND>
<prop>
<A:ACL/>
</prop>
</D:PROPFIND>
HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace href = "http://www.ietf.org/standards/acl/" AS =
"A"/>
<D:MultiResponse>
<Response>
<Prop>
<A:acl>
<ace>
<principal><allprincipals/></principal>
<grant><read/></grant>
<deny/>
</ace>
<principal>domain/joebob</principal>
<grant/>
<deny><all/></deny>
<ace>
<principal>domain/superuser</principal>
<grant><all/></grant>
<deny/>
</ace>
<properties>
<D:prop><source/><A:owner/></D:prop>
<ace>
<principal>some sort</principal>
<grant/>
<deny/><all/></deny>
</ace>
</properties>
</A:acl>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
</D:MultiResponse>
The ACL on this property specifies that all principals, regardless
of authentication, have read access to this resource except for the
principal domain/joebob. The principal domain/superuser is granted
all rights. The principal "some sort" is denied any rights to the
Leach and Goland [Page 9]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
source and owner properties, although rights to the resource as a
whole and to other properties are still granted.
10.2. Example 2 - Retrieving an Inherited ACL
PROPFIND /top/container/file/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace href = "http://www.ietf.org/standards/acl/" AS =
"A"/>
<D:PROPFIND>
<prop>
<A:ACL/>
</prop>
</D:PROPFIND>
HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace href = "http://www.ietf.org/standards/acl/" AS =
"A"/>
<D:MultiResponse>
<Response>
<Prop>
<A:acl><dynamic/></A:acl>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
</D:MultiResponse>
This resource dynamically inherits its ACL from /top/container/
which is specified in Example 1.
Leach and Goland [Page 10]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
10.3. Example 3 - Setting ACLs
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx
<?XML:Namespace href = "http://www.ietf.org/standards/dav/" AS =
"D"/>
<?XML:Namespace href = "http://www.ietf.org/standards/acl/ AS =
"A"/>
<?XML:Namespace href = "http://www.someorg.com/std/names/ AS = "X"/>
<D:PropertyUpdate>
<Create>
<prop>
<A:acl>
<ace>
<principal><allprincipals/></principal>
<grant><all/></grant>
<deny/>
</ace>
<properties>
<D:prop><A:owner/></D:prop>
<ace>
<principal><allprincipals></principal>
<grant/>
<deny><all/></deny>
</ace>
<ace>
<principal><X:superuser/></principal>
<principal>someotheruser</principal>
<grant><all/></grant>
<deny/>
</properties>
</A:acl>
</prop>
</Create>
</D:PropertyUpdate>
HTTP/1.1 207 Multiresponse
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace href="http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace href="http://www.ietf.org/standards/acl/" AS = "A"/>
<D:MultiResponse>
<Response>
<Prop><A:acl/></Prop>
<Status>HTTP/1.1 405 Conflict</Status>
</Response>
</D:MultiResponse>
Leach and Goland [Page 11]
INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997
The request would grant all rights to modify this resource to
everyone, with the exception of all rights to the owner property.
The principals superuser and someotheruser, however, are granted all
rights to the owner property. The result is that the only principals
that can modify the owner property are the superuser and
someotheruser.
The attempt to set the ACL failed due to a conflict. What conflict,
on what, can not be specified.
11. Authors' Addresses
Paul J. Leach
Yaron Y. Goland
Microsoft
1 Microsoft Way
Redmond, WA 98052
Phone: (425)936-4765
Email: {paulle, yarong}@microsoft.com
12. Bibliography
[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-
Lee, 'Hypertext Transfer Protocol -- HTTP/1.1', RFC 2068, January
1997, <URL:ftp://ds.internic.net/rfc/rfc2068.txt>
[WebDAV] Y. Goland, E. J. Whitehead, Jr., Asad Faizi, Stephen R.
Carter, Del Jensen 'Extensions for Distributed Authoring and
Versioning on the World Wide Web -- WEBDAV', March 1997,
<URL:http://ds.internic.net/internet-drafts/draft-jensen-webdav-
ext-01.txt>
[XML] W3C, 'Extensible Markup Language - Part1. Syntax', March 1997
<URL:http://www.w3.org/pub/WWW/TR/WD-xml-lang.html>
Leach and Goland [Page 12]