Access Control Preliminary Draft

Here is the preliminary access control requirements draft.

This is based on some of the general consensus reached here
on the list:

   1) Treating security policies as a resource was popular;
   2) Not including issues pertaining to authentication,
      auditing and encryption were favored;
   3) The methods should work within the framework of HTTP 1.1 as
      extended by WebDAV.

Please send all your comments this way.  I will be periodically
posting proposed changes/additions/deletions and will post a
proposed final draft after discussion starts to die down.

-------


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

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

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

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.

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 Web Applications

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, Web 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").

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.

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.

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 Wednesday, 11 June 1997 19:54:50 UTC