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

[NISHIMURA Toshihiro <nishimura.toshi@jp.fujitsu.com>]

Hello Kudo-san,

I've been wondering about post-conditions and now it becomes much
clear.


> > 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.)


In the SAML document (core-26), the description of <Conditions>
element is as follows:
| If an assertion contains a <Conditions> element, the validity of the
| assertion is dependent on the conditions provided. Each condition
| evaluates to a status of Valid, Invalid, or Indeterminate. 

<Conditions> element affects the validity of the assertion itself.

The following assertion (it is not accurate) isn't an assertion to say 
  "Alice is allowed to read resource X, and post-condition is the
  log".
It is an assertion to say
  "Alice is allowed to read resource X"
and this assertion is valid when "log" condition is valid.

<Assertion>
  <Conditions>log</Conditions>
  <AuthorizationDecisionStatement Resource="X" Decision="Permit">
    <Subject>Alice</Subject>
    <Actions>read</Actions>
  </AuthorizationDecisionStatement>
</Assertion>


When some errors occur during processing the post-condition, the
difference become distinguishing.
In the first case, 
  Alice is allowed to read resouce X, but the PEP can't "log", so the
  PEP doesn't give X to Alice.
In the latter case,
  Because the PEP can't "log", the assertion "Alice is allowed to read
  resource X" is invalid. The PEP has no valid assertion about Alice.


Though using <Conditions> element might be one option, I think it is
preferable to place post conditions in <Statement>
(<AuthorizationDecisionStatement>) element (but there is no room for
it now).

---
Toshi

NISHIMURA Toshihiro (FAMILY Given)
nishimura.toshi@jp.fujitsu.com
XML Application Technology Dept., PROJECT-A XML, FUJITSU LIMITED