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

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

Hi, Nishimura-san

I see your point.

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

First I had the same idea and if such modification is accepted by SAML,
that would be the ideal way to take. Actually, I tried to find alternative
solution that might work under a certain assumption.
AuthorizationDecisionStatement may include validity period such as "from 1
March to 31 March" in <Conditions> element in some cases. But access
decisions returned by XACMLed PDP will not generate such restriction from
the discussion in XACML so far. Thus, I thought that <Conditions> element
can be used for post-conditions. From the PEP viewpoint, it is easy to
distinguish AuthorizationDecisionStatement generated by XACMLed PDP from
one generated by other component by looking <Issuer> element etc. But I am
not confident with this usage.

>When some errors occur during processing the post-condition, the
>difference become distinguishing.

If <Conditions> element is used, your concern might be considered. But as I
wrote in the previous mail, my position is that the semantics of the
post-condition depends on each application. If the application uses simple
post-condition like "log", the meaning of the assertion with condition
differs as you described. But if the post-condition is "delete in 30days",
it is meaningless to wait 30days to give the grant decision to the
requester and I think that PEP grants the access to the request after it
registers the "delete in 30days" post condition to the post-condition
management component. In this case, there is no big difference between two
cases you pointed out because even if the delete operation fails after 30
days, there is no way to cancel the grant decision issued 30 days ago.
Anyway the application should deal with this exception independently. I am
quite optimistic that application-specific exception handling can solve
this kind of problems.

Best regards,
Michiharu Kudo

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



From: NISHIMURA Toshihiro <nishimura.toshi@jp.fujitsu.com> on 2002/02/14
      18:36

To:   xacml@lists.oasis-open.org
cc:
Subject:  Re: [xacml] [model] Proposal of Post Condition



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

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