Prevent Global Search on a new table

Gerald Harris · ‎10-22-2013

I created a custom application for our information security group and there are two issues that I could use help with.

#1 If a non-permissioned user gains access to a URL they can open a page. That page will immediately redirect them but the page is open for a split-second before the redirect. Does anyone know of a way to keep the page from even populating in the first place.

#2 Is related to #1. If a user (ITIL) has a ticket number they can perform a global search and the page will open and then redirect. So, I need to prevent the search from even happening.

My business rules, which are before query and just check for the user role and redirect if there is a problem, are not doing the job.

Do you have any strategy to help me lock down the tables in this application so that users won't be able to access the secure data via a hyperlink or global search?

And if it should be a business rule can you provide an example?

Valor1 · ‎10-22-2013

You'll still need to use an ACL for that behavior--I've never had an ACL allow access, regardless of the manner in which access was requested.

Given your complex requirements, you'll probably have to script the ACL rule, and it sounds like you're familiar with the concepts involved. We NEVER recommend writing an on/query business rule--they can impact performance, and ACLs are still better.

In similar situations (Group A shouldn't see Group B's tickets and vice versa), we combine all ROW/read ACLs into a single one.
NOTE: make sure you combine your "cheap" access checks (those in the current object or a part of the session, or likely cached) first. Roles and session variables (like "gs.getUserID()") are cached:



answer = shouldReadTicket();
function shouldReadTicket(){
   var u = gs.getUserID();
   if (gs.hasRole('itil_admin') || current.caller_id == u || current.opened_by == u){
      return true;
   }
   if (gs.getUser().isMemberOf(current.assignment_group + '')){
      return true;
   }
   return false;
}

View solution in original post

Valor1 · ‎10-22-2013

You need a *ROW* level access control.

Type: record
Operation: read
Name: Table Name [table_name] | -- None --

NOTE: on the Name field, make sure it does not say


table_name.*

, but rather just


table_name

Then save. When you (re)open it, there's now a Related List called "Requires role". Add the appropriate role that should be ALLOWED.

Aaron40 · ‎10-22-2013

Hi,

For #1 you could be using ACLs. An ACL will take place before the screen loads so you won't ever get that split second delay of something displaying when a user doesn't have access to it. Have read rights set appropriately.

For #2 you need to modify your global search properties. Enter some test string in your Global Search box and search it. On the results page click EDIT SEARCH GROUPS. Click TASKS. Under TASKS you'll find INCIDENT. You'll see that INCIDENT has no additional conditions assigned to it. The TASKS link you clicked first required admin or ITIL (by default) so anyone with an ITIL or Admin role will be able to search this table). Anyone who has these two roles can search ANYTHING on the incident table.

More information can be found on http://wiki.servicenow.com/index.php?title=Administering_Global_Text_Search.

Gerald Harris · ‎10-22-2013

I was working with an ACL but couldn't get it to cover what I wanted.

Basically, there are multiple groups, each with their own role, who do have access to the table but shouldn't have access to the information owned by other groups who have access to the table. There is a hidden value on each form that uses some scripting to set a value relative to the appropriate role owned by the user. The ACL have a condition equal to one of the roles and lists a required role that is equal to the condition.

So, when a user with role "A" creates a record it is marked in a hidden field with the role associated with the user that is also valid to the application.

Then, the ACL rules (one rule for each allowed role) check the hidden field. IF the hidden field designates role "A" then we can look at the Required roles field.

If the User has role "A" then we are all good and they are allowed to read the file.

Not real smooth and more work than I want to do but there are a very small number of groups who will have access to the application.

I haven't had a chance to fully test out the changes but they "seem" to be working.

Gerald Harris · ‎10-22-2013

The ACLs seem to be working for the search functionality but not for the hyperlink problem.

Blocking access from a link is currently happening using a client script that checks for specific roles and then redirects if the user does not have one of the required roles.

Still working on this . . . thank you everyone for your help so far. Any suggestions are appreciated.