Proposed Requirements for Access Control within Distributed Authoring and Versioning Environments on the WWW * * * Proposed Draft * * * [Standard Document format and jargon to be done] 1.0 Abstract To provide a robust model for modifying documents and data within a distributed World Wide Web authoring environment, it is necessary to furnish a methodology which controls access to objects. Access control may include the ability to read an object, modify an object, or perform other more advanced functions upon an object. Access control is necessary to prevent unauthorized access or modification of objects within the authoring environment which could lead to unintended loss, damage or disclosure of data. This document describes functionality which could be incorporated within the existing HTTP framework [1] to provide standardized methods which would allow Web Servers, Web Applications and Web Distributed Authoring and Versioning Tools (WebDAV) to exchange and process information regarding access controls. 2.0 Rationale The IDC report, "The Intranet's Many Faces" [2] points to "Central Administration of user access rights and restrictions" as an essential benefit of Web-based technology. Unfortunately, this fundamental requirement has not been standardized. Existing Web Server and Authoring Tool implementations do not have an interoperable mechanism for assigning access control information to a particular resource or requesting access control information about a particular resource. Present access control mechanisms, including native-operating system methods and Web-based htaccess mechanisms do not adequately address the need for managing the modification of documents within a distributed authoring environment. Native operating system methods are ineffective because the users responsible for modifying information on the Web site are generally not logged in interactively to the server in a manner that maps their identity to a local user-id. Further, there are significant differences between access control implementations on different operating systems which make it difficult or impossible to create standardized authoring tools that recognize access control information on different platforms. The "htaccess" file utilized on many Web Servers today deals principally with read permission, and is unsuitable for the more complex access control issues that exist in the distributed authoring environment. : [Howard: This last sentence is possibly dated in its assessment of : htaccess, but more importantly, it suggests that there is an actual : requirement to provide solutions for all of the "complex access : control issues" through this standard. And that is a little too : open-ended for my taste. : : Actually, if this standard were to define a protocol for conveying : access control information at about the level of htaccess (not : necessarily using htaccess syntax), I would consider that a : successful version 1.0. However, I do have hopes for something : a little better than that.] In addition, authoring tools need to the ability to assign permissions to particular resources from within the authoring environment. To have a reasonable level of management, it is necessary to both read and query for access control information within the framework of the proposed HTTP standard. This document describes requirements for a set of methods which : [Howard: I'd change "set of methods" to "set of mechanisms", to : avoid misleading the reader to believe that the access control : protocol will necessarily require new HTTP methods.] could be implemented within the framework of the proposed HTTP standard for the following: [Judy: Deleted Jon's list] : [Howard: Judy, I don't understand why you want to delete the list. : It seems important to describe in the requirements document the : capabilities to be enabled by an access control protocol. The list, : repeated below, seems to do that reasonably well. : : Creation and modification of security policies : Assignment of security policies to resources : Querying for policy information on a resource : Types of standard access control types : : That last one, "types of standard access control types", could be : clearer. It might be better cast as a property of extensibility : in the protocol, if I understand the intent. That would be less : biased toward a particular mechanism for implementing extensibility.] This document also specifies the principles that WebDAV-compliant Web Server products should adhere to when dealing with resources [Judy: that are subject to access control]. This will produce a consistent expectation as to [Judy: access control behavior] that WebDAV applications can depend upon. 3. Terminology Terminology is intended to be consistent with that specified in the Internet Draft "Requirements for Distributed Authoring and Versioning on the World Wide Web" [3]. In addition, the following terms are used within this document: [Judy: Deleted definitions of Access Policy and Access Attribute] : [Howard: I'm not fond of those definitions either. However, I : think we ought to define some kind of terms, such as "principal", : "right", and "policy", which can be used to describe the access : control model. I know that these terms may be seen as biased : toward a particular type of implementation, but there really must : be some kind of model of how access control works, even in this : requirements document. : : A requirements document that says that the requirement is to pass : an opaque blob of access control information between the client : server is not likely to lead to a standard that will result in : inter-operable implementations with respect to access control. : Even if the form of the access control information is defined by : a registered type or profile, at least one such type or profile : must be spelled out and required by the standard. In order to : do that, we will eventually have to get very specific about the : form of access constraints, how user identities are referenced, : and how access rights are represented in the protocol. : : I believe that this requirements document should specify an : extensible mechanism for representing access control information : as a requirement. It should also require that some basic level : of functionality be provided by the protocol. I'd like to see : some discussion on the scope of the extensibility and the nature : of the required basic functionality.] Server-Based Application A type of resource which may have dynamic output and has the ability to interact with users. A CGI (Command Gateway Interface) [4] program is an example of a Server-Based Application. There are now numerous other means of implementing Web Applications than CGI. 4. General Principles This section describes a set of general principles that WebDAV-compliant access control systems should follow in addition to the principles set forth as overall WevDAV principles [3]. 4.1 Abstraction of [Judy: Access Control Model] [Judy: Web servers and applications should have maximum flexibility in deciding what sorts of access control rules they will support. For example, different applications may wish to constrain different operations on resources: print, copy, modify properties, modify particular properties, retrieval of particular classes of variants, etc. Different applications may want to constrain access based on user age, membership lists, date. Copyright concerns may lead a server to limit the number of simultaneous users of the resources it maintains.] : [Howard: Given what I said above, I'm happier with Judy's version of : this section. I think that the point should also be made that the : objective is not to constrain how a server represents access control : information internally, but to specify how access control information : is represented in the protocol between clients and servers. However, : an internal representation which can be efficiently converted to and : from the protocol representation is likely to be more desirable.] 4.2 Open User Authentication It should not be a requirement that a particular user authentication method be used. [Judy: Delete sentence] However, certain recommended methods for user authentication may be suggested. [Judy: Delete sentence] : [Howard: I don't have a problem with this per se, but the mechanism : used for authentication is related to how users are identified, and : I believe that we are going to face a fundamental issue of how users : are referenced in the access control protocol. That, in turn, will : raise the issue of whether references to users will vary with the : authentication mechanism being used, or whether the user identity : determined via authentication must be mappable to a common form of : user reference.]
: [Howard: Section 4 is too vague. It needs to describe the scope of : a mandatory basic model, and the dimensions in which extensibility : is required. For example, does the basic model require that access : constraints be able to refer to user identities? Group identities? : Client IP address? Client DNS name? Should users be represented : as resources, and user groups as collections?] 5.0 Requirements [Judy: This section describes the access control operations that WebDAV will provide.] 5.1 Setting of Access [Judy: Constraints] It must be possible to set access constraints on resources through a protocol-based mechanism. 5.1.1 Rationale Experience with users of distributing document management environments and experience with administrating Web servers has shown that it is necessary to manage access control information in a distributed fashion. Otherwise, it will require modifying of files and resources via an administrator with "local" access to the machine in question. 5.2 Access Inheritance It must be possible to [Judy: set access constraints on] a collection (such as a directory). The system must assign appropriate default access [Judy: constraints] to resources [Judy: that belong to the collection]. 5.2.1 Rationale Inheritance of security information between directories and files within most file systems behave in this manner. This promotes an orthogonal implementation on the Web.
: [Howard: That seems a weak rationale for a feature which raises : so many issues. One fundamental question is when inheritance : happens. When a resource is created, like most files systems? : Or on every access to resource, like many web servers? If this : second form, which I'll call "lazy inheritance", is used, when : a client is viewing the access constraints on a resource, there is : a question as to whether that should be the access constraints : which would apply to accesses to that resource, including lazily : inherited constraints, or whether it should be only the access : constraints attached directly to the resource itself. Or should : the client be able view either of these? : : From my experience I'm not convinced that either kind of : inheritance based on the collection/resource hierarchy is ideal. : I would rather see the ability to name sets of access constraints, : and then attach a list of such names to a resource. If some : kind of inheritance from parent collections were supported, my : preference would be for non-lazy inheritance. : : In defense of lazy inheritance, which we support in our products, : it is good to have it when resources can "appear" in a collection : without going through a central "create resource" mechanism. For : example, before the advent of web publishing systems, it was : common to create web resources using native file system operations : or some other protocol, such as ftp. This provided no opportunity : to apply web-oriented access constraints to a resource when it was : created, so lazy inheritance seemed the only way to achieve this. : : However, it is possible for servers or other entities which care : about web-oriented access constraints to support "lazy resource : creation". That is, when a file that is not yet a resource is : referenced via its name relative to a collection which corresponds : to the file directory in which it was placed, a resource is : automatically created for that file, and access constraints are : attached to that resource at that time. These access constraints : may be inherited from the parent collection, but only once, as : the resource is being (lazily) created.] 5.3 Reporting to Server-Based Applications [The following is still being discussed. The objective was to provide for an object-oriented approach to insuring that the WebDAV environment could pass access control change information to an application that could be responsible for its own denial of service] : There must be a standard mechanism for reporting changes to access : attributes to Web Applications so that they can take any special : internal actions that might be appropriate for them. It must be : possible for the Web Application to report back its acceptance or : advisory refusal of the access attribute change. : [Howard: Ok, let's discuss it. If Web Applications are viewed as : engines which drive the operation of active resources (objects), : the active resources can have their access constraints manipulated : through the same mechanisms as static resources. It may be : desirable to allow Web Applications to create new kinds of access : rights or other attributes used in formulating access constraints. : A Web Application itself may have to evaluate when the access : constraints attached to an active resource apply to a particular : operation on the resource, but that should have no effect on the : protocol for conveying access control information between clients : and servers.] 5.3.1 Rationale Changing of access attributes on a static resource such as an HTML document is relatively straightforward. However, Server-Based Applications may wish to know that access control data has changes, because they may need to update their internal information. This is an attempt to provide for an object-oriented view of how resources can provide for their own access control when they are capable of doing so.
: [Howard: I don't see what the relationship between a server and : Server-Based Applications has to do with a protocol for conveying : access control information between client and server. The : server interprets the protocol, and if its associated applications : need to be aware of protocol events, the mechanism for notifying : them appears to be out of the scope of this standard.] 5.4 Access Control [Judy: for Access Constraints] [Judy: It should be possible to set access constraints on the operation of modify access constraints.]
: [Howard: Recursively? The requirement should be made clear one way or : the other.] 5.4.1 Rationale This is intended to make it simple to administrate changes to access [Judy: delete "policy"] information.
5.5 Standard Access Attributes [Judy: Although different servers and applications will wish to constrain different operations on resources, it is useful to provide a core set of operations for which all WebDAV servers are required to support access control.] This section enumerates [Judy: that core set of operations]. It is acceptable if some implementations wish to treat different access attributes as synonymous (e.g., a change to the attribute controlling "list" access may simultaneously change both "list" and "read"). [Judy: It is also acceptable if an implementation supports access control for additional operations.] [Howard: extending the set of operations in a manner prescribed by the standard.] [Clarification Added:] [Judy: Delete sentence] 5.5.1 Rationale A [Judy: core] set of standard [Judy: operations subject to access control] will facilitate the creation of interoperable tools that will make it easier to change or query for access control information. Further, by standardizing on certain types of access control methods, we will promote a more orthogonal implementation upon which tools and users can base their expectations. [Howard: orthogonal to what?] 5.5.2 List [Judy: It must be possible to set access constraints that determine whether a particular request to list the contents of a collection resource will be allowed.] [Judy: It must be possible to set access constraints that determine whether a particular request to discover whether a particular resource exists will be allowed.] 5.5.2.1 Rationale Experience with file systems has shown that unauthorized access or attempts at circumventing security policies increase when users have more information about the contents of the file system. Therefore, it is helpful to define an access control attribute that controls whether a user can obtain this information about a particular resource. [New 5.5.3] 5.5.3 Read [Judy: It must be possible to set access constraints that determine whether a particular request to view the contents of a particular resource will be allowed.] 5.5.3.1 Rationale Some resource may contain confidential or sensitive information. It should be possible to limit whether a particular user is allowed to read the contents of a resource. 5.5.5 Modify [Judy: It must be possible to set access constraints that determine whether a particular request to modify the contents of a particular resource will be allowed.] 5.5.5.1 Rationale Experience with a wide number of information systems has shown that different users need the ability to modify different resources. 5.5.6 Delete [Judy: It must be possible to set access constraints that determine whether a particular request to delete a particular resource will be allowed.] 5.5.6.1 Rationale Experience with file systems has shown that it is sometimes preferable to permit certain users to modify a particular resource without allowing them to delete it. 5.5.7 [Judy: Change Access Constraint] [Judy: It must be possible to set access constraints that determine whether a particular request to change an access constraint will be allowed.] 5.5.7.1 Rationale Experience with file systems has shown that there is a significant desire to separate the management of information content (what is contained within the resources when a user reads it) from the manage of access control structure. Often, different people in different roles are responsible for these capabilities, and it may compromise the intended security plan to allow users to change access control information about a resource even if they are normally allowed to change or delete it. 5.6 Discovery It must be possible to discover what categories of access control [Judy: constraints] can be set for a given resource. The server should also be capable of providing a "plain" description of [Judy: the syntax and semantics of each constraint category it supports]. 5.6.1 Rationale It will be necessary for WebDAV tools to understand what the WebDAV server understands insofar as access control, as well as a description in human-readable terms of how the server will treat changes to a particular access control [Judy: constraint]. 6.0 Security This document generally deals with the issue of access control, which is a fundamental security issue. However, this document raises other security concerns that implementors may wish to consider. For example, this requirements document does not deal with issues pertaining to the integrity of a request to change an access control attribute to a different access policy. It is assumed that issues of spoofing, impersonating users, data integrity and encryption are suitably dealt with elsewhere and that nothing within the access control requirements preclude these techniques. 7.0 Acknowledgements TBD
: [Howard: I'll collect names of people who contribute to the : access control discussion from this point forward, but I'd : appreciate information about who has contributed in the : past.] 8. References [1] T. Julian, R. Villars, "The Intranet's Many Faces," Report 11344, International Data Corporation, April 1996. [2] J. A. Slein, "Requirements for Distributed Authoring and Versioning on the World Wide Web," Internet Draft, draft-ietf-webdav-requirements-00.txt, May 1997. [3] T. Berners-Lee, D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, MIT/LCS, November 1995. [4] "The Common Gateway Interface 1.1," University of Illinois, http://hoohoo.ncsa.uiuc.edu/cgi, December 1995.