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: 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]