Re: Interim Access Control Draft

Howard,

It's great that you are taking on the access control requirements and
protocol specification.

About a week before the Orem meeting, I sent this revision of the
requirements draft to Jon, but never to the whole mailing list.  It was an
attempt to get rid of what seemed to me to be design constraints rather than
requirements.  The main point was to get rid of the notions of access
policies and access attributes.

In addition, I think we should get rid of 5.3, which really has to do with
interactions on the server and seems to go beyond what could be embodied in
a protocol.

--Judy

   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:

[Judy: Deleted Jon's list]

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]

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 [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.]

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]

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.

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 [Judy: for Access Constraints]

[Judy: It should be possible to set access constraints on the operation of
modify access constraints.]

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.]

[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.

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

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.


Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		105-50C

Received on Tuesday, 7 October 1997 10:46:50 UTC