MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: xacml, policy, issuer, combinator parameters...
The purpose of this note is to argue where the issuer of a policy should
reside.
I believe we all agreed that the PDP somehow has to be able to associate
an issuer with a policy, and it's only a matter whether we add it
explicitly to the policy itself or whether we use a separate external
element that links the policy (through a reference) and the issuer info.
First there is the observation, that we could rewrite the schema such
that we use external associations for all the policy content. The policy
itself would then consist of only a reference, and all other policy
elements/attributes would be bound to that policy reference through
external associations. This would work as long as the entity that has to
use the policy information "knows" where the associations are that it
needs to crunch. If that entity is the combining algorithm, then the
parameters are an easy vehicle to use for the associations that the
combining algorithm needs.
Note that this observation is equally valid for the policy target
element as for the issuer...
The only thing left are the practical, pragmatic, philosophical and
religious reasons why certain policy elements should be grouped together
in one envelope or why others should be separated out in externally
maintained associations.
First "my" philosophical/religious reason to make the policy and issuer
inseparable, are based on the believe that there is no policy statement
without an issuer - it just doesn't make sense. There is alway some
subject (implicitly) associated with a statement. The only reason we
have been able to ignore the issuer so far, is that the local "PDP" (or
how ever we want to call that local authority) has been the implicit
issuer of all the policies that it considers.
Which would point at another criteria for inclusion: a policy element
should (at least) include all elements/attributes that make it a
"policy". In other words, a policy should be a tuple that conveys the
"semantical" meaning of a policy... For me this would put the target and
rules back into the policy envelop ... as well as the issuer.
The other parallel I see is with the attributes we have, which also have
issuers associated with them. The attributes came in through some form
external assertions, like SAML. Why did we decide to add the issuer to
the attribute, and why didn't we add attribute issuer as a combining
algorithm parameters?
The reason for the latter is probably more historical ... but suppose we
could do it over again and start from scratch: where should the
attribute-issuer association be kept?
The practical/pragmatic reason is of course that we wouldn't have to
make any schema changes to the PolicySet/Policy type elements, which is
only a valid argument if we have to cut corners and such...
A related reason would be that we are still uncomfortable with all this
delegation stuff, and that a combining algorithm parameter solution
allows us to side-step the whole issue at the expense of some elegance
and purity...
In conclusion, adding the policy-issuer association as a combining
algorithm parameter would work but IMHO it is a butt-ugly hack... and I
would prefer to add the issuer info to the policy element.
Regards, Frank.
PS. Polar mentioned that there are possible "issues" when the issuer
would be included in the policy, but without giving more details it
sounds like FUD to me ;-)
--
Frank Siebenlist franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]