[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