--- 1/draft-ietf-webdav-acl-01.txt 2006-02-05 02:10:04.000000000 +0100 +++ 2/draft-ietf-webdav-acl-02.txt 2006-02-05 02:10:04.000000000 +0100 @@ -1,96 +1,99 @@ - INTERNET-DRAFT Eric Sedlar, Oracle Corporation - draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software + INTERNET-DRAFT Geoffrey Clemm, Rational Software + draft-ietf-webdav-acl-02 Anne Hopkins, Microsoft Corporation + Eric Sedlar, Oracle Corporation - Expires November 1, 2000 May 1, 2000 + Expires January 14, 2001 July 14, 2000 Access Control Extensions to WebDAV Status of this Memo - This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. - Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract - This document specifies a set of methods, headers, and resource-types that define the WebDAV Access Control extensions to the HTTP/1.1 protocol. - Sedlar, Clemm [Page 1] Table of Contents 1 INTRODUCTION............................................3 1.1 Notational Conventions................................3 2 PRINCIPALS..............................................3 3 RIGHTS..................................................4 - 3.1 RIGHTS-DISCOVERY method...............................5 + 3.1 DAV:access-rights property............................5 3.2 Rights defined by WebDAV..............................6 3.2.1 read Right........................................6 - 3.2.2 write Right.......................................6 - 3.2.3 readacl Right.....................................6 - 3.2.4 writeacl Right....................................6 - 3.2.5 all Right.........................................6 + 3.2.2 write Right.......................................7 + 3.2.3 readacl Right.....................................7 + 3.2.4 writeacl Right....................................7 + 3.2.5 all Right.........................................7 4 ACCESS CONTROL PROPERTIES...............................7 - 4.1 Example 1 - Retrieving Access Control information.....8 - - 5 USING ACLS..............................................9 + 4.1 Retrieving Access Control Information................11 + 4.1.1 Example: Retrieving Access Control information...11 + 4.2 Setting Access Control Information...................12 + 4.2.1 Example: Setting Access Control information......13 - 6 ACL METHOD.............................................10 - 6.1 Example 1 - Setting ACLs.............................10 + 5 USING ACLS.............................................14 + 5.1 System Controlled Rights.............................14 + 5.2 Special Principal Identifiers........................15 + 5.3 ACL Semantics Options................................15 + 5.3.1 FirstSpecific....................................16 + 5.3.2 ExplicitDenyPrecedence...........................16 - 7 ACL INHERITANCE / DEFAULT ACLS.........................11 + 6 ACL INHERITANCE........................................18 + 6.1 Inheritable ACEs.....................................18 + 6.2 Propagate ACE but do not use for Access Check on this resource....19 + 6.3 Propagate to immediate children only.................19 + 6.4 Protect ACL from inheritance.........................19 - 8 XML SCHEMA FOR DEFINED ELEMENTS........................12 + 7 XML SCHEMA FOR DEFINED ELEMENTS........................20 - 9 INTERNATIONALIZATION CONSIDERATIONS....................13 + 8 INTERNATIONALIZATION CONSIDERATIONS....................21 - 10 SECURITY CONSIDERATIONS..............................13 + 9 SECURITY CONSIDERATIONS................................21 - 11 SCALABILITY..........................................13 + 10 SCALABILITY..........................................21 - 12 AUTHENTICATION.......................................13 + 11 AUTHENTICATION.......................................21 - 13 IANA CONSIDERATIONS..................................13 + 12 IANA CONSIDERATIONS..................................21 - 14 INTELLECTUAL PROPERTY................................13 + 13 INTELLECTUAL PROPERTY................................21 - 15 ACKNOWLEDGEMENTS.....................................14 + 14 ACKNOWLEDGEMENTS.....................................22 - 16 INDEX................................................14 + 15 INDEX................................................22 + 16 REFERENCES...........................................22 - 17 REFERENCES...........................................14 + 17 AUTHORS' ADDRESSES...................................23 - 18 AUTHORS' ADDRESSES...................................15 + 18 STILL TO DO :........................................23 - 19 STILL TO DO :........................................15 + 19 OPEN ISSUES:.........................................25 - Sedlar, Clemm [Page 2] 1 INTRODUCTION The underlying principle of access control is that who you are determines how you can access a resource. The "who you are" is defined by a "principal" identifier; users, client software, servers, and groups of the previous have principal identifiers. The "how" is determined by an "access control list" (ACL) associated with a resource. An ACL contains a set of "access control entries" (ACEs), where each ACE specifies a principal and a set of rights that are either granted or denied to that @@ -110,567 +112,930 @@ 2 PRINCIPALS A principal identifies an entity that can be given access rights to HTTP resources. On many implementations, a user or a group will be examples of principals, but other types of principals are possible. For the most part, any classification or other information about the entity identified by a principal is opaque with respect to this specification, and is dependent on the implementation. - Principals are manifested to clients as a HTTP resource, identified by a URL. The set of properties exposed by that resource are implementation dependent, although certain properties are required by this specification. Those properties include: + . DAV:principalname: A 'live' property containing the name + used to authenticate this principal (typically typed into a + login prompt/dialog). [OPTIONAL] + . DAV:displayname: A property containing a human-readable + description of this principal. This property may be "live" + and not settable via PROPPATCH. [REQUIRED] - @ : A "live" property containing the - name used to authenticate this principal - (typically typed into a login prompt/dialog). - [OPTIONAL] - - @ : A property containing a human-readable - description of this principal. This property - may be "live" and not settable via PROPPATCH. - [REQUIRED] - - @ : A "live" property containing a - classification word for this principal. The - values and are - choices for value of this property - recommended by this spec. The presence of - - Sedlar, Clemm [Page 3] - this property can be used to distinguish it - as a principal from other resources on a - WebDAV server. (Note that - may not be used, as all collections must use - the value "collection" for , - which wouldn't distinguish normal collections - from principal collections.) [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 information for a principal via properties. - A principal resource may or may not be a collection. A collection principal may only contain other principals (not other types of resources). Servers that support aggregation of principals (e.g. groups of users or other groups) MUST manifest them as collection principals. The WebDAV methods for examining - maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used - to maintain collection principals. Membership in a collection - principal is recusive, so a principal in a collection principal A - contained by collection principal B is a member of both + maintaining collections (e.g. DELETE, PROPFIND) may be used to + maintain collection principals. Membership in a collection + principal is recursive, so a principal in a collection principal + A contained by collection principal B is a member of both collection principals. Implementations not supporting recursive membership in principal collections can return an error if the client attempts to bind collection principals into other collection principals. Using WebDAV methods to alter the content of a principal (e.g. using PROPPATCH or PUT) is outside the scope of this specification, and is not required, recommended, or forbidden by this spec. 3 RIGHTS A right controls access to a particular set of HTTP operations on a resource. The set of rights that apply to a particular - resource may vary with the of the resource, as + resource may vary with the DAV:resourcetype of the resource, as well as between different server implementations. To promote interoperability, however, WebDAV defines a set of well-known - rights (e.g. and ), which can at least be - used to set some context to the other rights defined on a - particular resource. - + rights (e.g. DAV:read and DAV:write), which can at least be used + to set some context to the other rights defined on a particular + resource. Rights may be aggregates of other rights. For example, one implementation may split out a right controlling the ability to - BIND children into a collection from the right allowing a - resource to be removed from a collection. Since these rights - control the ability to write to a collection, these rights would - be aggregated by the right. The relationships - between atomic rights and aggregate rights can be discovered via - the RIGHTS-DISCOVERY HTTP method on a particular resource. - Servers may specify some rights as abstract, which means that it - may not appear in an ACL, but is described in the RIGHTS- - DISCOVERY method to aid in setting context. Server - implementations must return the same response to the RIGHTS- - DISCOVERY method on all of the resources with the same - value. + 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. - Sedlar, Clemm [Page 4] - 3.1 RIGHTS-DISCOVERY method + 3.1 DAV:access-rights property - Rights discovery is a method with no arguments, that returns the - rights aggregation tree. Each right appears as an XML element, + The DAV:access-rights property is a live property that contains + the rights aggregation tree. The DAV:access-rights property MUST + be available on every resource available via a WebDAV Access + Control-compliant server. Each right appears as an XML element, where aggregate rights list all of their children as sub- elements. Each right element can contain the following attributes: + . abstract (Boolean): 'true' if this right MUST NOT be used in + an ACL/ACE. Defaults to 'false.' Note: an abstract right need + not be an aggregate right. - @ abstract (Boolean): "true" if this right cannot be used in - an ACL/ACE. Defaults to "false" - - @ description (string): a human readable description of what - this right controls access to. Required. + . Description (string): a human-readable description of what + this right controls access to. [REQUIRED]. The server MAY + localize this description, based on the Accept-Language header + of the request. For example, the following response might be generated to a - RIGHTS-DISCOVERY request on a WebDAV server implemented by a - relational database (where the resource in this case corresponds - to a table): - + request on a WebDAV server. Request - RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1 + PROPFIND /file HTTP/1.1 Host: www.foo.bar Content-type: text/xml; charset="utf-8" - Content-Length: 0 + Accept-Language: en-us + Depth: 0 + Content-Length: xxx + + + + + + + Response - HTTP/1.1 200 Success + HTTP/1.1 207 Multi-Status Content-Type: text/xml - Content-Length: xxxxx + Content-Length: xxx - - + + - - - - - - - - - + http://www.foo.bar/file + + HTTP/1.1 200 OK + + + + + + + + + + + + + + + It is envisioned that a WebDAV ACL-aware administrative client - would list the available in a dialog box, and allow the user to - choose non-abstract rights to apply in an ACE. The rights tree - is useful programmatically to map well-known rights (defined by - WebDAV or other standards groups) into rights that are supported - by any particular server implementation. + would list the available rights in a dialog box, and allow the + user to choose non-abstract rights to apply in an ACE. The + rights tree is useful programmatically to map well-known rights + (defined by WebDAV or other standards groups) into rights that + are supported by any particular server implementation. - Sedlar, Clemm [Page 5] 3.2 Rights defined by WebDAV The rights defined by WebDAV access control MUST be present in - the response to the RIGHTS-DISCOVERY method, although they may be - abstract (and not usable within an ACE on a particular - implementation). + 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 - Name: - + Name: DAV:read Purpose: The read right provides and restricts access to information regarding the state of the resource, including the resource's properties. Affected methods include GET and PROPFIND. The read right does not affect the OPTIONS method since it reflects capabilities rather than state. 3.2.2write Right - Name: - - Purpose: The 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. + Name: DAV:write + Purpose: The write right affects the same methods as the + Write Lock. Please refer to [WEBDAV] section 5.3 for the list of + affected methods. Note however, that a write lock is a different + mechanism than a write access change, although they affect the + same methods, they have independent methods to set them and + independent error codes. 3.2.3readacl Right - Name: - - Purpose: The right provides and restricts - access to the property of this resource, rather than - the right. If a user has the right and not - the right, the property ONLY is accessible via - PROPFIND, and the GET method is not authorized. If a user has - the right and not the right, the - property will not be included in any PROPFIND requests on the - associated resource. + Name: DAV:readacl + Purpose: The readacl right provides and restricts access + to the DAV:acl property of this resource, rather than the + DAV:read right. If a user has the readacl right and not the read + right, the DAV:acl 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 - Name: - - Purpose: The (Access Control ADMINistration) - right provides and restricts access to ACL method, which is the - only means of altering the (and indirectly, - ) property of a resource. + Name: DAV:writeacl + Purpose: The writeacl right provides and restricts access + to the DAV:acl and DAV:owner properties. 3.2.5all Right - Name: - - Sedlar, Clemm [Page 6] - Purpose: The right controls all other rights on - this resource. If the right appears in an ACE, it is - an error to have any other right in that ACE. This right is - merely shorthand for all of the rights enumerated in the RIGHTS- - DISCOVERY method, and should not control access to rights not - exposed via that route. + Name: DAV:all + 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 This specification defines a number of new properties for WebDAV - resources. Access control properties may be retrieved just like - other WebDAV properties, using the PROPFIND method. An HTTP - resource on a WebDAV ACL-compliant server MUST contain the - following properties: + resources. Access control properties may be set and retrieved + just like other WebDAV properties, using the PROPFIND and + 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. - @ : A property containing the principal - information identifying a particular user as - the owner of the resource. This property is - readable by anyone with read access to the - resource. There is no provision for a client - updating this property in this spec, however - it is recommended that any authenticated user - with appropriate administrative privileges be - allowed to issue a PROPPATCH to update its - value. Normally, an attempt to PROPPATCH this - property will result in a 401 (Not - Authorized) error. [REQUIRED] + This property is readable by anyone with read access to the + resource. [REQUIRED] - @ : A "live" property containing a human- - readable description of the - [OPTIONAL] + . DAV:rights: A 'live' readonly property containing the list of + rights of the currently authenticated HTTP user. The read + right controls read access to this property. [REQUIRED] - @ : A "live" property containing the list of - rights of the currently authenticated HTTP - user. Read access to this property is - controlled by the right. This - property can NEVER be set directly. - [REQUIRED] + . DAV:acl: A 'live' property containing one or more DAV:ace + tags, which specify which principals are to get access to what + rights, for the resource with this ACL property. [REQUIRED] - @ : A "live" property containing one or more - tags, which specify which - principals are to get access to what rights, - for the resource with this ACL property. + . DAV:aclsemantics: A readonly property indicating the ACL + semantics model supported by the system. [REQUIRED] + + . DAV:protectaclfrominheritance: A "live" property indicating + 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 + elements: + . 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] - The element (property) contains 0 or more of the + . DAV:principalname, DAV:displayname, DAV:principal-type: These + 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 following XML elements: + . 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. - @ : An access control entry, which specifies the - set of rights to be granted to a single - principal. + The DAV:ace element contains the following XML elements: + . 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. - The element contains the following XML elements: + . DAV:deny: Contains the set of XML elements corresponding to + the rights being denied via this ACE. MUST contain at least + one right, if present. MUST NOT be present if the DAV:grant + element is present. - Sedlar, Clemm [Page 7] - @ : Contains the set of XML elements - corresponding to the rights being granted via - this ACE. Must contain at least one right + . DAV:principal: Contains information about the principal + resource this ACE applies to. [REQUIRED]. - @ : Contains the set of XML elements - corresponding to the rights being denied via - this ACE. Must contain at least one right, - if present. + . DAV:acepropertytypes: A "live" property containing one or more + 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] - @ : A URL of the principal resource this ACE - applies to, or one of the tags or - . Always present. The - value of this element must be unique within - an ACL. + . DAV:inherittochildtype: A "live" property containing one or + more elements, each of which is an XML tag identifying the + type of child object that will inherit this ACE. This + 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. - @ : Contains properties of the principal - resource (made available here to avoid the - need for a separate PROPFIND request). - Optional. + . DAV:inheritanceflags: A "live" property containing flags + 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] - A PROPFIND on a resource on a WebDAV ACL server might produce the - following XML output: + . DAV:inheritancesource: A readonly property containing the URL + 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. - 4.1 Example 1 - Retrieving Access Control information + The DAV:principal element contains the following elements: + . DAV:href: This is a URI representing the resource to which + the ACE applies, or one of the special principal identifier + tags (e.g., DAV:owner) described in the "Special Principal + Identifiers" section of this spec. [REQUIRED] + + . DAV:principalname, DAV:displayname, DAV:principal-type: These + are the same as the properties that can exist on the principal + URI. In this context they are considered 'live.' [OPTIONAL] + + The DAV:inheritanceflags element contains 0 or more of the + following XML elements: + . 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 + during access check. The ACE is present for the purposes of + inheritance only and does not affect the security of the + current resource. [OPTIONAL] + . DAV:containerinherit: This flag indicates that container + 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 + 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 + be inherited one level only. If an object inherits this ACE, + the DAV:containerinherit and DAV:objectinherit flags are + removed from the resultant inherited ACE, preventing further + propagation of this ACE. [OPTIONAL] + 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 + conforms to the ExplicitDenyPrecedence semantics described in + this spec. + + 4.1 Retrieving Access Control Information + + Retrieving Access Control information is done via PROPFIND on the + 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 + + 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 Content-type: text/xml; charset="utf-8" Content-Length: 0 Depth: 0 - - + + Response - HTTP/1.1 200 Success + HTTP/1.1 207 Multi-Status Content-Type: text/xml - Content-Length: xxxxx + Content-Length: xxx - + + HTTP/1.1 200 OK + 1997-12-01T17:42:21-08:00 Example collection XXXXX - - http://www.rational.com/principals/users/gclemm - Geoffrey Clemm - - Sedlar, Clemm [Page 8] + + http://www.foo.bar/users/gclemm + Geoffrey Clemm + - - http://www.foo.com/users/esedlar - - User + http://www.foo.bar/users/esedlar + esedlar Eric Sedlar - - - http://www.foo.com/groups/marketing - - Group - Foo.Com marketing + http://www.foo.bar/groups/marketing + + Foo.Bar marketing department mktdept + + + + http://www.foo.bar/groups/marketing + + Foo.Bar marketing + department + mktdept + + + - + + + + + 4.2 Setting Access Control Information + + An ACL is set by executing a PROPPATCH against the resource that + contains the DAV:acl property. An ACL must be written in its + 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 + + The following example follows from the previous example and + changes the group ACE to disallow read access to the ACL for the + marketing group. The other information had to be copied from the + ACL retrieved in the previous example. + Request + PROPPATCH /top/container HTTP/1.1 + Host: www.foo.bar + Content-Type: text/xml + Content-Length: xxxx + + + + + + + + + + http://www.foo.bar/users/esedlar + + + + + + http://www.foo.bar/groups/marketing + + + + + + + + Response + HTTP/1.1 207 Multi-Status + Content-Type: text/xml + Content-Length: xxx + + + + + http://www.foo.bar/top/container/ + + HTTP/1.1 200 OK + + + + + + 5 USING ACLS - By default, a principal has no access rights to an object - protected by an ACL. A particular ACE may either grant or deny a - set of rights to a single principal. It is illegal for an ACL to - have two ACEs applying to the same principal. However, since a - server may match the currently authenticated HTTP user with - multiple principals, it is possible for multiple ACEs to apply to - the current user. In this case, if a particular right is denied - to the current user by any ACE, this supercedes any ACE that - might grant that right. This is the case regardless if a ("more - specific") ACE granting access applied to a principal identifying - the user directly, while the ACE denying access applied to a - collection principal containing that user. The particular order - of the ACEs within an ACL is irrelevant. The tag - can also contain the following special tags: , , - . These tags have the following meaning: + An ACL contains zero or more ACEs that express the rights granted + or denied to the principal specified in the ACE. An ACL with + 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." - Sedlar, Clemm [Page 9] - @ owner: The principal identified by the owner property on + 5.1 System Controlled Rights + + Some implementations may grant certain rights implicitly. For + 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 DAV:principal element in an ACE may contain, instead of a + specific security principal identifier, one of the following + special tags: + . DAV:owner: The principal identified by the owner property on this resource is granted or denied the rights specified in this ACE. - @ all: The current user always matches this ACE, whether or + . DAV:all: The current user always matches this ACE, whether or not s/he is authenticated. - @ unauthenticated: The current user matches this ACE if not + . DAV:authenticated: The current user matches this ACE if + authenticated. + + . DAV:unauthenticated: The current user matches this ACE if not authenticated - Server implementations may limit the number of ACEs in an ACL. - However, ACL-compliant servers are required to support at least - one ACE granting rights to a single principal, and one ACE - granting rights to a collection principal. The server should - return an error "Too many ACEs" in this case. + . DAV:selfprincipal: The current user matches this ACE if the + resource (for example, a user information object or security + principal account) associated with this ACL is a + representation of the current user. - 6 ACL METHOD + 5.3 ACL Semantics Options - The ACL Method provides a mechanism to set ACL information. Its - request body is used to define alterations to the ACL of the - resource identified by the request-URI. Its response body - contains the current ACL for that resource. The ACL method - replaces the and properties on the specified - resource with the properties in the request. All readable ACEs - previously stored in the ACL on the indicated resource are - removed, so an ACL method on a resource with an unreadable - property will be ignored. (If the server implements rights - outside of those defined in this specification, they might allow - only some ACEs to be visibleùin this case, only part of the ACL - will be replaced). + In order to accommodate the different semantics of multiple + 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, - Change requests through the ACL method MUST be atomic. If any - part of the change request fails then all changes MUST fail. The - presence of an empty ACL causes all ACEs in the ACL, including - ACEs for associated properties, to be deleted. An empty request - body will cause no change to the ACL or associated values. If - the element (specifying properties of the resource - identified by the ACE's ) is specified, it (and its - children) is ignored. + . how to determine during access check which ACE(s) apply to a + user that matches multiple principals, - 6.1 Example 1 - Setting ACLs + . how to combine the rights granted or denied by multiple + matching ACEs during access check. - An ACL request body is an acl-info XML element. The element contains properties that can be set by the ACL - method (currently just ). + Additional ACL models may be accommodated by defining and + 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. - Request - ACL /top/container HTTP/1.1 - Host: www.foo.com - Content-Type: text/xml - Content-Length: xxxx - - + Effective Rights: The "effective rights" of a user is the set of + 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. - Sedlar, Clemm [Page 10] - - - - - http://www.foo.com/users/esedlar - - - - - - http://www.foo.com/groups/marketing - - - - + 5.3.1FirstSpecific - Response - HTTP/1.1 200 Success - Content-Length: 0 + The FirstSpecific semantic model has the following + 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. - This request changes the group ACE to disallow read access to the - ACL for the marketing group. The other information had to be - recopied from the ACL retrieved in the previous example. + 5.3.2ExplicitDenyPrecedence - 7 ACL INHERITANCE / DEFAULT ACLS + The ExplicitDenyPrecedence model has the following + characteristics: + 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. - To be added + ACE Matching and Combining Algorithm: The ACE matching and + 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 - Sedlar, Clemm [Page 11] - 8 XML SCHEMA FOR DEFINED ELEMENTS + . if it is a Deny ACE, any rights in the ACE that are not + already in the "Granted rights" or "Denied rights" sets are + added to the "Denied rights" set + + If the "Granted rights" set now contains all rights in the set of + "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 + 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 + contains all possible rights, then no more ACEs are evaluated and + 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 + + To support a more scalable administration model for configuration + of access control information, the spec defines an ACL + 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 + + Access control information is inherited at the granularity of an + 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 + should inherit the ACE, or + + . both to indicate that all child resources should inherit the + ACE. + + 6.2 Updating an inherited ACE + + When a child resource ACL inherits an ACE, the DAV:inherited + 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 + + In some cases, an ACE (whether explicit or inherited) may be + present on a container ACL purely for the sake of propagating + the ACE to child objects and NOT to be used for access control + 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 + + To indicate that an ACE should be inherited by children, but not + by grandchildren or any further down the tree, the optional + 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 + + To prevent an ACL from inheriting any ACEs, the optional + DAV:protectaclfrominheritance property is set on the resource. + If this property is present on a resource, the DAV:inherited + 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 - - - - + + + - + - + - - - - + + + + - - + - - + - - - - + + + + - + - - - Sedlar, Clemm [Page 12] - - + - - + - + - 9 INTERNATIONALIZATION CONSIDERATIONS + 8 INTERNATIONALIZATION CONSIDERATIONS To be supplied. - 10 SECURITY CONSIDERATIONS + 9 SECURITY CONSIDERATIONS To be supplied. - 11 SCALABILITY + 10 SCALABILITY To be supplied. - 12 AUTHENTICATION + 11 AUTHENTICATION Authentication mechanisms defined in WebDAV will also apply to WebDAV ACL. - 13 IANA CONSIDERATIONS + 12 IANA CONSIDERATIONS This document uses the namespace defined by [RFC2518] for XML elements. All other IANA considerations mentioned in [RFC2518] also applicable to WebDAV ACL. - 14 INTELLECTUAL PROPERTY + 13 INTELLECTUAL PROPERTY The following notice is copied from RFC 2026, section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. - Sedlar, Clemm [Page 13] The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, @@ -678,61 +1043,219 @@ permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. - 15 ACKNOWLEDGEMENTS + 14 ACKNOWLEDGEMENTS This protocol is the collaborative product of the WebDAV ACL design team: xxx, yyy, zzz. We would like to acknowledge the foundation laid for us by the authors of the WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV working group. - 16 INDEX + 15 INDEX To be supplied. - 17 REFERENCES + 16 REFERENCES [RFC2026] S.Bradner, "The Internet Standards Process", Harvard, 1996, . - [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, . - [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Harvard, 1997, . - [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 . - Sedlar, Clemm [Page 14] - 18 AUTHORS' ADDRESSES - - Eric Sedlar - Oracle Corporation - 500 Oracle Parkway - Redwood Shores, CA 94065 - Email: esedlar@us.oracle.com + 17 AUTHORS' ADDRESSES Geoffrey Clemm Rational Software 20 Maguire Road Lexington, MA Email: geoffrey.clemm@rational.com - 19 STILL TO DO : + Anne Hopkins + Microsoft Corporation + One Microsoft Way + Redmond, WA + Email: annehop@microsoft.com - @ Describe the interactions with resource locking. I'm not + Eric Sedlar + Oracle Corporation + 500 Oracle Parkway + Redwood Shores, CA 94065 + Email: esedlar@us.oracle.com + + 18 STILL TO DO : + + . Describe the interactions with resource locking. I'm not clear what the resolution was as far as locking the ACL separately from locking the resource. + + . Add a section defining new error codes/messages? Or should we + 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 + agreement. Add sample code. Anne will need to update + Semantics descriptions to address property ACEs. + + . Update the self, ownergroup stuff according to eventual + agreements. + + . Make document consistent: + + o Ensure all property descriptions indicate whether the + property is: + + . "live" or "dead" + . read-only or writable + . REQUIRED or OPTIONAL + o Ensure sample XML exists for all new properties, tags, + etc. + o Complete empty sections, like Scalability + 19 OPEN ISSUES: + + Issue Description Status + 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 , 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?