Re: HRAC decision object locality constrained?

[Konstantin Beznosov <beznosov@baptisthealth.net>]

John,

my comments are inlined

> Konstantin,
> 
> I think you contradicted yourself! WRT QoP let me juxtapose a couple of
> your comment without (I hope) bashing context:
> 
> >there is no intent to use ADO as "QoP policy enforcer." ...
> >A simple rule could be like this ".... if QoP >= Confidentiality"
> >For such a rule, ADO's decision logic will look at the QoP and make
> >decision accordingly.
> 
> What you call "making a decision accordingly" is exactly what I mean by
> enforcing a policy. Your ADO wants information about the level/kind of
> protection (e.g. is it confidential) in order to decide if that meets the
> access requirement for *quality* of protection. If not (e.g. conf is
> required but there isn't any for this request) then your ADO would reject a
> request, right? 

no. The ADO will reject a particular access operation on a particular resource.
More than one access operation on more than one resource can be performed
during single CORBA request.

> The QoP *policy* is the set of rules about when you should
> or should't honor a request based on the level of protection it is. 

I did not find a definition of "QoP policy". The spec defines only QoP:
"QOP: Quality of Protection. The type and strength of protection provided by a
message-protection service."

I would define QoP policy as a set of rules how messages sent and received by
an application should be protected. There is difference between what you wrote
and what I wrote. In your definition, the stress is on honoring or not a
request. In mine, on how a request or reply should be protected.

> This
> kind of policy is very different from the "what level of protection will I
> use here," it is more like "did the other party use the right level of
> protection for my needs?"
> 
> Sooooo, I think that you ADO seems to be enforcing QoP policy. And coupling
> a general kind of policy like QoP with some policies that meet more
> specialized needs, well, it seems unneeded. Not necessaily unwise or
> impractical, just not actually needful. 

Try to look at the use of QoP information as yet another factor in a decision
of authorizing a client to access resource x by using operation y. In that case
it becomes less controversial.

> 
> My opinion that QoP is its own distinct area, should be dealt with as such,
> and in the ideal secure ORB of the future it would be possible to add (when
> needed) a QoP policy enforcer as another one in a series of policy
> enforcers that must rule on a request.

Such QoP policy enforce (let's call it QPE) would have to be contacted by an
application service, correct? And QPE will have to apply some rules to make a
decision. The decision will be in the form yes/no. Where the meaning of "yes"
would be "yes -- grant access to the resource x with operation y and QoP == p
to the client/principal in question" and the meaning of "no" would be "no --
don't grant access to the resource x with operation y and QoP == p to the
client/principal in question". Isn't it again an authorization decision?

If ADO and QPE will apply the same set of rules and use the same set of factors
in order to make a decision with the only difference that QoP information will
be excluded in making decisions by ADO, then I do not see a point in creating
yet another object with almost the same logic behind it and the the same
semantics of its service -- check if access is allowed.


> 
> I'd be interested to hear supporting or opposing views.

I think you got it :)

Konstantin
-----------------------------------
Distributed Computing Architect
Baptist Health Systems of South Florida
voice: 305.596.1960 x6469

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