Re: [xacml] xacml, policy, issuer, combinator parameters...

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

If you have an edge server that does the authentication and an 
application server behind it where access control decisions are made, 
then the app server *says* (ssl-session key *says* (edge-server key 
*says* (edge-server-DN *says* access-subject is polar))). In other 
words, we have learned to deal with all these different entities in the 
validation trust chain such that we can insert "polar" as the 
access-subject in the request context.

If we use an external attribute validation service, which we send all 
the saml assertion that will get validated on their signatures and such, 
and which will give back a simple statement that "polar stated that 
frank is part of the friends group": validation svc *says* (polar *says* 
frank is friend).

If we validate an x509 certificate with a subject name polar, then we 
may have to jump through hoops, cross certification, processing 
incomprehensible extensions, and end up with the app service x509 
validation code *says* (x509 church/religion *says* access-subject name 
is polar).

In other words, we deal with these construct all the time right now, 
without having to consider any policy issuers. In the end, however, we 
manage to process and validate the different assertions such that we can 
"simply" add them in the end as binding that were issued by "some" 
entity. Along the way we have to make authorization decisions about the 
made statements, and one could even argue that for some one could use 
xacml/pdp again... but that is all with the purpose of filling in the 
request context for the original question whether an access subject can 
invoke an action on a resource.

Again, I do not see why this is any different with policy assertions, 
and why this has anything to do with the question where we keep the 
issuer-policy association.

This was really my last email about this ;-)

-Frank.




Polar Humenn wrote:

>On Mon, 19 Jul 2004, Frank Siebenlist wrote:
>
>  
>
>>I simply don't understand why you even want to have a discussion of how
>>a policy "written" by polar becomes "mine".
>>    
>>
>
>because it happens all the time.
>
>And given the element, it just makes that sort of thing possible, possibly
>leading to ambigous behavior.
>
>  
>
>>The reduction: polar *says*
>>A & frank *believes* polar => frank *says* A...  is at the heart of the
>>proposed scheme....
>>    
>>
>
>True, the logic of Abadi, Burrows, Lampson, and Wobber, the following is
>valid in all applicable models:
>
>Polar says A
>Frank believes (speaks for) Polar
>
>then
>
>Frank says A
>
>However, we must be really careful about this.
>
>First and foremost, if you have a policy that states "Polar says A", then
>who said that statement? This policy may be a lie. Furthermore, you may
>not even know who Polar is.
>
>So, the fact that Frank *believes* Polar
>
>has no real effect if indeed, Carol says (Polar says A).
>
>So, the question is not that Frank *believes* Polar. It may be one of,
>does Frank *believe* that somebody else says Polar says A.
>
>it gets complicated, but we can work through it.
>
>My point, is that if you put that <Issuer> in the policy, the policy no
>longer just states who has access, but now states somebody else says who
>has access, and there is a complicated question if that should be
>believed, and where it should be believed.
>
>Putting the "issuer" as a combining parameter associated with a
>particular policy states to the combingin algorithm that "this issuer"
>states that "this policy" says who has access. and in the context of "this
>combining algorithm" we have a mechanism for discovering and validating
>the authority chain.
>
>If <Issuer> is to exist within a policy, what does it mean?
>What does it mean in the context of a combining algorithm
>Furthermore, the real question that must be answered, must be
>What does an <Issuer> element mean for *all* combining algorithms?
>
>Cheers,
>-Polar
>
>
>
>
>  
>

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