[COAS-List] RE: [hrac resources]

[John Sebes <ejs@tis.com>]

I strongly support a view that is a composite of views expressed by Dave
and Juggy: 
  - first you have to distinguish different kinds of resource and different
instances of each kind
  - second you have to determine what facts about a resource (or instance
of a resource) govern the access control decision
  - you must also take care determine which facts are represented as part
content of a given instance, versus facts that are associated with an
instance ("metadata")
  - third you must be able to express an access control rule in terms of
these facts
  - at the most primitive level, these rules are composed of expressions
about "attributes" and "value" (e.g. date and 3 Aug 1998, owner and bhhsf)
  - finally, there are tricky inter-dependencies between way that you
represent the attribute/value pairs amd the way that you represent the
access control rules that apply to them
  - it is very easy to cook up an approach to one of them (representing
attributes and values) that create management problems for the others (how
to specify access control rules for all the jumbillion resource kinds you
have and the 15 bazillion stompilion instances you have).

This brings us to a very important question: "What organization of resource
space will allow us to express reasonable authorization policies?" Juggy
has suggested that perhaps a hierarchy isn't all that helpful. I couldn't
agree more. The simplest structure for access control rules is simply an
unordered list of attribute/value expressions, where each one states what
kinds of values for a specific attribute are permissible (or required) for
access to be granted. If you jump into a hierarchical structure without
having a strong reason to do so (i.e. lack a strong semantic model) you
quickly get confused about that the hierarchy means. For example, in this
thread of discussion, people have asked whether one particular attribute
name (e.g. owner) has to be implicit as the first element of a hierarchical
name, and whether the ordering of a name provides strictly conjunctive
semantics (each of the steps in the hierachy has an attribute/value
relationship all of which have to be satisfied) and whether there is
disjunctive semantics (alternate rules, only one of which needs to be
satisfied) via links across the hierarchy (similar to Unix symlinks) or
cycles in the hierachies (a special case of link). Once these questions
arise, you know you're already in trouble and need to back up.

Here's an example from our work of how to specify access control rules and
how these relate to (a) unrelated groups and (b) groups with subset
relationships (a.k.a. hierarchies). Everything is a resource instance. Each
instance is of one kind of resource. Each kind of resource has a default
access control rule that is defined in terms of attribute/value
expressions. Resource instances are associated with groups of resource
instances, and each group is associated with an access control rule. There
is a default group associated with the default rule, and all instances of a
kind of resource are part of this group unless they are put in another
group. A non-default group of resources has a non-default access rule. That
rule can be completely different from the default rule, or can simply add
additional conditions to it, in order to represent additional restrictions
on access to instances in the group that are not applicable to instances in
the default group. So far we have grouping for scalability, but no
hierarchy. Hierarchy can be added by putting the *groups* into a hierarchy
(but not specific instances and certainly not individual attributes!!!) For
one group to be subsidiary to another means that instances in the
subsidiary group have to satisfy the access rule of the subsidiary group
and also the group that it is subsidiary to. In many cases, complex
hierarchy is not needed. We try to keep it simple by having each group be
subsidiary to only one other group, in a directed Acyclic graph. Cyclicity
and multi-parenting can be accomodated by a more complex access control
algorithm, but most often at the cost of preventing mere mortals from
understanding one another's policies or even their own.

That's about it. We have tools for grouping and simple languages for
expressing rules; and we have a separate calculus for grouping accessors
and relating them to rules.

Just my $0.02 but I don't see an obvious need for HRAC to be a potentially
complex and semantically rich hierarchy model.

EJS
===