Re: [xacml] Rule References

[Polar Humenn <polar@syr.edu>]

> On 5 June, Polar Humenn writes: [xacml] Rule References
>  > Once rules incorporated referenced from outside the policy, it becomes 
>  > unwieldy, as you cannot specify the evaluation semantics of a policy in 
>  > the face of dynamically updating outside rules.
>  > 
>  > Rules can change dynamically underneath the URI. I don't like this.
> 
> This is identical to the current situation with a PolicySet.  The
> policies included via <PolicySetIdReference> and
> <PolicyIdReference> can "change dynamically underneath the URI".

What I was hoping for was to use be able to use the Policy definition for
the semantic definition of what is behind the Policy interface in the
CORBA Resource Access Decision (RAD) service. The RAD has
"administration" interfaces for combining policies. So, if things are
changed, they are changed semantically by contract by virtue of executing
those operations on the service that combines the policies. If things get
changed, then there are the proper "notifications"  and everybody knows
what is going on.  This all happens at the granularity of Policy.  What is
missing is a definitional language for the Policy.

Now, with a policy language, it gives a complete semantic definition to
the whole access decision question. Remember we had this argument long
ago. Remember the argument about how you couldn't really say anything
about whether you had one "initial" Policy or many policies because you
had no semantics about their combination at an administration level. The
PAP, PDP, PEP do not have comprehensive integrated interfaces.

Notwithstanding, the definitions do get *easier* once you start
referencing everything.  However, the only reason you want these
references is NOT to cut down on definition bulk (as XML is so verbose
already), but to operationally reference Rules because you want them to
change on the fly.

Currently, as you suggest, you must "wrap" each of those rules in a
Policy, and combine them in a PolicySet.  What better more defined way to
do that, being that we have approaches to encapsulate the Policy with
signatures, for integrity and such? It is the minimum point of
administration. Now you have to extend that administration to Rules as
well? You end up doing the same thing, only twice, in two different spots.

The "wrap" gives you the framework and a single administration point with
which to combine the policies, such that if they change you have a better
handle to manage evaluation, notification of change, etc.

I'll grant you, it seems all so simple if you are using XACML to replace
the Java Policy File, as that probably just gets fully evaluated top down
from each invocation.

Make the system bigger with components representing various XACML
entities, and now when a Rule suddenly gets changed behind its URI, then
there must be some upward notification involved. Therefore, you need to
make sure you have notifications upward from the Rule level as well as the
Policy Level, complicating matters. Since the rule targets may change the
targets of the policy (effectively), then the Policy must notify any
encompassing Policy Set.

Of course anything can be done, but the more you throw in, the more
complicated it gets. You just open up a whole bunch of operational worms,
just for definitional ease, and the perception that you are actually
making things *more* functional, when you can be crippling other more
complex systems.

> Currently, I find I keep creating a <Policy> solely because I
> need a <Rule>.  The <Policy> element serves only to be a <Rule>
> wrapper that allows the <Rule> to be referenced from a
> <PolicySet>.  This is a workaround, but it means the resulting
> policies are much wordier than necessary.

Wordiness is not my concern as the wrap doesn't take much,

However, my concern is that if we are to use XACML for the RAD, we would
have to yet again "Profile" something too unwieldy, (such as the X.509
fiasco) just so we can use it effectively, such as eliminating Rule 
References. Ugggh.

This approach usually results in definitional complexity (yet another
"companion" document), and subsequently inadequate specifications (i.e.  
document mismatch, misinterpretation).

Case in point, we have these obligations, which nobody, but IBM would dare
use.  So, we must "profile" them out.

I know some things are going to have to change with the RAD if XACML is
going to be effectively and fully be used. (Such as policies are retrieved 
via resource and operation only, not by subject, or the environment). But 
that only means adding an interface or two. 

However, if rules are referenced, which can quite possibly outside the
system with spurious URIs, they will be outside the administration model
for the RAD. Making it work will be just too much duct tape, glue, and 
paint.

Just my $0.02, worth about 28,502 Turkish Liras.

Cheers,
-Polar