ACL rule removed - why access now?

[Kenneth Zabrisk]

After a plug-in install, certain users couldn't edit form fields.

We couldn't figure out what had changed.

In desperation, we disabled a new ACL rule.  Users could now edit as before.

Why?   According to SN documentation, ACL rules are cumulative "unlocks" not "locks".  In other words, a user only needs to pass one (of several) table level rules to have access to the table and only one (of several) field level rules to have access to the field.   Why would removing one of the "unlocks", suddenly allow a user access?

[Kenneth Zabrisk]

Well this is interesting - and a bit disturbing that SN can't describe the ACLs consistently.  I agree that step 3 looks a bit odd, but it is verbatim from the documentation:

https://docs.servicenow.com/en-US/bundle/sandiego-platform-administration/page/administer/contextual-security/concept/acl-rule-types.html

Also, the order of processing from the documentation states:

Record ACL rules are processed in the following order:

• Match the object against table ACL rules.
• Match the object against field ACL rules.
  
  
  But the KB states the reverse:
  
  When a user attempts to access a record from a table, we first check for field level access on the table the user is trying to access (first gate). 

[Kenneth Zabrisk]

I also think the Access Controls Evaluation Order article that you referenced hints at an answer to my critical question when it mentions rule masking.   Perhaps the masking rules are too hard to describe in words, but I wish it were as simple as: "if ACL rule(s) exist at step N but all fail to give access, SN will not check for anything at step N+1.  It will only go on to Step N+1 if there is nothing at step N."

[Allen Andreas]

Hi,

Yes, ACL processing and which way it goes (table first...fields first, etc.) has long been something misunderstood. There was even an episode of live code happy hour (a ServiceNow YouTube series) and during one a few months back there was someone discussing the ACLs and said a certain way that it processes and even Chuck said something like oh...ok...well...you're the ACL guy, implying that he, himself, felt it worked a different way.

I'm personally in the camp that it does table first, then field, and have commonly used the analogy that your house is like a table, you need to get in the front door. Inside, you have many rooms and those rooms are the fields. etc. etc.

In any case, when you create an ACL and it masks another, it is letting you know that a more specific ACL now overrides the prior ACL.

Please mark reply as Helpful, if applicable. Thanks!

[Kenneth Zabrisk]

If none do, as it's evaluating those ACLs, it'll go down those 5 steps in that order from most specific to least specific.

And that's the behavior we didn't see, at least in regards to the fifth step.

A wild card field rule *.* existed that allowed the user create privileges.   Once we added the table.field rule, the *.* rule was not evaluated even though the table.field failed to give access.  The *.* rule couldn't have been evaluated because it would have given access.

I'm going to do a bit of experimenting, but thanks for your insight, time and patience on this.  The community remains the brightest aspect of ServiceNow for me.

[Allen Andreas · Accepted solution]

Hi,

Yeah, I believe I misspoke or misquoted something.

From my testing I've just done, the way it works is not that it goes down 5 steps to look for one that passes...it looks for one at the most specific level and if found, evaluate it and go with that result (whether pass or fail).

So it's not that it runs down the 5 steps if ACLs are found at all of those steps. It means it only goes through those 5 steps, in that order, is NO ACL is found at the prior step.

So in your case, if you had a *.* ACL which did allow them to do 'x'...but then an update to an app or whatever introduced table.field ACLs, then those would "mask" any less specific ACLs and would now call the shots of access or not.

Please mark reply as Helpful/Correct, if applicable. Thanks!