Deny-Unless ACL - Product Documentation: Xanadu

Deny-Unless ACL

Configuring an ACL rule Configuring an ACL rule

Configure a custom ACL rule to secure access to new objects or to change the default security behavior.

Role required: security_admin

To create ACL rules, you must elevate privileges to the security_admin role.

For tables that are in a different scope from the ACL rule record, the types of rules are limited. For Scope Master tables to derive scope and execute scoped ACLS, set the glide.enforce_security_scope. property to true . This ensures ACLs in the global scope do not match when there are scope specific ACLs created on the relevant table. Examples are when securing data within shared application tables in the Global scope, such as sys_attachment or sys_question_answer tables.

Elevated privilege roles to the security_admin role. Navigate to System Security > Access Control (ACL) . Tip: When creating a new ACL it is helpful to review the Deny-Unless ACL .

Click New . Complete the form. Table 1. Access control fields Field Description Type Select what kind of object this ACL rule secures. The type of object determines how the object is named and what operations are available. This field becomes read only after the ACL rule is created. If you want to change the type, you must delete the ACL and create a new one with the correct type. Operation Select the operation this ACL rule secures. Each object type has its own list of operations. An ACL rule can only secure one operation. To secure multiple operations, create a separate ACL rule for each. Admin overrides Select this check box to have users with the admin role automatically pass the permissions check for this ACL rule. Admin users pass regardless of what script or role restrictions apply. However, the nobody role, which only ServiceNow personnel can assign, takes precedence over the admin override option. If an ACL is assigned the nobody role, admin users cannot access the resource even when Admin overrides is selected. See Base system roles .

Clear this check box if administrators must meet the permissions defined in this ACL rule to gain access to the secured object. Since administrators always pass role checks (see the description of the Requires role field), use the condition builder or Script field to create a permissions check that administrators must pass.

Active Select this check box to enforce this ACL rule. Advanced Select this check box to display the Script field. Important: If there is script in the Script field. This script executes even if the field is not displayed on the form. Name Enter the name of the object being secured, either the record name or the table and field names. The more specific the name, the more specific the ACL rule. You can use the wildcard character asterisk (*) in place of a record, table, or field name to select all objects that match a record type, all tables, or all fields. You cannot combine a wildcard character and a text search. For example, inc* is not a valid ACL rule name, but incident.* and *.number are valid ACL rule names. Note: Click the blue triangle to manually enter the record name or the table and field names of the object being secured. Use this option to secure an object that does not appear in the dropdown. Description Enter a description of the object or permissions this ACL rule secures. Requires role Use this list to specify the roles a user must have to access the object. If you list multiple roles, a user with any one of the listed roles can access the object. The Requires role list appears as a related list. Note: Users with the admin role always pass this permissions check because the admin role automatically grants users all other roles. Condition Use this condition builder to select the fields and values that must be true for users to access the object. Script Enter a custom script describing the permissions required to access the object. The script can use the values of the current and previous Global variables in business rules as well as system properties. The script must generate a true or false response in one of two ways: return an answer variable set to a value of true or false evaluate to true or false

In either case, users only gain access to the object when the script evaluates to true and the user meets any conditions the ACL rule has. Both the conditions and the script must evaluate to true for a user to access the object.

Note: If the evaluated item is in a related list, current points to the item the related list is on, not to the current item the ACL is for. However, If the item you are evaluating the ACL for is not in a related list, current points to the actual item.

Right-click the form header and select Save .

Secure records in an embedded list

To apply security to the records in embedded lists, limit editing and deleting records in embedded lists to specific roles.

Role required: security_admin

Navigate to All > System Security > Access Control (ACL) . Open the Write or Delete record for the appropriate table. In the Requires Role section of the form, add the roles that have write or delete permission for that table. Save the changes. When records from the associated table appear in an embedded list, the edit and delete options are available only to users with the specified roles.

Deny-Unless ACL

Learn details about Deny-Unless ACLs.

Deny-Unless ACLs are evaluated with a "deny-unless" approach. The ACL defines the users that will NOT be denied. Said another way, the user will be denied access unless the role, condition, and script requirements are met.

Important: Deny-Unless ACLs will take priority against Allow-If ACLs in ACL Evaluation as it will be evaluated first.

A Deny-Unless ACL produces 2 outcomes Evaluation outcome Result Pass The defined roles, data conditions, security attributes, and script requirements are met. The ACL proceeds to further evaluation Important: Allow-If ACLs must still grant access for the subject to be able to access the resource. Fail The Deny-Unless ACL is marked as failing and access will be denied.

The following is an explained example of a Deny-Unless ACL: ACL has roles sn_hr_core.manager and itil Condition has active = true script has answer = gs.isLoggedIn(); The user is denied access unless all 3 requirements for this ACL are satisfied. In order for this Deny-Unless ACL to pass, a users needs either the sn_hr_core.manager or itil roles, be accessing a record that has active field = true , and be logged in. The Deny-Unless ACL will fail if any of the three requirements isn't met.