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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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


Subject: Re: [xacml-dev] Handling NotApplicable


Kuketayev, Argyn wrote:
 > How do you handle NotApplicable?
 >
 > My PEP has a method in Java implementation
 > void checkPermissions(...).
 >
 > It raises an exception if user is not authorized to execute an action,
 > which means anything but "Permit".
 >
 > "Deny" is also easy. In addition to throwing exception, I also log this
 > event as a warning. In a well designed webapp, this shouldn't happen
 > often.
 >
 > What to do with NotApplicable decision? I decided that it's bad thing to
 > have this, because in my case it indicates that policy wasn't found or
 > something more serious. So, I log this as an error or alert. Unlike,
 > "Deny" this should be dealt with.
 >
 > Thanks,
 > Argyn


depends on the 'bias' of your PEP. most implementers will do just what 
you have explained: deny unless specific permit is granted. there are 
those that believe the opposite has value (permit biased PEPs - permit 
unless specifically presented with deny).

to accommodate both positions XACML allows for either. of course that 
leaves 'base' implementations that don't know what to do! ;o)

my personal opinion is that base pep isn't all that practical given the 
other two exist, but that is just me...

/*

7.1.1.	Base PEP
If the decision is "Permit", then the PEP SHALL permit access.  If 
obligations accompany the decision, then the PEP SHALL permit access 
only if it understands and it can and will discharge those obligations.
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 understand, and it can and will discharge those obligations.

If the decision is “Not Applicable”, then the PEP’s behavior is undefined.

If the decision is “Indeterminate”, then the PEP’s behavior is undefined.

7.1.2.	Deny-biased PEP
If the decision is "Permit", then the PEP SHALL permit access.  If 
obligations accompany the decision, then the PEP SHALL permit access 
only if it understands and it can and will discharge those obligations.

All other decisions SHALL result in the denial of access.

Note: other actions, e.g. consultation of additional PDPs, 
reformulation/resubmission of the decision request, etc., are not 
prohibited.

7.1.3.	Permit-biased PEP
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.

All other decisions SHALL result in the permission of access.

Note: other actions, e.g. consultation of additional PDPs, 
reformulation/resubmission of the decision request, etc., are not 
prohibited.

*/
b




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