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
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
________________________________________