Re: [xacml] Draft proposal for new work item: properties for newcombining algorithm

[Seth Proctor <Seth.Proctor@Sun.COM>]

> There are several ways to support arbitrary
parameters in the policy.

It's somewhat unlcear to me whether you're really
talking about arbitrary parameters here since the
example you give is specific to priority. Are you
talking about allowing arbitrary tags to provide
arbitrary parameters, or are you talking about
adding specific new tags? I think it's the former,
so I'll add my thoughts on this. Apologies in
advance if I've got this wrong.

It seems to me that allowing arbitary XML content
under some Property tag is pretty dangerous, both
because people could abuse this like crazy but also
because all the careful type systems in XACML get
thrown out the window. In my opinion, if you're
going to add a feature like this, I'd rather see it
use XACML Attributes. This way at least you always
know what kind of data you're dealing with and you
can easily reject data that is inappropriate for a
given algorithm. That said, I'm not sure that I'm
just crazy about this idea, but I'm willing to be
convinced.

This is actually related to something I came across
last week while writing some interesting policy
examples. I have a Policy that can effectively be
used as a function to define membership by using a
specific action defined in the Target of the Policy.
I then reference this Policy from other PolicySets
and use the result (conceptually) as the return
value from a membership function. I was thinking
that it would be cool to be able to include
attributes in the policy reference and have those
show up in the request when the referenced policy
was evaluated (a la function parameters). While I
think this is an interesting idea, I have some of
the same concerns about it that I have about this
property idea. Still, it seems like they have a
common thread, and so if properties were supported,
I would suggest that some common mechanism using
attributes should be used to inject values into the
request for any number of tags...the request
attributes could then be used by a combining
algorithm (for example) as input. Of course, this
raises a lot of questions about overriding values,
what a policy should and shouldn't define, how to
keep this managable, etc, which is why I'm not sure
I'm all that crazy about this idea. Still, I thought
I'd add this view to the conversation.


> - Another extension: support environment in target
element

I really don't like this idea. Targets are meant to
be simple things that can be evaluated easily. More
to the point, they're supposed to represent where a
policy is stored in some data system so that it's
easy to retrieve the few candidate policies that
might apply. When you start adding environmental
data, this can become much harder. I don't think the
spec suffers from having to put environmental
conditions in the Condition...and in the case you
give it seems that an action attribute is just as
appropriate anyway.Sorry I'm so down on this idea,
but I've spent the last two weeks building systems
that use custom databases to store policies in
clever ways, and right now I'm squarely in the camp
[1] of people who think that XACML is already
complex enough and shouldn't get things like this
added without a _really_ good, clear reason. Again,
however, I'm willing to be pursuaded that this is
important if there are compelling use cases.


seth


[1] I'm also willing to accept that this may be a
camp of one :)