Is there any notion of returning an indeterminate response instead of

EFFECT_ALLOW

/

DENY

? Use case would be adding Cerbos on top of existing authorization logic. eg: If Cerbos returns an answer use it -- but if indeterminate, fallback to the existing logic (outside of Cerbos).

Policies are compiled in such a way that there cant be an indeterminate answer to any request. Cerbos will always return EFFECT_DENY if it cant compute your intent from the claims provided to it. I thnk what you might be looking for is some way for cerbos to say "According to what I have here, I don't know" and pass that along to the caller. The issue with that approach is that unless you explicitly deny things via EFFECT_DENY, cerbos will always return EFFECT_DENY precisely because it couldnt produce EFFECT_ALLOW...so you'll get a lot of noise. I am currently transitioning my systems to use cerbos for authz, and I've found that you need to perform the bespoke checks first before checking with cerbos...with the intent of removing those bespoke checks altogether Working with multiple authz implementations can be pretty painful...but until you are ready to convert, you should use your existing auth as the source of truth until your policies are battle-tested...just my 2¢

Hi Mark, Steve's right, you can only get allow/deny out of a check request. I can see a few possible ways around it for your use case: • You could pass the result of the existing logic to Cerbos as a resource attribute, and include that in the conditions in your policy. • You could add an additional action that indicates an indeterminate result, e.g. you could have

view

and

view_with_fallback_logic

, and pass both actions to your check resources request. • You could set

includeMeta: true

on the check request and look for empty

matchedPolicy

in the result metadata, which would indicate an implicit rather than explicit deny (the caveat here is that you would have to write two rules for every action, one allow and one deny, in order to be able to tell whether you have an answer or an indeterminate result). • You could do a plan rather than a check, which allows three-valued results (

KIND_ALWAYS_ALLOWED

,

KIND_ALWAYS_DENIED

, or

KIND_CONDITIONAL

); you could set it up so that you'll get a conditional result if you need to fall back to the existing logic.