INTERNET-DRAFT Eric Sedlar, Oracle Corporation draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software Expires November 1, 2000 May 1, 2000 Access Control Extensions to WebDAV Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a set of methods, headers, and resource-types that define the WebDAV Access Control extensions to the HTTP/1.1 protocol. Sedlar, Clemm [Page 1] INTERNET-DRAFT WebDAV ACL May 1, 2000 Table of Contents 1 INTRODUCTION............................................3 1.1 Notational Conventions................................3 2 PRINCIPALS..............................................3 3 RIGHTS..................................................4 3.1 RIGHTS-DISCOVERY method...............................5 3.2 Rights defined by WebDAV..............................6 3.2.1 read Right........................................6 3.2.2 write Right.......................................6 3.2.3 readacl Right.....................................6 3.2.4 writeacl Right....................................6 3.2.5 all Right.........................................6 4 ACCESS CONTROL PROPERTIES...............................7 4.1 Example 1 - Retrieving Access Control information.....8 5 USING ACLS..............................................9 6 ACL METHOD.............................................10 6.1 Example 1 - Setting ACLs.............................10 7 ACL INHERITANCE / DEFAULT ACLS.........................11 8 XML SCHEMA FOR DEFINED ELEMENTS........................12 9 INTERNATIONALIZATION CONSIDERATIONS....................13 10 SECURITY CONSIDERATIONS..............................13 11 SCALABILITY..........................................13 12 AUTHENTICATION.......................................13 13 IANA CONSIDERATIONS..................................13 14 INTELLECTUAL PROPERTY................................13 15 ACKNOWLEDGEMENTS.....................................14 16 INDEX................................................14 17 REFERENCES...........................................14 18 AUTHORS' ADDRESSES...................................15 19 STILL TO DO :........................................15 Sedlar, Clemm [Page 2] INTERNET-DRAFT WebDAV ACL May 1, 2000 1 INTRODUCTION The underlying principle of access control is that who you are determines how you can access a resource. The "who you are" is defined by a "principal" identifier; users, client software, servers, and groups of the previous have principal identifiers. The "how" is determined by an "access control list" (ACL) associated with a resource. An ACL contains a set of "access control entries" (ACEs), where each ACE specifies a principal and a set of rights that are either granted or denied to that principal. 1.1 Notational Conventions The augmented BNF used by this document to describe protocol elements is described in Section 2.1 of [RFC2068]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2068], those rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2 PRINCIPALS A principal identifies an entity that can be given access rights to HTTP resources. On many implementations, a user or a group will be examples of principals, but other types of principals are possible. For the most part, any classification or other information about the entity identified by a principal is opaque with respect to this specification, and is dependent on the implementation. Principals are manifested to clients as a HTTP resource, identified by a URL. The set of properties exposed by that resource are implementation dependent, although certain properties are required by this specification. Those properties include: @ : 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] INTERNET-DRAFT WebDAV ACL May 1, 2000 this property can be used to distinguish it as a principal from other resources on a WebDAV server. (Note that may not be used, as all collections must use the value "collection" for , which wouldn't distinguish normal collections from principal collections.) [REQUIRED] Server implementations may include any other descriptive information for a principal via properties. A principal resource may or may not be a collection. A collection principal may only contain other principals (not other types of resources). Servers that support aggregation of principals (e.g. groups of users or other groups) MUST manifest them as collection principals. The WebDAV methods for examining maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used to maintain collection principals. Membership in a collection principal is recusive, so a principal in a collection principal A contained by collection principal B is a member of both collection principals. Implementations not supporting recursive membership in principal collections can return an error if the client attempts to bind collection principals into other collection principals. Using WebDAV methods to alter the content of a principal (e.g. using PROPPATCH or PUT) is outside the scope of this specification, and is not required, recommended, or forbidden by this spec. 3 RIGHTS A right controls access to a particular set of HTTP operations on a resource. The set of rights that apply to a particular resource may vary with the 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 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. Sedlar, Clemm [Page 4] INTERNET-DRAFT WebDAV ACL May 1, 2000 3.1 RIGHTS-DISCOVERY method Rights discovery is a method with no arguments, that returns the rights aggregation tree. Each right appears as an XML element, where aggregate rights list all of their children as sub- elements. Each right element can contain the following attributes: @ abstract (Boolean): "true" if this right cannot be used in an ACL/ACE. Defaults to "false" @ description (string): a human readable description of what this right controls access to. Required. For example, the following response might be generated to a RIGHTS-DISCOVERY request on a WebDAV server implemented by a relational database (where the resource in this case corresponds to a table): Request RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1 Host: www.foo.bar Content-type: text/xml; charset="utf-8" Content-Length: 0 Response HTTP/1.1 200 Success Content-Type: text/xml Content-Length: xxxxx It is envisioned that a WebDAV ACL-aware administrative client would list the available in a dialog box, and allow the user to choose non-abstract rights to apply in an ACE. The rights tree is useful programmatically to map well-known rights (defined by WebDAV or other standards groups) into rights that are supported by any particular server implementation. Sedlar, Clemm [Page 5] INTERNET-DRAFT WebDAV ACL May 1, 2000 3.2 Rights defined by WebDAV The rights defined by WebDAV access control MUST be present in the response to the RIGHTS-DISCOVERY method, although they may be abstract (and not usable within an ACE on a particular implementation). 3.2.1read Right Name: 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. 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. 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. 3.2.5all Right Name: Sedlar, Clemm [Page 6] INTERNET-DRAFT WebDAV ACL May 1, 2000 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. 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: @ : 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] @ : A "live" property containing a human- readable description of the [OPTIONAL] @ : 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] @ : 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. [REQUIRED] The element (property) contains 0 or more of the following XML elements: @ : An access control entry, which specifies the set of rights to be granted to a single principal. The element contains the following XML elements: Sedlar, Clemm [Page 7] INTERNET-DRAFT WebDAV ACL May 1, 2000 @ : Contains the set of XML elements corresponding to the rights being granted via this ACE. Must contain at least one right @ : Contains the set of XML elements corresponding to the rights being denied via this ACE. Must contain at least one right, if present. @ : 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. @ : Contains properties of the principal resource (made available here to avoid the need for a separate PROPFIND request). Optional. A PROPFIND on a resource on a WebDAV ACL server might produce the following XML output: 4.1 Example 1 - Retrieving Access Control information Request PROPFIND /top/container HTTP/1.1 Host: www.foo.bar Content-type: text/xml; charset="utf-8" Content-Length: 0 Depth: 0 Response HTTP/1.1 200 Success Content-Type: text/xml Content-Length: xxxxx 1997-12-01T17:42:21-08:00 Example collection XXXXX http://www.rational.com/principals/users/gclemm Geoffrey Clemm Sedlar, Clemm [Page 8] INTERNET-DRAFT WebDAV ACL May 1, 2000 http://www.foo.com/users/esedlar User esedlar Eric Sedlar http://www.foo.com/groups/marketing Group Foo.Com marketing department mktdept 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: Sedlar, Clemm [Page 9] INTERNET-DRAFT WebDAV ACL May 1, 2000 @ owner: The principal identified by the owner property on this resource is granted or denied the rights specified in this ACE. @ all: The current user always matches this ACE, whether or not s/he is authenticated. @ unauthenticated: The current user matches this ACE if not authenticated Server implementations may limit the number of ACEs in an ACL. However, ACL-compliant servers are required to support at least one ACE granting rights to a single principal, and one ACE granting rights to a collection principal. The server should return an error "Too many ACEs" in this case. 6 ACL METHOD The ACL Method provides a mechanism to set ACL information. Its request body is used to define alterations to the ACL of the resource identified by the request-URI. Its response body contains the current ACL for that resource. The ACL method replaces the 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). 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. 6.1 Example 1 - Setting ACLs An ACL request body is an acl-info XML element. The element contains properties that can be set by the ACL method (currently just ). Request ACL /top/container HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx Sedlar, Clemm [Page 10] INTERNET-DRAFT WebDAV ACL May 1, 2000 http://www.foo.com/users/esedlar http://www.foo.com/groups/marketing Response HTTP/1.1 200 Success Content-Length: 0 This request changes the group ACE to disallow read access to the ACL for the marketing group. The other information had to be recopied from the ACL retrieved in the previous example. 7 ACL INHERITANCE / DEFAULT ACLS To be added Sedlar, Clemm [Page 11] INTERNET-DRAFT WebDAV ACL May 1, 2000 8 XML SCHEMA FOR DEFINED ELEMENTS Sedlar, Clemm [Page 12] INTERNET-DRAFT WebDAV ACL May 1, 2000 9 INTERNATIONALIZATION CONSIDERATIONS To be supplied. 10 SECURITY CONSIDERATIONS To be supplied. 11 SCALABILITY To be supplied. 12 AUTHENTICATION Authentication mechanisms defined in WebDAV will also apply to WebDAV ACL. 13 IANA CONSIDERATIONS This document uses the namespace defined by [RFC2518] for XML elements. All other IANA considerations mentioned in [RFC2518] also applicable to WebDAV ACL. 14 INTELLECTUAL PROPERTY The following notice is copied from RFC 2026, section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. Sedlar, Clemm [Page 13] INTERNET-DRAFT WebDAV ACL May 1, 2000 The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 15 ACKNOWLEDGEMENTS This protocol is the collaborative product of the WebDAV ACL design team: xxx, yyy, zzz. We would like to acknowledge the foundation laid for us by the authors of the WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV working group. 16 INDEX To be supplied. 17 REFERENCES [RFC2026] S.Bradner, "The Internet Standards Process", Harvard, 1996, . [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] INTERNET-DRAFT WebDAV ACL May 1, 2000 18 AUTHORS' ADDRESSES Eric Sedlar Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 Email: esedlar@us.oracle.com Geoffrey Clemm Rational Software 20 Maguire Road Lexington, MA Email: geoffrey.clemm@rational.com 19 STILL TO DO : @ Describe the interactions with resource locking. I'm not clear what the resolution was as far as locking the ACL separately from locking the resource.