[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 Action: 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. Explanation: 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:outerBoundaryIs> <gml:LinearRing> <gml:coordinates decimal="."
cs="," ts=" ">-120.000000,65.588264
...-120.000000,65.588264 </gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> 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 Action: Turn AttributeSelector’s RequestContextPath
attribute to a parameter represented as child element of the <AttributeSelector>
element. Explanation: 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"/> </Apply> <AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">/Geometry/Polygon</AttributeValue> </Apply> </AttributeSelector> Change Request 3: Any-Of, All-of and Map functions are defined to restrictive Action: Reformulate the definitions of the Any-Of, All-of and
Map functions in a more general way. Explanation: 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 Action: Allow a more flexible parameter order of match
functions as the current definition (1852) reduces the flexibility and expressiveness. Explanation: 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 Action: 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 Explanation: 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: Q1: 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. Q2: 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? Q3: 3054: do not make use of the name space axis.. why? Q4: 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 ________________________________________ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]