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