[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hrac resources]
Since we did not determine terminology for resource, resource id, etc., those
words are used interchangeably right now, and I'm not surprised such usage
introduces confusion. It looks like it's high time to define resource-related
terminology. I think, David did a good job in the message above. I'll go ahead
and extract his definions into addition to the existing terminology section.
Also, see my comment in-lined.
Konstantin
> Gentle colleagues:
>
...
>
> 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.
What does the word "uniquely" mean in this context? Does it mean 1:1 mapping?
Taking the above definition of resource ID (RID) I think the only case when RID
would be used is when authorization rules do not take into account any other
RSM (see below for RSM definition). In all other cases, I doubt that actual RID
should be passed to ADO via the interface of ADO to ADO client.
>
> 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.
>
> ----------------
> Broadcast message to hrac-rfp from "David M. Chizmadia"
> <dmc@tycho.ncsc.mil>. Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse
> the mail list archive.
----------------
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.