Re: ACL Draft

Yaron,

>    The basic model for access control, informally expressed, is that
>    who you are determines how you can access a resource. The "who you
>    are" is defined by a "principal name"; users, client software, and
>    servers have principal names. The "how" is determined by an "access
>    control list" (ACL) associated with a resource.

Ok, but most of the Web-based access control mechanisms I've seen allow the
principal to be described or qualified by IP address or DNS name patterns.
If the intent is not to support that, I'd like to discuss that point in
more detail.

>    An ACL contains Access Control Elements (ACE). An ACE specifies a
>    set of principals, a set of granted rights, and a set of denied
>    rights.

As I mentioned before, I like the ACL/ACE model, but your model of the ACE
seems more complicated than necessary.  I could see where it would make
sense if only one ACE in one ACL would ever apply to a particular
principal, but since you include the notion of a "compound principal", this
cannot be guaranteed.  Therefore there must be a way to resolve or avoid
conflicting access control policies between ACEs which happen to apply to
the same principal.  One might suppose that this would be done by favoring
the ACE with the most specific principal specification, but that would
require some assumptions about the nature of compound principal
specifications, such as a strict hierarchy of principal groups.  Even given
that, what if the ACE with the more specific principal specification
happens to be dynamically inherited from a collection, rather than attached
to a specific resource?

So I'd claim that resolving conflicts between ACEs using specificity as the
dominant characteristic will not work unless the model is further specified
in such a way that specificity is always well-defined.  But I'd rather see
a model that assigns a controllable ordering or precedence to ACEs.  The
Netscape model makes use of both syntactic ordering and a precedence flag
to resolve conflicts.  Granted rights and denied rights are specified in
separate ACEs, which is reasonable because conflicts are resolved in a
uniform way.

>    Rights may be generic, such as "read", "write", or "delete", or they
>    might be specific to the kind of resource protected by that ACL,
>    such as (perhaps) "send-to", "unsubscribe", and "administer" for
>    mailing lists.

Maybe rights should be defined in a named "access rights profile", which
could be defined and registered for different types of resources.  We could
start with a profile for the generic rights.  Collecting the rights in
profiles this way would enable the protocol to convey the list of supported
rights more efficiently by expressing it as a list of profiles.

And yet again, the existence of generic and specific rights creates another
dimension in which conflicts can potentially occur between ACEs.

>    When a resource is created it inherits a set of default ACL
>    properties from a designated resource, referred to as an ACL source.
>    The inheritance can be "static", so that subsequent changes to the
>    ACL source do not effect the new resources ACL properties; or it can
>    be "dynamic", so that subsequent changes are reflected in the new
>    resource's ACL properties.

I heartily endorse your terminology for what I was calling non-lazy and
lazy inheritance.  However, I'm still concerned about the complications
that can arise in supporting dynamic inheritance.  A fundamental
requirement for access control policy is a certain clarity in its
representation.  Lack of clarity ultimately can lead to lack of security.
Dynamic inheritance is a fairly large step away from clarity, in my view.
The same can be said of mechanisms for resolving ACE conflicts, when these
mechanisms are complex or vague.

>    Properties on a resource have, by default, the same ACL as the
>    resource. However individual properties can be given their own ACLs.
>    The ACL property on the resource also contains information regarding
>    the ACLs of any properties on the resource, if those ACLs are
>    different from the resource's.

That seems to imply that ACLs have some kind of "target" information, which
indicates whether they apply to properties of a resource, and if so, to
which properties.  But that need only relate to the storage of ACLs on the
server.  In the protocol, it sounds like you intend that ACLs on properties
are independently addressable.

>    [Ed Note. This draft deserves the name "rough draft". It is being
>    released for consideration of the ACL model it proposes. The
>    intention is to replace the property based model defined herein with
>    an ACL method. The reasoning being that it is a bad design decision
>    to define any mechanism based on "side-effects." In this case, by
>    setting the ACL property to a certain value the ACL on the resource
>    gets set to the same value. The new ACL method based version should
>    be out in a week or two.]

That sounds like a real enough concern, but I don't think I understand it.
Care to elaborate on how that could create a problem?

> 2.   Granting and Denying Rights
>
>    An ACL can both grant and deny rights. The reason both types of
>    grants are required is because of compound principals. A compound
>    principal is a principal that represents a number of other
>    principals. For example, a user group in UNIX.

Ok.  But can a compound principal describe an open set of principals in
terms of attributes they may possess, or does it imply the existence of
something like a user database, in which all of the principals
corresponding to a compound principal can be enumerated?

>     The consequence of the existence of compound principals is that
>    there are times when a compound principal may be granted a right but
>    a particular member of the compound principal may need to be denied
>    access. In order to make this possible an ACL must be able to list
>    principals both allowed and denied a right.

That depends on how flexible you can be in defining compound principals.
For example, if a compound principal can be specified as "all Beatles
except Ringo", you might find that you don't need both "grant" and "deny".
The Netscape model does have very flexible compound principal
specifications, but I still advocated supporting both "allow" and "deny",
not because they were necessary to express particular kinds of policies,
but because I believe that they can contribute to the *clarity* of
expressing certain policies.

>    By default all rights for a principal MUST be denied. Rights MAY
>    only be granted to a principal by an explicit listing of that
>    principal in a "grant" section of an ACL.

That goes against the grain of tradition in Web Servers, where no access
control meant no access control.  However, that originated in the days when
HTTP was read-only for the most part.  But it's no big deal either way,
provided that a "universal principal" is defined, that is a reserved
compound principal specification that refers to all principals, even
principals who do not authenticate, e.g "anyone".  That way, it's easy to
attach an ACL that changes the default.

>      The following rules, processed in order, MUST be used to resolve
>    scope conflicts between rights.
>
>    1) In a conflict between a right granted by a parent and a right
>    granted by a child, the right specified by the child MUST override.
>
>    2) In a conflict between a right granted or denied to a compound
>    principal and a right granted or denied to a member of the compound
>    principal, the reference to the member of the compound principal
>    MUST override.
>
>    Note that rule 2 is conceptually identical to rule 1. The concept
>    represented by rules 1 and 2, stated generally, is that a specific
>    references always overrides a more general reference.

Ok, so rule 1 takes precedence over rule 2?  That's one way to do it:
instead of ordering the ACEs, order the rules that resolve the potential
conflicts.  Been there.  Considered that.  Bleh!

> 3.   ACL Inheritance
>
>    When a new resource is created it may inherit its ACL from its
>    containing resource. This inherited ACL MUST be applied to the
>    resource before it is available for manipulation. Thus the resource
>    will never be in a state where it does not have access control
>    protection.

Is "containing resource" a well-defined concept?  What about hierarchical
collections of resources?  Are ACLs inherited from multiple levels?

>    Inheritance can either be static or dynamic.

I agree that the model should allow for access control to be applied to a
resource during its creation, but I think it should deal only with static
assignment of initial ACLs, and even then, not get into where the initial
ACLs may have originated.  Basically, when you create a resource, a server
may statically assign some ACLs to it at creation.  As the creator, you
would normally be able to view and change these ACLs after resource
creation.  On the other hand, dynamic inheritance need not be prohibited,
but a client needs to be able to distinguish between views of ACLs on
resource as including or not including dynamically inherited ACLs.  You
might want to see dynamic ACLs when you're trying to determine the rights
of a particular principal, but the presence of dynamic ACLs could add
significant complexity to the operation of setting ACLs.  For example, if
the client cannot distinguish dynamic from static ACLs, what happens if the
user unknowingly elects to change a dynamic ACL?  Some kind of dialog box
like:

    "You don't realize what you're asking
     and you're probably going to be sorry.

        Ok      Cancel      God Help Me"

?
Actually not, unless it came from the server, since the assumption was that
the client can't distinguish between dynamic and static ACLs.

Perhaps I can use your dislike of "side-effects" to dampen your enthusiasm
for dynamic inheritance?

> 4.   Properties and ACLs
>
>    Properties MAY have their own ACL independent of the associated
>    resource. By default a property's ACL MUST be dynamically inherited
>    from the associated resource.

Nevertheless, dynamic inheritance seems to make sense here.

>    For purposes of applying scoping conflict resolution rules the
>    resource is the parent and the property is the child.

"containing resource" becomes clearer.

>    Compliant resources are not required to support setting ACLs
>    directly on properties.

That's fine, but I think it would be good if the protocol definition
included an optional, standard way to do it.

> 5.   Owner Property
>
>    Name:            owner
>    Namespace:       http://www.ietf.org/standards/acl/
>    Purpose:         Specifies the owner of the resource.
>    Values=          Principal
>    Description:     The owner property specifies the principal who owns
>    the resource. The default value for this property is the principal
>    who created the resource. The owner always retains the right to
>    alter the ACL. So, for example, an owner who was not granted the
>    right to read the resource could not read the resource. However the
>    owner could alter the ACL so as to grant the read right to himself.
>    A principal MUST have the writeowner right to change the owner
>    property's value. All compliant resources MUST support the owner
>    property.

The nature of a principal identifier should enable client software to
answer the question,"Does the current user own (a certain)  resource?"
Even if principal identifiers are opaque, they need to disallow aliases, or
provide a way to enumerate the aliases of a principal, or provide a way to
resolve an alias to a canonical form, in order for this to work.
Alternatively, the protocol could provide a way to answer questions about
relationships between principals, by posing those questions to the server.
Questions such as:

  What is my principal identity?  (Require me to authenticate and return a
principal identifier for my identity.)

  Do two given principal identifiers refer to the same principal?

  Is a given simple principal a member of the set of principals described
by a given compound principal?

Actually I'd like to hear some arguments about why principal identifiers
should be opaque, if you'd be kind enough to indulge me.  I claim that
"open authentication" can be supported without this, since a principal
identifier for our purposes need not be the same as a principal identifier
used during authentication.  Authentication can be viewed as associating
the user with a particular "user resource", and that user resource could
contain, for example, an ASN.1 object identifier that could serve as the
principal identifier for the user.  Or perhaps the "user resource" would
actually have a corresponding URL that would serve.

However, it seems to me that "open authentication" does require a "who am
I?" mechanism, whether principal identifiers are opaque or not...

...unless the assumption is that only clients and servers which grok the
same "opaque" format can interoperate with respect to access control
management.

Howard

Received on Wednesday, 22 October 1997 07:02:26 UTC