Re: [xacml] FW: recommendations regarding xacml.3.0

[Erik Rissanen <erik@axiomatics.com>]

Hi Jan, and all,

The TC has agreed on a feature freeze on the 3.0 core, although we keep 
breaking that all the time. :-)

Personally, I think that these are major changes which I would not like 
to pursue in the 3.0 timeframe. I would very much prefer to delay this 
to 3.1 or an additional profile to 3.0.

Regarding the attribute selector for the environment, I'm not sure if I 
understand you correctly, but if I do, then it's already part of the 
current 3.0 draft. In 3.0 all the request elements have the same 
functionality and may contain XML in an <Content> element.

Regarding dynamically generated attribute selectors, I am afraid that 
it's going to make XACML policies very hard to understand and analyze, 
but everything that uses XPath is pretty bad already, so I don't know 
what the difference would be.

The multiple resource profile scope sounds like a simple thing to fix.

Regards,
Erik


Hal Lockhart wrote:
>
> ------------------------------------------------------------------------
>
> *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:
>           o 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
>           o 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.
>           o 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.
>           o 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.
>           o …
>           o 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
> ________________________________________
>