How to Build a User Security Model

Published in

Salesforce Architects

8 min readSep 23, 2020

At Salesforce, trust is our number one value, and security is non-negotiable. The platform comes with a comprehensive set of features that you can use to build a robust user security model. When designed the wrong way, however, this security model can have gaps that could be exploited by an attacker to access your data. It is the Salesforce Architect’s responsibility to ensure that these features are configured correctly.

This post provides a step-by-step approach to defining a user security model that is at the same time scalable and maintainable, while respecting the principle of least privilege, by granting users the lowest level of access rights that they need to do their job.

Before diving in, you may want to review this Trailhead module for a refresher on Salesforce data access controls. Refer to the Salesforce Security Guide for a deep dive on security features.

Five steps for building a user security model

The five main steps in building a security model are defining personas, defining base profiles, extending access with permission sets, defining the sharing model, and accounting for specific access types.

Step 1: Define the personas

A persona represents a group of users that require similar access rights to the platform. The first step in defining a security model is to put together a comprehensive list of these personas. This will help define the scope of the security model and help ensure that it has no gaps.

The first type of persona is human users. These users usually access the platform through the user interface and log in using authentication mechanisms like identifier/password or single sign-on (SSO). Of course, a human here can be either an internal or an external user. Internal users include business users, who access the platform as part of their daily job activities, and administrative users, who are responsible for maintaining the organization. External users access the platform from Salesforce communities and sites. One group that is often forgotten is unauthenticated guest users. There is one guest user per site or community, and the security model should cover all of them.

The second type of persona is non-human. These include user accounts that are used for technical processes such as integration, registration, or record ownership. Such accounts may or may not need to log in to the platform (e.g., a user whose sole purpose is to own records will never need to authenticate). When non-human user accounts do log in, it is often via API, based on secured mechanisms like OAuth 2.0 JWT bearer flow.

As a Salesforce architect, you need to make sure all personas are covered in the security model:

Human users

Internal business users
Internal admin users
External authenticated users
External unauthenticated users

Non-human users

Integration users
System/technical Users

Step 2: Define fully locked down base profiles

Most permissions can be assigned via either profiles or permissions sets.
Going forward, Salesforce is discouraging admins from relying on profiles for permission management, and instead envisions permission management being completely delivered by permission sets and permission set groups.

As of now, however, there are three configurations that are only available on profiles:

Default record type
Page layouts
IP ranges and login hours

Also note that licenses are granted through profiles and are limited to one type of user license per profile.

So, although both approaches (i.e. profiles and permission sets) are technically possible, they should not be used interchangeably. The aim is to keep the number of base profiles as low as possible. These profiles should only be used for those capabilities that are not present in permission sets, like authorized IP ranges. All remaining permissions should be assigned through permission sets.

Here is one example of how this would look:

One or more base profiles for business users, based on their need for default record types and page layouts (while waiting for dynamic forms)
One base profile for admin users with the IP restrictions aligned with the corporate network
One base profile per external user license
One base profile for all integration users that make calls from the same IP range
One base profile for all system users that don’t need to authenticate. These profiles would be configured with locked down IP restrictions.
One guest profile per community and site

Each profile should include only those permissions that can’t be achieved via permission sets:

No system permissions
No access to object and fields
No access to connected apps
No access to Apex classes and Visualforce pages
No tab settings
No custom permissions

For base profiles requiring a full license, you can clone the Minimum Access — Salesforce profile. It comes with Access Activities, Chatter Internal User, and Lightning Console User permissions, which are mandatory with a full license.

Step 3: For each persona, extend access with permission sets and permission set groups

For each persona, define a list of required access rights based on the expressed business needs. You can then articulate these access rights into one or more permission sets. The permission sets are then grouped in permission set groups with one group corresponding to one persona. With this approach, you have the flexibility to associate permission sets to more than one persona as well as an easy way to maintain each persona’s access rights.

One good way to structure permission sets is on a per-application basis, covering data access rights (objects and fields), assigned apps (including communities and connected apps), and access to technical components (including Apex, Visualforce pages, flows, custom metadata types, and custom settings). This approach aligns with package-based development and allows for each app to be bundled with its own security configuration.

Specific permission sets can also be defined for system-level permissions, for example, access to Chatter, Lightning user, or session settings. In sandboxes and other non-production environments, permission sets would provide admin and developer access.

For guidelines on permissions assignment best practices, see key permissions to watch for.

Step 4: Define the sharing model

Now that you have a good idea of the required object- and field-level access, it is time to define record-level access controls.

All objects’ default access should be set to minimum. Organization-wide sharing defaults should be set to Private or Controlled By Parent for both internal and external users. Any standard objects that are not used should stay Private. (And of course, any custom objects that are not used should be deleted.)

Once you’ve done this, the next stage is granting further access as required. This subject is so rich that it deserves a blog post on its own. Below are some high-level considerations to keep in mind as you design your sharing model.

If the object is fully public, then organization-wide sharing defaults can be set to Public Read Only or Public Read/Write. This is typically the case for reference data (although I recommend using custom metadata types for this). Please note that Public organization-wide sharing defaults are rare; this is the exception rather than the norm.

In some cases, it may be acceptable to set the organization-wide sharing defaults for internal users only, for some shared objects like Account or Contact. With this configuration, all users have access to all the records for these objects, without exception. It is not possible to restrict record access for objects with Public organization-wide sharing defaults.

Private organization-wide sharing defaults usually remain enforced for external users for all objects.

Several options are available for granting additional access to a large group of users or for a large set of records without changing organization-wide sharing defaults:

For internal users as well as Partner Community and Customer Community Plus users, a large criteria- or ownership-based sharing rule is the way to go.
Keep in mind that the All Internal Users group also includes integration and system users that may not need access to these records.
Use View All and Modify All permissions with caution. Some objects are used for more than one purpose. For example, Account records could include information about Customers but also about Partners. Modify All grants delete access.

To open access to a smaller number of users with a fine-level of control, Salesforce provides a rich set of capabilities, from record ownership and role hierarchy, to programmatic sharing via teams and territory management. More details about these capabilities can be found in the Salesforce Security Guide.

For Customer Community users it is often more effective from a security point of view to reparent records created by the users as soon as possible and reopen access via sharing set (e.g., with a lookup to Account, Contact, or User on the object to share). The only way to share records owned by a Customer Community user is via share groups, which comes with limited capabilities.

Consider asking for vendor recommendations regarding the sharing approach for the objects in their managed packages. Don’t hesitate to ask further questions if you think the data access controls are too loose.

Step 5 : Account for specific access types

Some artifacts controlled only at the profile or permission set level should also be considered as part of the security model. Access to these artifacts should be granted through permission sets as in Step 3:

External objects
Custom settings and custom metadata types
Apex classes and Visualforce Pages
Apps, including connected apps

Conclusion

By following the steps outlined in this post, you can design a user security model that is both robust and maintainable, while respecting the principle of least privilege.

Considerations for large implementations

On large implementations with numerous objects and personas, you may want to start with a high-level view. For example, limit the scope to the 20 most used objects. For each object, define the default sharing and a high-level access strategy for just two groups: internal and external users. Then use this as a guideline as you iterate over the personas.

It is easy for a security model to grow in complexity over time. The more complex a security model is, the harder it is to maintain and the more likely it is for security gaps to emerge. Complex security models can also diminish platform performance in large organizations. Take steps to put a strong governance structure in place to avoid this security bloat.

Resources

About the Author

Sandrine Hiest is a Senior Program Architect at Salesforce. Since joining in 2017, Sandrine has served as a trusted advisor, technical leader, and platform expert for Salesforce’s most complex enterprise customers. Sandrine is passionate about empowering her customers and coaching other architects on security and scalability topics.