Servicenow readonly role operating principle

About Servicenow readonly role

The Servicenow readonly role (snc_read_only) is one of base role (OOB). Thus, users with this role cannot create, update and delete records in the database. Of course its the exact meaning of readonly. But the beauty here is, this role enforces readonly across the platform.

What other privileges comes with Servicenow readonly role?

Frankly none, this role intent to prevent users from create, update and delete records in the database. So the effective read access of a user based on privileges granted by other roles & read ACL.

How Servicenow enforces readonly across platform?

This could be Interesting part. Servicenow do uses “iAccessHandler” functionality to achieve readonly enforcement. Which is an internal system check using hidden source code on the platform. Because of an internal check, its capable of grant or deny access to a resource without evaluating ACLs. In otherwords ACL’s evaluation starts only if IAccessHandler result to either Ignored or allow.

IAccessHandler – Key points

  • Internal system security check that cannot modified and bypassed by users
  • It is a hidden source code on the platform
  • This functionality does exist since the Istanbul release

Proof of concept

Lets explore the behaviour of servicenow readonly role accordance with IAccessHandler. Assume for audit purpose, need to grant a user external_auditor a readonly access to full Incident management application. To achieve the same assign below roles to the user.

  • incident_mgr
  • snc_read_only

Debug security rules

  • As a privileged user like admin, enable security rules debug by navigate through System Diagnostics -> Debug Security
  • Then Impersonate to readonly role applied user, here “external_auditor”
  • Open any of existing Incident or else try to create new one
  • All the fields including comments & work notes should be visible as readonly
  • Review debug logs to ensure IAccessHandler is in effect on top of ACL for update, write and delete actions.

For demo, captured the snap of debug log from my instance here.

User read operation allowed

access granted23:24:45.992 TIME = 0:00:00.000 PATH = record/incident.number/read CONTEXT = null RC = true RULE =
not evaluated	access denied	not evaluated	not evaluated	record/incident/read	  App: Global
not evaluated	access granted	access granted	access granted	record/incident/read	  App: Global

Following picture represents pictorial view of debug log for a successful read operation request. Firstly IAccessHandler has not evaluevated and its represented as grey circle icon. Secondly read ACL conditions evaluated to true and they represented in green circle icons.

IAccessHandler not evaluated and read access granted as per ACL
IAccessHandler not evaluated and read access granted as per ACL

Create/Write/Delete operations denied

access denied 23:24:49.766 Global TIME = 0:00:00.000 PATH = record/incident/create CONTEXT = INC0010112 RC = false RULE =
access denied	record/incident/create
access denied23:24:50.75 Global TIME = 0:00:00.000 PATH = record/incident/write CONTEXT = incident.sys_id=null RC = false RULE =
access denied	record/incident/write
access denied23:24:50.80 Global TIME = 0:00:00.000 PATH = record/incident/delete CONTEXT = incident.sys_id=null RC = false RULE =
access denied	record/incident/delete

Similarly below snapshots are the pictorial view of debug logs for create, write and delete operations. The IAccessHandler eveluated in first place which results false. Hence evaluation of ACL rules not happened. As a result create, update and delete operations are denied.

IAccessHandler blocked create operation
IAccessHandler blocked create operation
IAccessHandler blocked write operation
IAccessHandler blocked write operation
IAccessHandler blocked delete operation
IAccessHandler blocked delete operation

Tips to deal with ACL

Best approach to troubleshoot ACL related problems are,

  • Turn on security debug logs and review
  • If IAccessHandler errors are noticed, as a first step ensure to validate does user has Servicenow readonly role assigned

Obviously there will be numerous other scenarios where IAccessHandler takes effect. But the above one is good known reason to start with. There is another similar such scenario documented by Servicenow here – Unable to add users to a group. Group form is read-only

Add exceptions to Servicenow readonly role

As exception if any of table needs to be out of readonly role enforcement should be done through system property. For details refer to the Servicenow document – ReadOnlyRoleProperties

Hope it helps you. I would appreciate your feedback under comments section, either if you got benefit out of it or thrilled of known new things.