FW: recommendations regarding xacml.3.0

From: Jan Herrmann
[mailto:] 

Sent: Friday, December 12, 2008
5:00 AM

To: ; ; '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

Jan

________________________________________

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

www11.informatik.tu-muenchen.de

________________________________________