Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indeterminate - a force for good or evil? #28

Open
steven-legg opened this issue May 24, 2024 · 0 comments
Open

Indeterminate - a force for good or evil? #28

steven-legg opened this issue May 24, 2024 · 0 comments
Labels
question Further information is requested

Comments

@steven-legg
Copy link

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.

@steven-legg steven-legg added the question Further information is requested label May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant