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

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

                      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