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

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

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.



> -----Original Message-----
> From: Frank Siebenlist [mailto:franks@mcs.anl.gov] 
> Sent: Tuesday, November 18, 2003 2:12 AM
> To: XACML TC
> Subject: [xacml] Modeling Delegation of Rights in a simplified XACML with
> Haskell
> 
> 
> Dear colleagues,
> 
> At the last F2F, we had extensive discussions about how delegation of rights
> and 
> the associated admin of policy could be implemented in xacml.
> 
> At the very end of the F2F, we concluded that it was best to come up with a
> more 
> "formal" way of describing the different ideas, such that it is easier to
> reason 
> about and to discuss the underlying model.
> 
> After Polar came out with his "The Formal Semantics of XACML" paper, he 
> convinced me that the use of a pure functional language may be a good way to
> 
> explain and discuss new xacml language features, like delegation.
> 
> So, I started to model a subset of xacml in haskell, and to see how
> delegation 
> schemes would be rendered in that environment.
> 
> You can find the current snapshot of that work at:
> http://www-unix.mcs.anl.gov/~franks/haskell/XacmlDelegationHaskell0.html
> 
> I realize that most of you are new to haskell, but my hope is that because I
> 
> myself am a haskell novice also, that I could pull some of you along the
> same 
> learning curve that is reflected in the document. I've tried to add
> complexity 
> to the model gradually in stages as I was trying to get my mind around the 
> problem. So, if your mind works a little like mine, you may be able to learn
> 
> with me. If your have a normal mind, then you may be out of luck ;-)
> 
> Please note that nothing is set in stone, there are still some issues to
> work 
> out, and suggestions and comments are most welcome.
> 
> Enjoy, Frank.
> 

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