RE: [xacml] Modeling Delegation of Rights in a simplified XACML w ith Haskell

[Tim Moses <tim.moses@entrust.com>]

Frank - Yes.  Clarified.  But, I was expecting that your solution would also
solve the "pilot" use-case.  It doesn't, does it?  All the best.  Tim.

P.S. For those who aren't familiar with Frank's "pilot" use-case, it allows
the issuer of a policy not to possess the privilege that it delegates.

P.P.S. What if the delegator and the delegate are both permitted access
under disjoint rules?  Example: PDP permits access by people in the West of
the US.  Frank, who lives on the West Coast of the US and therefore has
access, grants access to people who live in the East of Canada.  Tim lives
in the East of Canada.  Both Tim and Frank are granted access, but only
Frank satisfies the PDP's requirements.  Is this what we want?

-----Original Message-----
From: Frank Siebenlist [mailto:franks@mcs.anl.gov] 
Sent: Thursday, November 20, 2003 6:51 PM
To: Tim Moses
Cc: 'XACML TC'
Subject: Re: [xacml] Modeling Delegation of Rights in a simplified XACML w
ith Haskell


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