[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