OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] <xacml><model> Proposal of Post Condition


The following is the proposal of the post condition.
Comments are welcome. I will post XML Schema definition later.

Best regards,
Michiharu Kudo

--------------------------------------------------
Proposal of Post Condition Specification

Date:   11 February, 2002
Author: Hal Lockhart and Michiharu Kudo

1. Overview

1.1 Definition of post conditions
A process specified in a rule that must be completed in conjunction with
access.
The post condition is specified using URI reference. 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.

1.2 Usage Scenarios
Necessary cryptographic/security operations to secure target resource:

"Employees can update their personal information provided the access is
logged" --- post condition is "log"

"Users can read data provided it is encrypted" --- post condition is
"encrypt"

"Subscribers can download digital music from the library provided their
id are digitally fingerprinted on the downloaded data" --- post condition
is "fingerprint"

Obligatory operations associated with private information:

"Merchant A can read customer's annual income provided that it
is anonymized" --- post condition is "anonymization"

"Customers can register themselves with their private information
provided that such information is deleted in 90 days." --- post condition
is "delete-in-90days"


2.  Examples

2.1 Example 1
Here is the XACML policy instance.

<policy>
  <lessOrEqual>
    <valueRef attributeName="rec:expirationDate"/>
    <value xsi:type="date">2002-03-31</value>
  </lessOrEqual>
  <postCondition>
    <onTrue>
      <operation uri="http://www.xyz.com/postCond/log"/>
    </onTrue>
  </postCondition>
</policy>

Notes:

This policy contains a "log" post condition using URI "
http://www.xyz.com/postCond/log".
The meaning of this policy is "if the expiration date is prior or equal to
31 March
2002, then access is granted but necessary post condition is defined by
http://www.xyz.com/postCond/log." Note that the post condition is defined
under
<onTrue> element.


2.2 Example 2
Here is another XACML policy instance.

<policy>
  <lessOrEqual>
    <valueRef attributeName="rec:expirationDate"/>
    <value xsi:type="date">2002-03-31</value>
  </lessOrEqual>
  <postCondition>
    <onTrue>
      <operation uri="http://www.xyz.com/postCond/notify" value="owner"/>
      <operation uri="http://www.xyz.com/postCond/log"/>
    </onTrue>
    <onFalse>
      <operation uri="http://www.xyz.com/postCond/warning"/ value="level1">
      <operation uri="http://www.xyz.com/postCond/log"/>
    </onFalse>
  </postCondition>
</policy>

Notes:

This policy contains four post conditions: two for the true condition
(in case that the expiration date is equal or prior to 2002-03-31) and two
for the
false condition (in case that the expiration date is after 2002-03-31).
The notify post condition has an optional value attribute that specifies an
arbitrary
argument. The meaning of this policy is "if the expiration date is equal
or prior to 2002-03-31, then access is granted and necessary post
conditions
are the "notify (owner)" and the log. Otherwise, the access is denied but
post conditions must still be made true that are the "warning (level1)"
and the log.


3. Processing Rules

The following describes the processing rules of post conditions.

3.1 Condition evaluation
PDP determines whether the conditional expression holds or not in response
to
an access request.

3.2 Post condition computation
If there is <onTrue> post condition and the condition holds, the processor
tries to
return one or more post conditions specified under <onTrue> element. If
there is <onFalse>
post condition and the condition does not hold, it tries to return one or
more post
conditions specified under <onFalse> element.

3.3 Handling PDP-supported post conditions
If PDP is configured to support post conditions, PDP retrieves the
supported post
conditions from the resolved set and performs those post conditions.
PDP finally returns the remaining post conditions to the PEP. If PDP is not
configured
to support post conditions, PDP just returns the resolved post conditions
back to PEP.

3.4 Execution result of post conditions
PDP trusts PEP with regard to the execution of the post conditions. Errors
and
exceptions for post conditions are out of the scope of XACML. They are
determined
in each XACML application. This trust relation is similar to the one
between PDP
and PEP in the sense that the resource protection finally depends on the
PEP configuration
regardless of the PDP's access decision.


4. Issues
4.1 Internal v.s. external post conditions
XACML does not support any distinction between internal post condition and
external post condition. It depends on the configuration of PEP and/or PDP.
Refer to 3.3.

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.
Applications must define them. Refer to 3.4.

4.3 Inapplicable
The post condition is not computed and executed when the binary expression
is determined as
inapplicable (or other undecidable cases)

4.4 Base policy v.s. policy reference
The post conditions CAN be specified in the base policy as well as the
policy
reference. When the policy reference returns one or more post conditions,
the
base policy MUST deal with the returned post conditions. The possible
processing
rule is the following (this is subject to change):

  4.4.1 Boolean expression handling
  In the base policy, the processor MUST determine whether the condition
holds
  or not regardless of the post condition.

  4.4.2 Post condition handling
  If the condition holds, the processor gathers all the post conditions
that are
  attached to the TRUE conditions. If the condition does not hold, the
processor
  gathers all the post conditions that are attched to the FALSE conditions.

  4.4.3 Return final decision
  After gathering all the post conditions, the processor returns Grant or
Deny
  permission with corresponding post condition(s).


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


4.6 When to execute post condition
While post condition implies that specified operations must be dealt with
prior to the requested access, it does not necessarily mean that the
specified
operations must be executed synchronously. Taking the obligatory operation
usage scenario in 1.2 for example, it is impossible to execute
"delete-in-90days"
post condition prior to the requested access. It would be reasonable if
such
operation is queued in the application and guaranteed to be executed later.


4.7 Extension point
XACML SHOULD support extension point in the post condition specification
and
semantics. It includes the process of how to determine the post condition.
One example is that the processor selects the post condition that is
attached
to the rule of the highest priority.

Michiharu Kudo

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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC