Re: [xacml] [model] Proposal of Post Condition

[Michiharu Kudoh <KUDO@jp.ibm.com>]

Hi, Bill

> forgetting for a moment the syntactic issues with the term 'post
> condition' itself, i have a fundamental problem with the concept of MUST
> BE COMPLETED as a result of granting access. this implies that if the
> action does not occur the access should not be granted. that makes it a
> precondition, or at the very least, an action that occurs *as part of*
> the evaluation (e.g. 'confirmation of audit entry prior to issuing
> grant').

I agree that the phrase "MUST BE COMPLETED" is misleading. The heart of the
post-condition is the notion of an annotation that should be attached to
the access
decision. How the post-condition should be processed? So let's assume
a (virtual) post-condition management component that receives a set of
post-conditions
from PDP and that manages them (execute them, queue them, fire them, etc.).
The post-condition management component here is a new component in the
current
XACML domain model and practically it may be a part of PDP or a part of
PEP.
Roughly speaking, the PDP's role should be limited to how to generate the
right access
decision with necessary post-conditions. How it is executed in the
post-condition
management component could be outside the XACML normative specification.

Suppose that PDP generates the access decision like "Alice is allowed to
read
resource X, and post-condition is the log". The post-condition is submitted
to the
post-condition management component and it instantly executes the log
operation.

Suppose another access decision like "Alice is allowed to write her
preference in the
server, and post-condition is to delete her preference in 30 days". In this
case,
the post-condition cannot be executed instantly, instead the delete
operation must be
performed 30 days after this decision is generated. Thus the write
privilege is given to her
provided the system can guarantee the delete operation in 30 days.

As two examples shows, the meaning of the post-condition and how it is
executed
depends on each application. The point is that XACML does not have to worry
about
what it means and how it is executed. XACML only has to define how the
post-condition
is syntactically represented and how it is computed in response to the
access request.

Thus, "... MUST BE COMPLETED ..." in the definition should be rephrased as
"A process specified in a rule that should be returned in conjunction with
access as
an annotation. It means that the post-condition should be executed in
conjunction
with access."

We may need the following description:

"How post-condition is executed is outside the XACML specification.
XACML describes potential configurations of PDP/PEP for supporting
post-condition as informative"

> ...which in my mind will hamper interoperability greatly.

My opinion on interoperability is "XACML processor generates the same set
of access
decisions with the post-condition in response to the set of access
requests". and
"How the post-condition is executed is outside the XACML interoperability"

> here we have the situation where a user is only supposed to be on one
> ...

I think your examples can be distinguished using different URIs of
post-conditions.
For the case of the vender A, the semantics could be represented by
    <operation uri="http://www.vendorA.com/postCond/kill-other-session"/>
For the case of the vender B, the semantics could be represented by
    <operation uri="http://www.vendorB.com/postCond/kill-other-session"/>

Policy writer must be careful in writing the post-condition URI because
different URI means different semantics. Again, note that the semantics of
each post condition is outside the XACML specification as I wrote above.
Does this answer your question?

>
> it seems to me from the meeting that the primary issue here was
> that SAML provided no such mechanism for response?
> ...

Section 4.5 of the proposal writes the following:

4.5 How to return post conditions via SAML
Post conditions are stored in <condition> element of SAML authorization
decision assertion. XACML provides a namespace for storing post conditions.
(It would be an unbounded sequence of <operation> element.)

Is this what you are concerned?

Best regards,
Michiharu Kudo

IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428



From: bill parducci <bill@parducci.net> on 2002/02/14 00:18

To:   "XACML TC <xacml"
cc:
Subject:  Re: [xacml] <xacml><model> Proposal of Post Condition



sorry to take so long to respond to this.

Michiharu Kudoh wrote:
> 1.1 Definition of post conditions
> A process specified in a rule that must be completed in conjunction with
> access.

forgetting for a moment the syntactic issues with the term 'post
condition' itself, i have a fundamental problem with the concept of MUST
BE COMPLETED as a result of granting access. this implies that if the
action does not occur the access should not be granted. that makes it a
precondition, or at the very least, an action that occurs *as part of*
the evaluation (e.g. 'confirmation of audit entry prior to issuing
grant').

otherwise we get into some very dangerous ground quickly:

> While XACML defines the processing rules of the post conditions, the
> actual meaning of each post condition differs from application. It
> also depends on the configuration of the PEP and/or PDP.

which would lead us into this:

> 4.2 Mandatory v.s. advisory post conditions XACML does not support
> any distinction between mandatory post condition and advisory post
> conditions. The meaning of the post condition is determined in each
> application. Thus, errors and exceptions of the post conditions are
> not defined in XACML.

...which in my mind will hamper interoperability greatly.

example
(gated security)
--------

request access to resource X
policy: user only log onto 1 system at a time
post-condition: kill other sessions on grant

(vendor A)
evaluate -> kill access to Y -> if ack, grant; else deny

(vendor B)
evaluate -> grant -> kill access to Y

here we have the situation where a user is only supposed to be on one
system at a time (or logged in only once, or only one user per system at
a time, as in the case of a write to a record...) and yet we are
granting access without actually enforcing this. should be a
PRE-condition, right? what's the distinction? do we list all the things
that are OK to do after because they are not 'necessary' to granting
access? i know that it is a slippery slope, but is there a finite set of
operations that we are acceptable 'post conditions'? logging seems to
really be the only actual example we have, do we do something
specifically for that?

does this make sense?

on the other hand, this makes sense to me:

> Necessary cryptographic/security operations to secure target resource:

...in that a 'grant with stipulation' has a finite evaluation. obviously
there a requirement for a concise description of stipulations needed
here--something similar to our extension for evaluation methods i would
imagine. it seems to me from the meeting that the primary issue here was
that SAML provided no such mechanism for response? is that the case?

b

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>