xacml — archive

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

From: Frank Siebenlist <[email protected]>
To: [email protected]
Date: Thu, 20 Nov 2003 23:46:00 -0000

MHonArc v2.5.0b2 -->

xacml message

Subject: Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell

From: Frank Siebenlist <[email protected]>
To: Tim Moses <[email protected]>
Date: Thu, 20 Nov 2003 15:50:56 -0800

Tim,

Tim Moses wrote:

> Frank - Let me see if I've got this right ...

and let's hope that I got it right...

> 1. An XACML policy has an identified issuer.
> 2. Whether or not a subject is permitted to issue a policy can be stated as
> an XACML policy (I'll call this an intermediate policy), which (in turn) has
> an identified issuer.  The issuer of a policy is treated as the subject in
> its immediate "upstream" policy.  So a chain is formed.  Valid chains
> terminate with the PDP.
> 3. The subject of an intermediate policy can be identified by name or by any
> other attribute.
> 4. The immediate downstream policy in a chain can be identified by name or
> by its contents using our ResourceAttributeDesignator and
> ResourceAttributeSelector mechanisms.
> 5. A combining algorithm will specify how the decisions from each of the
> policies in a chain are to be combined to produce the ultimate access
> decision.
> 
> Obviously, there are other subtleties.  But, I wanted to be sure I had this
> coarse level correct before delving further.
> 
> Is an action specified in an intermediate policy?

This last question really worries me that I haven't been able to explain the 
model well...

Your "intermediate policy" is essentially no different from any other policy, 
and the same policy can be evaluated for an actual access decsion in one case, 
or for delegating purposes in the next case.

Maybe an other example will help:

1. tim tries to read a file abc
2. pdp evaluates all available policies with (tim,abc,read) request context
3. pdp will only consider those decisions that evaluated explicitly to permit/deny.
4. suppose there is only one policy that rendered permit, and this policy was 
issued by frank.
5. the next step will be for the pdp to see if this issuer frank has permission 
to access the resource - if frank does not, he clearly doesn't have the right to 
say anything about tim's access rights to that resource. So, we have to take the 
original request context (tim,abc,read) and substitute frank in place of tim: 
(frank,abc,read), which includes both the original resource, action and the 
whole environment. With this new request context, we can find out whether the 
issuer frank who allowed tim read access to abc, is himself allowed to read abc.
6. if we evaluate all the policies with that new request context, and yield a 
permit decision for frank from a policy issued by PDP, then we've ended up at 
the root issuer and don't have to recurse further.

To re-iterate, the exact same request context with the original subject 
substituted by the issuer, has to be used to render the intermediate decisions.

Thinking about the subject categories some more, we may only want to substitute 
the access-subject category element with the issuer's subject information, and 
re-use the other category subjects of the original subject.
I can see that if there are policy statements that depend on certain attributes 
of for example an intermediate subject, that they are equally valid for the 
issuer as subject and for any policy that may apply to that...

> What about delegated attributes?  Is this outside the scope of your
> proposal?  Don't we need to solve this, too?

Yes, not really, probably ;-)
(I didn't really think of that part much ... any suggestions?)

Except for the last statement, I hope I managed to clarify the model a bit more.

Regards, Frank.

>