← Prev in month
← Prev in thread
Next in thread →
Next in month →
Re: WG: AW: [xacml] usage of status:missing-attribute in case ofan AttributeSelector - control of the pip through xacml rules
Hi Jan,
Ok, so the issue you are addressing is performance, where providing
the full XML description would be expensive. I think that is a valid
issue, but I have two concerns:
1. I don't think iteration between PEP and PDP to request a missing
attribute/XML fragment at a time is a good architecture.
2. I am unsure about to which degree these XML fragments can be
worked with.
Regarding the first point, it would be better to use a dynamic
context handler, rather than missing attributes.
Regarding the second point, what I mean is that I understand your
example, but I think that the example is perhaps a bit simplistic,
and it is unclear to me what can be done and should be done in the
solution.
In your example it is an attribute selector pointing out a single
element containing a value. If it ends up selecting an empty bag,
you can trigger the missing XML fragment logic.
However, in full generality it is hard to know what constitutes a
missing XML fragment. Consider this example instead:
<Content>
<ShoppingCart>
<Book>...</Book>
<Book>...</Book>
<DVD>...</DVD>
<DVD>...</DVD>
</ShoppingCart>
</Content>
Let's say that the XACML rule sums the prices of the items in the
shopping cart. How could you detect in this case whether there are
missing items or not?
In the general case it might be impossible. Should there be
additional information saying what has been omitted? How could the
PDP act on that information? Should we ignore the full general case
of the problem? If so, which subclass are we solving? What are the
various subclasses of the problem?
Also, why are you not simply using the normal plain XACML attributes
instead of XML content in this case? You would not have the issue in
that case.
Best regards,
Erik
On 2011-04-01 10:48, Jan Herrmann wrote:
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:]
Gesendet:
Freitag, 1. April 2011
09:55
An:
Betreff:
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
← Prev in month
← Prev in thread
Next in thread →
Next in month →