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


Hi Erik,

Thanks for your comments.

Performance can be one aspect but it is actually more than that. Such a mechanism allows you to express and enforce rights that would otherwise not be expressible.

Regarding your issue 1.:

Let’s move to a human-interaction scenario:

If you were responsible to decide if some person P is allowed to get a US-visa (so you act in the role of a PDP) and you can’t answer this question because of missing information, you would ask someone to provide the needed information (this equals the PIP & any-information-source interaction). After you have received the needed information you can either grant or deny the visa request. Requiring the Person P to provide all possibly relevant information is certainly not what you want. Further asking all additional information sources about all available information on Person P upfront is also not very convenient.

 

Back to your architecture/workflow concerns:

Why should a PDP not ask some entity for more information, if it cannot derive a decision? Doesn’t this sort of architecture/workflow model the real life situation?

 

What do you mean by dynamic context handler? From my point of view it must be dynamic in the sense, that he is controlled by the policy?

 

A solution to the example could look similar to the proposal described in my mail form (29.03.2011 16:00). Attach an obligation with instructions to the rule. In case the rule can not evaluate because of missing information the context handler will forward the instructions to the pip which will in turn come up with the needed information. In the example this instruction would be:

Submit a select-request that has the same selection-predicat as the original intercepted delete-request (i.e. ID-attribute = 123), refers to the same table and only projects on the owner attribute (i.e. select owner from...).

 

I have problems understanding the point of your example. Whatever the additional data you need might be, the editor of the rule should be able to give some instructions how to get it (based on the initially available information). Clearly there will always be cases where you can’t direct the pip to the right information source or where the needed query might not be computational.

 

Regarding your questions in the end of you mail:

The example illustrates the general case.

- Information under <content> is missing.

- tell the contextHandler/PEP/PIP what to do, to get more data and how to insert this data in the first-try auth. decision request.

- resubmit the augmented auth. decision request.

Can this be more general? You could ask for whatever data you want, if you need this information to evaluate your access rule.

 

and to the question why not use <xacml:attribute> elements:

They are “flat” (i.e. basic data types) and therefore not very convenient if you represent hierarchical data structures like XML documents (which are the native encoding forms of the evaluation context data in the use cases I am addressing). Further AttributeDesignator do not allow to selectively select data within AttributeValues.  BTW: another solution would be to add a new xacml data type urn:...:XML and to enhance the <AttributeDesignator> by the functionality of a <AttributeSelector> (i.e. add its Path and ContextSelectorId XML Attributes and allow fine-grained selection of data in a AttributeValue). This would allow using the missing-attribute mechanism currently defined in the spec. This would however mean that <Content> and the <AttributeSelector> Element are “loosing use cases” and there are further issues in going this direction.

 

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: Erik Rissanen [mailto:erik@axiomatics.com]

Gesendet: Freitag, 1. April 2011 13:19

An: xacml@lists.oasis-open.org

Betreff: Re: WG: AW: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules

 

Hi Jan,

 

Ok, so the issue you are addressing is performance, where providing the full XML description would be expensive. I think that is a valid issue, but I have two concerns:

 

 

 

1. I don't think iteration between PEP and PDP to request a missing attribute/XML fragment at a time is a good architecture.

 

2. I am unsure about to which degree these XML fragments can be worked with.

 

Regarding the first point, it would be better to use a dynamic context handler, rather than missing attributes.

 

Regarding the second point, what I mean is that I understand your example, but I think that the example is perhaps a bit simplistic, and it is unclear to me what can be done and should be done in the solution.

 

In your example it is an attribute selector pointing out a single element containing a value. If it ends up selecting an empty bag, you can trigger the missing XML fragment logic.

 

However, in full generality it is hard to know what constitutes a missing XML fragment. Consider this example instead:

 

<Content>

  <ShoppingCart>

    <Book>...</Book>

    <Book>...</Book>

    <DVD>...</DVD>

    <DVD>...</DVD>

  </ShoppingCart>

</Content>

 

Let's say that the XACML rule sums the prices of the items in the shopping cart. How could you detect in this case whether there are missing items or not?

 

In the general case it might be impossible. Should there be additional information saying what has been omitted? How could the PDP act on that information? Should we ignore the full general case of the problem? If so, which subclass are we solving? What are the various subclasses of the problem?

 

Also, why are you not simply using the normal plain XACML attributes instead of XML content in this case? You would not have the issue in that case.

 

Best regards,

Erik

 

On 2011-04-01 10:48, Jan Herrmann wrote:

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

 

________________________________________

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]