RE: [hrac resources]

["V. Juggy Jagannathan" <juggy@careflow.com>]

I seem to agree as I read this - but would dearly appreciate examples to
elucidate various
approaches :-)

- regards
- juggy


> -----Original Message-----
> From: owner-hrac-rfp@cs.fiu.edu [mailto:owner-hrac-rfp@cs.fiu.edu]On
> Behalf Of John Sebes
> Sent: Wednesday, August 05, 1998 4:48 PM
> To: hrac-rfp@cs.fiu.edu
> Subject: Re: [hrac resources]
>
>
> 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.
>

----------------
Broadcast message to hrac-rfp from "V. Juggy Jagannathan" <juggy@careflow.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.