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: WG: AW: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules


Hi Erik, all

a use case could be:

you want to enforce rights that restrict delete operations on a Web Service-based DBMS depending on the properties of the objects you want to delete.

Assume the following:

The Web Service (WS) is offering access on a table building and you want to restrict delete access for building objects whose owner = Bob.

A subject is now sending a delete request to the WS saying: “delete the building object with a ID-attribute = 123.

Obviously based on this intercepted request the PDP can not derive a decision as the information needed to evaluate the rule (i.e. the owner attribute) is not present in the intercepted request.

As the semantics of the rule requires the augmentation of the auth. decision request, I think is appropriate to let the rule drive this augmentation process.

Having a built-in semantic in the PEP that says get all attributes for features that shall be deleted is a very primitive approach and can easily result in an inacceptable and unnecessary overhead.

Based on the semantics on the rule it can be precisely stated which information is additionally needed next to the intercepted delete request (in the example the owner attribute for the object affected by the delete request).

 

Note that this policy driven extension of the auth. decision request is independent of the WS use case.

You could also think of subject information that is missing. Assume that the subject data is represented under the <content> element of the <Attributes> category subject. If a rule needs the <Person><Age> information (which can be missing), you want to instruct the PIP to get the age of the subject from a certain repository. I argue that this additional information retrieval should not be hard-coded” in the pep/context handler as it is dependant on the state of the rules. if you don’t have rules that are dependant on the age of  person, there is no need to force the pep/ctx-handler/PIP do the retrieval of this data.

 

all the best

jan

 

--

Jan Herrmann

Dipl.-Inform., Dipl.-Geogr.

Scientific Assistant

Chair for Applied Informatics / Cooperative Systems

Technische Universität München

Boltzmannstr. 3

85748 Garching

Germany

T: +49 89 289 18692

F: +49 89 289 18657

W: www11.in.tum.de


Von: Erik Rissanen [mailto:erik@axiomatics.com]
Gesendet: Freitag, 1. April 2011 09:55
An: xacml@lists.oasis-open.org
Betreff: Re: AW: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules

 

Hi Jan,

What is the use case for doing it like you propose, instead of submitting the full expected content in the first place?

Regarding the missing attribute detail for plain attributes, I see it as more of an error diagnostic rather than a protocol for submitting attributes to the PDP.

Best regards,
Erik



On 2011-03-31 17:43, Jan Herrmann wrote:

Hi Paul,

what are your concerns when you are controlling the pip/context handler through the policy?

Following your argument it should consequently also not be possible to fetch missing xacml attributes at runtime.

Outsourcing this control in the PEP depending on the type and content of intercepted messages or the subject-credentials, means unnecessary customization and complexity of the PEP implementation.

Best regards

jan

 

--

Jan Herrmann

Dipl.-Inform., Dipl.-Geogr.

Scientific Assistant

Chair for Applied Informatics / Cooperative Systems

Technische Universität München

Boltzmannstr. 3

85748 Garching

Germany

T: +49 89 289 18692

F: +49 89 289 18657

W: www11.in.tum.de


Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
Gesendet: Donnerstag, 31. März 2011 17:08
An: Jan Herrmann; XACML-TC-mailinglist
Betreff: RE: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules

 

Jan,

 

I do not favor this proposal.  XML content in a XACML request is provided “as is”, and should not be negotiable at run-time in the same way that attributes in the request context might be.

 

Any cause of potential defects in XML content should be worked out during development and testing of the PEP and policies, to prevent missing content failures at run-time.

 

Regards,

--Paul

 

From: Jan Herrmann [mailto:herrmanj@in.tum.de]
Sent: Tuesday, March 29, 2011 09:00
To: XACML-TC-mailinglist
Subject: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules

 

Hi there,

 

page 85 and 71 of the XACML core spec describe the missing attribute mechanism. Line 3609 says:

 

In this case [missing-attribute], the <Status> element MAY list the names and data-types of any attributes that are needed by the PDP to refine its decision”

 

In case of <AttributeDesignators Must-be-present=true ...> elements that point to no-existing XACML-Attributes the PDP will know which Attribute-Id values and data-types to list under such a <Status> element.

 

How to achieve a similar behaviour in case of <AttributeSelecor> elements?

 

If this is not yet specified I would propose the following generic solution:

 

Add a new XML Attribute to the AttributeSeletor (e.g. resolve-missing-content-data-obligation).

The value of this . resolve-missing-content-data-obligation XML attribute shall be an ObligationId. The referenced Obligation will instruct the CTX-Handler/PIP how to get more data and how to insert this data through a new <content> in the refined authorisation decision request.

 

Example from the access control for web services (ws) use case

 

0) the intercepted ws-request from the user (think of xml encoded sql requests)

      <delete class=Building>

        <filter>Building.price < 1,000,000</filter>

      </delete>

 

1) the derived XACML ADR

<request>

  <Attributes Category=”ws-request”>

    <Content>

      <delete class=Building>

        <filter>Building.price < 1,000,000</filter>

      </delete>

    </Content>

  </Attributes>

...

</request>

 

2) a Rule demonstrating the control of the pip/context handler from within the policy:

intended semantics of the rule: deny if the ws-requests tries to delete building objects with an owner equal Bob

<Rule Effect=”deny” ...>

...

and(

  string-equal(<AttributeSeclector Category=”ws-request” Path="/” ...> , “delete”) ,

  string-equal(<AttributeSelector Category=”ws-request” Path="/@class” ...> , “Building”) ,

  any-of(string-equal(<AttributeSeclector Category=”response-to-SUB-request” Path=”/Building/Owner/text()” Must-Be-Present=”True” resolve-missing-content-data-obligation=”solve-missing-content-data-problem” ...>, “Bob”))

)

<ObligationExpression ObligationId=”solve-missing-content-data-problem“ >

  <AttributeAssignmentExpression AttributeId=”instruction-To-Generate-sub-request” ...>

    <xslt:transform>

       ....

    <!-- this xslt sheet will be used to transform the originally intercepted ws-request into a subrequest that can be forwarded by the PIP to the ws. The result of the transformation of the once intercepted ws-request into the subrequest might look like this:

<select class=Building>

  <projection>Building.Owner</projection>

  <filter>Building.price < 1,000,000</filter>

</select>”

           -->

     </xslt:transform>

  </AttributeAssignmentExpression>

  <AttributeAssignmentExpression AttributeId=”name-of-Category-under-which-to-include-the-response-to-the-sub-request” ...>response-to-SUB-request</AttributeAssignmentExpression>

</Obligation>

</Rule>

 

3) Consequence of this rule:

In case of an intercepted delete ws-request on building objects the PDP will return an auth. decision with Decision="Indeterminate" and status code = status:missing-content-data. Further the <Status> element will indicate an ObligationId that points to the solve-missing-content-data-problem Obligation. This Obligation instructs the Context Handler/ PIP how to get the missing data and how to refine the original authorisation decision request. In the example the refined auth. decision request will look like shown below. The Context handler will then resubmit the refined request context and the rule will apply as all needed information is available.

 

 

4) refinded XACML ADR

<request>

  <Attributes Category=”ws-request”>

    <Content>

      <delete class=Building>

        <filter>Building.price < 1,000,000</filter>

      </delete>

    </Content>

  </Attributes>

  <Attributes Category=”response-to-SUB-request”>

    <Content>

      <Building id=123>

        <Owner>Alice</Owner>

      </Building>

      <Building id=567>

        <Owner>Bob</Owner>

      </Building>

      ...

    </Content>

  </Attributes>

 

...

</request>

 

 

 

Looking forward to hear your opinions on this issue.

 

Best regards

jan

 

 

 

 

 

--

Jan Herrmann

Dipl.-Inform., Dipl.-Geogr.

Scientific Assistant

Chair for Applied Informatics / Cooperative Systems

Technische Universität München

Boltzmannstr. 3

85748 Garching

Germany

T: +49 89 289 18692

F: +49 89 289 18657

W: www11.in.tum.de

 

 



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