[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [xacml] usage of status:missing-attribute in case of an AttributeSelector - control of the pip through xacml rules
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] 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: 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]