OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[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.

 

Nick

 

From: Hal Lockhart [mailto:hal.lockhart@oracle.com]
Sent: Thursday, May 03, 2012 4:02 PM
To: Andrea Margheri; xacml-users@lists.oasis-open.org
Subject: RE: [xacml-users] XACML 3.0 Obligations

 

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.

 

Hal

 

From: Andrea Margheri [mailto:margheri.andrea@gmail.com]
Sent: Thursday, May 03, 2012 2:02 PM
To: xacml-users@lists.oasis-open.org
Subject: [xacml-users] XACML 3.0 Obligations

 

Hi,

I’m a student of University of Florence and I’m doing a master thesis on XACML 3.0 and the use of obligations. I’m trying to define a formal semantic for  XACML 3.0 and I don’t understand how Obligations are managed by the PEP with Base algorithm.  In fact in section 7.2.1 the standard says: “PEP shall permit access only if it understands and it can and will discharge those obligations”  but it doesn’t say which is the decision of PEP when it can’t understand the obligations, is it deny or indeterminate? And for a PDP authorization decision “Deny” with unsuccessful obligation, it becomes indeterminate?

Thanks

Andrea



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