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)
XML Application Technology Dept., PROJECT-A XML, FUJITSU LIMITED
