[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Re: [xacml] obligations & error conditions] - PROPOSAL
ok, here is the proposal for the changes to the spec that modify PEP behavior to treat incomprehensible obligations as ERROR conditions (vs. "Deny"). the discussion for this proposal is encapsulated in the discussion thread. line numbering refers to the 0.8 version of the spec and the text provided is meant to replace the corresponding paragraphs in the current spec. line 570: Therefore, bilateral agreement between a PAP and the PEP that will enforce its policies is required for correct interpretation. The PDP returns <Obligations> elements for the PEP to discharge. While the contents of <Obligations> tags are opaque to the PDP, PEPs MUST understand, and be capable of discharging, all obligations associated with a given decision if provided; failure to do so MUST act as if the PDP returned an ERROR. line 1538: [a478]-[a499] The <Obligations> element. One or more obligations MAY be associated with a "Permit" or "Deny" authorization decision. The <Obligations> element contains set of obligations, which are operations that MUST be discharged by the PEP in conjunction with the associated authorization decision. line 1715: The <Obligations> element contains a set of obligations that MUST be discharged by the PEP in conjunction with the authorization decision. If the PEP does not understand, or cannot disharge, any of the obligations, then it MUST act as if the PDP returned an ERROR for the authorization decision value. line 2977: The <Result> element represents an authorization decision result for the resource specified by the ResourceId attribute. It MAY include a set of obligations that MUST be discharged by the PEP. If the PEP does not understand or cannot discharge an obligation, then it MUST act as if the PDP returned an ERROR for the authorization decision value. line 3006: A list of obligations that MUST be discharged by the PEP. If the PEP does not understand or cannot discharge an obligation, then it MUST act as if the PDP returned an ERROR for the authorization decision value.. See Section 7.15 for a description of how the set of obligations to be returned by the PDP is determined. line 3130: A PEP SHALL allow access to the resource only if a valid XACML response of "Permit" is returned by the PDP. The PEP SHALL deny access to the resource in all other cases. An XACML response of "Permit" SHALL be considered valid only if the PEP understands and can and will discharge all of the obligations contained in the response. An XACML response of "Deny" may also be accompanied by obligations. In this case, if the PEP understands the and can discharge the obligations it MUST deny access and make best efforts to discharge the obligations; otherwise the PEP MUST treat the decision by the PDP as an ERROR. > What if the PDP returns an Indeterminate or NotApplicable? see below (want to get all the text changes in first ;o) line 3478: A PEP that receives a valid XACML response of "Permit" with obligations SHALL be responsible for discharging all of those obligations. A PEP that receives an XACML response of "Deny" with obligations SHALL be responsible for discharging all of the obligations that it understands and is capable of discharging. If the PEP cannot understand the obligations provided by the PDP it must treat the decision by the PDP as an ERROR. below: per the second sentence those will result in a "Deny" as well. this is not an 'obligation' issue but rather is what i believe has been the de facto solution to the 'default policy' issue that has swirled around since the first XACML meeting. what i believe is implied here is that while a decision of "Permit" is required for access, this may come about implementationally as a result of multiple attempts by the PEP to contact a variety of PDPs (PAPs? i always find that line confusing ;o) in response to some internal logic. so, if you were to build a PEP that had the logic of: ask PDP1 for access control decisions for the door, but ask PDP2 (the lenient PDP) for decisions in the event PDP1 said no and it is really cold outside or rephrase access control decisions to include 'it is really cold' when the temperature is below 50 (which invokes a kinder, gentler policy) or even ask PDP2 for an access control decisions if PDP1 returns that obligation gibberish and either solution *ultimately* yielded a "Permit" you are still in compliance of the spec even though you received a "Deny", "Indeterminate" or "Error" as part of the process. what can't happen--and what it is i think we are trying to say here--is that unless *something* tells you to "Permit" and you *fully* understand that message then you *cannot* allow access. this is not a 'skew to deny' in the policy evaluation, but rather the default behavior of any system that is conformant, and is done to ensure that there is some level of determinism at the point of *application* of a decision. we need to have this for the simple reason that we must have some sort of baseline vocabulary from which to work. in this case "Permit" = grant access and *any* other result is a flavor of != grant access (a 'normally open' relay on the old circuit board ;o) b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]