OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: Comments on the XACML 3.0 commitee draft 1 (16 April 2009) during the public review period

XACML 3.0 Comments:


Note: These are my personal comments but they resulted from the experiences made during the work within the OGC (especially the last test bed phase OWS-6 and the work done within the GeoXACML Standards Working Group).


Before I start criticising, I’d like to mention that some major changes incorporated in the new 3.0 version are exactly what I/we was/were looking for. For example the new Target definition which adds so much flexibility is really great. Now we can e.g. directly represent the access control system context information (defined as an XML document) under a XACML Content element of category environment in a decision request. Another really helpful change is that obligations per rule are allowed now. This is very helpful in case you enforce access control on Web Service requests and if you use the obligation mechanism for query rewriting.



Change Request 1: AttributeSelectors must be able to select element nodes


Remove the restriction that XPath expressions evaluated by an AttributeSelector are not allowed to select element nodes (Line 2392-2395). This restriction contradicts XACML 2.0 line 3270 and XACML 3.0 line 3184.


Certain use cases need complex data types in XACML (e.g. GeoXACML’s Geometry data type). A geometry Attribute is defined by the following XML code:


<gml:Polygon srsName="http://www.opengis.net/../epsg.xml#43">



      <gml:coordinates decimal="." cs="," ts=" ">-120.000000,65.588264 ...-120.000000,65.588264






In order to instantiate a Geometry Attribute in GeoXACML the AttributeSelector has to point to the <Polygon> element (c.p. example under Change Request 2).



Change Request 2: AttributeSelector’s RequestContextPath attribute


Turn AttributeSelector’s RequestContextPath attribute to a parameter represented as child element of the <AttributeSelector> element.


Having the XPath expression specified as an XML attribute of the <AttributeSelector> element unnecessarily limits the functionality of the AttributeSelector. In use cases were you use XACML to protect XML resources it is necessary to be able to express semantics like:

AttributeSelector(concad(XPath_Expression_Base, XPath_Expression_offset)). Having the XPath expression declared in an XML attribute, doesn’t allow to use XACML functions on this XPath expression.


The use of the AttributeSelector can than for example look like this:


<AttributeSelector DataType="urn:ogc:def:dataType:geoxacml:1.0:geometry">

  <Apply FunctionId=" urn:oasis:names:tc:xacml:2.0:function:string-concatenate">

    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

      <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>


    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/Geometry/Polygon</AttributeValue>





Change Request 3: Any-Of, All-of and Map functions are defined to restrictive


Reformulate the definitions of the Any-Of, All-of and Map functions in a more general way.


The current definition of these higher-oder functions are too restrictive (e.g. line 4556, 4590, 4786). For example the any-of and all-of function have the following signature:

any-of|all-of(function, primitive data type, Bag)

Problems arise e.g. as the order of parameters is restricted. Assume you have a function without its inverse counterpart and further the spec forces that the Bag is the second parameter of this function. Obviously this unnecessarily limits the expressiveness considerably.

Another restricting effect of the current definition of these functions shows up when you use XACML’s extension capabilities. It should be supported to add an function with three parameters like e.g. is-within-distance(geometry_A, geometry_B, 100 metres). Users need higher-order functions that can be used with the extended functions. Currently the definition of the higher-order functions is not generic or general enough in this regard.

The same limitations apply to the map function. As it is, it supports only functions with one parameter. A more expressive definition of the map function should also allow functions with more than one parameter. Assume for example a situation where you want to add five to each element of an integer-bag with the map function.



Change Request 4: limited expressiveness of the match functions


Allow a more flexible parameter order of match functions as the current definition (1852) reduces the flexibility and expressiveness.


Closely related to the problems mentioned under Change Request 3 is the fact that the match function’s parameter order definition (see line 1852) of is too restrictive. Again when self-defined match functions are added without its inverse counterpart the policy writer has to face limitations as there are unnecessary constraints on the order of parameters of match functions.



Change Request 5: add two more attribute-categories for the Web Service use case


add urn:oasis:names:tc:xacml:3.0:attribute-category:web-service-request and urn:oasis:names:tc:xacml:3.0:attribute-category:web-service-response


When using XACML to protect Web Services you perform access control on the Web Service request and/or Web Service Response. By definition, at least the Web Service request is XML encoded. Thus the WS-request and -response (if xml encoded) is conveniently represented under a XACML Content element.

Having the new XACML 3.0 categories the question arise which category to use for a Web Service request or response. As a request is a resource and indirectly represents the action at the same time one should in principle use the resource and the action category at the same time which is not possible. Therefore I recommend to add the attribute-category:web-service-request and attribute-category:web-service-response categories for the access control for Web Services use case.


Open questions:



I am wondering whether it is best practise to put namespace definitions of XML data under a Content element in the first child element of the Content element. Isn’t it maybe more appropriate to include it to the name space definitions of the whole XACML decision request. Doing so might simplify/help validation of the decision request with out of the box tools.



What is the explanation for the proposed target structure? What were the decision that led to the AND, OR ordering under the target element? Why didn’t you use e.g. CNF?



3054: do not make use of the name space axis.. why?



3286: a match –id function should be easily indexable? What is your definition of easily indexable?




At the end some minor bugs/inconsistencies I noted while reading the XACML 3.0 spec…


52: update error

An operation specified in a rule, policy, or policy set…


302: writing error?

..whose target and condition is…


4919:…any attribute, element AND TEXTNODE….



So far my comments towards the new XACML 3.0 draft. Of course I am happy to provide more input on these thoughts if need. Simply call me or contact me via email.



Best regards





Jan Herrmann
Dipl.-Inform., Dipl.-Geogr. 

wissenschaftlicher Mitarbeiter

Technische Universität München
Institut für Informatik

Lehrstuhl für Angewandte Informatik / Kooperative Systeme

Boltzmannstr. 3
85748 Garching

Tel:      +49 (0)89 289-18692
Fax:     +49 (0)89 289-18657


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