Re: HRAC decision object locality constrained?

[Konstantin Beznosov <beznosov@baptisthealth.net>]

My comments are inlined:

> a quick peep from the lurker's gallery: I see HRAC and QoP as
> orthogonal. I don't see HRAC making any new requirements for QoP that are
> separate from CORBAsec. I like the idea of QoP policy enforcer, but it can
> be separate from an HRAC access decision object. 

Actually, there is no intent to use ADO (decision object of HRAC) as "QoP
policy enforcer." There was a question during the first conference call
(6/30/98) if QoP for the particular secure association (in the context of the
current request to the ADO client) should be a factor in making authorization
decisions. 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.

If ADO is not locality constrained and we want to have a design allowing to use
QoP for authorization decisions, then current QoP has to be passed as an
argument of access_allowed().

> And, yes, I see no reason
> for an HRAC access decision object to be locality constrained. Note,
> however, that if it is not in the address space of the invoker, then you
> need security on the connection from invoking object and the HRAC access
> decision object. The recursion of the security-checking mechanisms could
> get tricky, but eh so what!?! that would be an implementor's headache, not
> a specifiers' headache!

agree.

> EJS
> ===
> At 01:08 PM 7/13/98 -0400, you wrote:
> >We discussed during last conference call the issue of having QoP as one
> >more factor in making authorization decisions.
> >
> >We decided to stay away from including QoP into the list of parameters for
> >access_allowed method. The decision had 2 rationales:
> >
> >1. Not everyone will need it
> >2. QoP can be obtained via Current provided that the HRAC decision object
> >is locality constrained (LC).
> >
> >Here is the question: Why should we impose the restriction of the HRAC
> decision
> >object to be LC?
> >
> >As far as I understand, making an interface is considered to be a last
> resort.
> >If my understanding is true, then we want to have better than just
> "because of
> >QoP" justification of making the decision interface to be LC. 
> >
> >Any thoughts?
> >
> >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. 
> >
> E. John Sebes
> -----------------
> Technology Officer, TIS Labs at Network Associates
> 408/346-3791
> ejs@tis.com


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