The most crucial part of any enterprise-level application (built on Salesforce or otherwise) is the control of data. The litmus test for the effectiveness of an enterprise-level application is the way in which we restrict unauthorized access to data.
The following diagram illustrates the record sharing in an organization:
The four records A, B, C, and D are evenly distributed between the reps and the Manager. Rep 1 should only see record A, Rep 2 should only see record B, and so on.
At the top of the chain, the Super Manager can see all the records under him.
Before we design the application, we first need to consider the stakeholders of the application:
- Who will be using the application?
- What will these users do?
- Is the data sensitive or critical?
- Who will be customizing the application?
- Are there any global records that should not be edited by the users?
- Which set of users will be editing which data?
These are some of the questions that need to be addressed before we understand the security model of the application.
Let's revisit the problem statement of the Library Management System. The purpose of this exercise is to determine the actors in the system. Let's have a recap of the objects of the Library Management System:
|
Object name |
Related to (relationship) |
Comments |
|---|---|---|
|
Media |
|
The media object is the master table used to store the collection of media. Books and videos are separated by the record type to show different types of media. |
|
Customer |
Book Penalty (the detail object of a member) |
The Customer object stores the customer information. It also stores the total fine paid by the customer as a roll-up field. |
|
CustomerMedia |
Customer, Media (the master object) |
The |
|
Book Penalty |
Customer |
This is a child object of a customer and stores the amount of late fees paid by the customer. |
For the sake of simplicity, there will be two types of users that will be using the system:
- Librarian(s): They will be responsible for the check-in and checkout of the books. They will be responsible for collecting penalties from the customers.
- Admin: Admin will update the book catalogue and add new members to the library.
In the next section, we will take a look at the Force.com security control.
The security of the Force.com model is split into four parts:
- Organization-wide default
- Profile and role-based sharing
- Sharing rules
- Manual sharing
The four types of sharing can be visualized as a reverse pyramid with the maximum number of people accessing the data increasing as we move up the pyramid, as shown in the following diagram:
Let's climb to the top of the pyramid one by one and look at the different types of security offered by Force.com.
For example, if a user sees a record due to Organization-Wide defaults and profiles, there is no way we can restrict the user from seeing the record using Sharing Rules or Manual Sharing. However, if the user cannot access the object due to Organization-Wide defaults, we can make it visible using Sharing Rules or Manual Sharing. The rule of thumb.
As we have already seen in Chapter 1, Getting Started with Force.com, users need the combination of a username, password, and IP address or security token to log in to any Force.com application. As with any multiple users-based system, the most important aspect is not what the user sees, but what the user should not see.
Once the user is authenticated using any of the combinations mentioned earlier, the level of a user is determined. If the user has certain restrictions or special privileges, the data is displayed accordingly. The restrictions and privileges are stored by the system administrator in the profile.
Based on the permission set in the profile associated with the user, the data, application, and logic is displayed. By default, Salesforce provides us with six standard profiles. These six profiles cannot be modified; if we wish to change some permission in any of them, we clone the profile and modify the clone:
- System administrator
- Authenticated website user
- Standard platform user
- Force.com user
- Contract manager
- Standard user
Roles and profiles are used to determine user access to data. The profile determines what objects the user can see, while the user role determines what records the user can see.
Let's explore both of them in more detail.
The profile determines the level of access the user has to the object. It also contains the setting to enable or disable access to a few applications on the platform. Using the profile, we can control the following:
- We can set which apps the user can see
- We can set which tabs the users are permitted to use
- We can determine which objects the user can see, create, update, and delete
- We can configure the default RecordType and the default page layout available for the user
- We can set which fields are enabled or restricted for the profile
- The Apex class and Visualforce pages are accessible to the user
- Whether the profile also configures the hours in which the user logs in as well as the IP address from which they can log in
- The system-level configurations that the users are permitted to change
Force.com limits editing of the standard profile, and hence, it is recommended that you create a custom profile for special permission set users. In this section, we will create a custom profile for the librarian.
To create a profile, perform the following steps:
- Go to Username | Setup | Administration Setup | Manage Users | Profiles.
- Click on the New button.
- We need to select the base standard or existing custom profile to clone the new one. This will copy the existing permissions to the new one.
- To create a Librarian profile, we need to clone the system administrator profile, as shown in the following screenshot:
- We will be redirected to the profile detail page. In the next section, we will take a look at the different and important aspects of the profile detail page.
- The profile details page contains different sections that allow us to configure the different aspects of the platform, as shown in the following screenshot:
Let's take a look at some of the important sections in detail.
The Assigned Apps section allows us to choose the Apps that the user can access. We can also set the Default app for the user:
The Object settings section allows us to choose the object's permission for the user. In one layout, we can see all the objects a user has access to. We can view the Object permissions and Tab settings tabs:
Let's take a look at the Books object in detail:
The first section is the Tab Settings that determines the access level of the object tab.
There are three options that we can choose for the tab settings:
|
Default On |
This makes the tab default to the user when they open the app |
|
Default Off |
This hides the tab from the user, but the user can personalize their app to add the tab again |
|
Tab Hidden |
This hides the tab from the user and the user cannot add it |
If there are some sensitive tabs containing important data, the tab has to be specifically hidden from the user. The user can personalize his app and add new tabs to it as well. It is always recommended that you hide the tab separately along with the app:
The next section is the Record Types and Page Layout Assignments that determine which Recordtype the user can access. We can assign a Page Layout to every Record Type. We can also assign a recordType as default:
The Object Permissions section determines the level of access to the object. These permissions determine what access control the user has on the object that is specified. The View All and Modify All checkboxes make the object visible and shareable regardless of any other sharing settings.
The Field Permissions section allows us to select the individual Read and Edit permissions for each field of that object.
The App permissions section gives us administrative capabilities for the Salesforce CRM applications and the platform. We can configure the standard applications, such as Call Center, as shown in the following screenshot:
There are other permissions, such as Apex Class Access, Visualforce Access, External Data Sources Access, Named Credential Access, Data Visibility, and Custom Permissions, that allow us to assign the respective metadata to the profile:
System permissions controls the access to the system and allows us to turn on/off the features of the Salesforce system, as shown in the following screenshot:
For example, if we turn off the Author Apex permission, the user cannot access and see the custom code written on the platform.
You can refer to a complete list of user permissions at https://help.salesforce.com/htviewhelpdoc?id=users_profiles_system_perms.htm&siteLang=en_US.
Now, let's see how the user should see the data using roles.