How to lock down a ServiceNow app *very* securely (Part 3 of 3)

[Grant Hulbert]

Part 1

Part 2

Part 3 (you are here)

Congratulations on making it this far!

You are now in the top percentile of developers who know how to activate deep security on the platform! In part 2 of this series, you learned how to add row-level security, enabling different groups to access their own data privately. In this final tutorial, we’ll solve a subtle-yet-important limitation of the app we’ve built so far.

I’m sure you’re wondering “what’s the limitation?” I’m glad you asked. If you look very closely at the business rule script in step 6.5 of the instructions in part 2, you may notice a problem. To recap, that script automatically sets the ownership of records to match the logged-in user’s security group. This would normally be fine if the user only belongs to one secure group, but what happens if some of your users belong to several secure groups? In that case, the script just randomly finds the group with secure_data_user role, and assigns that to the record.

What’s the solution? We’re going to create a new table that keeps track of each user’s ‘group affinity’, which is a fancy way of saying we will let admins decide which specific group a user’s records should belong to whenever they create new rows. In other words, “As a user of this app, I will be able to read records from lots of different groups, but I only want my own records to belong to the main group where I interact with my close coworkers”. This gives users the freedom to straddle multiple groups securely, so they can create dashboards and reports that cross silos in your company, and that’s what ServiceNow is all about, right?!

After we create the ‘group affinity’ table, we’ll modify that business rule to look up the correct security group whenever new records are created.

Let’s jump in and start coding!

Prerequisite: make sure you have already followed all the steps in part 1 and part 2, because we’ll be adding new features to the app we built. You must be logged in as the same administrator that owns the application you built in part 1.

1. Launch Studio, and select your app.
2. First, we’ll build the new affinity lookup table:
   1. Create a new table named “Group Affinity”.
   2. Add a column labeled “User”: make it of type “reference” and configure it to reference table sys_user.
   3. Add a column labeled “Primary Group”: make it of type “reference” and configure it to reference table sys_user_group.
   4. Click [Submit] to create the table.
   5. Add 3 rows to the table:
      1. User: Abel Tuter, Primary Group: Secure Group 1
      2. User: Beth Anglin, Primary Group: Secure Group 2
      3. User: <<the user you are logged in as now>>, Primary Group: Secure Group 1
   6. Now that we’ve got a lookup table, we’ll modify our business rule to use it:
      1. From Studio, open the business rule you created in part 2. Server Development > Business Rules > “Mark records as owned by logged-in user”.
      2. Click the [Advanced] tab.
      3. Replace the entire script with the following:

         1. (function executeRule(current, previous /*null when async*/) {

            // Set the group ownership of this record to the currently logged-in user's primary secure group
            var gr = new GlideRecord('x_NNNN_secure_data_group_affinity');
            gr.addQuery('user', gs.getUserID());
            gr.query();
            if (gr.next()) {
            current.group_owning_this_record = gr.primary_group;
            }

            })(current, previous);

         2. You will have to modify the script slightly. On line 4, change x_NNNN_secure_data_group_affinity to be the exact name of the table you created in step 2.
   7. Try it out!
      1. In preparation for editing table roles, elevate your role to security_admin.
      2. Navigate to the sys_user_group table, find “Secure Group 2”, and add Abel Tuter to the Group Members tab.
      3. Impersonate Abel Tuter, open the left nav “Secure Data” app, and notice Abel can now see records both in Secure Group 1 and Secure Group 2. Why is that? Because Abel is now a member of both groups, so he can see records owned by either one. The ACL for that table allows “is (dynamic) One of My Groups”.
      4. While still impersonating Abel, add a record to the Secure Data table, and notice “Group Owning this Record” is automatically set to Abel’s group “Secure Group 1”. How is this different from part 1? Now we’re looking up Abel’s group affinity in the “Group Affinity” table, so we can always be sure we set the correct group for Abel’s records. He belongs to two groups now, so the affinity feature helps us know which group we should assign.

Conclusions:

1. You have now made it possible for people with high-level access, such as executives or report administrators, to see data across your entire organization, while still maintaining secure restricted access. Administrators and managers can decide how much or how little information is shared.
2. Members of teams don’t have to think about what their primary group is: groups are assigned automatically as they create new records.
3. Group ownership of records is easy to define, and is never accidentally set to the wrong group.

Wrapping up this entire blog series

Whew, that was a lot. If you’ve made it this far, congratulations! You have built a very flexible and highly-secure ServiceNow app that is locked down so tightly that not even system administrators can see its data. Your CEO will be very pleased that she can keep secret information in the platform without worrying about accidental security leaks.

Part 1

Part 2

Part 3 (you are here)

[Simen]

Thanks mate.

This was realy nice, clean and useful.