Please use docs.servicenow.com for the latest documentation.

This site is for reference purposes only and may not be accurate for the latest ServiceNow version

Contextual Security

From Wiki Archive
Jump to: navigation, search
Note
Note: This article applies to Fuji. For more current information, see Contextual Security Manager at http://docs.servicenow.com

The ServiceNow Wiki is no longer being updated. Please refer to http://docs.servicenow.com for the latest product documentation.

Overview

The contextual security manager provides incredible flexibility and power to protect information by controlling read/write/create/delete authorization. Key advantages include:

  • Contextual Security -- Secure a record based on its contents
  • Hierarchical Security -- Can apply security rules to any level in our object hierarchy

Differences between Contextual Security and Simple Security

Everything you can do with the simple security manager you can also do with the contextual security manager. Likewise, after conversion to the contextual security manager, you should not see any behavior changes in your instance. However, on a go forward basis, the process of security a small number of resources has changed.

Things that have changed

Securing Fields and Tables

Under the simple security manager, you could secure fields and tables by adding roles to the appropriate dictionary entry. After installing the contextual security manager, these dictionary roles are no longer tested. Instead the system looks for ACL rules on fields and or tables.

Note
Note: After you install the Contextual Security Manager you must secure fields and tables via ACL rules. Even if you configure the dictionary form and add roles to a dictionary entry, no change in rights will occur.


Granting Roles to Users

Roles can still be granted to users or groups using the same logic as under the simple security manager. The one noteworthy exception is that the "roles" field on the user record is no longer checked under the contextual security manager (and should be, in fact, removed from your user and group forms upon installation).

Note
Note: To add roles to a user or group record under Contextual Security you must add them to the Roles related list instead of to the user or group record itself.


Things that have not changed

Applications and Modules

Applications and modules both contain lists of roles under which they can be viewed. For example, the System Definition application requires the admin role to be viewed.

Security rights for Applications and Modules are still defined via these role arrays although they may be transitioned to ACLs at some future date.

Catalog Items and Variables

Both catalog items, and catalog variables contain lists of roles under which they can be viewed.

Security rights for these entities are still defined via these role arrays although they may be transitioned to ACLs at some future date.

Inheritability of Group Roles

Under the contextual security manager, a group still automatically inherits any role granted to the group.

Note
Note: The role's inherits flag is set to true.


Rule Search Order

The system is aware of our object hierarchy when it tries to identify a security rule to apply to a particular entity. The search order for a field level rule is:

  1. explicit rule on self
  2. explicit rule on field in parent
  3. ... until parent doesn't contain field
  4. wildcard rule on self
  5. wildcard rule on field in parent
  6. ... until parent doesn't contain field

Example: Given incident.number

Search is:

  1. incident.number
  2. task.number
  3. *.number
  4. incident.*
  5. task.*
  6. *.*

Precedence between Row and Field Level Rules

What happens if a row level rule and a field level rule are in conflict? Perhaps my row level field indicates that I shouldn't be able to write to a particular row, but the field level rule indicates I do have write access?

In a nutshell, both rules must be met before an operation is allowed.

So, given a row level rule on incident, and a field level rule on incident.number, access to the number field would be allowed only if both rules evaluated to true.

Multiple Rules at the Same Level

What if the system, for example, finds two rules for incident.number?

The system will evaluate both rules and if either is true, then the requested access is allowed.