Rich,
The analogy with file system is confusing. You aren't
proposing this system of URIs for representing files, are you? That
capability is already provided by the "file:" URI scheme. One might be
motivated (or required) to represent a filesystem in an XML document, but then
one would have to adopt a suitable schema to reflect the properties of their
particular type of filesystem.
I think Erik's proposal of ContentReference would address
your actual example, and allow use of xpath for identifying the decision
node. It would allow either xpath-node-match or regexp for writing
policies about the resources.
<Request>
<Attributes Category="resource">
<ContentReference
ContentURI="http://example.com/section01/file01.xml"/>
<Attribute AttributeId="resource-id"
DataType="xpathExpression">/a/b/c/d</Attribute>
</Attributes>
...
</Request>
This would mean "give me a decision on the node(s)
represented by '/a/b/c/d' in
'http://example.com/section01/file01.xml'".
If you exclude the use of namespace prefixes in your system,
you can use string-regexp-match on the xpath expressions, and
anyURI-regexp-match on the ContentURI. (Interesting point--would the
ContentURI value be available in the decision context? Since this is just
a proposal, we don't know yet. It would have to be available to satisfy
Rich's use case.)
If your XML files do use names outside the default namespace,
then you would be constrained to use xpath node matching in your rules for
document content. But namespaces would not be a concern for the filesystem
references, so you could easily write a target or condition to select "all files
under section01" using anyURI-regexp-match.
Regards,
--Paul
Hi Erik,
I can either reply with a long detailed email or
try something short and hopefully to the point. I will try the short
approach.
First, I think we can all agree, for example, that a list of
files in a file system can represented equally well by a "dir listing" or a
"dir listing that has been channeled into an xml document format", such that
if one is handed the xml document then they can easily use the document to
tell them how to navigate to any file in the file system of interest to them.
i.e. there is an interchangability between actual file system navigation and
navigation thru an xml document.
Given that relatively simple point,
without going into detail of all the syntax, brackets, and curly braces vs
namespace prefix discussion, I think the objective I am trying to achieve w
the proposal can be simply stated, namely:
The objective of the proposal is to provide the ability to
system admins to use the same web access URI techniques they currently use
to control access to html files, for example, and apply those techniques to
control access to nodes in xml documents.
i.e. the proposal is
not intended to enable an admin to say any more about accessing a node in an
xml document than the admin would be able say about accessing an html file
that was addressable w the exact same path.
i.e. the first part of the URI, the existing Hier section 2.2,
would be used to identify the specific xml file, then the second part,
the fragment identifier would be able to use the same slash-component
technique to identify the node within the XML document.
The
admin would write policies that would say something like:
grant admingroup readprivilege http://www.example.com/section01/*.xml#/a/b/c/-
which
would allow the admin group to read nodes below the "/a/b/c/" level in
section01 of www.example.com. So, if someone came in
with an http GET on:
resource-id = http://www.example.com/section01/file01.xml#/a/b/c/d
the
policy above would allow access if they were in the admin group.
I
realize the above policy is not in xacml, however, one could fairly easily
have the admingroup as the subject target, the readprivilege as the action
target, and then write a regular expression to test the resource-id against
the scoped policy.
Probably no need for constructing resource lists,
multi requests could be simply like:
resource-id = http://www.example.com/section01/file01.xml#/a/b/c/*
which
would effectively be a query for all the child nodes of /a/b/c in the doc
file01.xml.
Hopefully, this is enough to make the objectives more
clear, and show why with this relatively limited scope of objective there is
no real need for document content to be provided in the requests, and policies
can be written such that everything can be determined from the query
alone.
The point is that current web access control products
effectively provide these capabilities, and the idea is to simply provide a
technique to extend this type of capability to the nodes of xml
documents.
Thanks,
Rich
Erik Rissanen wrote:
4AD60C16.4000407@axiomatics.com type="cite">Hi Rich,
One thing which is missing from this proposal is that there is no
specification for how the URI selects nodes in the XML document.
Personally I find it difficult to work with expressions like this
since it is about performing "matching on a matching language" in order to
get the actual resource. I am concerned that it is easy to make a mistake in
this dual step matching process, but if others find it desirable to work
with, I could live with it in the spec. :-)
I understand that it may
be desirable in some cases to hide the XML content, but that could perhaps
be handled better by a construct like this:
<Request>
<Attributes Category="resource"> ...
<ContentReference .....something here..../>
</Attributes> </Request>
With a content
reference like this in the core schema, the <Request> element could be
used as a transport format where the XMl can be hidden. And there would be
no need to introduce another conceptual model for hiding the XML content.
When the PDP receives a <Request> like this, it would conceptually
replace the XML content and behave according to the current spec. (Or based
on yet another hierarchical scheme which we define.)
Best Regards,
Erik
Rich.Levinson wrote:
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.
1. 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.
2. 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.
3. 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:
* The
change represents missing functionality as initially
outlined here:
http://lists.oasis-open.org/archives/xacml/200909/msg00075.html
* The specific change that was outlined in
above ref, was explicitly contained in
the attachment to this email: http://lists.oasis-open.org/archives/xacml/200909/msg00076.html
* Trade-offs between the URI and XPath
approach, including the fact that URI
does not require the presence of the actual XML
document, were considered in this
email: http://lists.oasis-open.org/archives/xacml/200909/msg00079.html
* A detailed walkthru of one possible use case,
selected to show direct comparison
between the XPath and URI approaches was
contained in this email: http://lists.oasis-open.org/archives/xacml/200909/msg00099.html
* The following email discusses in more detail
the relation of the URI-reference
scheme naming and the implicit Mult scoping:
http://lists.oasis-open.org/archives/xacml/200910/msg00007.html
Comments and suggestions welcome.
Thanks, Rich
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS
at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|