OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[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 
> 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 
>>>                    <SubjectAttributeDesignator
>>>                    <ResourceAttributeDesignator
>>>                        AttributeId="owner-id"
>>>            </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 
>>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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]