RE: [hrac resources]

[John Sebes <ejs@tis.com>]

Juggy,

I think that your example are fine, but should be completely unrelated to
representation or enforcement of security policy. For example you have a
tree of things like (patient-info (Labs (blood tests ...) (Discharge
summaries ...) (Outpatient Notes ...) ...). That's fine, but it looks to me
like a resource schema which would provide structure to actual resource
instances, i.e. would have pointers to some representation of a specific
cholesterol test on a certain date, etc. If a COAS concept code applies to
one or more of the leaves, I guess that is OK. But so far we haven't said
anything about security policy or access control rules! The details of the
schema don't and shouldn't say anything about this. In fact, I could see
applications that would want to implement multiple such schemas as
different views over the same underlying data.

You seem to be only the right track by specifying policy statements (e.g.,
if accessor is consultin_physician ...) as separate from any particular
schema. However, you may be getting a bit into the danger zone when you
talk about tying policy statements to nodes in a tree. Really what I think
you mean is that you tie policy statements (or access rules-- there is a
difference but not important here) to *groups* of resource instances. The
question is how you identify resource instances, how you specify the
groups, and how you associate the rules with the groups. 

Perhaps what you are getting at is some idea of how a hierarchical schema
(instances of which may contain multiple resource instances) helps to
identify resource instances and membership in groups. If so, then that
sounds fine with me. Sounds like there is a lot of complicated information
to represent, and the hierarchical structures seem to help. 

Secondly, you are right in pointing out that the resource instance itself
(and any data it contains, and any data associated with it via a schema or
otherwise) and the access rule isn't enough; you need information about the
accessor as well. However, when you talk about a tree of relationships, I
get uncomfortable. That's because is not as obvious to me that the
hierarchal representation is indicative of real inter-relations of real
domain-specific info. In the resource side of things, the hierarchy stuff
seems to model useful data dependencies and inter-relations that are
actually meaningful in the real world. Your hierarchy of "relationships"
seems to me like part of a hierarchical role-based access control model. 

It is not clear to me that the complexity is needed. But regardless, the
most important thing is to abstract away from it. As with resources, you
need to represent accessors (by information in credentials plus perhaps
other stuff derived from same), and you need to specify how the accessors
are grouped. Whether a hierarchy of roles is useful or not shouldn't be an
issue. What should be an issue is how to have a flexible way of
representing and grouping principals who may be accessors of resources.

Thirdly, you have an example that ties together info about the accessor and
the resource, and called a policy statement:
>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 :-)
In spirit yes. In practice, I would abstract away from the two clauses
"physician=consulting physician for patient" and "resource-type=blood
tests". You have a simple case where a single criterion is sufficient for
establishment of the accessor's membership in one group and the resources's
membership in another. There may be lots of criteria, and you don't want to
duplicate the logic in every rules. What you do instead is bundle the logic
into separate areas of policy statement. So for example you can have a rule
like:
        A principal is in the "Typical Viewer of Lab Results" group if 
        the principal is "consulting physician for patient" 
        or "resident working in patient's ward" or ...
and also a rule like:
        A resource is in the "Typical Lab Results" group if 
        resource-type=blood_test and does not contain HIV data 
        or resource-type=urine_test ... or ...
and finally a bunch of rules like:
        If principal is in group ""Typical Viewer of Lab Results" and 
        resource is in group "Typical Lab Results" then grant access

Each of these three different kinds of rules can encode different kind of
information (and require different kinds of authority and responsibility to
assert) so it is very useful to have them be separable for management reasons.

EJS
===
----------------
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.