Access Control Interim Draft

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