In Salesforce, Securing Data from unauthenticated users is very important. Data in Salesforce is stored in the form of Objects, Fields, and records. To Secure data we have to design and implement salesforce security data model for all different users and data they need to access. There are four different levels of data access in Salesforce.com.
- Organization level Security or system level Security
- Objects level Security
- Field level Security
- Record level Security
Organization or System level Security
System level security is the highest level of security in Salesforce where we maintain a list of authorized users to login, Password policies, Login IP ranges, limiting login access to certain hours, Session Security, Login Flows, Network Access.
Object Level Security or Profiles
Object Level Security in Salesforce is done at profile level by setting permissions on Objects. We can prevent user to edit, Create, Delete, View of a record in that Object.
Field Level Security in Salesforce
In Field Level Security, User can’t access certain fields in an object.
Record level Security in Salesforce
In Record level Security in Salesforce grant user to access some object records and not all. Record level sharing or Security can be done by
- Organization-wide Sharing settings
- Role Hierarchy
- Sharing Rules
- Manual Sharing
- Apex Managing sharing
Salesforce Security Model Classification
AUTHENTICATION
Authentication means preventing unauthorized access to your organization or its data by making sure each logged in user is who they say they are.
Multi-Factor Authentication :-
Multi-factor authentication (MFA) is a secure authentication method that requires users to prove their identity by supplying two or more pieces of evidence (or factors) when they log in. One factor is something the user knows, such as their username and password.
Other factors include something the user has, such as an authenticator app or security key. By tying user access to multiple types of factors, MFA makes it much harder for common threats like phishing attacks and account takeovers to succeed.
Single Sign-On :-
Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials. For example, after users log in to your org, they can automatically access all apps from the App Launcher. You can set up your Salesforce org to trust a third-party identity provider to authenticate users. Or you can configure a third-party app to rely on your org for authentication.
Custom Login Flows :-
A login flow directs users through a login process before they access your Salesforce org or Experience Cloud site. You can use a login flow to control the business processes that your users follow when they log in to Salesforce. After Salesforce authenticates a user, the login flow directs the user through a process such as enforcing strong authentication or collecting user information. When users complete the login flow successfully, they’re redirected to their Salesforce org or site. If unsuccessful, the flow can log out users immediately.
Connected Apps :-
A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps. The external apps that are integrated with Salesforce can run on the customer success platform, other platforms, devices, or SaaS subscriptions. For example, when you log in to your Salesforce mobile app and see your data from your Salesforce org, you’re using a connected app.
Manage User Passwords :-
Salesforce provides each of your users with a unique username and password that they enter at each login. As an admin, you can configure several settings to ensure that your users’ passwords are strong and secure.
Device Activation :-
With device activation, Salesforce challenges users to verify their identity when they log in from an unrecognized browser or device or from an IP address outside of a trusted range. By adding extra verification to unfamiliar login attempts, device activation keeps your orgs and Experience Cloud sites secure.
Session Security :-
After logging in, a user establishes a session with the platform. Use session security to limit exposure to your network when a user leaves the computer unattended while still logged in. Session security also limits the risk of internal attacks such as when one employee tries to use another employee’s session. Choose from several session settings to control session behavior.
AUTHORIZATION
OAuth authorization flows grant a client application restricted access to protected resources on a resource server. Each OAuth flow offers a different process for approving access to a client app, but in general the flows consist of three main steps. To initiate an authorization flow, a client app requests access to a protected resource. In response, an authorizing server grants access tokens to the client app. A resource server then validates these access tokens and approves access to the protected resource.
For example, when you open the Salesforce mobile app to access your Salesforce data, you initiate an OAuth 2.0 authorization flow. In this flow, your Salesforce org is the resource server that hosts the protected resource. The Salesforce mobile app is the client requesting access. You’re the resource owner, who allows the Salesforce mobile app to access and manage your Salesforce data over the web at any time. Your Salesforce org, acting as the authorization server, grants access to the Salesforce mobile app by issuing an access token. Let’s go over the flow step by step.
- You open the Salesforce mobile app.
- An authentication prompt displays, in which you enter your username and password.
- The Salesforce mobile app sends your credentials to Salesforce and initiates the OAuth authorization flow.
- Salesforce sends the mobile app access and refresh tokens as confirmation of a successful validation of the user and the mobile app.
- You approve the request to grant access to the Salesforce mobile app.
- The Salesforce mobile app starts.
After this initial flow, the Salesforce mobile app starts immediately when the session is active. If the session is stale, the Salesforce mobile app uses the refresh token from its initial authorization to get an updated session.
Contrast this approach with giving your username and password to a client app to access a resource server on your behalf. The client app effectively impersonates you, with precisely the same access to your data. If you no longer trust the client app, you must change your password at the resource server, which is an inconvenience and a security risk. For this reason, OAuth authorization is a better solution.
SOCIAL SIGN-ON
By offering social sign-on, customers have a convenient and secure experience with Universal Deliveries.
To enable customers to log in to Salesforce with their social credentials, you configure an authentication (auth) provider for the social account. Here’s what your customer experiences when you do.
Social sign-on process :-
- A customer encounters a Salesforce login page with options to log in via Google, Facebook, Twitter, as well as username and password. (1)
- The customer chooses to log in via Facebook credentials. (2)
- Salesforce redirects the customer to Facebook. (3)
- The customer logs in to Facebook. (4)
- Facebook logs in the customer to Salesforce automatically because Salesforce trusts Facebook’s verification. (5)
Salesforce has several auth providers to choose from—more, if you count those auth providers that your developers can configure using the OpenID Connect protocol. And even more—if your developers want to create their own authentication provider, they can use Salesforce APIs to do so.
Profiles
Profile is a collection of settings and permissions that determine which data and features in the platform users have access to.
Settings determine what users can see for example apps, tabs, fields, and record types whereas Permission determine what users can do for example create or edit records of a certain type, run reports, and customize the app.
Profiles Control:
- Object Permission
- Field Permission
- User Permission
- Tab Settings
- App Settings
- Apex class access
- Visualforce page access
- Page Layouts
- Record Types
- Login Hours
- Login IP Ranges
Profiles are typically defined by a user’s job function but anything that makes sense in an organization can be created as a profile. The platform includes a set of standard profiles. Each of the standard profiles includes a default set of permissions for all of the standard objects available on the platform.
Some of them are ,
- Standard User:
Standard User profile has Read, Edit, and Delete permissions to most standard objects.
- Read Only:
Read-only user had permissions exactly similar to standard user but limits the access to read-only.
- Marketing User:
Permissions of Standard User+ Additional Permissions.
- Contract Manager:
Permissions of Standard User + Additional Permissions.
- Solution Manager:
Permissions of Standard User + Additional Permissions.
- System Administrator:
The System Administrator profile has the widest access to data and the greatest ability to configure and customize Salesforce. The System Administrator profile also includes two special permissions namely “View All Data” and “Modify All Data”. When a custom object is created most profiles except those with modify all data permission do not give access to that custom object.
Object permissions on the Standard profile cannot be edited So to overcome through this it is good to make copies/clones of standard profiles and then customize the copies to fit the needs of the organization. The profile functionality in an organization depends on the user license type. Every profile should have at least one visible app. If an app is visible, its tab won’t show up unless a profile has permissions to view the associated objects. A profile can be assigned to many users, but the user can be assigned to only one profile at a time.
Permission Sets
- A permission set is a collection of settings and permissions that give users access to various tools and functions. Permission sets extend users’ functional access without changing their profiles.
- Users can have only one profile but, depending on the Salesforce edition, they can have multiple permission sets. You can assign permission sets to various types of users, regardless of their profiles.
- Create permission sets to grant access among logical groupings of users, regardless of their primary job function. For example, let’s say you have several users who must delete and transfer leads. You can create a permission set based on the tasks that these users must perform and include the permission set within permission set groups based on job functions.
- If a permission isn’t enabled in a profile but is enabled in a permission set, users with that profile and permission set have the permission. For example, if Manage Password Policies isn’t enabled in a user’s profile but is enabled in one of their permission sets, they can manage password policies.
- A permission set’s overview page provides an entry point for all of the permissions in a permission set. To open a permission set overview page, from Setup, enter Permission Sets in the Quick Find box, then select Permission Sets and select the permission set you want to view.
Types of Permission Sets
Salesforce offers several types of permission sets to help your users achieve their business goals.
Create Permission Sets
You can clone a permission set or create a new one. A cloned permission set starts with the same licenses and enabled permissions as the original one. A new permission set starts with no licenses selected and no permissions enabled.
Assign Permission Sets to a Single User
Assign permission sets or remove permission set assignments for a single user from the user detail page.
Standard Permission Sets
A standard permission set consists of a group of common permissions for a particular feature associated with a permission set license. Using a standard permission set saves you time and facilitates administration because you don’t need to create the custom permission set.
Use Permission Set Lists
To view permission sets, from Setup, enter Permission Sets in the Quick Find box, then select Permission Sets.
Integration Permission Sets
Integration permission sets define the scope of data access by Salesforce integration-related features and services.
Session-based Permission Sets
Create session-based permission sets that allow access only during specified sessions. For example, create a session-based permission set that grants access to an application only during an authenticated session.
Permission Set Considerations
Be aware of these considerations and special behaviors for permission sets.
Create a Permission Set Associated with a Permission Set License
For users to access license functionality, they must both be assigned the permission set license and a permission set containing the feature permissions.
ROLE HIERARCHY
Role Hierarchy is a mechanism to control the data access to the records on a salesforce object based on the job role of a user. For example, a manager needs to have access to all the data pertaining to the employees who report to him, but the employees have no access to the data that is only owned by their manager. In this manner, the access model looks similar to the org chart in an organization, but it need not be exactly same as the Org chart.
The role hierarchy automatically grants record access to users above the record owner in the hierarchy. This option is enabled for all objects by default. To change this, we take help of custom objects and manual aces grants.
SHARING SETTINGS
In Salesforce, you can control access to data at many different levels. For example, you can control the access your users have to objects with object permissions. Within objects, you can control the access users have to fields using field-level security. To control access to data at the record level, use sharing settings.
There are several sharing mechanisms that you can use to configure record access for your users.
Organization-Wide Defaults
Your organization-wide default sharing settings give you a baseline level of access for each object and enable you to extend that level of access using hierarchies or sharing rules. For example, you can set the organization-wide default for leads to Private if you only want users to view and edit the leads they own. Then, you can create lead sharing rules to extend access of leads to particular users or groups.
Role Hierarchy
The role hierarchy automatically grants record access to users above the record owner in the hierarchy. You can control sharing access using hierarchies for any custom object, but not standard objects.
Sharing Rules
Sharing rules represent the exceptions to your organization-wide default settings. They allow you to extend record access to users regardless of their place in the role hierarchy. If you have organization-wide sharing defaults of Public Read Only or Private, you can define rules that give additional users access to records they don’t own. You can create sharing rules based on record owner or field values in the record.
Manual Sharing
Sometimes it’s impossible to define a consistent group of users who need access to a particular set of records. Record owners can use manual sharing to give read and edit permissions to users who don’t have access any other way. Manual sharing isn’t automated like organization-wide sharing settings, role hierarchies, or sharing rules. But it gives record owners the flexibility to share records with users that must see them.
Apex Managed Sharing
Apex managed sharing allows developers to programmatically share custom objects. When you use Apex managed sharing to share a custom object, only users with the “Modify All Data” permission can add or change the sharing on the custom object’s record, and the sharing access is maintained across record owner changes.
Other Methods for Allowing Access to Records
In addition to sharing settings, there are a few other ways to allow multiple users access to given records:
Map category groups to roles
Control access to data categories by mapping them to user roles.
Queues
Queues help you prioritize, distribute, and assign records to teams who share workloads. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue.Use queues to route lead, order, case, and custom object records to a group.
Teams
For accounts, opportunities, and cases, record owners can use teams to allow other users access to their records. A team is a group of users that work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. The record owner adds team members and specifies the level of access each team member has to the record, so that some team members can have read-only access and others can have read/write access. The record owner can also specify a role for each team member, such as “Executive Sponsor.” In account teams, team members also have access to any contacts, opportunities, and cases associated with an account.
Thank you for giving this blog content Muhseena
https://www.linkedin.com/in/muhseena-hussain-b890b5128/