Re: [hrac resources]

[John Sebes <ejs@tis.com>]

In response to Konstantin's question (which I may paraphrase as, if we
don't use trees then what do we use) I will elaborate on the very important
point that:
>> the proposal was directed at the 
>> structure of resources not the structure of resource metadata. 
This is a very good idea, but unfortunately the following does not follow
from it:

>> each element of a path is a resource with which security metadata
>> (e.g., name/value pairs as John describes) about that element may be
>> associated. 

Here is how I suggest using a hierarchy, in such a way that in many cases
the hierarchy will be flat or at least very shallow, and where complex
linking and cyclic semantics is not needed:
1. Each element of a path is *not* a resource, but simply the name of a
container of resources. Analogy: non-terminal elements of a path are
directories; terminal elements (resources) are files; file data (contents)
and metadata (access time, owner, ...) are entirely separate from the shape
of the directory structure and the names of directories.
2. The end of a path is the name of a resource instance.
3. Resource "directories" simply group resources into blobs which share an
access control rule
4. The application of a common rule (common to a group) varies from
resource-instance to resource-instance b/c each resource instance has
different data/metadata 
5. Again, the names of the "directories" and resource-instances do not
carry any policy-semantic information. However, there is a mapping from a
directory-name to an access rule, and from a resource-instance name to
data/metadata that are input to an algorithm which evaluates the access
rules for a specific resource-instance.
6. The parent-child relationships of the directories do not *have* to carry
any policy-semantic information. That is, you could have the
resource-instances in a parent directory be subject to one access control
rule, the resource instances in a child directory be subject to a different
rule, and have no relationship between the rules. (The parent-child
relationship is to have have your resource-instance-groups live in a name
space more human-comprehensible than a large flat space.)
7. However, one *could* conceive that parent-child relationships might
indicate a relationship between access rules, i.e. in order for access to a
given instance to be granted, the access must be granted by the access rule
associated with *each* directory on the path of the name of the
resource-instance. I don't suggest that this would be useful (naming rules
and using specific link/embed relationships would be better IMHO) but it
*is* a conceivable way that a hierarchy could be used to represent some
policy semantics without doing the very unwise thing of encoding metadata
and access rules into paths by assigning semantics to each value of each
element of every pathname.

>> The resource structure may be independent of any metadata
>> structure. The resource structure may not have any relationship to metadata
>> structure.
Not 100% sure, but this seems to be related to point #5 above.

> What the intended (HRAC) service is
>interested in regards to resource is ability:
>1. To relate a resource identifier to a set (or group, or chain) of
>authorization rules, and 
>2. To obtain enough data to evaluate those rules and arrive to authorization
>decision.
I beleive that my numbered points provide an example of how to do these
things, without some of the excess semantic baggage of  examples discussed
earlier in this thread. Furthermore, Konstantin's suggestion below is an
excellent suggestion, to complement *any* method of organizing resource
instances:

>Maybe if we explicitly
>distinguish them and decide what way we want to go, then we can
concentrate on
>the selected one and refine it.
>
>Data used in rule evaluation (i.e. #2) can be decomposed into three groups:
>a. Data pertaining only to the principal credentials (roles, groups,
access id,
>etc.)
>b. Data pertaining only to the resource identified by the resource identifier
>(patient ID associated with this resource in healthcare, for example)
>c. Data derived from a relationship between data from a and data from b
>(relationship between the principal and the patient associated with the
>resource as of the healthcare domain).

Yes, yes, and yes. For (a) you define rules that map information about
principals into a group, effectively putting each principal into a group in
which all members share the same access rights. This is essential for
scalability and for sane policy management. For (b) you define rules which
map resource instances to access rules which evaluate the data listed by K.
in (b) above; the resource ID name space (flat, hierarchical, whatever) is
one way to do this; so is a DB which maps resource instance ID (of whatever
form) to an access rule (or ACL or whatever you want to call it) where many
instances are associated with the same rule. Again, this is criticial for
scalability and managability. And finally for (c) you define rules that
state what kinds of access under what conditions principals have, by virtue
of membership in the groups of (a).

There remains the question of how you obtain the full set of data (meta or
otherwise) about a resource instance in order to make an access decision
about it. Konstantin suggested the following taxonomy of alternatives.
>1. Pass only resource id to the ADO. In order to obtain the data the ADO is
>supposed to go elsewhere and use resource id to find the data.
>2. Pass only resource id  to the ADO and use it as a carrier of the data.
Where
>as, 
> a. data syntaxes and semantics of the data are predefined and assumed.
> b. data syntaxes is not assumed. Data is represented by parsable tag-like
>structures. Semantics of data is predefined elsewhere.
> c. syntaxes and semantic of data are defined elsewhere and a reference to
>those definitions is passed along the data itself.
I favor an approach that smells like (1) or maybe (2c) but really leaves it
as an implementation detail: have the resource instance ID be something
opaque that might be just a name that you use as in (1), or might be a
bunch of encodings (or one of various flavors like (2)) but is,
fundamentally opaque. An ADO implementation can do whatever it needs to do
with one of these IDs. The insides of how ADOs work (WRT data strorage,
representation, flow, and access) is something that a good spec is agnostic
about.

And finally, for the CORBAsec cogoscenti, if this line of thinking sounds
familiar (part of the object state is which policy it is subject to, the
policy is an object that can contain access control rules, ...) it should
be-- it is structurally similar to the way the CORBAsec spec is structured,
though without the notion that rules are expressed in terms of required
rights. For HRAC, the main issue is what can the rules say? The management
structure whereby rules are associated with resource instances (which is
the topic of this thread) is really a side show. The CORBAsec spec makes a
clean separation from the management stuff (which is actually rather hard
to specify interoperably) from the stuff about how access control decisions
are computed. The HRAC spec needs to have the same clean separation.

EJS
===
PS: I'd be interested in whether Bob Blakeley has an level of agreement
here, or whether I have taken the form (if not the name) of his CORBAsec
work in vain!

----------------
Broadcast message to hrac-rfp from John Sebes <ejs@tis.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.