Re: Access Control Preliminary Draft

>Here is the preliminary access control requirements draft.

Thank you for writing up this preliminary access control requirements draft!

Some comments I have are below:


>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

I think it's important to keep a good separation of term usage between
"security," which many in the Web community view as "how to keep to
protocol stream safe from snooping," and "access control," which is what
you're talking about here.  I know access control is about keeping your
data secure, but to avoid terminological overload, we should stick to
access control.


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

I prefer the term, "data producing process," which is used in RFC 2068,
over "web application," which is a little broad for this meaning -- after
all, a Web browser is a Web application too.

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

There is a real tension between this, and wanting to give a specification
for what a policy object is.  I'm not sure that leaving this unspecified
gives enough information for an interoperable solution.  I definitely feel
uncomfortable with this as a general principle.

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

I agree.

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

I find that this is blurring the line between requirements and design.

The requirement I see in this paragraph is:

It must be possible to set access control permissions on a resource.

The design decision embodied here is:

Access control permissions should be stored in a metadata item.

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

This is design rationale.

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

I like this.

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

OK, this confused me.  Since these requirements should be focusing
exclusively on what facilities can be specified over the wire between a
client and a server, I think this doesn't belong in the requirements
document, since this is a internal server issue.

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

There are really two requirements here:
1) access policies must be stored in a resource
2) the req't listed above

However, #1 above somewhat goes against your design intention of using
attributes to store access control, since the most recent metadata draft
has metadata being part of the state of the resource it describes (links
still exist, though, so a separate access control resource can still be
linked to a resource)

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

If you have separate access rights for read and for confirm the existence
of a resource, how do they interact?  Persumably if I can read a resource,
it exists, and this is a confirmation of its existence.


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

Even though this is probably aimed at the scenario I brough up about
reducing access to a resource while editing is taking place, I suspect it
would be wise to keep access control and locking as separate as possible.
So I'd rather see a "read" permission, than the "read locked" and "read
unlocked" permissions.

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

If access control permissons are stored in a resource, then that resource
is subject to the "modify" access right, and hence there wouldn't be a
separate access permission for access permission resources.

That said, I think it makes sense to keep this requirement.


I've always thought that the easiest approach for access control on the Web
would be to create a matrix of:

{resource x HTTP method x {list of principals}}

So, one entry might be:

/jon/index.html GET *any*
/jon/index.html PUT jradoff

The most important concept for this document being the exact 1:1
correspondence between methods and access lists.  Some of your categories
cut across several HTTP methods, and I'm not sure that's a good thing.
Perhaps there should be requirements like:

Each HTTP method must have separate access permissions (excepting maybe
TRACE and OPTIONS).

But, since I like the grouping idea:

A mechanism for grouping related methods into a more abstract, named access
control permission must be available.

This way different access control schemes can be described using the same
primitives (which are HTTP methods).

- Jim

Received on Friday, 13 June 1997 22:10:59 UTC