Designing the Security Model
To begin the design process, review the fundamentals of Force.com security and the sample application’s security requirements:
Force.com data security has two facets: profiles and the sharing model. Profiles protect objects and their fields, and the sharing model controls access to individual records.
Data security in the sample application is determined by an employee’s job function and business unit. Job functions are identical across business units, and business units do not normally share data.
The design strategy followed in the remainder of this section examines each of the sample application’s security requirements and discusses the configuration of the Force.com security features necessary to satisfy them.
Security by Job Function
Job functions dictate what type of data a user is allowed to view and modify. For example, consultants should not create projects or assignments. A staffing coordinator creates projects and assigns resources to them. But a consultant is allowed to create and edit timecards.
As you’re thinking about job functions, you’re naturally discussing the objects that make up the application. In Force.com, profiles control access to objects and fields. To design profiles for the Services Manager application, start by listing all job functions and objects in a grid. At the intersection of each job function and object, determine the level of access needed. The level of access is expressed as a series of permissions. The permissions are read, create, edit, and delete. Table 3.1 shows the output of this exercise.
Security by Business Unit
Business units are autonomous minicompanies that have a somewhat competitive relationship with each other. All business units report to an executive team. The sample organization is shown in Figure 3.10.
The Force.com security model must account for the following facts about the organization:
In normal day-to-day operations, business units do not share data. This includes projects, resources, customers, and contacts. All data is private, belonging to the business unit that created it.
In some cases, business units might need to share records. For example, a consultant with specialized skills is needed on projects in all three business units.
Members of the executive team are able to read and write all data.
In the preceding section, you designed profiles to provide each job function in the organization with access to objects and fields. Now you must look at the requirements to protect each record of data. This is where Force.com’s record-level security features come into play. To design for record-level security, use the following three steps:
1. Establish the sharing model—For each object, determine the most restrictive mode of sharing that is called for on its records. For the custom objects found in Services Manager, the options are Private, Public Read Only, and Public Read/Write. Private means that records remain under the control of their owners. Do not consider objects on the Detail side of Master-Detail relationships because records in these objects inherit ownership from their parent record. The output of this step is a list of objects, each with a default access setting (Private, Public Read Only, or Public Read/Write).
2. Build groups of users—Identify scenarios in which users need to share data outside of the restrictive defaults defined in the sharing model. Look for groups of users involved in these exceptions to the sharing model. Examine the flow of information between the two groups. It can be symmetric, with both groups getting equal access to the data. Or it can be one-sided, with one group receiving elevated rights to another group’s data without reciprocation. The output of this step is a list of roles and public groups. Use roles where the sharing relationship is one-sided, and public groups where the relationship is equal.
3. Set sharing rules—Using the list of roles and public groups from the preceding step, build a list of sharing rules. To build each rule, follow three steps, as shown here:
a. Determine which group owns the record to be shared.
b. Identify the other group requiring access to the records owned by the first group.
c. Decide whether the other group requires Read Only or Read/Write access to the shared record.
Following the first step creates the results given in Table 3.2, which shows the sharing model chosen for each object.
In the second step, the groups of users are defined. In Services Manager, the only groups relevant to sharing are the business units. Each business unit will become a role, including the executive team.
For the final step of defining sharing rules between the groups, the requirement is to allow users in the same business unit to collaborate on records. To accomplish this task, grant each business unit Read/Write access to records owned by users in its business unit.