Deny-Unless vs Allow-IF ACL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday - last edited yesterday
I am looking for clarification on the ACL evaluation logic for Deny-Unless and Allow-If ACLs.
The official documentation states:
"If no Allow-If ACL is matched and the Deny-Unless ACL passes, the system grants access by default."
Docs link - https://www.servicenow.com/docs/r/platform-security/access-control/acl-denial-behavior.html
However, I've seen blogs/videos explaining that after passing a Deny-Unless ACL, a user still needs an Allow-If ACL to grant access.
My confusion is around the phrase "no Allow-If ACL is matched" in the documentation.
Does this mean:
- No Allow-If ACL exists at all for the requested operation?
- Allow-If ACLs exist, but none of them evaluate to true for the user?
- Both of the above scenarios?
What I want to know is:
1. Deny-unless passed, no allow if defined at all, what happens?
Here one persons says
- If you pass all Deny Unless ACLs, you are then evaluated against Allow If ACLs. Passing at least one Allow If ACL grants access.
What if allow-if is not defined at all?
very confusing statement
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hello @Suggy ,
In short it's scenario 1, not scenario 2.
Also Deny Unless passed, no Allow-If defined at all : what happens?
- If literally zero Allow-If ACLs exist anywhere in the table's inheritance chain for that operation > access granted.
- If Allow-If ACLs exist somewhere in the chain (even on a parent table) but none of them evaluate true for this user > access denied.
don't rely on the grants by default behavior, always define an explicit Allow If for anything security sensitive. Treat the no Allow If = allow fallback as an artifact of ACL inheritance, not something to design around.
If my response helped mark as helpful and accept the solution.