Re: ideas about the decision interface

[Konstantin Beznosov <beznosov@baptisthealth.net>]

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

It's correct. However, resources are passed to ADO only via its decision
interface. We can impose semantics on resources in 2 ways, as far as I
understand:

1. Pass resources via the decision interface (*access_allowed() methods) as
opaque data and describe semantics of resources somewhere in the spec outside
of the IDL code. In this case, it will be a contract between ADO and its
clients. The contract will specify something like this:
	Even though the resources are opaque, the first x bytes mean this, and
the next y bytes mean that and so on.

2. Pass resources as sequences of traits, for example, (or some other
structured data types), and define types of traits explicitly in IDL code and
semantics of those traits somewhere in the spec. It will still be some kind of
contract between ADO and its clients. But the syntaxes will be specified via
IDL code and be enforced by IDL compilers and/or ORB environment.


> I'm not sure that your example necessarily implies that the admin
> interfaces need know about resource structure or semantics. 

It's correct. Admin interfaces do not have to know resource structure and/or
semantics. This why I believe that decision interfaces should.

> 
> 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 requester 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.

I've got impression that we agree in general, but have different scenarios in
our minds. I'm sure it will clear the situation once we have several scenarios
described and depicted in use case, and interaction diagrams, as well as object
models of the decision facility.


Konstantin

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