XACML Wish List
Below are the examples, requirements, use scenarios and general things that users wish to be solved by XACML
1. Quality of Service Decisions
These Scenarios assume that a PEP is itself, or is part of a logical unit that is, capable of providing more than binary access control. I believe that in a real world scenario such an assumption is practical as it is not uncommon to see an access control system span environments which provide tiered resources.
Scenario 1 ''Static QoS on resource identity''
action: read (get)
www.foo.bar is a represented by a PEP that fronts two physical devices: weakling and herc.
- weakling is in some way inferior to herc (be it type/breadth of information available, physical performance, etc.)
there are two groups on the system: paid and free.
Decision: The Policy Writer wishes to provide access (route) to herc for those Subjects that are a members of the paid group/role.
Scenario 2 '''dynamic QoS (environmental)'''
action: read (get)
www.foo.bar is a represented by a PEP that fronts two physical devices: itchy and scratchy.
itchy and scratchy are identical servers that are provide the same functionality
Decision: The Policy Writer wishes to provide access (route/redirect) to itchy or scratchy depending upon which responds first to a whoIsFree test.
Scenario 3 '''Polymorphic Resource (filtering)'''
subject: Bill | Dr. Bob
action: read (get)
- www.foo.bar/myrecord.document represents a data source with discrete data components that are filterable. This may be as course as truncating attachments in an email file or as granular as "sanitizing" words in a document.
Decision: The Policy Writer wishes to provide access to both Bill and Dr. Bob, however only after filter X has been applied when Bill requests and filter Y is applied when Dr. Bob requests the resource.
The dilemma in the Scenarios above is that a binary decision cannot provide sufficient information to answer the access request questions, e.g. "Can Bill access www.foo.bar?" because there may be multiple answers ("Yes, grant him access to herc," or, "Yes grant him access to weakling.") The reason that there is a many-to-one ratio of requestedResources to physicalResources is that it is impractical to require the PEP to query all possible resourceInstances for access. Additionally, the Subject may have access to both systems but preference/priority is given to the "better" system unless it unavailable (which introduces another concept "fall back decisions", but that is a note on a different day since it would only make sense IF parameterized decisions were possible ;o)
In the case of filtering you have a situation where access control may be techically defined as Permit|Deny decisions, but that level of information alone is insufficient to describe the level of detail necessary. In essence what you have here is sub-resource access control.
(taken from a post by Erik in response to the original email)
This is similar to a requirement we have been discussing in our work with network based defense. I some cases we would like to differentiate between regular permissions and "emergency" permission, so that the use of the latter would be logged in a special manner and audited more thoroughly than other accesses. The logging requirement can easily be expressed in an obligation, but if there is both a regular permission and an emergency permission for the same access, we would like the regular permission to take over so that no special auditing will be done.
2. Discovery queries
This is related to Items 13 and 14 in IssuesList. Can someone write Request and Response xml samples for these features?
3. Set difference operation
It seems that provided set operations in the specifications are incomplete, as they do not provide a way to do difference of sets.
I suggest that we add "type-except" (or type-difference, I slightly prefer except for being used in some other places) with a description:
"This function SHALL take two arguments that are both a bag of type values. The expression SHALL return a bag of type such that it contains all elements that are in the first argument that are not in the second argument. No duplicates as determined by "urn:oasis:names:tc:xacml:1.0:function:type-equal" SHALL exist in the result."
A use case would be to remove a particular value(s) from a bag/set.
4. Formatting of PDF documents: exclude line numbers when ctrl-c
I noticed that when copying multiple lines from our spec PDF documents, the line numbers get included into the copyied content. For example, if you want to copy-paste a paragraph, then the line numbers get copied. It's incovinient when using "Read out loud feature" of acrobat reader. In SAML specs line numbers are skipped when highlighting and copying text from the PDFs. I'd wish we make our PDFs like SAML's ones.
5. Merge PolicySet into Policy
The current three layers of policy constructs (PolicySet/Policy/Rule) is one more than is really necessary. By allowing a Policy to embed or reference another policy it would be possible to eliminate PolicySet and a lot of the redundancy that goes with it.
- Instead of separate policy combining algorithms and rule combining algorithms (which largely duplicate the policy combining algorithms) we would have just "combining algorithms".
- The XACML core would be smaller.
- The XML Schema would be smaller.
- Implementations would be smaller and more efficient.
- The scope of variable definitions would be extended to cover sets of policies.
6. Targets as Conditions
The lack of expressiveness of targets is a perennial problem that could be solved by defining targets to contain an XACML expression instead of AnyOf. The Match element could be retained as a member of the Expression substitution group to ease translation from XACML 3.0, and because Match is a more concise representation than the equivalent as an Apply expression. The XACML core and XML Schema would still be simpler as a result.
7. first-applicable-target combining algorithm
True case-statement-like behaviour is not possible with the first-applicable combining algorithm when the cases may evaluate to NotApplicable (this would cause the policy [set] evaluation to check the next case rather than return with NotApplicable. A first-applicable-target combining algorithm would check only the target of each child until it found a target that was applicable, and when it did, fully evaluate the corresponding child and return the result. To allow combining algorithms like first-applicable-target, I propose that rules should retain both a target and a condition even if targets are changed to contain XACML expressions.
8. Conditions on Obligation Expressions and Advice Expressions
Obligations and advice are awkward to define and use when the scope of applicability of an obligation or advice is not aligned with the targets of existing policies and policy sets. Conditions on obligation and advice expressions would allow them to be placed in an outer policy set with a sufficiently wide scope while the condition restricts the applicability to relevant subcases. See these email threads for more discussion:
9. Polymorphic Functions
The practice of defining datatype-specific comparison, set and bag functions leads to a lot of bloat and repetition in the XACML function definitions which could be reduced by using polymorphic functions. For example, instead of defining a separate equal function for each data-type there would be a single equal function that would apply the appropriate equality comparison semantics for the data-type of its given arguments (or Indeterminate if the data-type doesn't have an equality relation or is unknown to the implementation). The current arithmetic, relational comparison, set and bag functions could all be replaced by a much smaller set of polymorphic functions.
10. Decimal Data-Type
There isn't a convenient data-type for representing currency amounts in XACML policies. Using the existing double data-type leads to rounding errors from conversion between decimal and binary, and implicit fixed point integers are not natural or straightforward for ordinary users. An explicit decimal data-type would be better. With polymorphic functions there would be no need to define any new functions to process decimal values (of course, some of the polymorphic function descriptions would need to be extended).
11. Default values for MustBePresent and IncludeInResult
I find it annoying to continually provide the MustBePresent XML attribute on attribute designators and the IncludeInResult XML attribute on XACML attributes when they are nearly always set to "false". I would rather see these attributes being optional with an assumed value of "false" when omitted. There are probably other XML attributes that could be given default values, but these two bug me the most.
12. XACMLAuthzDecisionQuery parameters should be in Request
The XACML SAML profile defines additional PDP capabilities within the parameters of the XACMLAuthzDecisionQuery element. These capabilities are not otherwise made available. These capabilities should be part of the core specification with the additional parameters being part of the XACML Request element instead.
13. AdministrativePolicy[Set] in the core XML Schema
With regard to the administration and delegation profile, there has been discussion on the mailing list about labelling policies and policy sets as administrative policies or policy sets instead of using category prefixing. That labelling, in whatever form it eventually takes, should be reflected in the core XML Schema.
14. Generalize the request context into a graph of entities
XACML is limited when it comes to making decisions using the attributes of entities that are related to the principal entities of access-subject and resource (this topic has been extensively discussed in the "Attributes of Relations" email thread). Attribute "flattening", the process of pushing these attributes of related entries into the access-subject or resource, doesn't handle one to many relationships well because it loses the correlations between the attribute values. My own proposal for a solution calls for reinterpreting the request context as a graph of entities with links described by XACML attributes and additional expressions types in the <Expression> element substitution group to traverse the links. These additional capabilities would be better described in an updated XACML core rather than a standalone profile.
15. More to come...