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



Greetings,

I have some questions on the post conditions w.r.t compose the policies,
especially with the GRANT/DENY semantics that MUST be performed by the PEP
in the "provided that" clause, which Michiharu-san lays out below.

What should the PDP result be if the PDP cannot determine that the PEP can
fulfill the "provisions" on a policy? Say a policy evaluates to "Permit
provided that p1,...,pn" which, according to the semantics in the summary
below a PEP that could not fulfill any of p1,...,pn would change this
result to "Deny". This "change" is performed by the PEP. However, what if
we have two policies, each with provisions that are composed by the PDP.

If policy A is composed with another policy B, the PDP must know exactly
what the PEP can enforce, because according to the operational semantics
outlined below, the PEP can "change" the policy A evaluation from "Permit"
to "Deny", which may effect the out come of the composition of Policy A and
B, say if the combinator were to mean "all policies MUST Permit".

Also another question:

It seems that the "provisions" are stated on "onTrue" "onFalse", lets say
in our current proposal from Simon that we are really talking about
"onPermit"  or "onDeny".

This means that a policy either evaluates to

1. Permit provided that p1,...pn
2. Deny provided that q1,...,qm

Let us say we have a policy with BOTH "onPermit" and "onDeny" provisions.

If #1 is the case, and the PEP cannot fulfill one of p1,...,pn, then does
the PEP need to fulfill q1,...,qm?

What does "Deny with ERROR that may need to be handled by the PEP or ERROR
output to the PEP administration" really mean?

The semantics of the PEP in this situation are underspecified, and are
probably left better not specified at all. That way, you can lift up the
all the "onPermit" and "onDeny" "provisions" from policy and that all
"provisions" are lifted up to the authorization assertion. (I think :^)

Also, another point to think about, since it seems that p1,...,pn
seem to be "imperative" operations what if pk, 1<k<=n, cannot be
fulfilled? Does p1,...,p(k-1) have to be "rolled-back"?

Cheers,
-Polar

On Thu, 21 Feb 2002, Michiharu Kudoh wrote:

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



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


Powered by eList eXpress LLC