Deny-Unless vs Allow-IF ACL

Suggy
Giga Sage

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:

  1. No Allow-If ACL exists at all for the requested operation?
  2. Allow-If ACLs exist, but none of them evaluate to true for the user?
  3. 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

https://www.servicenow.com/community/developer-articles/allow-if-vs-deny-unless-in-servicenow-acls-a...

  • 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?

 

Suggy_0-1786008195928.png

 

very confusing statement

1 REPLY 1

yashkamde
Giga Sage

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.