[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[COAS-List] Re: [hrac resources]
Gentle colleagues:
I'm Lost!
I have 12 years of experience in the computer security field:
most of which was spent attempting to understand the deeper
mysteries of access control and mediation (what we're basically
talking about in HRAC) and the associated models that attend
those disciplines.
Despite all of that, I don't have a clue what you're all
talking about. Or maybe, I have a clue, but can't believe that
you're making it so hard!
Let's back up a bit...
In my model of the world:
A RESOURCE is the kind of entity - which in HRAC is NOT a
*CORBA* object - to which access must be controlled. Examples
of RESOURCEs would be: records in a specific database, drug
prescriptions, medical professionals' credentials, and so on.
A RESOURCE INSTANCE is a specific example of the entity to
which access must be controlled. Examples of RESOURCE
INSTANCEs would be: one record in a specific database, a drug
prescription for a specific patient, and the medical
credentials for a specific doctor.
A RESOURCE ID is the handle, or name, by which the HRAC is
able to uniquely identify the resource it has been given and
thereby determine which policies must be used to decide whether
the supplied credentials indicate sufficient and necessary
authorization to allow access to the resource instance(s)
that it (the HRAC) is given to process.
RESOURCE SECURITY METADATA is the set of information, which
is either externally associated with a RESOURCE (e.g., provided
as a label on a file) or is a subset of the data that comprises
the RESOURCE (e.g., the HIV-Result field of a blood-test record),
that is used explicitly by one or more HRAC policies as the
basis for an access decision.
As near as I can figure, my confusion is the result of most
people on this discussion equating the RESOURCE with the
RESOURCE SECURITY METADATA. I see no problem with creating
an ADO interface that accepts only the RSM, but I am concerned
that we not confuse people by mis-labeling the RSM as a
RESOURCE.
-DMC
-----Original Message-----
From: Konstantin Beznosov <beznosov@baptisthealth.net>
To: hrac-rfp@cs.fiu.edu <hrac-rfp@cs.fiu.edu>
Cc: coas@cs.fiu.edu <coas@cs.fiu.edu>
Date: Tuesday, August 04, 1998 11:43 AM
Subject: [hrac resources]
>The example that was used in the minutes was just for illustration
purpose
>only. It was not intended to show how a good organization of
healthcare
>information should be done in a tree-like resource space.
>
>Also, I have to stress that even if we manage to come up with an
ideal concept
>of how to structure healthcare resource space, the concept itself
would not be
>able to prevent someone from abusing it and doing very unscalable and
>in-efficient resource structures. It's like with programming
languages: no
>matter how good a language is, someone can still write very bad
programs using
>it.
>
>So, let's try to answer the following question: "What organization of
resource
>space will allow us to express reasonable authorization policies?"
>
>In the context of this question, I was thinking about how resource
space can be
>organized in the following situation:
>(it's just an example)
>
>Security labels are used to assign a sensitivity level to all patient
>information. The following sample set of sensitivity levels is used
{public,
>protected, confidential}.
>
>Then all public information can be associated with resource:
>/PID/public. All confidential data can be associated with resource
>/PID/public/protected/confidential
>
>Where PID is PIDS-compliant patient ID.
>
>Do you think such a way of resource organization can satisfy most of
reasonable
>policies based on sensitivity level?
>
>Konstantin
>
>>
>> Comment on proposed resource management scheme from the meeting
minutes:
>>
>> > Access to the resource is granted if
>> > access is granted to every node in the path to the resource. For
>> > example, in order to have access to resource identified by
>> > /BHSSF/SMH/patients/JohnSmith/bloodtests/August-02/test-3 access
>> > should be given to /BHSSF, to /BHSSF/SMH, to
/BHSSF/SMH/patients,
>> > ..., to
/BHSSF/SMH/patients/JohnSmith/bloodtests/August-02/test-3.
>> > The described logic is the same as in access control model of
Unix
>> > file system.
>>
>> Agree this is a simple (Unix-file-system) model to manage access
control.
>> But this does
>> have implications for COAS. The directory hierarchy example has the
>> following types of
>> contextual information about an observation (a resource in HRAC):
>>
>> owner: Bhssf
>> location: SMH
>> patientID: patients/JohnSmith
>> conceptCode: bloodtests
>> date: August 2
>> instanceID: test 3
>>
>> obviously there is a mapping with the contextual information that
one may
>> record with an observation
>> and the tree hierarchy for resource management being considerd in
HRAC. the
>> problem is that
>> given the above set of dimensions, one may construct arbitrary
trees. One
>> can conceivably put the
>> patienID at the top node - given a patient info can from multiple
sites,
>> one can put conceptCode at the
>> top of the tree, etc.
>>
>> Also, i have no clue how you would implement the management of this
really
>> bushy tree. As soon
>> as you hit the patient node, you are going to have million leaves,
with
>> each one having potentially
>> hundreds (if not thousands) of items hanging off it.
>>
>> i need to think about this a bit more, and these are off-the-cuff
>> remarks....but it appears it might
>> be simpler to treat them as straight dimensions and we basically
have an
>> n-dimensional space -
>> and policy statements can involve one or more dimensions.
>>
>> - regards
>> - juggy
>
>
>----------------
>Broadcast message to hrac-rfp from Konstantin Beznosov
<beznosov@baptisthealth.net>.
>Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list
archive.