Re: [xacml] Modeling Delegation of Rights in a simplified XACML withHaskell

[Frank Siebenlist <franks@mcs.anl.gov>]

Von Welch wrote:

> Frank Siebenlist writes (21:21 December 3, 2003):
> ...
>  > But, also permit-overrides doesn't address all the use cases well...
> 
> Frank - can you elaborate on the hitches here?

Ideally, you would not have to use any explicit deny policy because it makes the 
reasoning about the overall policy much more difficult.

The issue of not being able to narrow the subject scope when you equate access 
rights with delegation rights as pointed out in the next paragraph could be 
addressed by cleverly adding some explicit deny policies that somehow should 
kick-in, but would complicate the understanding of the consequences of each 
policy statement considerably.

>  > The real issue with this access right => delegation right model is that one can 
>  > narrow the scope of the resource and actions in every subsequent delegation 
>  > statement, but you can't narrow the subject.
> 
> Just to make sure I understand, what you mean by this is that is,
> e.g., I delegate "Boat:Drive" to Frank, I have no way of controlling
> who Frank may delegate "Boat:Drive" to (besides preventing him from
> delegating at all)?

Correct.

An other example is the use case where you want to outsource the admin policy 
for a foreign domain to an administrator. In that case you would want to limit 
the subjects that this admin can manage to only those from that foreign domain 
(maybe through some group membership attribute). Again, with only 
permit-override and access equates right to delegate, you can't...

>  > The more correct way to address this is a scheme where the admin policy is 
>  > expressed as a function of the tuple (issuer, subject, resource, action), with 
>  > attributes of course. This allows a PDP to specify that an other subject as 
>  > issuer, john, is allowed to specify access control policy for the subject mary 
>  > on resource boat and action drive. In other words, the PDP can narrow down the 
>  > potential subjects that john is allowed to manage the access rights for, to a 
>  > single mary.
> 
> I assume it is still the case that someone has to have a right to
> delegate it?

Correct.

> Walking through the broker use case (#2):
> 
> PDP says Frank has some set of rights... (Frank, Boat, Drive), (Frank,
> Car, Drive), etc.
> PDP says Frank may delegate any rights to anyone "(Frank, *, *, *)"
> 
> Frank says Broker can drive boat "Frank says (Broker, Boat, Drive)
> Frank says Broker can delegate drive boat to anyone "Frank says
> (Broker, *, Boat, Drive)"
> 
> Broker says resource can drive boat "Broker says (Resource, Boat,
> Drive)"
> 
> Could this be modeled with an "Allowed delegatees" attribute on
> rights?
> 
> PDP says Frank has some set of rights and can delegate to anyone
> (Frank, Boat, Drive, Allowed_delegatees=*), (Frank,
> Car, Drive,  Allowed_delegatees=*), etc.
> 
> Frank says Broker can drive boat and can delegate to anyone "Frank
> says (Broker, Boat, Drive, Allowed_delegatees=*)
> 
> Broker says resource can drive boat "Broker says (Resource, Boat,
> Drive" (no Allowed_delegates indicated undelegatable right)

If I understand your "allowed_delegatee" well, then it is identical to the 
issuer in the tuple (issuer, subject, resource, action) which I mentioned in the 
following snippet:

 >> The more correct way to address this is a scheme where the admin policy is
 >> expressed as a function of the tuple (issuer, subject, resource, action),with
 >> attributes of course. This allows a PDP to specify that an other subject as
 >> issuer, john,is allowed to specify access control policy for the subject mary
 >> on resource boat and action drive. In other words,the PDP can narrow down the
 >> potential subjects that john is allowed to manage the access rights for, to a
 >> single mary.

It is probably more clear to write:
"issuer: P(allowed_delegatee,subject,resource,action)".

Thanks for showing how you can narrow the scope of the subjects in subsequent 
delegated policies through this "allowed_delegatee"

-Frank.


> 
>  > The latter was essentially what I initially proposed at the last F2F, and I'm 
>  > trying to model this again in similar fashion as the others. I actually believe 
>  > that we could implement this in the current xacml, by defining an 
>  > issuing-subject category for the request context's subjects, with the addition 
>  > of associating issuers with a policy/policyset.
>  > 
>  > In the end, I hope that we can make a choice between the different combinator 
>  > and reduction schemes, and find the one that makes most sense, is easiest to 
>  > understand and least "surprising".
>  > 
>  > Regards, Frank.
>  > 
>  > 
>  > -- 
>  > Frank Siebenlist               franks@mcs.anl.gov
>  > The Globus Alliance - Argonne National Laboratory
>  > 
>  > 
>  > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>  > 
> 

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory