OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: AW: AW: [xacml] RE: XACML's limitations in the access control for XML documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of xpath definition


Hi Erik,
further comments inline.
best regards 
jan

> -----Ursprüngliche Nachricht-----
> Von: Erik Rissanen [mailto:erik@axiomatics.com]
> Gesendet: Montag, 28. September 2009 16:33
> An: Jan Herrmann
> Betreff: Re: AW: AW: [xacml] RE: XACML's limitations in the access control
> for XML documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of
> xpath definition
> 
> Hi Jan,
> 
> See responses inline. BTW, it is a good idea to post to the TC list so
> everybody can see the discussion.
> 
> Best regards,
> Erik
> 
> Jan Herrmann wrote:
> > Hi Erik, all,
> >
> > in your mail
> > (http://lists.oasis-open.org/archives/xacml/200909/msg00095.html) you
> are
> > identifying three different use cases. Just to make sure that I
> understood
> > your suggestions let me summarise how I understood your use cases and
> add
> > some comments:
> >
> > Use case 1:
> > You have one physical resource (a book) and a XML encoded metadata doc
> that
> > describes the physical resource.
> > You are further saying that XACML can handle this case well. Is this
> correct
> > or do the same problems exist in this use case too?
> > Let me extend your example to demonstrate that similar problems can
> occur:
> >
> > <Subject>Alice Miller</Subject>
> > <Resource>
> >   <Content>
> >     <book>
> >       <title>xxx</title>
> >       <authors>
> > 	  <Person>
> > 	    <lastname>Smith</lastname>
> > 	    <yearOfBirth>1970</yearOfBirth>
> >         </Person>
> > 	  <Person>
> > 	    <lastname>Miller</lastname>
> > 	    <yearOfBirth>1980</yearOfBirth>
> >         </Person>
> >       </authors>
> >       <id>100</id>
> >       <price>30</price>
> >     </book>
> >   </Content>
> > </Resource>
> >
> > Now assume that you try to define a rule that denies access to a book if
> one
> > of its authors is from the requestor’s family (i.e. the miller family)
> and
> > born after 1978.
> > Doesn’t this imply similar limitations as I described in
> > http://lists.oasis-open.org/archives/xacml/200909/msg00081.html?
> >
> 
> I am not sure. At the very least, the attribute selector with an offset
> wouldn't help anything here, since it is a request for a single
> resource, so the PDP would not iterate the resource-id over anything.
> 
> I suspect that it is fairly easy to write an xpath expression which
> selects a <Person> element if this dual condition is satisfied in the
> contained elements of the <Person> element. But I haven't been doing
> xpath in a while, so I don't recall exactly how to do this from the top
> of my head.

The prob with this XPath expression is that it has to look like this:
/Request/Resource/Content/book/authors/Person[lastName= subject-id AND
yearOfBirth > 1978]
If this xpath selects at least one node than the rule should deny access to
the book. Because of subject-id (and other reasons) this can't be done in
XPath and thus you have to mix XPath semantics with XACML (or do it in XACML
completely) and this is were the limitations start without using the
multiple "resource" approach.

If you use the multiple resource approach in this use case (even if you have
only one single resource) you could achieve the desired behaviour

What you could do in this metadata use case is:
-let resource-id point to book[1]
-scope = descendants

The following individual decision requests will thus have resource-id values
like:
ind. request 1:
resource-id = .../book[1]
ind. request 2:
resource-id =.../book[1]/title[1]
...
ind. request n:
resource-id =.../book[1]/authors[1]/Person[1]
ind. request n+1:
resource-id =.../book[1]/authors[1]/Person[1]
...

Thus a rule like the following might implement the intended semantics: 
xpath-node-match(resource-id, .../book/authors/person) AND
AttributeSelector(concat(resource-id,/lastname) == subject-id AND
AttributeSelector(concat(resource-id,/ yearOfBirth) > 1978

This rule will than match the individual request n and n+1.


> 
> > Use case 2:
> > From my point of view this is a special case of use case one where you
> have
> > an access to multiple physical resources and thus multiple metadata xml
> docs
> > describing these physical resources. I agree that this should be encoded
> > through multiple resource elements as you proposed. So this is simply a
> > convenient way of packing, in fact separate access requests (of type use
> > case 1) into one xacml decision request.
> >
> 
> Yes. I brought this example in because the example you had with books
> was something that is perhaps better handled through multiple <Content>
> elements rather than multiple <Book> elements in a single <Content>
> element. And I want to emphasize the difference between a bunch of XML
> which describes a single resource and a bunch of XML which itself is a
> bunch of resources.
> 
> > Use case 3.
> > Here the nodes of a XML document are the resources. The XML document is
> > contained under a resource-category <Content> element.
> > This means that a rule will point to an individual or a set of nodes and
> > control access to these nodes. In order to allow for powerful rules a
> rule
> > can define access semantics that depend on other node values. For
> example an
> > access decision to one node can depend on the value of another node in
> the
> > xml doc but it can also depend on a node value included e.g. in another
> > content element describing the metadata to the xml doc (or even
> environment
> > data like the state of the access control system).
> >
> > In your discussion of use case 3 you are saying that XACML does not have
> the
> > capabilities to handle this use case well.
> > I believe that XACML is very well suited to handle this use case too.
> All it
> > needs is a minor relaxation of the interpretation that an individual
> request
> > can contain the attributes of a single resource only. Let an individual
> > request be exactly identical to the original request context with two
> > exceptions.
> > 1. resource-id must point to exactly one individual resource (as
> identified
> > by resource-id and scope of the original global request)
> > 2. the scope Attribute must be absent.
> >  Further, if a <ResourceContent> element was present in the original
> request
> > context, then that same <ResourceContent> element SHALL be included in
> each
> > Individual Resource Request.
> >
> > Actually this is very very close to line 172 ff (in the 2.0 version of
> the
> > multiple resource profile).
> >
> 
> If I recall correctly, this is exactly how the current multiple resource
> profile works. Have you identified something which is different? What in
> that case?

the relevant section in the 2.0 version of the profil is as follows.

Each Individual Resource Request SHALL be identical to the original request
context with two exceptions: the “scope” attribute SHALL NOT be present and
the <Resource> element SHALL represent a single Individual Resource. This
<Resource> element SHALL contain at least one “resource-id” attribute, and
all values for such attributes SHALL be unique, normative identities of
the Individual Resource. If the “resource-id” attribute in the original
request context contained an Issuer, the “resource-id” attributes in the
Individual Resource Request SHALL contain the same Issuer. If a
<ResourceContent> element was present in the original request context, then
that same <ResourceContent> element SHALL be included in each Individual
Resource Request.

If you read it carefulle it is a bit contradictious.
First:
the <Resource> element SHALL represent a single Individual Resource
Second:
If a <ResourceContent> element was present in the original request context
(note that it is a child of <Resource>, then that same <ResourceContent>
element SHALL be included in each Individual Resource Request.

Thus the part that needs an update is:
... and the <Resource> element SHALL represent a single Individual Resource.
should be changed to something like:
... and the <Resource> element SHALL represent the high-level or global
Resource

Taken into account the discussion on use case 1 you could further think of a
more general naming instead of resource. Basically the same mechanism can be
applied in use case 1 and 3 but the word resource doesn't fit in case 1.
Further case 3 needs an expression for the xml document (i.e. a collection
of individual resources)

> 
> The problem with this approach is that it is difficult to correlate
> attributes belonging to the "resource-id". We need something like the
> offset you are suggesting (and I think Paul suggested this in the past
> on the TC list as well).
> 
> > From my point of view defining it like this won’t introduce any changes
> to
> > the “old” way how to define policies as the definition implies a strict
> > extension of the individual decision request (or more precisely you
> don’t
> > delete data not related to this ind. resource).
> > Further I don’t see a risk that this will lead to confusing results.
> >
> 
> I haven't thought so much about the risks, so maybe you are right. But
> consider this:
> 
> A policy expects the a request like this:
> 
> <Subject>Alice Miller</Subject>
> <Resource>
> <Content>
> <book>
> <title>xxx</title>
> <authors>
> <Person>
> <lastname>Smith</lastname>
> <yearOfBirth>1970</yearOfBirth>
> </Person>
> <Person>
> <lastname>Miller</lastname>
> <yearOfBirth>1980</yearOfBirth>
> </Person>
> </authors>
> <id>100</id>
> <price>30</price>
> </book>
> </Content>
> </Resource>
> 
> There is a policy which says that Alice can get access if the book has
> id 100, like this:
> 
> if AttributeSelector[book/id] == 100, then permit
> 
> But then the PDP receives a multiple request, which is processed into a
> single request like this:
> 
> <Subject>Alice Miller</Subject>
> <Resource>
> resource-id = book[2]
> <Content>
> <book>
> <title>xxx</title>
> <authors>
> <Person>
> <lastname>Smith</lastname>
> <yearOfBirth>1970</yearOfBirth>
> </Person>
> <Person>
> <lastname>Miller</lastname>
> <yearOfBirth>1980</yearOfBirth>
> </Person>
> </authors>
> <id>100</id>
> <price>30</price>
> </book>
> <book>
> <title>yyy</title>
> <authors>
> <Person>
> <lastname>Jones</lastname>
> <yearOfBirth>1971</yearOfBirth>
> </Person>
> </authors>
> <id>101</id>
> <price>34</price>
> </book>
> </Content>
> </Resource>
> 
> See how this could get mixed up, since the policy was not prepared to
> use the resource-id, since it expeced a single resource only. The policy
> might grant access to book 101 to Alice just because the xpath matches
> to other resource, which isn't what the request is really about.


If you write policies you have to know how the xacml requests look like. So
if your agree with other parties that the requests are conformant to the
multiple resource profile than the resource-id and scope attribute will
indicate to the pdp that the behaviour as specified by the multiple resource
profile has to be conducted. This in turn allows the policy writer to be
sure that his policies will apply.

In case another party writes rules not conformant to the multiple resource
profile than this party will expect decision request that just contain the
content element. 

I guess the point of what I am trying to say is that there is a very strong
dependency between the form of the decision request and how to define the
corresponding rules. If an administrator is aware of what kind of requests
can come in than the rules can be defined correspondingly.

best regards
jan



> 
> As I said, I haven't thought this through yet, so maybe this is not a
> real issue.
> 
> 
> > Conclusion:
> > In order to support expressive XACML rules for XML documents (according
> to
> > use case 3) there is a need to…:
> > 1) to relax the interpretation that an individual request can contain
> the
> > attributes of a single resource only
> > 2) move the AttibuteSelector’s RequestContextPath XML-Attribute to the
> only
> > Child element of an AttibuteSelector.
> >
> >
> > Best regards
> > jan
> >
> > ________________________________________
> >
> > Jan Herrmann
> > Dipl.-Inform., Dipl.-Geogr.
> >
> > wissenschaftlicher Mitarbeiter
> >
> > Technische Universität München
> > Institut für Informatik
> >
> > Lehrstuhl für Angewandte Informatik / Kooperative Systeme
> >
> > Boltzmannstr. 3
> > 85748 Garching
> >
> > Tel:      +49 (0)89 289-18692
> > Fax:     +49 (0)89 289-18657
> > www11.informatik.tu-muenchen.de
> > ________________________________________
> >
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Erik Rissanen [mailto:erik@axiomatics.com]
> >> Gesendet: Freitag, 25. September 2009 11:15
> >> An: Jan Herrmann
> >> Cc: 'Tyson, Paul H'; xacml@lists.oasis-open.org
> >> Betreff: Re: AW: [xacml] RE: XACML's limitations in the access control
> for
> >> XML documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of
> 
> >> xpath definition
> >>
> >> Hi All,
> >>
> >> One complication in this whole discussion is that it mixes up several
> >> different use cases. There is a difference between doing access control
> >> on a resource which is described by an XML document and doing access
> >> control to sections of an XML document itself.
> >>
> >> Let me try to illustrate:
> >>
> >> Use case 1, XML is used to describe the attributes of a single
> resource:
> >>
> >> <Subject>Alice</Subject>
> >> <Resource>
> >> <Content>
> >> <book>
> >> <title>xxx</title>
> >> <author>Bob</author>
> >> <id>100</id>
> >> <price>30</price>
> >> <book>
> >> <Content>
> >> <Resource>
> >>
> >> In this case the question is "Is Alice allowed to get access to this
> >> book, whose metadata is described by the given XML content?". (For
> >> instance, this could be for access control in a digital library.) Note
> >> that the question is _not_ "Is Alice allowed to see the title of this
> >> book?" That is a different use case, which I discuss below.
> >>
> >> This is something which XACML handles well as it is.
> >>
> >> Use case 2, XML is used to describe the attributes of a multiple
> >> resources:
> >>
> >> This is like a series of requests as in use case 1, and it should be
> >> encoded as multiple <Resource> elements. Like this:
> >>
> >> <Subject>Alice</Subject>
> >> <Resource>
> >> <Content>
> >> <book>
> >> <title>xxx</title>
> >> <author>Bob</author>
> >> <id>100</id>
> >> <price>30</price>
> >> <book>
> >> <Content>
> >> <Resource>
> >> <Resource>
> >> <Content>
> >> <book>
> >> <title>yyy</title>
> >> <author>Alice</author>
> >> <id>101</id>
> >> <price>300</price>
> >> <book>
> >> <Content>
> >> <Resource>
> >>
> >> If you encode it like this, XACML works well and there is no need for
> an
> >> offset. It would be misuse of XACML to encode it as a single Content
> >> element and use xpath to select the two books.
> >>
> >> Use case 3, XACML is used to perform access control on an XML document
> >> itself:
> >>
> >> <Subject>Alice</Subject>
> >> <Resource>
> >> resource-id=MedicalRecord/Treatment[1]/node()
> >> <Content>
> >> <MedicalRecord>
> >> <Patient>
> >> <SocSecNo>....</SocSecNo>
> >> ....
> >> </Patient>
> >> <Treatment>
> >> <Infection>HIV</Infection>
> >> <Medication>...<Medication>
> >> </Treatment>
> >> <Treatment>
> >> <Infection>HepC</Infection>
> >> <Medication>...<Medication>
> >> </Treatment>
> >> <MedicalRecord>
> >> <Content>
> >> <Resource>
> >>
> >> In this case the request says "Is Alice allowed to see the data about
> >> the first treatment in the list of treatments this patient has
> received?".
> >>
> >> This is fundamentally different than the above case, and it isn't quite
> >> what XACML was designed for in the first place. "Normal" XACML is based
> >> on that the request defines the attributes of a single resource. The
> >> attributes can be described in the form of URI identified attributes,
> or
> >> as free form XML in the <Content> element.
> >>
> >> Instead, what we see in use case 3 that the request contains multiple
> >> resources. But there is a fundamental difference to how the multiple
> >> <Attributes>/<Resource> elements multiple resource profile works. With
> >> multiple <Attributes> elements, a "pre-processor" to the PDP will
> >> transform the request into individual requests which contain attributes
> >> of only a single resource. This means that the policy which works on
> >> these types of requests needs to be no different from a policy which
> >> works on an individual request. Any attribute selectors simply refer to
> >> metadata about this individual resource.
> >>
> >> But in use case 3, the pre-processor will not make a clean split of the
> >> resources. All the resources follow into all the individual requests,
> so
> >> a policy which is used to control access to pieces of an XML document
> >> will have a different form and needs different capabilities. XACML
> >> currently does not have capabilities to handle this use case well.
> XACML
> >> works for simple requirements like "You can see all "Treatment
> >> elements", but not for more complex ones like "You can see those
> >> treatment elements which do not contain the <ConsentRequired> element"
> >> which require resolving relations between sections of the XML document.
> >>
> >> Perhaps we should split up the multiple resource profile into two
> >> different profiles:
> >>
> >> 1. "Multiple Resource Profile of XACML 3.0". This would contain the
> >> multiple <Attributes> elements based functionality as well as the
> >> "scope" based functionality on hierarchies defined with URI-attributes.
> >> Note that these forms of multiple request transform cleanly into
> >> individual XACML requests with single resource.
> >>
> >> 2. A new "Access control on XML documents Profile of XACML 3.0". This
> >> profile would define how we handle use case 3, and here we probably
> need
> >> new capabilities, like the offset, or something similar. We also need
> to
> >> figure out how these kind of policies interact with normal policies. I
> >> am worried that evaluation a "normal" policy on an XML document request
> >> could lead to confusing results, so we need to work out the security
> >> issues of a PDP which contains mixed types of policies. (I am not
> saying
> >> that I know there is a problem, I just want that we make sure that
> there
> >> isn't one.)
> >>
> >> I also suspect that to properly do XML access control on XML documents,
> >> then other features besides the offset could be needed, so we should
> >> read up on the research in this issue.
> >>
> >> If this sounds good, we could do profile 1 in the first batch of 3.0
> >> documents, and do 2 for the next batch, so we can do a proper work on
> >> it, say within a year or so.
> >>
> >> Best regards,
> >> Erik
> >>
> >>
> >>
> >>
> >> Jan Herrmann wrote:
> >>
> >>> HI Paul,
> >>> see comments inline and the edited attached files.
> >>> Best Regards
> >>> Jan
> >>>
> >>> ________________________________________
> >>> Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> >>> Gesendet: Donnerstag, 24. September 2009 21:01
> >>> An: Jan Herrmann; Erik Rissanen; Rich.Levinson
> >>> Cc: xacml@lists.oasis-open.org
> >>> Betreff: [xacml] RE: XACML's limitations in the access control for XML
> >>> documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of
> xpath
> >>> definition
> >>>
> >>>
> >>>
> >>>> 1. Given this use case, are we agreed that we want to get book-
> response
> >>>> when we send book-request?  (Please correct any content errors in
> these
> >>>> documents--I have not been using Content and xpath features of
> XACML.)
> >>>>
> >>>>
> >>> Yes, a book-request implies a book-response. In our use case we have
> xml
> >>> based Web Service requests and response. Thus you have two options
> when
> >>>
> >> to
> >>
> >>> enforce your access rights - either on the web service request or on
> the
> >>> response. Lets follow the later case (i.e post-processing access
> >>>
> >> control) in
> >>
> >>> the following.
> >>>
> >>>
> >>>
> >>>
> >>>> 2. Do we agree that current XACML 3.0 drafts (core, hier, multi) do
> not
> >>>> provide features to achieve (1)?
> >>>>
> >>>>
> >>> Depending on how much expressiveness you need, some large parts can
> >>>
> >> already
> >>
> >>> be done with the specs. In order to enhance expressiveness little
> >>>
> >> extensions
> >>
> >>> are needed.
> >>>
> >>>
> >>>
> >>>>   If anyone has such a solution, please post.  Jan's "Approach 2"
> uses
> >>>> xpath predicate, based on simplicity of this example, but that is not
> a
> >>>> general solution.
> >>>>
> >>>>
> >>> I attached a doc showing another example in another geospatial
> scenario
> >>> (c.p. Apendix A). Note that the approach 2 was just for explanation
> >>>
> >> purposes
> >>
> >>> (demonstrating the probs) and is not what I recommend to do.
> >>>
> >>>
> >>>
> >>>> 3. book-policy.xml illustrates the xpath "offset" feature that has
> been
> >>>> discussed [1] as a solution. (Again, please correct any errors.)
> >>>> 4. Where do the specs define the return value for an
> >>>> xpathExpression resource-id?  In my example, I have:
> >>>>
> >>>>     Request: resource-id=ns1:objects/ns1:book
> >>>>
> >>>>
> >>> Following the multiple and hierarchical resource profile, there is a
> >>>
> >> first
> >>
> >>> global decision request with an resource-id and scope pair. Both
> >>>
> >> together
> >>
> >>> describe a set of nodes.
> >>>
> >>> The resource-id value you proposed can only be a value in a GLOBAL
> >>>
> >> decision
> >>
> >>> request. In an individual decision request (that is derived
> >>>
> >> automatically by
> >>
> >>> the PDP following the guidelines in the mult. & hier. resource
> profile)
> >>>
> >> the
> >>
> >>> resource-id value must refer to exactly one node. This must be one
> node
> >>>
> >> that
> >>
> >>> was originally specified by the resource-id and scope value of the
> >>>
> >> global
> >>
> >>> decision request. Thus example values of the individual resource-id
> >>>
> >> values
> >>
> >>> in the different decision requests are e.g.:
> >>> derived decision request one:
> >>> resource-id=ns1:objects[1]/ns1:book[1]
> >>> derived decision request two:
> >>> resource-id=ns1:objects[1]/ns1:book[2]
> >>> ...
> >>>
> >>> if you go down the book trees depends on the chosen scope value. e.g.
> in
> >>> case of dependants you would do that.
> >>>
> >>>
> >>>
> >>>>     Response: resource-id=ns1:objects/ns1:book[1],
> >>>>
> >> ns1:objects/ns1:book[2]
> >>
> >>> if your decision requests asks for multiple responses (one for each
> >>>
> >> node)
> >>
> >>> than you get back n individual decision responses. The resource-id
> >>>
> >> values
> >>
> >>> will therefore also be:
> >>> resource-id in decision response 1:	resource-id
> >>>
> >> =ns1:objects/ns1:book[1]
> >>
> >>> resource-id in decision response 2:	resource-id
> >>>
> >> =ns1:objects/ns1:book[2]
> >>
> >>> ...
> >>>
> >>>
> >>>
> >>>> Many other trivial, but equivalent, variations could have been
> >>>>
> >> returned.
> >>
> >>>> But I only guessed at these from an example Erik gave, not from
> >>>>
> >> anything I
> >>
> >>>> read in the specs.  I would expect to find it in multi section 2.2.
> >>>>
> >>>>
> >>> The question here is if it is sufficient to say that the resource-id
> >>>
> >> value
> >>
> >>> of an individual request has to match exactly one node (as the spec
> >>> currently says) or whether it makes sense to specify a certain form.
> >>> Depending on how you write the Target Match part a certain form may be
> >>> required.
> >>>
> >>> If you match like this you are free to define the exact syntax of your
> >>> resource-id values.
> >>> In the Rule Target:
> >>> xpath-node-equal(resource-id, /objects/book)
> >>>
> >>> If you match like this a certain form must be defined in order to
> ensure
> >>> interoperability.
> >>> In the Rule Target:
> >>> reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\])
> >>>
> >>>
> >>> Note that these are two equivalent options and whether option 1 is
> >>>
> >> better
> >>
> >>> than option 2 still needs to be discussed. Performance might be an
> issue
> >>>
> >> in
> >>
> >>> case 1 and favour option 2. On the other side option 2 has to deal
> >>> explicitly with the namespace prefix prob.
> >>>
> >>> Attached I edited your examples in the way how I would do it. Note
> that
> >>>
> >> I
> >>
> >>> was in a rush so I hope I got them mostly right.
> >>>
> >>> Best regards
> >>> Jan
> >>>
> >>>
> >>>
> >>>> Regards,
> >>>> --Paul
> >>>>
> >>>>
> >>> [1] http://lists.oasis-open.org/archives/xacml/200909/msg00023.html
> >>>
> >>>
> >>> ________________________________________
> >>> From: Jan Herrmann [mailto:herrmanj@in.tum.de]
> >>> Sent: Thursday, September 24, 2009 07:00
> >>> To: Tyson, Paul H; 'Erik Rissanen'; 'Rich.Levinson'
> >>> Cc: xacml@lists.oasis-open.org
> >>> Subject: XACML's limitations in the access control for XML documents
> use
> >>> case - AW: AW: [xacml] CD-1 issue #11: strictness of xpath definition
> >>> Hi Paul, all
> >>>
> >>> in the following I try to explain some limitations of the current
> >>>
> >> version of
> >>
> >>> the multiple and hierarchical resource profile and the core-spec in
> the
> >>> xml-resource use case. Then through an example I will show how the
> >>>
> >> proposed
> >>
> >>> extensions could enhance the capabilities and expressiveness
> >>>
> >> significantly.
> >>
> >>> Baseline:
> >>> - you are trying to control access to xml resources on a fine-grained
> >>>
> >> level
> >>
> >>> - contend dependant rules should be supported. i.e. it must be
> possible
> >>>
> >> to
> >>
> >>> express access rights for a node that are dependant on the value of
> >>>
> >> other
> >>
> >>> nodes
> >>> - filtering should be supported. I.e. in case access to one (or some)
> >>> node(s) in the xml resource is denied, it should be possible to filter
> >>>
> >> out
> >>
> >>> these nodes and return the accessible part of the xml-resource to the
> >>>
> >> user
> >>
> >>> Example Scenario:
> >>> To simplify the discussion assume the following situation:
> >>> You have xml docs looking like this one:
> >>> <objects>
> >>>   <book>
> >>>     <title>xxx</title>
> >>>     <author>Bob</author>
> >>>     <id>100</id>
> >>>     <price>30</price>
> >>>     <book-content>…..</book-content >
> >>>   <book>
> >>>   <book>
> >>>     <title>yyy</title>
> >>>     <author>Alice</author>
> >>>     <id>200</id>
> >>>     <price>80</price>
> >>>     <book-content >…..</book-content >
> >>>   <book>
> >>> </objects>
> >>>
> >>> This resource is included in a global decision request which looks
> like
> >>> this:
> >>>      <request>
> >>>             subject-id=Bob
> >>>             <content>…the xml resource </content>
> >>>      </request>
> >>>
> >>> Further assume you try to define a rule, that denies access to book
> >>>
> >> nodes,
> >>
> >>> if the book’s price is higher than 50$ and the author OF THIS BOOK is
> >>>
> >> the
> >>
> >>> requesting subject.
> >>>
> >>> A first try to define the needed rule could look like this:
> >>> Approach 1:
> >>> <Rule effect=Deny>
> >>> …Any-Of(less-than, 50, AttributeSelector(/objects/book/price/text()) )
> >>>
> >> AND
> >>
> >>> Any-Of(string-equals, string-one-and-only(AttributeDesignator(subject-
> >>>
> >> id)),
> >>
> >>> AttributeSelector(/objects/book/author/text()) )
> >>> </Rule>
> >>>
> >>> Unfortunately this rule doesn’t implement the intended behaviour.
> >>>
> >>> Prob 1: filtering is not possible
> >>> The XACML decision request & response refers to the XML resource as a
> >>>
> >> whole.
> >>
> >>> What you actually need to allow filtering are access decision request
> >>>
> >> and
> >>
> >>> responses for each individual node.
> >>>
> >>> Prob 2: The use of two and-ed Any-Of expressions destroys the
> semantical
> >>> relationships between the nodes
> >>> If e.g. Bob is the requesting subject, than the rule will match and
> deny
> >>> access although Bob should be allowed to access the first and second
> >>>
> >> book
> >>
> >>> element.
> >>>
> >>> Note that this problem could be solved, if you would allow the
> following
> >>> type of xpath expression in the AttributeSelector:
> >>> Approach 2:
> >>> integer-greater-than
> >>> (integer-one-and-
> >>>
> >> only(AttributeSelector(count(/objects/book[price/text()>50
> >>
> >>> AND author/text() = AttributeDesignator(subject-id)])), 0).
> >>> This is not possible as XACML constructs like the AttributeDesignator
> >>>
> >> can’t
> >>
> >>> be used inside the XPATH predicate.
> >>>
> >>> Another approach that is XPath conformant could therefore be:
> >>> Approach 3:
> >>> <Rule effect=Deny>
> >>> …Any-Of(string-equals, string-one-and-
> only(AttributeDesignator(subject-
> >>>
> >> id)),
> >>
> >>> AttributeSelector(/objects/book[ price/text() > 50]/author/text()) )
> >>> </Rule>
> >>>
> >>> This rule should implement the intended access semantics but still has
> >>>
> >> its
> >>
> >>> limitations:
> >>> 1. The problem was solved through a mix of XACML constructs and XPath
> >>> predicates. To overcome the limitations parts of the XACML constructs
> >>>
> >> were
> >>
> >>> shifted into the XPath predicate. Note that this worked in the
> example,
> >>>
> >> as a
> >>
> >>> less-than or higher-than function is allowed in XPath predicates.
> >>> Unfortunately this means that XACML’s functions are not eXtensible
> below
> >>>
> >> the
> >>
> >>> functions supported by XPath.
> >>> E.g. in the OGC GeoXACML use case we have added functions like within,
> >>> touches, disjoint and so on. As these functions are not supported by
> >>>
> >> XPath
> >>
> >>> they can only be used in the extened form of XACML and this introduces
> >>> strong limitations in the expressiveness.
> >>> 2. Assume you want to change the intended rule semantics to:
> >>> deny access to a book node, if the book’s price is higher than an
> XACML
> >>> Attribute A and the author OF THIS BOOK is the requesting subject
> >>> This will prevent you from shifting the semantics into the XPath
> >>>
> >> predicate
> >>
> >>> and thus will cause limited expressiveness.
> >>>
> >>> From my understanding using the xpath-match functions doesn’t help
> >>>
> >> solving
> >>
> >>> the problems mentioned above.
> >>> Filtering will still not be possible and the problem that pointers to
> >>>
> >> XACML
> >>
> >>> decision request data are not allowed inside an XPath predicate and
> the
> >>> problem that only predicates supported by XPath can be used still
> apply.
> >>>
> >>> The good news is that with very little changes to the profiles the
> >>>
> >> problems
> >>
> >>> above can be solved.
> >>>
> >>> A solution could look like this:
> >>>
> >>> 1. A PDP receives a global decision request with
> >>>     resource-id=/objects
> >>>     scope=descendant
> >>>     <content>… the xml resource </content>
> >>>
> >>>     The resource-id and scope Attribute specifies a set of nodes that
> >>>
> >> are
> >>
> >>> the individual resources for which the access rights have to be
> checked.
> >>>
> >>> 2. Based on this global decision request the PDP generates individual
> >>> decision requests. – one for each individual node.
> >>>     Thus the PDP generates the following decision requests:
> >>>      <request>
> >>>             subject-id=Bob
> >>>             resource-id=/objects[1]
> >>>             <content>…the xml resource </content>
> >>>      </request>
> >>>      <request>
> >>>             subject-id=Bob
> >>>             resource-id=/objects[1]/book[1]
> >>>             <content>…the xml resource </content>
> >>>      </request>
> >>>      <request>
> >>>             subject-id=Bob
> >>>             resource-id=/objects[1]/book[1]/title[1]
> >>>             <content>…the xml resource </content>
> >>>      </request>
> >>>      <request>
> >>>             subject-id=Bob
> >>>             resource-id=/objects[1]/book[1]/author[1]
> >>>             <content>…the xml resource </content>
> >>>      </request>
> >>>      <request>
> >>>             subject-id=Bob
> >>>             resource-id=/objects[1]/book[1]/price[1]
> >>>             <content>…the xml resource </content>
> >>>      </request>
> >>>      …
> >>>
> >>>      <request>
> >>>             subject-id=Bob
> >>>             resource-id=/objects[1]/book[2]
> >>>             <content>…the xml resource
> >>>      </request>
> >>>      …
> >>>
> >>> 3. Having these decision requests allows you to define very powerful
> >>>
> >> rule
> >>
> >>> semantics and filtering is supported too.
> >>>     e.g. the rule in the example above would look like this
> >>>
> >>>     <Rule effect=Deny>
> >>>             Target:
> >>>                         reg-exp-string-match(resource-id,
> >>> /objects\[\d+\]/book\[\d+\]
> >>>             Condition:
> >>>                         AttributeSelector(concat(resource-id,
> >>>
> >> /price/text())
> >>
> >>>> 50 and
> >>>>
> >>>>
> >>>        AttributeSelector(concat(resource-id, /author/text()) =
> >>> AttributeDesignator(subject-id)
> >>>     </Rule>
> >>>
> >>>
> >>>
> >>> Note that all the problems mentioned above are solved.
> >>> Filtering is possible as resource-id always refers to exactly one node
> >>>
> >> in
> >>
> >>> the xml resource and thus we get individual access decisions for each
> >>>
> >> node
> 
> >>
> >>> in the xml resource. As resource-id is included in the decision
> response
> >>>
> >> the
> >>
> >>> PEP can (e.g. through a simple xslt) filter out the nodes for which
> the
> >>> decision was deny.
> >>> Further the problem of defining content dependant rights without
> >>>
> >> reducing
> >>
> >>> the possible authorization semantics is solved, thanks to an
> >>> AttributeSelector that uses a concatenation of the resource-id
> attribute
> >>> value and an arbitrary offset as its RequestContextPath value.
> >>>
> >>> Note that the explanations above are simplified and try to focus the
> >>>
> >> core
> >>
> >>> aspects of the idea only. I hope that I could nevertheless make clear
> >>>
> >> where
> >>
> >>> the limitations are and how they could be solved.
> >>> Let me know if you have problems understanding the ideas and I will
> try
> >>>
> >> to
> >>
> >>> explain in more detail. Further, more detailed information can be
> found
> >>>
> >> in
> >>
> >>> the comments I submitted during the public review period.
> >>>
> >>> Best regards
> >>> Jan
> >>>
> >>>
> >>> <snip>
> >>> ----------------------------------------------------------------------
> --
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >
> >




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]