[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft proposal for new work item: properties for new combiningalgorithm
>It seems to me that allowing arbitary XML content >under some Property tag is pretty dangerous, I agree. I posted another proposal to the list that uses attribute element. >I have some of the same concerns about it that I >have about this property idea. The motivation I had is different from yours. While XACML allows venders to use their local combining algorithm, the current schema does not allow to specify any algorithm-specific arguments in the policy. Priority for rule is just an example. Hierarchical information for rule might be another example. If the property thing satisfies some of your concerns, it would be great. >I really don't like this idea. Targets are meant to >be simple things that can be evaluated easily. You may have misunderstood my opinion. I clarified in the separate mail so please refer to: http://lists.oasis-open.org/archives/xacml/200304/msg00050.html I think we are in the same camp. Michiharu Kudo Seth Proctor <Seth.Proctor@Sun To: Michiharu Kudoh/Japan/IBM@IBMJP .COM> cc: XACML TC <xacml@lists.oasis-open.org> Subject: Re: [xacml] Draft proposal for new work item: properties for new combining algorithm 2003/04/23 03:03 > 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 :)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]