OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules

    Posted 03-29-2011 14:00
    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  


  • 2.  RE: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules

    Posted 03-31-2011 15:08
    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  


  • 3.  AW: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules

    Posted 03-31-2011 15:44
    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  


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

    Posted 04-01-2011 07:56
    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