[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [hrac resources]
maybe i am beginning to see some light :-) thanx, John! let me try out these
examples on you all :-)
the following assumes that organization (tree, forrest or ADG) CANNOT
include patient ID or resource ID.
here is an example:
patient-info
|
Labs
| |
| --- blood tests
| |
| alcohol level test
| |
| cholestrol tests
|
Discharge summaries
|
Outpatient Notes
|
.........
In COAS they are talking about associating a conceptCode with each
observation (a resource in HRAC).
This concept code can map to one or MORE leaf node in the above
organization. This also suggests
that one ties rules to nodes of the above tree. But as Konstantin pointed
out, there are three types
of information that is needed by policy rules:
1. credentials of the person accessing the resource
2. what is being accessed on whose record
3. relationship of accessor to accessee (hope i have this right :-)
so that seems to imply that you cannot tie policy statements just to nodes
of the above tree -
as it does not have all the relevant information. One can potentially have
another tree of relationships:
Relationships
|
primary care provider
|
attending physician
|
consulting physician
|
care team for episode of care
|
ward nurse
|
attending physician
etc.
Then presumably you can have policy statements such as:
if physician=consulting physician for patient and resource-type=blood tests
then permit access
Let me know if this is what you all have been talking all along :-)
the above example is simplistic - one may want to include a variety of
Resource Security Metadata as part of
the rules above.
- 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.