When you send a XACML request, you always send a set of attributes with one or more values. You would either send:
- an attribute with identifier gender, datatype string, and category subject, or
- an attribute with identifier male, datatype boolean, and category subject.
Either way you still send an attribute. In one case the value is a string. In the other the value is a string. In the explanation below, I take the string approach. If you want the boolean approach, just replace gender=="male" with male.
Note that in XACML, attributes may possibly not have a value. This makes XACML booleans more than just boolean. Male could be true, false, or undefined. Keep that in mind when you write a policy / rule.
To express negative conditions e.g. not(gender==male), you have two options:
- either the set of possible values is finite e.g. true/false, male/female, hot/warm/cold and you are happy building a policy or rule per case.
- or the set of possible values is too long or infinite e.g. a numerical value or a list of citizenships (180+ of those).
In the former case you can write the following (pseudo-code in ALFA):
policy checkGender{
apply firstApplicable
rule male{
target clause gender=="male"
permit
}
rule female{
target clause gender=="female"
permit
}
/**
* Optionally add a catch all case
*/
rule other{
target clause ... // Here you'd have to define other checks you are interested in
}
}
In the latter case, you need to write a negative condition. To do that you need to use a XACML condition. Since XACML conditions only live inside rules, you need to go down to the XACML Rule level.
policy checkGender{
apply firstApplicable
rule notMale{
condition not(gender=="male")
permit
}
}