Re: fwd: Re: ideas about the decision interface

[barkley@sdct-sunsrv1.ncsl.nist.gov (John Barkley)]

<Probably I did not express well what I was asking about. The issue is if we
<want the access decision object to be aware about the resource space structure.
<
<If not, then the notion of wild-cards can not be used in the decision rules.
<Let me explain what I mean by the wild-cards in decision rules.
<
<For example, let's assume, that we have authorization policies based on
<security labels and each piece of patient medical records has a sensitivity
<label from the set <public, sensitive, confidential, private>. Then, we want to
<be able to express some rules in the way resembling the following statement:
<
<Patient's attending physician has READ access to 'confidential' parts of the
<patient records.
<
<The statement above, in my opinion, uses implicitly the notion of wild-cards.
<In order to evaluate such a rule, the decision facility should be able, besides
<other things, to analyze the resource and find out the resource sensitivity
<label. Also it needs to find out the relationship between the originating
<principal (we assume the principal is associated with a human-been) and the
<patient associated with this resource (a resource owner, in other words). In
<order to do it, the decision facility has to understand to some degree (i.e.
<probably not completely) the resource semantics. I can see only one way to do
<it: structure the resource and to give the decision facility an ability to
<parse the data packaged in the resource and, if possible, to find information
<like patient ID of the resource owner and sensitivity label associated with
<that resource. It does not necessary mean that the decision facility has to
<understand all information packaged in the parameter "resource".
<
<What do you think?
 
First, I think some confusion results from the fact that my 
comments about resource structure applied to
the methods which you have just proposed for the access decision object.
In other words, the methods access_allowed() and 
multiple_actions_access_allowed() should not have to be aware of resource
structure. They just consult the rules and give a response.
 
I believe your example is really referring to what the administrative
interfaces must know about the resource semantics.
I'm not sure that your example necessarily implies that the admin
interfaces need know about resource structure or semantics. 

Consider the following implementation
strategy for your example. One has a database of patient records. Each
record is made up of fields (columns in relational lingo). Each record
is a resource and each field is a resource. The client of the access decision
object (ADO) knows this. Given a request for certain fields of a
specific patient record, the ADO client calls the ADO which applies
the rules for that record and if the requestor has the requested access
to the record, then the ADO client calls the ADO for each requested
field. So far, the ADO need not know that there is a relationship between the
field resource and the record resource, i.e., fields are contained in
records.

Consider now the admin interfaces of the ADO. Some admin tool calls the
ADO admin interfaces. Presumably, this tool must know the structure. Suppose a 
sensitivity label is an attribute of each field resource (as an aside,
I should point out that an access control list with entries referring
to roles should work equally well and is likely a more natural metaphor
for an administor). By means of the admin tool, an administrator is able
to set the label for any field and define the following rule:

A requestor's credential which contains the role attribute value 
"attending_physician" is granted READ access to a field resource with the label
attribute "confidential". 

I believe that this is the equivalent of the rule in your example, that the
ADO does not need to know that fields are contained in records, and that
although there is the notion of "wildcard", a wildcard character is not needed
in a language describing the above rule.

When you say:

<probably not completely) the resource semantics. I can see only one way to do
<it: structure the resource and to give the decision facility an ability to
<parse the data packaged in the resource and, if possible, to find information
<like patient ID of the resource owner and sensitivity label associated with
<that resource. It does not necessary mean that the decision facility has to
<understand all information packaged in the parameter "resource".

I think that you are assuming that what many call resource attributes 
(the labels in your examples) are "part" of the resource itself. This is
usually not the case. If it is, then I think one has "content-based access
control" which from the last conference call, I thought everyone agreed was
not required by the RFP.

My impression from the discussion so far is that the ADO 
interfaces support some fixed basic access control
mechanism like RBAC enhanced to take into account time of day
and location. This fixed basic access control mechanism can be extended in
an implementation to include other mechanisms like labels and/or some 
kind of "predicates" that can be associated with  resources and/or resource 
classes.  These predicates allow the specification of access policy for those 
examples in the RFP (and others that might arise) which can't be handled by
a fixed mechanism.

jb
----------------
Broadcast message to hrac-rfp from barkley@sdct-sunsrv1.ncsl.nist.gov (John Barkley).
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.