[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml-users] XACML 3.0 Obligations
Indeed, the PDP has no way to ensure/enforce what PEP is doing on obligations & advices. It seems that how a PEP behaves is really in the hands of implementers, not determined by the spec. In that case, shouldn’t the TC consider removing obligation/advice elements from the spec so you can have a more semantically sound spec?
We had some problems when dealing with the obligation on the PEP part in the past. For instance, if an obligation requires sending an email out when a PEP performs a “Permit”, but the email server is down, despite the fact that email function is non-essential, but you will have to deny access according to the spec. Furthermore, to add to the semantic confusion, you can define an obligation in such a way (or nothing prevent people from doing so) that it is actually perform the real Permit or Deny function in a PEP. It seems that the obligation/advice elements really deal with business logic/rules that are not access control related. The initial idea of XACML is to create a centralized access control policy, but what obligation/advice are dealing with are really local matters. Mixing central policies with local matters will cause confusions.
You have to realize that there is a distinction between the decision produced by a PDP and the action taken by a PEP.
XACML defines precisely the conditions for all possible decisions of a PDP.
XACML only defines some of the required behavior of a PEP.
A few examples:
When a PDP says “Not applicable” some PDPs will deny access, some will consult a different PDP.
When a PDP says “Indeterminate, missing attributes” some PDPs will locate additional attributes, some will deny access.
When a PEP asks for a hypothetical (what if) decision in order to analyze or debug policies, the PEP will take no enforcement action whatever, since there is no actual request to permit or deny. (Note that this does not violate the text you cite below.)
In the case you mention the PDP decision is “Permit” with Obligations. That ends the involvement of the PDP.
However XACML specifies that in such a case, if the PEP is unable to understand and comply with the Obligation, it MUST NOT permit access.
You could say that in this case, the PEP acts as if the PDP decision had been DENY. However, the actual PDP decision is still Permit with Obligations. If fact, the PDP has no way of knowing the PEP was unable to comply with the Obligations.