Hi Paul,
I pulled two of your email replies to me together here for one thread
and will try to cover both in my response.
In your first email (Wed, 14 Oct 2009 09:15:50 -0500) I agree that the
place in the sequence of "base-system-no-authz.png" attached to that
email that the place I am focused on applying enforcement is primarily,
but not exclusively, point 1. i.e. there is a lot that can be done at
point 1, and from my perspective, the objective is to as much there as
technically feasible in order to avoid actually accessing the backend
data.
You then say:
"With
your URI-reference scheme, you are proposing that the PEP compose a
series of URIs representing an XML document that might be created at a
future point in the process (perhaps, after ACP 2)."
This statement is partially correct in noting that the URI-reference
scheme is concerned with representations of XML documents that might be
created at a future point in the process, however, what I am not
proposing is that the PEP compose a series of such URIs. The earlier
email which demonstrated this process was for reference only as to how
such URIs could be created from an existing XML document, but it is
probably not a common use case that this would be done, and
specifically, it would not be done at step 1, because at that point the
XML document does not exist and you rightly point out that these URIs
could not be created without a knowledge of what was in the database.
However, having said all that, let me explain a little further how the
scheme would work in practice. Using the example I provided in:
http://lists.oasis-open.org/archives/xacml/200910/msg00043.html
I thought the type of question you raised would have been answered, but
maybe it needs a bit more elaboration. In that example, I said the user
makes a query, which presumably effectively gets translated to a
specific node, and possibly that node plus all its children, or that
node plus all its descendants:
http://www.example.com/section01/file01.xml#/a/b/c/d
and following the example in Jan's presentation, we can include a scope
attribute with value "Immediate", "Children", or "Descendants".
The policies that can be written w regular expressions can refer to
node ranges, such as (using the Java FilePermission notation):
http://www.example.com/section01/file01.xml#/a/b/c/d/-
("-" => node and all descendants)
http://www.example.com/section01/file01.xml#/a/b/c/d/*
("*" => node and all children)
http://www.example.com/section01/file01.xml#/a/b/c/d
("" => identified node only)
Therefore, all one needs to determine access is the name of the node
requested, and possibly the scope as well.
- For the case where just a single node is requested, it should be
clear that policies such as the above can operate w/o the xml document
having to be created.
- For the case where a scope is requested, it should be
straight-forward to determine if the scope of any policy overlaps the
scope of the request.
For the above, one can test the strings /a/b/c and a/b/c/d/e with
immediate,children,descendants attrs to see how the policies would
work, for example if the policy said Deny if there was a match and
Permit otherwise. I won't go thru the examples, but the point is that
this is the way it would work in practice:
- Somehow, the PEP/context handler would determine a node and scope
that was being requested, and submit the node string and the scope
attribute.
- The policies would be tested for matches and provide Decision
accordingly.
Hopefully this explains how the nodes can be requested w/o knowledge of
the contents of the db. i.e.all that needs to be known is what's being
asked for, which should be implicit in whatever query is being issued
to the database or the xml document representation of that database.
Also, it should be clear that there is no reason obligations cannot be
returned with the results as well, which, as you suggest could place
limits on the amount of a purchase that would be accepted, etc., but
that type of thing is beyond the scope of the hierarchical profile in
the sense that it is not part of the essential hierarchical
determination that is being made.
Granted, if people want to combine the straight hierarchical aspect of
the request, with related conditions based on other nodes in the
hierarchy, then one will probably need XPath. However, I don't think it
makes sense to force people to use XPath when they don't need it. My
proposal is providing an option for those situations where it is not
needed.
I expect the decision of which to use would be some kind of
configuration option, whereby certain pep's might be configured to use
xpath and others to use URIs, and they would route the requests to
pdp's that advertised metadata consistent w those requests.
On your later email (Thu, 15 Oct 2009 08:11:02 -0500), I am only using
file system analogies because people are generally familiar with them
and the usage scenarios can easily give real world examples
representing scope, etc. using the most rudimentary types of regular
expressions w simple wildcards. I am not suggesting people represent
file systems w xml documents, but just trying to make the point that
because resources can be represented using either vehicle, at least
from a hierarchical perspective, that there generally are no inherent
aspects of xml documents that make them the only means by which the
resources they contain can be represented. The GeoXacml case makes this
obvious because the actual resources are stored in a relational
database, and it is only execution of the query the presents that data
in xml format.
As far as the ContentReference suggestion is concerned, I am not sure
what that adds. Your example appears to simply include the first part
of the URI identifying the xml file, which is already covered by
section 2.2 of the hierarchical profile. The proposal I made extends
the 2.2 defn w the syntax in section 2.2.1 which shows how to make
absolute paths from xml documents in a manner consistent with the XPath
data model.
Your suggestion indicates regexp could be used on provided xpath
expression, which is fine, but the problem is that only works if there
are no namespaces. The core of this whole issue, imo, is that xpath
works w qnames, which are 2-component entities that do not have an
official single entity string representation. That is exactly the point
of the "Clark notation": it gives an example of what could be an
"official single entity string representation", but it has not been
designated as "official" by anyone.
From my perspective, if we wanted to add the section 2.2.1 as I have
proposed, we would then have to ask whether the fact it uses an
"unofficial" string representation of QNames, because an "official"
representation does not exist, effectively prevents us from using this
technique. My position is that the limit of usage of this technique is
totally contained within the XACML domain of control, i.e. between the
context handler and the PDP (where context handler abuts the
resource-id producer, i.e. I think the resource-id is produced by
modules in section 3.2 table 2 of core spec that convert from
domain-specific representations to xacml representations so that it
would only be within the xacml representation that this "unofficial"
representation of QNames would exist, although the domain-specific
entities would have to know to convert to it.
I realize that this proposal is suggesting "older style" technology,
but it is needed because the "newer style" does not allow for a uniform
representation of all the resources. i.e. it allows you to represent
your hierarchies in XPath, but does not allow its hierarchies to be
represented by URIs, for the simple reason that it does not provide an
official string representation of QNames. Since there is an obvious,
although, unofficial, solution to this problem, my suggestion is that
we consider using this solution as better than no solution at all.
Thanks,
Rich
Tyson, Paul H wrote: (Thu, 15 Oct 2009 08:11:02 -0500)
3898C40CCD069D4F91FCD69C9EFBF09603E1234C@txamashur004.ent.textron.com" type="cite">
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">
<Attribute AttributeId="resource-id"
DataType="xpathExpression">/a/b/c/d</Attribute>
</Attributes>
...
</Request>
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
Tyson, Paul H wrote: (Wed, 14 Oct 2009 09:15:50 -0500)
3898C40CCD069D4F91FCD69C9EFBF09603E11CB4@txamashur004.ent.textron.com" type="cite">
Rich, I think I am closer to understanding your use
case, but I still believe there are architectural solutions that can be
implemented using current features of the 3.0 specs.
See
attached diagrams, which I put together to show the process of
implementing a PEP in a multi-tiered application. You have a
requirement:
(1)
"Authorization is determined prior to accessing any resources at all."
Therefore
the only choice for a PEP is at the access control point (ACP) labeled
"1" in the diagram, "base-system-no-authz.png". At this point, all the
system has is search parameters from the user. With your URI-reference
scheme, you are proposing that the PEP compose a series of URIs
representing an XML document that might be created at a future point in
the process (perhaps, after ACP 2). But how could it compose these
URIs without knowledge of what was in the database? Why
couldn't it issue a request to the PDP, "Can Jones query the database",
and get the decision (with obligation) like "yes, but only for books
not by Jones, or costing less than 50 dollars"?
I'm
probably still missing something about your use case and architectural
constraints.
Regards,
--Paul
3898C40CCD069D4F91FCD69C9EFBF09603E1234C@txamashur004.ent.textron.com" type="cite">
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