[xacml] Follow up on TC call

[Daniel Engovatov <dengovatov@crosslogix.com>]

I will try to list some of my specific objections to the proposed schema modification.

 

1) Target matching.   I believe that since any complicated logic, like applying some rule to everybody whose second letter in last name is "n", can be easily and effectively expressed in the condition, target matching logic should be limited to operation allowing for effective indexing.  Namely - simple equality comparison that can be equivalently expressed as equality comparison of some canonic string representation of a particular data type, if not integer or string.

Or matching that can be reduced to such comparison for "hierarchical" data types, such as X500 names, where the "parent" name can be inferred from the

supplied value.   Applying of simple set operations, based on equality operation, such as, for example set-equal, or member-of, can also be effectively "flattened out".  I can not say that about arbitrary binary predicate operations - I and did not see any value in supporting such operations in target matching, as all the logic can be expressed in condition.

 

2) Extensibility.  While it is true that supporting just the few "higher-order" predicates is not trouble some, including of the <function>, as a legal argument to any extension function complicates the development of proper extension interface.  For example take an extension function "all-greater" that takes an integer, sequence of integers and returns a Boolean.  If some policy requires it, this can be implemented as a library with a very simple interface - you pass in canonical representation of integer data type and it returns a canonical string representation of a Boolean value.   Implementing such extension with <function> passed to it will require an interface with "callback" functionality - to allow the extension to invoke an arbitrary other operation.  For multiple bindings it becomes troublesome.  But since such argument is allowed - it has to be be implemented..

 

3) Redundancy.  There are easy ways to accommodate the same functionality in the Apply construct without extending the schema.

One either can add a specialized sequence functions for different underlying binary operations: such as aforementioned "all-greater".  This has a disadvantage of involving a large number of functions - several per each binary predicate, one per each *-map" function, but an advantage of simple interface and the fact that the implementation of the low level functionality can be done in some general purpose language not only for the build in operations.

Other way is to mimic <function> operation by including new data type listing allowable function names for a particular operation.  Inferring the proper data type can be done by either looking at the other arguments or by restricting the list of operations - it to be done by implementation of a particular functions to determine what operations are legal.

 

This approach has an added flexibility that the operations can be specified in context as attribute values.

 

4) Non sufficiency.  While the proposed extensions solve some problems, any complicated logic: such as "true if half the values is "foo" and non is "bar"" will still require extensions.  IF such extensions can follow some easily portable API, interoperability of implementations will be greatly enhanced.

 

In my opinion  a large portion of policies will require such extensions.

 

If there are no "operations" passed as values to such API, one can easily design a schema for such interoperability APIs, implement it as web service or commonly used component.

 

 

Daniel;