I still can find no compelling reason to introduce this into the
standard. Any enterprise could certainly adopt this system of resource
identification without violating the XACML specification. I cannot see any
advantage in doing this, but I believe Rich when he says there may be
highly constrained situations that force one to this type of solution.
That is not a good enough reason to put it in the standard,
though.
To address some specific points:
1. XPath performance overhead. I don't know what others have
experienced, but I have used saxon xslt engine for years, and simply cannot slow
it down no matter how complex my xpath expressions are, or how large the input
documents are. I don't know what xpath engines are commonly used in XACML
implementations, but poor performance is not an inherent feature of xpath
processing. In the case of multiple authorization decisions on a single
document, it would be a very naive implementation that actually re-parsed
the document for every decision.
2. Paradigm shifting: Attribute(Designator|Selector), xpath vs.
regex. Really, who *likes* regex? ;-) XACML is an XML application,
therefore the first and favored approach should be xpath. It's nice to be
able to use regex when necessary, but I have never seen a case where it is the
best first choice in XML processing (except for datatyping and value checking,
but those areas are outside the domain of xpath). A developer
who knows regex better than xpath would want to use regex first, but
xpath is a much more natural fit with XML.
3. Not wanting to expose entire XML document to
PDP. If this is a hard constraint, there are other
architectural alternatives. Take the book catalog use case. For my
money, I would do something like this before using the alternative URI
representation:
a. Query book database for candidate
records
b. Send multi-decision request with attributes
like ((user=Jones), (type=book, author=Jones, price=50),
(type=book,author=Smith,price=30), ...)
c. Receive results
d. Form XML for delivery to user, based on
results.
This model would work for all cases where the XML is manufactured
from database or other backend sources. Just move the authorization step
ahead of the XML creation.
The book use case does not actually depend on any hierarchical
relations for the decision, so it is not the best example.
Regards,
--Paul
Based on Oct 8 TC meeting, proposals were solicited to address both
issue 11, and the broader issue of whether or not we should consider
separating out the XML document parts of Hier, Mult to another
profile.
The attached document represents a proposed addition to Hier
profile to address issue 11 (it is the same as attachment to http://lists.oasis-open.org/archives/xacml/200909/msg00076.html,
except w highlight changes turned off to make Hier sections 2.2, 2.2.1 easier
to read). (It is also included as attachment to emphasize it is a proposal, as
opposed to a draft of an agreed change, which would be rev'd in the
repository)
The following comments state why I think the proposed
addition to Hier is needed (#1, #2) and why I think the hierarchical
properties of XML documents should remain in the Hier/Mult profiles (#3), and
that if other profiles are developed for XML docs then those profiles should
refer to Hier/Mult for their hierarchical access properties.
- The proposed addition to Hier is needed because it represents
functionality that is currently missing from the Hier profile that enables
identifying resources within an XML document without having to provide the
XML document itself.
- The problem introduced by requiring the presence of the XML document
is that, for example, it requires actually accessing and exposing the
protected resources in order to determine if access is allowed to those
same resources. While this may be an acceptable increase in risk of
exposure in some application environments, it may not be acceptable in
others where very sensitive data is involved, and an alternative should be
provided for those cases.
- For more specific example, XML-frontended datastores contain resources
in relational or other legacy storage mechanisms and primarily use XML as
vehicle for containing and carrying those resources. Requiring
construction of XML documents containing those resources, which could
potentially contain very sensitive data, in order to construct a request
to determine whether access to those resources is allowed should not be
required if alternative mechanisms which do not require this exposure are
readily available.
- The proposed addition is also needed to provide a unique uniform naming
mechanism and policy reference mechanism for all hierarchical resources
whether they are contained in an XML document structure or some other
hierarchical structure. i.e. XML documents have an inherently simple
hierarchical structure that has an implicit resolved name structure in the
underlying XPath data model that should be able to be used for resource
identification and policy definition despite the fact that the XPath
language, itself, does not expose this capability of the underlying
reference model.
- The attached proposal uses a commonly used mechanism (Clark notation:
curly braces around resolved namespace prefix) that addresses the omission
from the XPath language of the ability to enable single string display
representation of explicit full hierarchical path to each node. This path
is also percent-encoded where required in order that it can be used as a
URI fragment as described in section 2.2.1 of attachment, which seamlessly
augments the existing Hier URI scheme in section 2.2.
- It is recommended to leave the XML document sections in Hier/Mult for
the following basic reason: The introduction to the Hier profile (section 1,
lines 41-54) makes it clear that XML documents are regarded as generally
only one possible "representation" of the actual target hierarchical
resources. Therefore there seems to be little to be gained by separating out
one representation of the general hierarchical resources covered by the
profile into a separate profile. What would seem to make more sense is that
a more general XML/WebServices profile could reference the Hier profile when
necessary for matters concerning the "hierarchical" access control aspects
of the more general XML/WebServices problem space addressed by that
new profile.
Additional context for this proposal has already been
discussed in tc emails and will not be repeated here, but may be found in the
following references to those emails:
Comments and suggestions welcome.
Thanks,
Rich