You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Indeterminate results when processing XACML expressions have some downsides. The policy writer loses a degree control of the decision at this point.
If the Indeterminate result trickles through to the final decision and then it is up to the PEP to decide what to do. A permit-biased PEP will allow access, which is probably not a desired effect from the policy writer's point of view. Permit-biased PEPs are allowed by the core spec, though likely rare or non-existent in a world focusing on zero trust and least privilege.
Obligations and advice can't be associated with an Indeterminate decision. So even though a deny-biased PEP will deny the access, any obligations or advice that would normally be associated with a Deny decision won't be present.
I have an additional concern because I index policies. Functions that return Indeterminate on well-formed input can't be efficiently indexed. In the worst case a policy has to go in a bucket of policies that have to be checked on every authorization request.
Bill floated the idea that a new decision type might address some of these concerns, with a suggested name of NotProcessable. The logic of NotProcessable in function evaluation and combining algorithms would probably need to follow that of Indeterminate. Possible differences would be that permit-biased PEPs would be required to treat NotProcessable as Deny, and obligations and advice could be associated with an effect of NotProcessable. Alternatively, we allow obligations and advice to be associated with Indeterminate and discard the idea of permit-biased PEPs.
A policy writer can enforce a particular bias by wrapping everything in a policy set with the deny-unless-permit or permit-unless-deny combining algorithm (at the cost of losing missing attribute indications). Assuming all PEPs are deny-biased removes the need for wrapping with deny-unless-permit in the most common case without removing the possibility of effective permit bias, although the wrapper converts an Indeterminate to Deny which would allow obligations and advice to be attached. Adding a Condition to obligations and advice would make this more flexible.
The text was updated successfully, but these errors were encountered:
Indeterminate results when processing XACML expressions have some downsides. The policy writer loses a degree control of the decision at this point.
If the Indeterminate result trickles through to the final decision and then it is up to the PEP to decide what to do. A permit-biased PEP will allow access, which is probably not a desired effect from the policy writer's point of view. Permit-biased PEPs are allowed by the core spec, though likely rare or non-existent in a world focusing on zero trust and least privilege.
Obligations and advice can't be associated with an Indeterminate decision. So even though a deny-biased PEP will deny the access, any obligations or advice that would normally be associated with a Deny decision won't be present.
I have an additional concern because I index policies. Functions that return Indeterminate on well-formed input can't be efficiently indexed. In the worst case a policy has to go in a bucket of policies that have to be checked on every authorization request.
Bill floated the idea that a new decision type might address some of these concerns, with a suggested name of NotProcessable. The logic of NotProcessable in function evaluation and combining algorithms would probably need to follow that of Indeterminate. Possible differences would be that permit-biased PEPs would be required to treat NotProcessable as Deny, and obligations and advice could be associated with an effect of NotProcessable. Alternatively, we allow obligations and advice to be associated with Indeterminate and discard the idea of permit-biased PEPs.
A policy writer can enforce a particular bias by wrapping everything in a policy set with the deny-unless-permit or permit-unless-deny combining algorithm (at the cost of losing missing attribute indications). Assuming all PEPs are deny-biased removes the need for wrapping with deny-unless-permit in the most common case without removing the possibility of effective permit bias, although the wrapper converts an Indeterminate to Deny which would allow obligations and advice to be attached. Adding a Condition to obligations and advice would make this more flexible.
The text was updated successfully, but these errors were encountered: