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 Leach and Goland [Page 8] INTERNET-DRAFT WEBDav ACL Protocol October 18, 1997 HTTP/1.1 207 Multi-Response Content-Type: text/xml Content-Length: xxxxx domain/joebob domain/superuser some sort HTTP/1.1 200 Success 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 HTTP/1.1 207 Multi-Response Content-Type: text/xml Content-Length: xxxxx HTTP/1.1 200 Success 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 someotheruser HTTP/1.1 207 Multiresponse Content-Type: text/xml Content-Length: xxxxx HTTP/1.1 405 Conflict 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, [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, [XML] W3C, 'Extensible Markup Language - Part1. Syntax', March 1997 Leach and Goland [Page 12]