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] Beginner query

Hi Paul.

> I am wanting to permit a request, provided certain attributes are
> present. I don't care about their value, just the fact that they are
> present. I cannot see any way of doing this without implementing my own
> match function. Is this correct or have I missed something? I believe my
> final policy doc would look like this:

You're right that one way to do this is to implement a custom function,
or as Anne suggested, you could do some operations that will always
return true as long as the value is present. My preference would be to
do this in a Condition as a custom function, but that's a matter of
style. Note that AttributeDesignator has a flag on it to require that an
attribute value be present, or the result is Indeterminate. You can't
use this just as a test for presence, but it's a good way to assert that
a value is there.

Note that there has been extensive discussion in the past about a "must
be present" function. The challenge is that presence of attribute values
is not as simple as it may sound. If all you want is "must be present in
an XACML Request" this is easy to think about. The problem, of course,
is that XACML works over an abstract context, where attribute values may
be gathered from arbitrary locations. It's often very hard to test for
the presence of any given value, which is why negative policies and
rights are such a scary thing for so many of us :)

Rather than testing for a value's presence in a policy, you might think
about having the PEP include some logic where an attribute is always
included, but with different values based on whether your initial
attribute is available or not. Then you can match on the string (or int,
or boolean, or whatever) in the policy. It's a little cleaner, and will
make policy evaluation faster. Just another way to think about this.


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