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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: FW: recommendations regarding xacml.3.0



From: Jan Herrmann [mailto:herrmanj@in.tum.de]
Sent: Friday, December 12, 2008 5:00 AM
To: bill@parducci.net; hal.lockhart@oracle.com; 'Seth Proctor'
Subject: recommendations regarding xacml.3.0


Dear  Hal, Bill, Seth,


I hope you are the right persons to address this mail to.

What  is the current work status of  XACML 3.0? As we have quite a few suggestions for improvement, it would be very interesting to know if it is still possible to introduce new ideas.


Within the Open Geospatial Consortium (OGC) we are using XACML or GeoXACML (a spatial extension adding a spatial geometry data type and some spatial functions) respectively to provide flexible, interoperable access control in OGC based Web Services infrastructures.


Currently we are working on a profile of GeoXACML for OGC Web Services to enhance interoperability when using (Geo)XACML in OGC Web Service environments.

In this profile we will describe little extensions/concretisations in order to enhance interoperability if you use (Geo)XACML in Web Service environments. Additionally our research resulted in some suggestions to improve XACML and some related profiles (e.g. multiple resource profile of xacml 2.0).


In short our main recommendations for XACML 3.0 are:


  • When using the ResourceContent to represent web service specific information (i.e. the ws-request or -response) the current AttributeSelector definition is not sufficient (and by the way not exactly defined in the xacml 2.0 spec – c.p page 66 and 78/7). What we need is an XMLAttributeSelector that returns arbitrary node sets as specified by the xpath expression within the selector (e.g. a sub tree of the ws response representing the geometry of a building). I suppose that at the moment the AttributeSelector mechanism is only intended to select text nodes (even if this is not specified unambiguously in the spec – c.p page 66 and 78/79) To return only text nodes is not sufficient in our use case and is an unnecessary restriction.
  • consequently we need a data type like urn:...:xml or urn:...:nodeSet


  • Additionally it would be more powerful to allow a XML(Attribute)Selector to pass the xpath expression as a parameter. Combined with a concatenate function one could do things like: XMLAttributeSelector(concad(resource-id, relativePathFromTheCurrentAC-NodeAsSpecifiedByRes-id). This is needed to allow rules based on ResourceContent of the form: permit access to building node if the building price is >100 and owner = Bob. If you use two different selectors to implement this semantic you loose the connection of the two attributes that belong to the same building. Solving this issue though predicates within the XPATh expression has limitations because of the limited set of functions you can use in xpath predicates.


  • Another topic is that at the moment you can only define XACML Attributes under the Environment Element in an access control decision request. In order to model more sophisticated application environment states in an access control decision request, it would be very helpful to extend the Environment according to the ResourceElement. What we have in mind is an EnvironmentContext Element under Environment and the corresponding XMlEnvironmentAttributeSelector. This is a consequent extension of what xacml provides for resources and it is very useful in our use cases (e.g. base access semantics on a current disaster sitautaion expressed through an xml document – In our use case the PIP or PEP includes this document in the access control decision request). By the way if you wonder why we don’t use XACML Attributes. The reasons are as follows:
    • lots of URNs for attribute-names & -values have to be defined for unique identification (e.g. action-id & getMap, getFeature, transaction, insert, update, delete...all possible operations on ogc web services)
      • on the other side we have standardised xml schemas that already define unique attribute-names & -values without URNs
    • more important: XACML Attributes destroy the hierarchical structure & semantical relationships and imply more generalized i.e. coarse-grained  atomic information entities
      à XACML Attributes are only possible if the information is atomic without structural relation. But in our use case we have structured parameter objects that we want to use in our rule functions (e.g. within(rulegeometryLiteral, PointerToGeometryOfBuildungInResourceContent)
      à not powerful enough as arbitrary ws requests and responses can not be easily, completely transformed into appropriate XACML Attributes without reducing the possible authorization semantics


  • The current multiple resource profile has some bugs and limitations that needs to be fixed.
    • e.g. the scope:xml attribute is used to specify how to generate individual access control decision requests from the global access control decision request. Unfortunately scope is also used to specify how to generate a global access control decision response from individual access control decision responses. This limits the possible combinations one likes to use.
    • It might be very useful to have an attribute specifying the node-type for which the individual access control decisions requests have to be derived by the context handler (e.g. XML element nodes only or XML element and XML attribute nodes.
    • In order to provide filtering correspondent to the access control decision we use the resource-id attribute value pointing to exactly one node. In certain situations it might be very helpful to define a relative path from this value where exactly to cut of nodes in the Resource (e.g. the ws-response)


Even if this introduction of our/my thoughts was very brief and superficial, I hope, that you can nevertheless understand the general ideas/probs.


What do you suggest how to introduce and maybe incorporate our results/recommendations to/within the xacml wg. As far as I know the OGC (stuff ) is a OASIS member (but the members of our OGC security working group aren’t). How can our security working group get into contact with the xacml working group?

What we could do, is write change requests that detail the topics mentioned above or we could if possible join a xacml wg session. I could ask Carl Reed the Chief Technology Officer at the OGC if I could get a proxy (act in the name of an ogc stuff – if this is possible) to introduce the ogc thoughts/recommendations to the xacml working group.


From my point of view it would be very helpful to coordinate OGC work on (Geo)XACML with OASIS’s XACML WG. Most of our topics we’d like to cover in our GeoXACML profile for OGC Web Services are more general topics that would be more appropriately specified in the XACML spec itself and in a profile of XACML for Web Services or within the multiple resource profile. Additionally I believe that our findings (especially  on the ResourceContent/Attributeselector approach) will mature XACML (especially the ResourceContent/Attributeselector related mechanisms) and our comparing analysis of the XACML ResourceContent/Attributeselector approach and the XACML Attributes/AttributeDesignator approach will maybe help to spread the use of the powerful ResourceContent/Attributeselector mechanism and thereby extend the use of XACML.


I am looking forward to hear your opinions.


Best Regards



Dipl.-Inf., Dipl.-Geogr. Jan Herrmann

Scientific Assistant

Technische Universität München
Department of Informatics

Chair for Applied Informatics / Cooperative Systems

Boltzmannstr. 3

85748 München


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]