[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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]