Re: HRAC decision object locality constrained?

[Konstantin Beznosov <beznosov@baptisthealth.net>]

John,

I think I found where we have miscommunication:

> >If ADO and QPE [QoP Policy Enforcer] 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.
> 
> The reason to separate them is because they are separate and because
> sometimes one is needful without the other. 

I believe that was our misunderstanding -- you thought I was trying to
eliminate QPE at all. I agree with you completely that QPE sometimes can be
needed without ADO. However, it does not prevent someone from letting ADO to
have functionality of QPE. It's like "you can have juice or you can have water
or yet you can have juice with water" (sorry for such a gastronomic example ;)

> In classical security
> architectures, there can be a whole set of distinct but complementary
> access control mechanisms that operate on the same data (what is being
> accessed, who is accessing it) but enforce different rules. Access is
> granted only if each distinct mechanism permits it. The
> MAC/DAC/Integrity/DenialOfService distinction are examples of distinct
> mechanisms enforcing distinct policies on the same kinds of access
> requests. 

In the case of HRAC, we are talking about an application invoking an ADO and
receiving a decision to grant access or not. We have to understand that by
granting the application the liberty of enforcing the decision or not, we have
already broken the classical model where application environment is enforcing
authorization decisions. 

> I suggest that CORBAsec access control (a la required rights),
> and QoP, and HRAC, are similarly separate, separable, orthogonal,
> complementary security mechanisms and policies.

I agree with your general statement. It's an important design principal.
However, I'm trying to play a scenario where an application first invokes  
if (ADO->access_allowed(resource, operation, credentials))
....
on ADO,
and in almost the next line, it invokes

if (QPE->access_allowed(resource, operation, credentials, qop))
....

on QPE.
What's wrong with this picture? :)

BTW, as far as I understand the spec, in a compliant implementation of
CORBASEC, an access decision object can take QoP policies into consideration
while making access decisions. It can do it because the object is locality
constrained (it can lookup QoP policy via current) and the logic behind the
interfaces can be almost whatever you want.

Any way, I think at least you and I clearly expressed our points of view on
this subject. I would be also interested in getting opinions of others. We can
talk about it more during the meeting of the submitting team next week in
Helsinki.

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.