[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-users] Sample with matching attributes of subj and resource
Kuketayev, Argyn wrote: >>I'm a little puzzled by what you're trying to do here...my >>comments are >>inline. I'm fighting a nasty cold today, which is probably >>why I'm not >>getting it :) > > > Actually, u got everything right, imho. Oh, good :) >>[...] >>That's a valid Condition, but of course the extra "or" function isn't >>needed, since "string-equal" returns a boolean, as you note >>in your next >>example... > > Right, but this is just a fragment of my rule, which I used to test the > construct. The real rule has several <Apply> elements in <Condition>, > and the result should be OR'ed in this case. Gotcha. In that case, both approaches do make sense. > [skip] > >>... but the tests only need to cover >>a Condition >>with a boolean function and some number of nested elements. > > I understand that Condition is of the same type as Apply, according to > Policy schema. So, if we have a test with Apply and "string-equal" > function with two string arguments - which we have- then we should be > fine with Condition and "string-equal" function, if XACML was > implemented ina reasonable way. On the other hand, it's still a > different element, and test wouldn't harm, imho. Anyways, I wouldn't > insist that the test is necessary. It's just I'm using CTs when I look > for examples to create my policies. It's nice to have a lot of examples, > that's really it for me. I agree that if you're looking in the tests for examples, then more tests makes a lot of sense. Of course, if we tried to handle each of these scenarios, there would be many, many more tests. I think what you're really getting at is the need for a non-normative collection of examples. I have suggested doing something like this in the past, but no one has had the time. I try to provide a few examples in my implementation, but I'm clearly not providing enough. I've thought about trying to put such a collection together at some point...maybe I'll make some time this fall to do just this... >>>Now, this one didn't work: >>>================== >>> <Condition >>>FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> >>> <SubjectAttributeDesignator >>> >>>AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" >>> >>>DataType="http://www.w3.org/2001/XMLSchema#string"/> >>> <ResourceAttributeDesignator >>> AttributeId="owner-id" >>> >>>DataType="http://www.w3.org/2001/XMLSchema#string"/> >>> </Condition> >>>================== >>> >>>SunXACML complained for illegal types. Debugging shows that >>>string-equal func expects single value, but gets a bag. So, >> >>the attr >> >>>designator returns a bag. Surprise for me. >> >>That's right. This shouldn't work. The spec is pretty clear that >>AttributeDesignators always return bags of values, even if >>there is only >>one (or none) matched values. This is why the *-one-and-only >>functions >>are provided. >> > > I see, it's just so inconvinient to put these one-and-only everywhere. > These are used often enough to think about how get rid of them :) You'll get no argument from me :) It is very inconvenient, both from the point of view of the policy writer, and from the evaluation engine (which takes a small but nonetheless real) performance hit in practice. This topic was discussed in great detail during the 1.0 specification. There was concern that allowing functions to automatically handle bags with one element would break the strict type system. There was some discussion about other approaches, like having a "one-and-only" attribute on Designators or Applys, but in the end the current approach won out as "cleanest." Sorry. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]