We care deeply about keeping our data secure. Ensuring that you can only see what you are supposed to see, keeps us and your organization happy. The general perception about security and data is that the more secure you make your data, the slower your system will be. It's like having to choose to have your cake or eat it, when all you want to do is have it AND eat it.
There are three general ways of limiting access to data:
(In order of their potential database performance impact from lowest to highest)
- Limiting the applications and modules a user sees in their navigator
- Limiting access through ACLs (Access Control Lists)
- Limiting access through appending WHERE clauses to queries
- Two technologies use that method:
- Domain Separation (typically not a large impact, since the domain separator field is usually indexed)
- Before query business rules
- Two technologies use that method:
Continue reading to see when you will use which one of these methods, and what their impact on your system's performance can be.
Limit viewable applications and modules in the Navigator
Application and module access is limited through assigning specific roles to these items that are not generally available, for example, the System Definition application modules are typically only available for administrators. For more information on administering applications and modules in Geneva, check out Enable or disable
an application menu or module and for the same on Fuji or older, see Administering Application Menus and Modules. This is the fastest and easiest way to limit access, but it is also the least secure. Were it not for additional security methods such as ACLs, users who know the table names of the underlying tables could still access the data behind the modules hidden from their navigator.
Limiting the applications and modules in the navigator should be seen as a usability tool (a self-service user would be overwhelmed if they would see an administrator's option) rather than a security tool, but it also provides our first level of security by making access to unauthorized items harder to attain.
Limit access through ACLs
ACL stands for Access Control List. ACLs define access for records, UI pages, client callable scripts, and processors within ServiceNow. Against each one of these items, certain operations are available, such as create, read, write, delete on record level, or execute on a client callable script. ACLs define who can, under which circumstances, perform these operations against these items.
ACLs work after the records were retrieved from the database, so they usually do not add additional load on the database performance. There are three ways ACLs can limit access to operations:
- Conditions
- Roles
- Scripts
Conditions vs. Roles vs. Scripts
Conditional and role ACLs have minimal impact on system performance. Scripted ACLs can get rather complex including programming involving loops and database queries. We sometimes find those scripts to be responsible for performance issues, and recommend to keep ACL scripts as simple as possible. Since ACLs are checked on every record, if an inefficient script is used, the performance impact is significant.
Loops and queries causing performance issues
If using for or while loop constructs in your code, ensure that the loop will stop at the earliest possible point. If using database queries, ensure that these queries are well indexed. See What index should it be? - OR - Slow Queries explained for detail on how to determine a good index for any slow query.
Limit access through WHERE clauses
One side effect of using ACLs to limit access to data is the dreaded "Security constraints prevent access to requested page" or "Number of rows removed from this list by Security constraints:...". Especially the latter message leads to confusion and calls to the help desk. One way of preventing this message is to append a WHERE clause to your query, so that these records the user is not supposed to see are not even returned from the database.
We typically do this through "before query" business rules. Our WIKI has an example for such a before query business rule: Scripting in Business Rules - ServiceNow Wiki This example though has one issue to be aware of:
var u = gs.getUserID(); var qc = current.addQuery("caller_id", u).addOrCondition("opened_by", u).addOrCondition("watch_list", "CONTAINS", u); |
The "CONTAINS" operator will translate to a LIKE "%xxx%" query on the database, which cannot be indexed.
When creating a before query business rule, it is very important to ensure that the resulting query can and will be indexed. Before query business rules are executed every time you search on this table. An inefficient query at this point will be responsible for higher load on your database as well as negatively impacted performance.
Before query business rules are not allowed on the sys_app_module and sys_app_application tables in UI16. This is due to steps to make the navigator more efficient. Menus and applications in UI16 can only be limited through roles, not before query business rules.
As you can tell, each option has its use within ServiceNow to secure your data and to improve the user's experience. Each method is designed to allow for minimal performance impact, but any scripting that does not follow best practices can cause significant performance impact. You can read up on coding best practices here: Coding Best Practices.
