[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] Base and Permit-biased PEPs
Hi Mary. On Mon, 2004-10-25 at 13:48, Mary Kolencik (email@example.com) wrote: > I have a question about section 7.1.1 and 7.1.3, the Base PEP and > the Permit-biased PEP in 2.0. Those sections say that "If the decision is > "Deny", then the PEP SHALL deny access. If obligations accompany the > decision, then the PEP shall deny access only if it understands, and it > can and will discharge those obligations." > > Suppose the decision is "deny" with obligations and the PEP cannot > understand or discharge the obligation, does this result in a "permit"? > The above sentance says the PEP will only deny if it understands and > can do the obligation, so what happens when it can't understand or > discharge the obligation? Here's my advice to you: forget that you read this section of the 2.0 specification, and replace it in your memory with the following explanation. A PEP is tied to a PDP (or to multiple PDPs), and is done so such that the PEP should deterministically use the PDP's Decision to determine access. In almost all cases, this means that if the Decision is Permit, then the PEP should permit the action, and if the Decision is Deny then the PEP should deny the action. If the Decision is NotApplicable then the PEP may consult some other source, but in most cases will deny the action. If the Decision is Indeterminate then the PEP may be able to recover and try again (depending on the error case), but in most cases will deny the action. Obligations complicate things a little. Obligations are not supposed to be a condition on the Decision, but they look like they act that way. For example, if the PDP returns Permit, and returns Obligations that the PEP cannot discharge, then the PEP is expected to Deny the action. This looks a lot like a condition on the Decision, but it's not really . So, what does this mean in the common case? If your PDP returns a Decision of Permit or Deny and some Obligations, if the PEP cannot discharge the Obligations, then your PEP cannot meet the contract it has with the PDP, and should not accept the decision of the PDP. Where does that leave you? In most systems, this is a case where the PEP cannot make an informed decision about access, and therefore will deny the action by default (although probably with different data logged). This was a long-winded way of saying "whenever you can't handle an Obligation, you should probably deny the action." :) Basically, you just need to think about what makes sense in your system. The text added in 7.1 is an effort to make sure that people don't build systems where the PEP non-deterministically ignores the PDP's decision. Personally, I think it confuses more than it helps, and in my experience common sense prevails in most people's deployments. Sorry this was such a long answer...did I at least answer your question? seth  You can get into endless semantic and pedantic arguments on this issue, and believe me, we have :) I don't want to go down that path right now, but mail me privately if you're interested in my views. To get you started, think about the previous paragraph where I talked about different Decisions that all (usually) result in Deny. Now think about why you care how the PEP decided to deny an action. Having fun yet?