Role-Based Access Control

Role-Based Access Control (RBAC) in ServiceNow – Complete Guide for CAD Exam

Why Role-Based Access Control (RBAC) Matters

Role-Based Access Control is one of the most fundamental security concepts in ServiceNow and a critical topic on the Certified Application Developer (CAD) exam. Without RBAC, every user would have unrestricted access to all data and functionality within the platform, creating massive security vulnerabilities, compliance violations, and operational chaos. RBAC ensures that users only see and interact with the data and features they need to perform their jobs — this is known as the principle of least privilege.

Understanding RBAC is essential not only for passing the exam but also for building secure, production-ready applications on the ServiceNow platform.

What Is Role-Based Access Control?

Role-Based Access Control (RBAC) is a security model in which access permissions are assigned to roles, and those roles are then assigned to users or groups. Rather than granting permissions directly to individual users, you define a role that encapsulates a set of permissions and then associate users with that role.

In ServiceNow, RBAC governs access to:
- Tables (which tables a user can read, write, create, or delete records from)
- Fields (which fields within a record a user can view or edit)
- Application modules and menus (which navigation modules appear for a user)
- UI Pages, UI Actions, and other UI elements
- REST API endpoints and scripted resources
- Application scopes and custom applications

Key Components of RBAC in ServiceNow

1. Roles (sys_user_role)
A role is a named collection of permissions. Examples include:
- admin – Full access to the platform
- itil – Access for IT Service Management users (e.g., incident, problem, change management)
- catalog_admin – Access to manage the Service Catalog
- Custom roles – Roles you create for your own applications (e.g., x_myapp.manager)

Roles can contain other roles. This means if Role A contains Role B, then assigning Role A to a user automatically grants them Role B's permissions as well. This is known as role inheritance or role hierarchy.

2. Users (sys_user)
Individual user records. Roles are assigned directly to users via the sys_user_has_role table.

3. Groups (sys_user_group)
Groups are collections of users. Roles can be assigned to groups via the sys_group_has_role table. When a role is assigned to a group, all members of that group inherit that role. This is the most efficient and recommended way to manage role assignments at scale.

4. Access Control Rules (ACLs) – sys_security_acl
Access Control Rules (commonly called ACLs) are the enforcement mechanism for RBAC. They define who can perform what operation on which object. Each ACL specifies:
- Type/Object: The table, field, or resource being protected (e.g., incident table, incident.priority field)
- Operation: The type of access — read, write, create, or delete
- Permission: The requirements to gain access — typically a role, a condition (script or conditional expression), or both

An ACL rule can require:
- A specific role (e.g., requires itil role)
- A conditional expression (e.g., current.assignment_group is the user's group)
- A script (advanced logic evaluated at runtime)
- Any combination of the above

How RBAC Works in ServiceNow – The Evaluation Process

Step 1: ACL Evaluation Order
When a user attempts to access a resource, ServiceNow evaluates ACLs in a specific order. The platform checks from most specific to least specific:

1. Field-level ACL on the specific table (e.g., incident.priority)
2. Field-level ACL using wildcard on the table (e.g., incident.*)
3. Table-level ACL on the specific table (e.g., incident)
4. Table-level ACL using wildcard (e.g., *)

The system processes all matching ACLs. For a user to gain access, they must pass every matching ACL rule. This means ACLs are cumulative and restrictive — if both a table-level and a field-level ACL apply, the user must satisfy both.

Step 2: Within Each ACL – Permission Evaluation
Within a single ACL rule, the permission requirements (role, condition, script) are evaluated with an AND relationship if multiple types are specified. However, if multiple roles are listed within the same ACL, they are evaluated with an OR relationship — the user needs at least one of the listed roles.

Step 3: The Admin Role
The admin role bypasses most ACLs by default. Users with the admin role have unrestricted access unless an ACL explicitly excludes admin or uses a script/condition that overrides this behavior. This is an important exam concept.

Step 4: No ACL Defined
If no ACL exists for a given object and operation, the system behavior depends on the High Security Settings property:
- If glide.sm.default_mode is set to allow (default for some versions), access is granted when no ACL exists.
- If set to deny, access is denied when no ACL exists.
This is a commonly tested concept. The default out-of-box behavior typically allows access when no ACL is defined, but best practice is to define ACLs explicitly.

Important RBAC Concepts for the CAD Exam

1. Creating Custom Roles for Applications
When building a scoped application, you should create custom roles specific to your application. These roles are prefixed with the application's scope (e.g., x_myapp.user, x_myapp.admin). Never rely solely on out-of-box roles like admin or itil for your custom application's security.

2. Role Inheritance / Contains Roles
Roles can contain other roles. For example, if you create x_myapp.admin and set it to contain x_myapp.user, anyone with the admin role for your app automatically gets the user role permissions too. This reduces redundancy and simplifies management.

3. Before Query Business Rules vs. ACLs
Both can restrict data access, but they work differently:
- ACLs are the standard, declarative way to enforce RBAC. They are evaluated by the security engine.
- Before query business rules add encoded queries to filter records before they are returned. They are sometimes used to restrict row-level access but are not a replacement for ACLs.
The exam may test your understanding of when to use each mechanism.

4. Table and Field-Level Security
You can protect entire tables or individual fields. For sensitive fields (like SSN, salary, etc.), you should create field-level ACLs to restrict read/write access even if the user has access to the table itself.

5. Application Scope and Cross-Scope Access
In scoped applications, cross-scope access to tables, scripts, and resources is controlled by Application Cross-Scope Access policies. Roles defined in one scope do not automatically grant access to resources in another scope. This is a key security concept for application developers.

6. Impersonation for Testing
When testing RBAC, developers use the Impersonate User feature to log in as a different user and verify that roles and ACLs are working correctly. This is a recommended best practice and may appear on the exam.

7. Elevated Privileges and security_admin
Certain sensitive operations (like modifying ACLs) require the security_admin role to be elevated. Even if a user has the security_admin role, they must explicitly elevate their privileges through the system to make changes to ACLs. This is a security safeguard that the exam may reference.

Practical Example

Suppose you are building a custom Expense Report application (x_expense):

1. Create roles:
- x_expense.user – Can create and view their own expense reports
- x_expense.approver – Can view and approve expense reports assigned to them
- x_expense.admin – Full access to all expense reports; contains both x_expense.user and x_expense.approver

2. Create ACLs:
- Table: x_expense_report, Operation: create, Role: x_expense.user
- Table: x_expense_report, Operation: read, Role: x_expense.user, Condition: opened_by is the current user
- Table: x_expense_report, Operation: read, Role: x_expense.approver, Condition: approver is the current user
- Table: x_expense_report, Operation: write, Role: x_expense.approver, Condition: approver is the current user
- Table: x_expense_report, Operation: delete, Role: x_expense.admin

3. Assign roles to groups (e.g., Finance Approvers group gets x_expense.approver).

Common Mistakes to Avoid

- Granting the admin role to application users instead of creating custom roles
- Forgetting that ACLs are cumulative — if multiple ACLs match, the user must pass ALL of them
- Confusing the OR logic for multiple roles within a single ACL with the AND logic across multiple ACLs
- Not testing security by impersonating users with different roles
- Assuming that if no ACL exists, access is denied (the default may actually allow access)

Exam Tips: Answering Questions on Role-Based Access Control

Tip 1: Know the ACL evaluation order. The exam frequently tests whether you understand that ACLs are evaluated from most specific (field-level) to least specific (wildcard table-level), and that ALL matching ACLs must be satisfied. If a question describes a scenario where a user has table-level access but not field-level access, the answer is that the user will be denied access to that field.

Tip 2: Understand the difference between roles within an ACL vs. across ACLs. Multiple roles listed within a single ACL are OR conditions (user needs any one). Multiple separate ACLs that match are AND conditions (user must pass all). This distinction is a common trap in exam questions.

Tip 3: Remember that the admin role passes most ACLs. If an exam question asks about a user with the admin role, the answer is almost always that they will have access — unless the question specifically mentions a script or condition that overrides admin access.

Tip 4: Custom applications should use custom roles. If a question asks about best practices for securing a scoped application, the correct answer involves creating application-specific roles, not reusing platform roles.

Tip 5: Know the security_admin elevated privilege concept. Questions about modifying ACLs or other security artifacts will reference the need to elevate the security_admin role. Simply having the role is not enough; it must be actively elevated.

Tip 6: Use process of elimination on scenario-based questions. Many RBAC questions present a scenario and ask what a user can or cannot do. Mentally walk through the ACL evaluation process: identify which ACLs apply, check if the user's role satisfies each one, and determine the final result.

Tip 7: Remember the default behavior when no ACL exists. If the exam mentions that no ACL is defined for a particular table or operation, recall that the default system behavior (unless changed) may allow access. This is counterintuitive and is a commonly tested point.

Tip 8: Distinguish between row-level and record-level security mechanisms. ACLs with conditions can restrict access to specific records (row-level). Before query business rules can also filter records. The exam may ask you to identify the correct mechanism for a given requirement — ACLs are the preferred and standard approach.

Tip 9: Role inheritance simplifies management. If a question describes a scenario where one role should automatically include the permissions of another, the answer involves using the Contains Roles related list to establish role hierarchy, not duplicating ACL rules.

Tip 10: Read questions carefully for scope. The exam may include questions about cross-scope access policies. Remember that roles and ACLs in one application scope do not automatically extend to another scope. Cross-scope access must be explicitly configured.

Summary

Role-Based Access Control is the cornerstone of ServiceNow security. For the CAD exam, focus on understanding how roles are created and assigned, how ACLs are structured and evaluated, the order of ACL evaluation, the behavior of the admin role, and best practices for securing custom applications. Practice walking through ACL evaluation scenarios mentally, and always consider the cumulative nature of ACL rules when determining a user's effective access.