|
INTERNET-DRAFT draft-ietf-webdav-advacl-00 Expires April 16, 2001 |
Anne Hopkins, Microsoft Corporation
|
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 Advanced Access Control extensions to the HTTP/1.1 protocol.
Table of Contents
2 Advanced Access Control Properties
3.3 Propagate ACE but do not use for
Access Check on this resource
3.4 Propagate to immediate children
only
3.5 Protect ACL from inheritance
4 Internationalization
Considerations
This
protocol defines advanced extensions to the access control protocol. In particular, finer control over
inheritance and control over individual property access control is defined.
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].
This specification defines a number
of new properties for WebDAV 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.”
·
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.
The DAV:ace element of a the
DAV:acl property contains the following additional XML elements:
·
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 permissions 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 permissions supported on
Property ACEs may be all or a subset of the DAV:access-permissions
present on this resource. This spec does not provide a mechanism to
specify a different set of access-permissions for a property,
than for the resource. An implementation that supports a different set of
access-permissions for a property than for the resource, must
return an error "Unsupported Permission" on an attempt to write a
Property ACE with permissions not supported by the server. [OPTIONAL]
·
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.
·
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]
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 permissions.
[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]
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.
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.
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 permissions 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.
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.
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.
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.
To be supplied.
To
be supplied.
Authentication mechanisms defined in WebDAV will also apply to WebDAV ACL.
This document uses the namespace defined by [RFC2518] for XML elements. All other IANA considerations mentioned in [RFC2518] also applicable to WebDAV ACL.
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.
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.
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.
To be supplied.
[RFC2026] S.Bradner, "The Internet Standards Process", Harvard, 1996, <http://www.ietf.org/rfc/rfc2026.txt>.
[RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, U.C. Irvine, DEC, MIT/LCS, 1997, <http://www.ietf.org/rfc/rfc2068.txt >.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Harvard, 1997, <http://www.ietf.org/rfc/rfc2119.txt >.
[RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen, "HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft, U.C.Irvine, Netscape, Novell, 1999 <http://www.ietf.org/rfc/rfc2518.txt>.
Anne
Hopkins
Microsoft
Corporation
One
Microsoft Way
Redmond,
WA
Email:
annehop@microsoft.com
·
Revisit
description of Property ACEs to reflect group agreement. Add sample code. Anne will need to
update Semantics descriptions to address property ACEs.