Re: comments on access control requirements

Yaron,

> Section 2.0 - Introduction
> "Native operating system methodsare ineffective because the users
> responsible for modifyinginformation on the Web site are generally not
> logged ininteractively to the server in a manner that maps their
> identityto a local user-id."
> While I am aware of systems, such as FrontPage, which create user-ids
> that only exist for FrontPage and not the underlying system, the
> majority of web servers I am familiar with map web based authentication
> directly to user IDs. The use of the clear text password challenge is
> often used to map users to their UNIX Ids and the use of NTLM is widely
> used in NT environments to map users to their accounts. I think the next
> sentence, regarding different types of ACL systems is strong enough to
> justify the existence of this draft, the sentence quoted above is not,
> in my opinion, needed.

What you're saying is often true for intranets, but is often not true for
extranets or ISPs.  How about if we change it to:

"Native operating system methods are not always applicable because web
server user identities are not always mapped to native operating system
identities, especially in situations where the web server may be accessed by
users outside of the enterprise which maintains it."

It might also be reasonable to add:

"In many cases, web server access control is based on the IP addresses or
DNS names of clients.  Native operating systems do not generally support
this type of access control on a per-resource basis."

A fundamental question for our access control requirements is whether the
protocol should support this type of access control.  I'd vote yes, simply
because it is widely used.  It could be argued that we should take a stand
for better security and deprecate this practice by not supporting it, but
who is to say that IP addresses and DNS names will not be more secure in the
future?


> Section 3 - Terminology
>
> I think the term principal should be defined in DAV and, at best,
> repeated verbatim in the ACL draft. I also believe a definition should
> be provided for both policy and ACL. As I have learned talking to
> different folks about security there are a lot of subtle differences in
> the way people use security terms. For example I use the word ACL in a
> way that most folks use the word ACE. Also, I agree with your comments
> that we will have to require the definition of some sort of
> extensibility mechanism along with some basic access controls. I believe
> you are dead on when you say that just passing around blobs that will
> get defined at some point in the future buys us nothing.

Does a "principal" consist of a user identity, as determined by some
authentication method, or does it also take into account client IP address,
DNS name, and possibly other properties?  Is a principal defined by a
description in terms of attributes, or is defined as a specific,
authenticated user identity?

> This having been said I would like to see the terms Application and
> Server Based Application both stricken from the terminology section. The
> definitions aren't, in my opinion, useful.

Going, going...

> Section 4 - General Principles
>
> I agree that this section requires significant work.
>
> Also, URLs are generally opaque to clients. Servers spit them out,
> clients just move them around. I suggest we follow the same rule when it
> comes to identifying principals. The requirement document should not
> require that principals can generate or even dissect principal
> identifiers. Rather I suggest we intentionally leave undefined how it is
> a principal comes into possession of a principal identifier.
>
> In fact I would suggest we stick to the agreements made at the Orem
> meeting that the DAV ACL mechanism would ignore issues of how principal
> identifiers are created or what they represent and instead define what a
> principal can do once they have such an identifier and the authorization
> to use it.

While I understand and agree with a desire to support "open user
authentication", I don't see that this by itself implies that references to
user identities should not be standardized in the access control protocol.
Once a user has authenticated to a server in some way, the server could map
the authenticated identity to a WebDAV-specified form of user reference.
Access control policy could be conveyed between client and server, using
this standardized form of reference to users.

The need to reference unique user identities goes beyond access control per
se.  I notice that for purposes of identifying a lock owner, XML is used
(section 5.6.2.5 of the DAV spec).  If a client program wants to compare
user identities for equality, for example, to test if the current user is
the lock owner, how is that done?  It seems that the XML user reference must
contain some component that uniquely identifies a user with respect to the
server, and the client must understand enough about the particular XML
schema being used to compare the appropriate parts of the XML text in an
appropriate way.

No doubt this is a hard problem, and one for which I don't claim to have all
the answers, but just specifying an XML representation, while wonderful for
extensibility, does not seem to advance the cause of interoperability much.

> Section 5.1 - Setting of Access
>
> Not to be picky but can we please use the word "control" instead of
> "constraints"? I believe the later to be common usage. We also need a
> very detailed definition of what an access control is. Otherwise, we
> don't know what it is we are requiring.

I prefer "access control" myself, but the more important thing is to define
what it is, as you suggest.  I understand/like models with ACLs made up of
ACEs, with each ACE allowing or denying specified access rights under
certain specified conditions, which usually have to do with attributes of
the client user, potentially including references to authenticated user
identities.  Are there any alternative proposals?

> Section 5.2 - Inheritance
>
> I am not clear as to what problem is introduced into the protocol by
> lazy inheritance. Inheritance is a mechanism to specify ACL information
> for resources within a certain scope. If a resource is available in the
> scope, regardless of how it got there, then it is expected to have the
> specified ACL information. So, examining the situation strictly from the
> view "on the wire" there is no discernable difference between lazy and
> normal inheritance. As such we should be able to specify them the same
> way.

Lazy inheritance need not affect the protocol design if we so choose.
However, I think that means that when viewing the access control on a
resource, you would not see or be able to set any lazily inherited controls
from a WebDAV client, although you would still be subject to these controls
when attempting to access the resource.  That would tend to relegate the
administration of lazily inherited controls to server administrators, or
encourage proprietary extensions to WebDAV to enable end-user
administration.  I have no problem with that.

If the access control protocol does convey lazily inherited access control
information between client and server, then it must, at a minimum, provide a
mechanism to distinguish between access controls which are directly bound to
a resource and those which are lazily inherited.  It may also be necessary
to distinguish between types of access control placed on a collection, as
applying to the collection itself, or applying (via lazy inheritance) to
resources in the collection.  With internal and external members of
collections, there is a potential for even finer distinctions.

> Either way I do not believe we can escape inheritance. Just about every
> ACL system I am aware of, from UNIX to the high end document management
> servers support inheritance as a way for someone to allow controlled
> access to creation capabilities within their namespace.

I don't disagree, but the inheritance model needs to be elucidated, even if
it's just to say that inheritance is server-specific and outside the scope
of this protocol design.  Even with that statement, I'd add:

"
 1) The WebDAV access protocol conveys only access controls which are
directly bound to, and applicable to accesses to, a given resource.  There
may be access controls bound to a resource which do not affect accesses to
the resource, and there may be access controls which are not directly bound
to the resource, which nevertheless may affect accesses to the resource.

Rationale: Allows servers to implement lazy inheritance of access controls,
if desired.

2) Access controls may be implicitly bound to a resource as a side-effect of
resource creation, through mechanisms outside the scope of this
specification.

Rationale: Allows servers to implement non-lazy (got a better word?)
inheritance of access controls, if desired.
"

One could replace "inheritance" with "assignment" in the above, and it would
be less biased toward the mechanism of inheritance, per se.

> Section 5.3 - Reporting to Server-Based Applications
>
> I believe this section is inappropriate to a protocol requirements
> document and should be removed. We are dealing strictly with the
> protocol definition and the expected behaviors from the commands passed
> through that protocol. How those behaviors get enforced on the server is
> out of scope for both the requirements and the protocol.

Going, going...

> Section 5.4 - Access Control [Judy: for Access Constraints]
>
> Ahh the snake biting its own tail. I would recommend that the
> requirements only state that there be a way to control who has the right
> to change access controls. The actual form of that mechanism should be
> left to the protocol group.

Well, that's fine with me, but won't the protocol group's first question
about this be:  what is the requirement?  If access controls are allowed on
viewing/setting access controls, there must be some way to end the potential
recursion, and if attachment of access controls by reference is allowed,
then cycles should be prohibited.  I'd say that server implementors ought to
be able limit how many levels of this they'll support, including not
supporting it at all.  What access control applies to the most meta of the
access controls should also be left to the implementor.

So I'd propose a requirement:

"The protocol must provide an optional mechanism for setting access controls
on the viewing and setting of access controls, but need not (and probably
should not) support cyclic bindings.  The protocol should provide a
mechanism for a server to reject such an operation as unsupported, and
ideally provide a way for the client to determine, without side-effects,
whether the server supports this operation, and if so, how many levels are
supported."

Or, if the group prefers:

"There is no requirement for the protocol to enable access controls to be
set on the viewing and setting of other access controls.  The mechanisms for
administering the controls on the viewing and setting of access controls are
outside the scope of the protocol."

> Section 5.5 - Standard Access Attributes
>
> While I think it is appropriate for the requirements document to mandate
> that some set of rights MUST be supported by all servers I additional
> believe that we need to make it clear that it is up to the protocol to
> decide how to group these rights. For example we may create a "list"
> right which provides both the rights Judy lists in section 5.5.2 rather
> then two separate rights. The final decision should remain with the
> protocol designers.

The list of standard access attributes seems to me to be a requirements
issue, although I can imagine valid reasons for postponing the decision.
Could you elaborate on why you think it should be deferred?

By the way, is there a good reason to call these "access attributes" instead
of "access rights"?  I notice that you seem to prefer "rights", as do I.  I
guess if your model of ACEs is:

if <attribute-expression> then <allow/deny>

where rights may be part of the <attribute-expression>, e.g.:

if (access-type=read AND dns="*.foo.com") OR (access-type=modify) then deny

then these rights might behave just like other attributes which might be
used in the <attribute-expression>.  But then I would use "access
attributes" to refer to all of the kinds of attributes that may appear in
the <attribute-expression>, and refer to the rights as "rights", or maybe
"access types".

Personally, I prefer a model of ACEs that is more like:

if <attribute-expression> then <allow/deny> <rights>

which makes it a little easier to sort out the ACEs that apply to a
particular access type and to understand their effect..

> Section 5.6 - Discovery
>
> "Plain"? I think that term is inappropriate. I believe the requirements
> document should restrict itself to specify that discovery must be
> possible through a mechanism that is capable of producing machine
> processable output. Human readable descriptions, in my experience,
> actually hinder rather than help interoperability.

I agree.  The rationale:


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

seems to imply that software interpretation, as well as human-readability
are required.  Perhaps the text of 5.6.1 belongs in 5.6, and a new 5.6.1 is
needed, one which would justify the need for each of these.  Perhaps the
requirement for human-readability should actually be a requirement for a
textual representation, suggesting the use of XML, without making a value
judgment about its readability.

Thanks for the feedback.

Howard

Received on Tuesday, 14 October 1997 00:04:41 UTC