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] Discussion summary and revised post-condition proposal


Attached is the discussion summary of post-condition sub-sub-committee
about the post condition. We also updated the proposal.

Michiharu Kudo

-------------------------------------------------
Discussion summary:

- Issue 1. Definition of post-condition

"A process specified in a policy that should be returned in conjunction
with access as an annotation. It means that the post-condition should be
executed 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."


- Issue 2. Distinction between internal post-condition and external
post-condition

No distinction.
XACML specification defines just the policy syntax and the evaluation
semantics with respect to the post-condition. Thus on XACML policy
specification level, there is no distinction between internal
post-condition and external post-condition. It only depends on the PDP/PEP
configuration.

Taking log post-condition for example, it can be divided into two
categories. One is a PDP-level logging. When PDP is configured to support
the PDP-level logging, every access request and access decision might be
logged. This is similar to the system log function in UNIX operating
system. This is outside of the scope of the XACML.  The other case is a
policy-level logging using "log" post-condition. The policy writer can
decide when and how the access is logged (the logging operation is enforced
by PEP in this case). For example, a policy writer may need to check only
write access requests on a specific resource requested in a certain time
period. Then this is a kind of application-level access control policy
rather than the system-level access control policy. In this case, XACML
post-condition can support this.

- Issue 3. Mandatory v.s. advisory post conditions

No distinction.
XACML does not support any distinction between mandatory post condition and
advisory post conditions. If users need to enforce post-condition as a
mandatory operation, PEP (or PDP) must be configured to support that
policy. Thus, errors and exceptions of the post conditions are not defined
in XACML. The meaning of the post condition instance (e.g. log, notify) is
determined by each application. XACML just defines how authorization
decision assertion with post condition SHOULD be handled in PEP:

Case 1: Permission is "GRANT" with a set of post conditions:
PEP checks whether PEP can fulfill every post condition (the semantics of
the fulfilment depends on each PEP). If PEP can fulfill, then the
permission is determined as "GRANT". PEP is responsible for fulfilling
every post conditions. If PEP cannot, then the authorization decision is
determined as "DENY" This situation implies "ERROR"that may need to be
handled by PEP. This error has nothing to do with PDP behavior.

Case 2: Permission is "DENY" with a set of post conditions:
PEP checks whether PEP can fulfill every post condition (the semantics of
the fulfilment depends on each PEP). If PEP can fulfill, then the
permission is determined as "DENY". PEP is responsible for fulfilling every
post conditions. If PEP cannot, then the authorization decision is
determined as "DENY" and PEP should output "ERROR" to PEP administration.
This error has nothing to do with PDP behavior.

- Issue 4. Post condition in SAML authorization decision assertion

Post-condition is returned in the SAML assertion with other authorization
decision information. <provisionStatement> element is added to the SAML
authorization decision assertion. See Example 2.1. Section 4.3 describes
XML Schema fragment.


- Issue 5. Appropriate word for "post-condition"

One of the problems with the term 'post-condition' is that it technically
refers to the *state* of something after an event, not something that must
be done (as is the case with the term 'pre-condition'). This can become
confusing when working in other contexts (like UML: "Postconditions -
Describe the state of the system, and perhaps the actors, after the use
case is complete...").

*** Tentatively, we use the word "provision" for "post-condition" in the
proposal below. Another option is "obligation". ***

--------------------------------------------------
Proposal of Provision Specification (updated)

Date:   21 February, 2002
Author: Michiharu Kudo, Hal Lockhart, Bill Parducci, and Toshihiro
Nishimura

1. Overview

1.1 Definition of provision

A process specified in a rule that should be returned in conjunction with
access as an annotation. It means that the provision should be executed in
conjunction with access. The provision is specified using URI reference.
While XACML defines the processing rules of the provisions, the actual
meaning of each provision 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" --- provision is "log"

"Users can read data provided it is encrypted" --- provision is "encrypt"

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

- Obligatory operations associated with private information:

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

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


2.  Examples

2.1 Example 1
Here is the XACML policy instance.

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

Notes:

This policy contains a "log" provision using URI "
http://www.xyz.com/provision/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 provision is defined by http://www.xyz.com/provision/log."
Note that the provision is defined under <onTrue> element. By definition,
the meaning of log provision by "http://www.xyz.com/provision/log" may be
different from the log defined by other URI such as "
http://my.com/provision.log".

Here is a potential authorization decision syntax. We extend SAML
AuthorizationDecisionStatement to include xacml:provisionStatement element
to return provision(s).

<Assertion>
  <AuthorizationDecisionWithProvisionStatement Resource="aaa" Decision
="Permit">
    <Subject>Alice</Subject>
    <Actions>read</Actions>
    <xacml:provisionStatement>
      <xacml:operation uri="http://www.xyz.com/provision/log"/>
    </xacml:provisionStatement>
  </AuthorizationDecisionWithProvisionStatement>
</Assertion>

2.2 Example 2
Here is another XACML policy instance.

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

Notes:

This policy contains four provisions: 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 provision 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
provisions are the "notify (owner)" and the log. Otherwise, the access is
denied but provisions must still be made true that are the "warning
(level1)" and the log.

Here is a potential authorization decision syntax with the denial access
decision.

<Assertion>
  <AuthorizationDecisionWithProvisionStatement Resource="aaa" Decision
="Deny">
    <Subject>Alice</Subject>
    <Actions>read</Actions>
    <xacml:provisionStatement>
      <xacml:operation uri="http://www.xyz.com/provision/warning" value
="level1"/>
      <xacml:operation uri="http://www.xyz.com/provision/log"/>
    </xacml:provisionStatement>
  </AuthorizationDecisionWithProvisionStatement>
</Assertion>



3. Processing Rules

The following describes the processing rules of provisions.

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

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

3.3 Return provisions to PEP
PDP just returns the resolved provisions back to PEP. We assume here that
PDP is not configured to support provisions. PDP-supported provision is
outside the scope of XACML.

3.4 Processing rules for provisiona in PEP

Case 1: Permission is "GRANT" with a set of provisions:
PEP checks whether PEP can fulfill every provision (the semantics of the
fulfilment depends on each PEP). If PEP can fulfill, then the permission is
determined as "GRANT". PEP is responsible for fulfilling every provisions.
If PEP cannot, then the authorization decision is determined as "DENY" This
situation implies "ERROR"that may need to be handled by PEP. This error has
nothing to do with PDP behavior.

Case 2: Permission is "DENY" with a set of provisions:
PEP checks whether PEP can fulfill every provision (the semantics of the
fulfilment depends on each PEP). If PEP can fulfill, then the permission is
determined as "DENY". PEP is responsible for fulfilling every provisions.
If PEP cannot, then the authorization decision is determined as "DENY" and
PEP should output "ERROR" to PEP administration. This error has nothing to
do with PDP behavior.


3.5 Execution result of provisions
While PDP trusts PEP with respect to the execution of the provisions,
errors and exceptions for provisions are outside 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. Other Issues

4.1 Inapplicable
In PDP, the provision is not computed and executed when the binary
expression is determined as inapplicable (or other undecidable cases)

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

  4.2.1 Boolean expression handling
  The processor MUST determine whether the condition holds or not
regardless of the existence of the provision.

  4.2.2 Provision handling
  If the condition holds (at any earliest point), the processor gathers all
the provisions that are attached to the <onTrue> element in actually
evaluated policy. If the condition does not hold, the processor gathers all
the provisions that are attached to the <onFalse> element in actually
evaluated policy.

  4.2.3 Return final decision
  After gathering the provisions specified in 4.2.2, the processor returns
Permit or Deny permission with corresponding provision(s).

4.3 How to return provisions via SAML
Provisions are placed in <provisionStatement> element in the extended SAML
authorization decision assertion (e.g.
AuthorizationDecisionWithProvisionStatement).

The following is the SAML (potential) schema definition extended for
provision.

<xs:element name="AuthorizationDecisionWithProvisionStatement" type
="xacml:AuthorizationDecisionWithProvisionStatementType" substitionGroup
="saml:AuthorizationDecisionStatement"/>
<xs:complexType name="AuthorizationDecisionWithProvisionStatementType">
  <xs:complexContent>
    <xs:extension base="saml:AuthorizationDecisionStatementType">
      <xs:sequence>
        <xs:element ref="xacml:provisionStatement"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

4.4 When to execute provision
While provision 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" provision prior to the requested access. It would be
reasonable if such operation is queued in the application and guaranteed to
be executed later.


Appendix

A.1 Schema definition for Provision (used in XACML policy specification)

<xs:element name="provision">
  <xs:choice>
    <xs:element name="onTrue">
      <xs:complexType>
        <xs:sequence>
          <xs:element name="operation" type="xacml:ProvisionOperationType"
maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>
    <xs:element name="onFalse">
      <xs:complexType>
        <xs:sequence>
          <xs:element name="operation" type="xacml:ProvisionOperationType"
maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>
  </xs:choice>
</xs:element>

<xs:complexType name="xacml:ProvisionOperationType">
  <xs:simpleContent>
    <xs:extension base="xs:string">
      <xs:attribute name="uri" type="xs:anyURI" use="required"/>
      <xs:attribute name="value" type="xs:string" use="optional"/>
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>


A.2 Schema definition for Provision Statement (used in SAML authorization
decision statement)

<xs:element name="provisionStatement">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="operation" type="xacml:ProvisionOperationType"
maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>


Best regards,
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