- From: Jon Radoff <jradoff@novalink.com>
- Date: Tue, 08 Jul 1997 12:59:59 -0400
- To: w3c-dist-auth@w3.org
Attached is a marked-up copy of the current access control requirements draft. The main areas for continued discussion are around: 1) Interrelationship (if any) between access control, reservations and locking. 2) Whether integration with "Server-based Application" resources is (a) out of scope, (b) in scope and desirable or (c) in scope and undesirable. Editing Conventions used: Editors notes are in square-brackets Text which will be deleted is indented after a colon Jon ---- 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. 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 could be implemented within the framework of the proposed HTTP standard for the following: 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 This document also specifies the principles that WebDAV-compliant Web Server products should adhere to when dealing with resources bound by security policies. This will produce a consistent expectation as to the behavior of access control attributes 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: Access Policy [Revised] A piece of information which describes who and under what conditions a particular access is allowed or denied. [Old] : A resource which contains information about who and : under what conditions a particular access is allowed : or denied. Access Attribute An attribute that relates a specified type of access with a named access policy. [3.1 is New] 3.1 Example There is an access policy A which states that users U1, U2 and U3 will be granted access. There is a particular resource with access attribute X set to A. U1, U2 and U3 would be allowed to perform whatever action is constrained by the presence of X; user U4 would be denied. [Renamed from "Web Application] 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 implementating 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 Security Implementation The structure internal to Access Policy resources is not defined. This is to allow the implementors of Web Servers and applications maximum flexibility in identifying the relationship between users, resources and their access capabilities. Standardizing the type of information that might be allowed within an access policy at this point could prematurely limit the ability to create complex access control rules. 4.2 Open User Authentication It should not be a requirement that a particular user authentication method be used. How users are identified and authenticated and how they relate to stated Access Policy resources should be handled within the Web Server or Server-based Application implementation. However, certain recommended methods for user authentication may be suggested. Similarly, issues pertaining to user lists, user list management and how a particular user is integrated with access policy is left to the Web Server implementation. 5.0 Requirements Standardized attributes must be provided for the purpose of associating access control information with individual resources. This section covers how access attributes should be implemented. [Revised 5.1] 5.1 Setting of Access Attributes It must be possible to set an access attribute 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. [Old] : 5.1 Setting of Access Attributes : The setting of access attributes must be handled through the same : protocol that is used to query and specify other attribute data [2]. : 5.1.1 Rationale : WebDAV already intends to specify the means to set and query metadata. : Since access control information is really just another type of : metadata, there is no apparent reason to produce new ways to tackle : this problem. 5.2 Access Inheritance [Old] : It must be possible to assign an access attribute to a collection : (such as a directory). By default, resources contained in a collection : must inherit access attributes from their parent resource. [Revised] : It must be possible to assign an access attribute to a collection : (such as a directory). The system must assign appropriate default : access attributes to resources added to a collection. 5.2.1 Rationale Inheritance of security information between directories and files within most file systems behave in this manner. This promotes an orthagonal implementation on the Web. 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. 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. 5.4 Access Control to Access Policies Since access policies are themselves a resource, they can in turn be controlled by other access policy resources. 5.4.1 Rationale This is intended to make it simple to administrate changes to access policy information. 5.5 Standard Access Attributes This section enumerates the access control attributes that must be available in any WebDAV implementation. 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"). [Clarification Added:] It is intended that the WebDAV server be responsible for interpreting exactly how a particular access attribute is implemented. 5.5.1 Rationale A set of standard access attributes 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 orthagonal implementation upon which tools and users can base their expectations. 5.5.2 List A standard access attribute must be provided that governs what happens when the user wishes to list the contents of a collection or confirm the existance of a particular resource. 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 A standard access attribute must be provided that controls access to view the contents of the resource. 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. [NOTE: The interrelationship between read access, locking and resource reservation is still an ongoing discussion.] [The old 5.5.3 through 5.5.4 are deleted. There was general despise for differentiating lock and unlocked read access states.] : 5.5.3 Read-when-unlocked : A standard access attribute must be provided that controls access : to the object when it is in an "unlocked" state. : 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. "Unlocked" versus "locked" : states are split to allow the possibility of allowing certain : users to read a resource despite an advisory lock. : 5.5.4 Read-when-locked : A standard access attribute must be provided that controls access : to that object when it is in a "locked" state. It is recommended : that the default access control behavior be to deny access to read : the resource except by the owner of the lock. 5.5.5 Modify A standard access attribute must be provided that controls access to modify the contents of the object. Implementations should check the lock status and apply the appropriate read-when-locked or read-when-unlocked access control policy prior to any modification attempt. 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 A standard access attribute must be provided that governs what happens when a user wishes to delete a resource. 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 Change-access-policy A standard access attribute must be provided that governs what happens when a user wishes to change an access attribute on a resource. 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. [Added 5.6] 5.6 Discovery It must be possible to discover what categories of access control attributes can be set for a given resource. The server should also be capable of providing a "plain" description of how it implements the named access control attribute. 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 attribute. 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 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.
Received on Tuesday, 8 July 1997 12:56:48 UTC