If you\u2019ve taken Salesforce Admin 201 training, you might remember learning about Sharing Settings. Sharing Settings include Sharing Models, Criteria Sharing Rules, Manual Sharing, and more. I\u2019m a software engineer on the Record Access Experience team here at Salesforce. When I took this training in 2017, it was the first time Sharing Settings truly clicked for me, even though I\u2019d been hired onto the team a month earlier. In this post, I\u2019m going to talk about Sharing, then describe a new feature called Restriction Rules and how it\u2019s implemented differently from other Sharing Settings.<\/p>\n
How Sharing Settings give you access to a record is described in this\u00a0image.<\/p>\n
How Sharing Settings give you access to\u00a0records<\/p>\n
If a user gets access to a record because your Org\u2019s Org-Wide-Default gives them access, Salesforce doesn\u2019t check anything else. If not, we check to find out if your Role, Owner or Criteria Sharing Rules, or Manual Shares give you access. If none of these settings grant access, we return a \u201cYou don\u2019t have access\u201d\u00a0message.<\/p>\n
Sharing works by materializing Share Rows in a table. For instance, if Maria owns an account, then we insert a row in an Account Sharing Table. The new row indicates that Maria can access the account because she\u2019s the\u00a0owner.<\/p>\n
The Accounts and Account Sharing tables with an Owner\u00a0Share<\/p>\n
If a Sharing Rule grants access to another user, Frank, we insert a row in the Account Sharing Table. The new row indicates that Frank has access because it was granted manually. If a Sharing Rule grants access to a group called \u201cStrategy,\u201d then the row in the Account Sharing Table points to the\u00a0group.<\/p>\n
The Accounts and Account Sharing tables with Owner, Manual, and Rule\u00a0Shares<\/p>\n
Now, if another user pulls this account up, we look at the Account Sharing Table to determine if they have direct access to it. In other words, we check if they are Maria or Frank, who have access because they are the owner or gained access via Sharing Rule. Salesforce also performs a lookup in multiple Group Maintenance Tables to determine if the user is part of the Strategy\u00a0group.<\/p>\n
Group Maintenance Tables help determine if the user is part of a\u00a0group.<\/p>\n
We have indexes and highly optimized queries on these tables, which typically gives us our lightning-fast performance at the point of accessing data. As you can see, we get a speedy response because we make a trade on the space side of the space-time trade-off. We write a whole bunch of rows in our tables to describe who sees what. While it may be fast at enforcement time, when rules are created, updated, or deleted, we end up having to rewrite a whole host of records. That process can be time-consuming. In most cases, writing these rows happens quickly. But there are times when this process increases wait times, and customers are prevented from updating object\u00a0access.<\/p>\n
The Restriction Rules feature is the newest addition to record-level access control mechanisms at Salesforce. For a while now, Sharing Settings have needed enhancement. There are objects that should have their own sharing model, but don\u2019t. There are objects that have their own distinct access control mechanisms. And there are objects that observe Sharing Settings, but could use improvement. Restriction Rules aim to plug these gaps and position Salesforce to make future forays into uncharted territory, such as data that resides outside of Salesforce, or data that is not stored in a relational DB. If you have other ideas, let us know in the comments.<\/p>\n
A Restriction Rule might look something like\u00a0this.<\/p>\n
The Restriction Rule\u00a0UI<\/p>\n
This is a sample Restriction Rule created on a task object. Check out the User Criteria and Record Criteria sections. This rule states that users in the US can only access tasks that they created. So even if the users get access to tasks that they didn\u2019t create through an existing access control mechanism, Restriction Rules act as a filter that is applied on top of that mechanism. The Restriction Rules thus deny access to those\u00a0tasks.<\/p>\n
Now, if we updated our Sharing triangle, it would look like\u00a0this.<\/p>\n
Sharing Triangle with Restriction Rules<\/p>\n
Restriction Rules invert the space-time tradeoff. Rather than store access in the Sharing Tables, we thought, why not generate an Access Control Policy that could be read at runtime to define access? This massively reduces the time it takes to create, update, or delete rules because we no longer have to materialize all these records. Furthermore, at the point of enforcement, we can reduce the number of times we make a database round trip to look at all the Sharing and Group Maintenance Tables.<\/p>\n
Enter XACML (and a few acronyms). Wikipedia says it\u2019s a declarative Attribute-Based Access Control (ABAC) policy language. It\u2019s a published standard specification that aims to function as an access control system. This system uses attributes associated with a user, action, or resource as inputs into the decision of whether a given user may access a given resource in a particular way. Perfect! Let\u2019s have our users create and upload these policies. Well, not so fast. XACML policies are powerful, but they can be verbose and can get complicated quickly as seen in this example from the same Wikipedia article.<\/p>\n
A Rule Expressed in\u00a0XACML<\/p>\n
Rather than make our users learn a new language altogether, we decided to make it simple to author rules either through the UI (as seen above) or the Metadata\u00a0API.<\/p>\n
In this image, if an admin user creates a Restriction Rule, we generate a XACML policy and store that in a XACML data store. Then, when a user accesses a record, before we go retrieve the data, we make a request to a Policy Decision Engine. This makes a decision based on what the policy says. That decision informs whether or not the user has\u00a0access.<\/p>\n
Architecture for Restriction Rules Creation and Enforcement<\/p>\n
In fact, it\u2019s not that easy. There\u2019s more happening here than meets the\u00a0eye.<\/p>\n
To make the request to the Policy Decision Engine, we need to know which pieces of data we need to supply to it. For instance, if a Restriction Rule on a Task was created as in our example, then the Decision Engine needs to know the current user\u2019s country in order to compare it with the country named in the rule. Similarly, it needs to know the record\u2019s creator. We solve this by scanning the policy once it\u2019s created, then caching a catalog of attributes that the policy references. Then, when a user makes a request for one or more records, we look at the catalog, and supply that information to the Decision Engine along with the\u00a0request.If a user is making a query for multiple records, we cannot afford to iterate through all of them and ask the Decision Engine for a decision on each record. In such situations, we make just one call to the Decision Engine, which will then return a filter. Whilst querying for the data, we add that filter to the query, thereby eliminating records the user does not have access\u00a0to.<\/p>\n
Every time we write a new line of code, we incur a cost. When it comes to performance, the best feature is one that is never written. Of course, we wrote the feature, but worked to aggressively reduce overhead. A feature such as Restriction Rules, which could potentially be run every time a user pulls up a piece of data, must be as performant as possible. Our early iterations, much to our performance engineering team\u2019s chagrin, were quite chatty with the database. This led to increased CPU and DB usage and response\u00a0times.<\/p>\n
We formulated a two-pronged approach to tackle our performance issues.<\/p>\n
Eliminate or tune SQL queries: Some queries could be eliminated. We could infer those results from data we already had cached in memory. We rewrote some others to be more performant.Caching: We aggressively cached data that would get frequently retrieved. Initially we cached things like the catalog of attributes and the contents of the XACML policy, thereby reducing the database round trips to retrieve the policy. On further examination, it became obvious that we\u2019d get significant benefits by remembering the decision itself, as long as nothing else had changed. So we wrote a mechanism to reuse the decision.<\/p>\n
After these performance improvements, preliminary testing revealed that, on average, the overhead of adding Restriction Rules in terms of response times decreased by almost\u00a080%.<\/p>\n
Factoring in the above changes makes our architecture look like\u00a0this.<\/p>\n
Updated architecture diagram for Restriction Rules creation and enforcement<\/p>\n
Restriction Rules are a powerful new feature that enhance our existing access control mechanisms. Furthermore, the underlying architecture that went into creating this feature also gives our engineering team a platform to create newer and more flexible access control mechanisms in the future. We invite you to try this feature out for yourself. Then, leave us some feedback!<\/p>\n
Learn MOAR in Winter \u201922 with Restriction Rules\u00a0\ud83d\udeab<\/a>Control Access to Sensitive Records with Restriction Rules<\/a><\/p>\n Thank you for reading! This project would not have been possible without the tireless efforts of the following people: Yanik Grignon, Matthew Wong, Larry Tung, Devshree Gehlot, Bhumi Damania, Priyank Bhawsar, Subhash Uppalapati, Benjamin Gee, Shyam Naren Kandala, Sunghyun Song, Virag Shah, Irina Sendyk, Arjun Sirohi, Lakshman Martha, Dan Sheehan, Dana Holloway, Alex Kaufman, Chuxi Wang, and many\u00a0others.<\/p>\n Restriction Rules<\/a> was originally published in Salesforce Engineering<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n Read More<\/a><\/p>","protected":false},"excerpt":{"rendered":"Acknowledgements<\/h3>\n