What is an Access Control (ACL)?
- An Access Control is a mechanism for specifying under what conditions permission should be granted to perform an operation in ServiceNow.
- Each Access Control is represented by a single record in the table sys_security_acl.
- An Access Control may include a list of Roles, a list of Conditions, and a Script block. These work together to either allow or deny access to an Operation in ServiceNow.
- Most Access Controls secure records, but other types of Access Controls secure objects such as UI Pages, REST Endpoints, and Script Includes.
- Access Controls are sometimes called Security Rules or ACLs (Access Control Lists), although an individual Access Control is obviously not a "List".
How do I know if my Instance of ServiceNow is Configured as "Default Allow" or "Default Deny"?
- This Security Manager Setting (glide.sm.default_mode) may be found here: https://YourInstanceName.service-now.com/now/nav/ui/classic/params/target/sys_properties_list.do%3Fsysparm_query%3DnameSTARTSWITHglide.sm.default_mode
- As the Description field states, this setting controls the default behavior in the absence of any Access Controls on a table.
- The default setting is "deny" which means that if a table has no Access Controls whatsoever, permission to that table will be denied.
- Under a "default deny" configuration, permission must be explicitly granted by Access Controls in order for a user to have access to records and fields.
- (Everything in this article you are reading assumes that your instance is setup as "Default Deny")
How do I edit, delete, or modify an Access Control?
Before you can make changes to an Access Control, you must ensure two things:
1) You must possess the role "security_admin", which is different than "admin".
2) You must explicitly execute an "Elevate Role" action via the user menu. Once this is done, Access Control fields become editable.
How do I locate Access Controls so I can review and edit them?
There are several ways to get to access controls...
- From Filter Navigator, go to System Security - Access Control (ACL) to review all access controls in the system.
- To review the Access Controls that apply to any one Table, from the filter navigator, just type in TableName.config.
- From any open Form record, go to the Additional Actions menu - Configure - Security Rules. - Or go to Configure - All and then click on the Access Controls tab.
- Open any table via Filter Navigator - System Definition - Tables, and from that sys_db_object record, scroll down to the related list Access Controls.
- From any List View, from any Column menu, go to Configure - Security Rules
What Types of Access Controls are there?
- The most common type of Access Control pertains to a database Record, but there are other types such as UI Page, REST Endpoint, and Script Include.
- To see the different types, just group by the Type field in table sys_security_acl.
What kinds of Operations do Access Controls secure?
- The most abundant types are Read, Write, and Delete, but there are also Execute and Report View operations, among others.
- To see the different Operations, just group by the Operation field in table sys_security_acl.
What kind of Table should I use to start understanding and experimenting with Access Controls?
- It is very helpful to create your own table, via System Definition - Tables - New.
- Add just a few fields, and then populate it with very few rows. Keeping the row count low will speed up your debugging efforts.
- Example:
For the most important Access Control table, sys_security_acl, how should I configure the list view to see the most useful data?
- It's very helpful to be able to see, in the main list view, all the relevant configuration fields, without needing to drill into every access control record.
- Configuring the List View as follows will ensure that you see the most important fields.
For the second most important Access Control table, sys_security_acl_role, how should I configure the list view to see the most useful data?
- To see the Roles configured for each Access Control record, configure table sys_security_acl_role as follows:
When a brand new Table is created, what Access Controls get created, and what is the Role name associated with them?
- When you create a new table, by default, the "Create access controls" checkbox is checked, so Access Controls will be automatically created with the associated role u_tablename_user.
- ServiceNow creates 4 access controls automatically: record read, write, create, and delete.
- The Access Controls for your new table (or any table) can be seen in either table sys_security_acl, but to see the relationship between the Access Controls and the associated role list, you will want to use table sys_security_acl_role.
What is the difference between Record level Access Controls and Field level Access Controls?
- In many cases Access Controls will pertain to entire records. Either the user can read the entire record, or he can't. This type of record is defined by simply leaving the Field part of the record set to the value "-- None --" rather than setting it to the name of a specific field in the table.
- If you do want an Access Control to pertain to only a single field, you will just select and populate the field to the right of the table name.
Note, if access to an entire Record is denied by a record level Access Control, no field-level Access Control can grant access.
Does a user need all of the roles specified in the Access Control? And do all three of the Access Control checks need to be passed?
- The help text in the Definition part of an Access Control explains pretty clearly how the different parts of the Access Control are evaluated, and includes a "More Info" link to the documentation.
- The user needs only ONE of the roles listed, but if the Condition and/or Script parts of the Access Control are non-blank, those conditions must evaluate to True for the user to be grated access, no matter what roles he has.
- In the following contrived example, a user will only be able to read records in the "Car" table if he has either the u_car_user user role or the u_house_user role. And he will only be able to see records where the Make field is Chevrolet or Ford. And he will only be able to see records where the Model field is Probe or 350Z. In other words, if he is a Car User, he will be able to see the Ford Probe record, but not the Chevrolet Blazer record, and not the Nissan 350Z record.
In an Access Control record, what do the Conditions pertain to?
- The Conditions are applied to each and every Record to determine if access to that record should be allowed.
- Just like the conditions (or filters) you apply to a List View determine if each record should be returned from the database, the conditions of an Access Control determine if the Access Control operation (Read, Delete, etc.) should be allowed on the record.
In an Access Control record, what does the Script pertain to?
- The Script block is run against each and every record which the user is trying to run an Operation against. So if the user is trying to display 20 records in a List View, the Script Block of each relevant Access Control will be run 20 times, once for each record.
- In the Script block a "current" object of type GlideRecord is available, and its fields may be checked to determine if the current record does or does not meet whatever criteria you specify to allow access. However, the script can be used for arbitrary decision-making in addition to checking the fields of the current record itself. In theory, you could use the script block to allow access to records on weekdays, but not weekends, for example.
- Access Control scripts execute server side. For best performance, avoid "GlideRecord" queries and restrict the script logic to only security-related logic.
- An Access Control script must return true, or set the "answer" variable to true.
When should I use the magical * in a Field-level Access Control instead of using a specific Field Name?
- Say you have a table with 100 fields, and you want 97 of them to be seen only by users with the role my_power_user, but the remaining 3 fields may be seen by everyone. In this case, rather than defining 97 separate Access Controls with the same conditions, you could just define a table.* Access Control one time to handle the group of 97 fields, and then you could address the remaining 3 fields individually.
- Since Access Controls work like a 2 gate system, with the outer gate being Record-level access controls, and the inner gate being Field-level access controls, you can't always use a Record-level access control to accomplish what you want.
What are the most useful Modules in Filter Navigator for working with Access Control?
- System Security
- Access Control (ACL) - Go here to see the entire list of Access Controls
- System Diagnostics
- Session Debug
- Debug Security - Use this to turn on Access Control debugging.
- System Security
- Debugging
- Stop Debugging - Use this to turn off Access Control debugging.
- System Properties
- Security - Use this to be sure your instances is setup as "Default Deny".
- System Definition
- Tables - Use this to configure Access Controls for an individual table.
- User Administration
- Users - Use this to (indirectly) assign a Role to a user so he can pass Access Control checks.
(Best practice is to assign Roles to Groups and place Users into those Groups).
In the Script Debugger, what options are useful for Access Control Debugging?
- Be sure that Security and Security Rules are turned ON, and to limit clutter, turn OFF all other options.
My Admin User does not have a required Role, and I unchecked "Admin overrides" checkbox, but I can still do everything; what am I missing?
- The "Admin overrides" checkbox is extremely misleading and problematic. Avoid using it. But if you insist on using it, first be aware of this article.
Where can I see screenshots of what happens when a user Fails the various Access Control conditions?
Here: Results of failing an Access Control (ACL) Rule - Screenshots
Where can I see screenshots of the Debugging entries that are generated when a user either Passes or Fails the various Access Control conditions?
Here: Debug Security - Screenshots
If this article was "Helpful" to you, please mark as such, and/or comment below.
