Before you guys all forget the problems you ran into while implementing, I thought I would try to solicit material for an XACML Implementers Guide. The intent would be to alert XACML implementers to subtleties in the specification that require particular attention. I did not do an implementation myself, so the attached list is just a starter to jog your memories and try to elicit more (or more accurate) material. Once we get an initial pass over this list from the TC, I suggest we post the list to xacml-comment to solicit a wider response. Anne -- Anne H. Anderson Email:
Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 Title: Potential topics for an XACML Implementor's Guide Author: Anne Anderson Version: 1.1, 03/01/16 (yy/mm/dd) These are potential topics to go into an XACML Implementor's Guide. The intent is to alert implementors to subtleties of the specification that need particular attention in order to avoid problems. - "Notional" Request context: o Request context can not be treated as static XML document o AttributeSelector evaluation can not depend on just XPath processing because even if the XPath expression does not return an attribute value, it will be necessary to invoke some sort of "attribute locator" to look for the referenced attribute in external databases. Suggestions: o Parse input Request.xml as a starting point for evaluation of AttributeDesignator (AD) and AttributeSelector (AS) references. o Define an "attribute retrieval" interface that takes as input an AD or AS and returns the matching attribute value, error, or "not found" result. The implementation of this interface first looks for referenced AD or AS in the parsed Request.xml. If attribute not found there, then implementation invokes an external attribute location API. This API should support plugins for different ways of locating attributes. The plugins should be configurable for particular LDAP repository locations, etc. - Functions o x500Name-equal: can this use a standard Java method? o rfc822Name-equal: local part is case-sensitive, domain-part is not case-sensitive - Bags o A singleton bag is NOT the same as an instance of the datatype contained in the bag. All the equality predicates, arithmetic functions, string conversion functions, numeric data-type conversion functions, Boolean functions, arithmetic comparison functions, date and time arithmetic functions, non-numeric comparison functions, and special match functions take only primitive data types as arguments. They must return Indeterminate if a bag or singleton bag is used as input. - Date and time arithmetic functions o Can these use implementations in "XQuery 1.0 and XPath 2.0 Functions and Operators"? - Combining algorithms o Note that the policy-combining version of each algorithm is different from the rule-combining version. o policy-combining version of Deny-overrides can NEVER return Indeterminate under any conditions. o First-Applicable: The "applicability" test is based solely on evaluation of the Target. The first rule, policy, or policyset whose Target evaluates to "true" is evaluated, and that result is returned even if the evaluation of the condition for the rule(s) evaluates to "NotApplicable". Thus it is perfectly possible to return a result of "NotApplicable" from a "First-Applicable" combining algorithm even if there were subsequent rules or policies that would have returned Permit or Deny. - MatchId o A function used in a MatchId (used in Target) is not passed the arguments directly. An iterator takes the first argument to the MatchId and iterates through each element of the bag returned from evaluating the second argument (the AttributeDesignator or AttributeSelector) and passes those two elements to the MatchId function. o The same function, when used in a Condition, is passed its arguments directly without any iterator intervening to handle bags. - Hierarchical resources o Hierarchical resources in XACML are under-specified. For example, ? o - Subject categories o When evaluating AttributeDesignators, all attributes of all Subjects that have the same SubjectCategory are lumped together as if they belonged to a single subject. o An AttributeSelector may distinguish between different subjects that have the same SubjectCategory by effectively asking for "Attribute A in the same subject that has a value of X for Attribute B".