Securing access to your applications, data and logic is a key part of application development and system configuration. This security should not only protect data and logic from unauthorized external access, but also from unauthorized internal access—for example by only granting data access to users with the appropriate authorization. Force.com is built around a robust and flexible security architecture, providing you with a fine degree of control over the users, network, and data. This article discusses these various aspects of security—introducing everything from user and client authentication through administrative permissions and the data access and sharing model.
This article examines three aspects of security. The first aspect is users and security, looking at how users are authenticated, network-based security that determines the IP ranges from which a user may access the network, sessions and auditing.
The second aspect is programmatic security. Any software client that needs to log in to the platform does so through a Web services SOAP interface. This section notes some of the security aspects involved, such as security tokens.
The third aspect is the Force.com platform security framework, which you can use to offer different access permissions to authenticated users within your organization. This security framework lets you grant security permissions to users or profiles, determine access control over a wide range of components (such as tabs or persistent objects), and configure data sharing, which limits access to individual records. Some of this security framework is administrative (only allow these user profiles access to this application), while some is also relevant to your application architecture (ensure that these records are always visible to managers).
At an infrastructure and network level, salesforce.com applies rigorous security standards, such as SysTrust SAS 70 Type II. This article doesn't cover this level of security, though you can find an overview on the corporate site. Another corporate site of interest is trust.salesforce.com, which provides real-time information on system performance and security, including information on security alerts.
Security is a cross-cutting concern—you may be interested in restricting user authentication based on an IP range, or in granting read access to a certain field in a persistent object. For this reason the purpose of this article is not to provide an immense amount of background to each security concern. Rather, it is to highlight what the security feature does and what configuration options are available—hopefully putting you in a position where you are aware of all the security features provided by the platform, and how they can affect application development and administration.
This section looks at how users are authenticated, how to restrict authentication to certain hours or IP ranges, and how to configure sessions and list audit logins.
Access to (most parts of) the Force.com platform is only granted after a user is authenticated. Users have to first be established, usually by an Administrator—a user with special security privileges.
All users are assigned to a user profile, which is examined in more detail in the section on user-based permissions below.
Most users are authenticated on the login page, typically https://login.salesforce.com/. After logging in, the user will have access to applications, data and logic to which he has been granted access. See the Platform Security Framework section below for details on how this is configured.
There are two other forms of user authentication, usually used to implement single sign-on within a corporation:
User configuration determines who can login, while network-based security limits where they can login from and when. Salesforce.com provides two options for limiting access based on the user's network location. The first option is to allow from users from trusted locations, but challenge them when they come from new and untrusted locations. Setup | Security Controls | Network Access allows you to whitelist a set of IP address ranges that you trust. If users attempt to login from a machine that is within the trusted IP ranges, they will be able to log in as usual. If users attempt to log in from a new location outside those IP ranges, they are challenged by the platform. The system sends them an email which contains a link. The user must visit the link in the email to allow access from the new IP address. Once this link is visited, the user can log in from the current IP address from then on.
Tighter restrictions can be defined on a user profile. If a profile has Login IP restrictions defined, any user with that profile can only login to the platform from those IP addresses. The user will never receive a challenge if they try to login outside those IP addresses: the login will simply fail.
Profiles can also be used to restrict the hours that a user can log into the platform. You can set either of these restrictions for a particular profile from the bottom of the Profiles page under Setup | Manage Users.
The limitations imposed on IP addresses are used to help protect against phishing attacks. A malicious attack cannot be triggered from outside your range of IP addresses, even if the attacker has a correct user name and password.
After logging in, a user establishes a session with the platform. The Setup | Security Controls | Session Settings page lets you control this session. For example, you can set a session timeout—if the user is inactive for this period of time, and he doesn't respond to a warning popup, then the user is automatically logged out. You can also suppress the session timeout warning popup, so that the user is automatically logged out after the specified time. In addition, you can require that all pages always be accessed using a secure connection, that is, HTTPS (SSL). Using secure connections is enabled by default.
A final aspect of this security is auditing. Setup | Manage Users | Login History displays the last 20 logins to your organization, as well as access to download 6 months worth of login data, which includes IP addresses, browser types and so on.
The Setup | Security Controls | View Setup Audit Trail page lets you audit metadata and system changes. For example, this page will show you when a Visualforce page was created or modified, when the session security settings were changes and so on.
You can turn on auditing for objects with a single click. Object-level auditing tracks changes in the overall object records, such as record creation. You can also enable auditing for individual fields, automatically tracking any changes in the values of selected fields. Although auditing is available for all custom objects, many standard objects do not allow auditing.
Although rather succinctly described here, data auditing is an extremely powerful feature, and one that only requires minor configuration settings to enable. To switch on tracking field history:
The following figure shows the automatically generated history that resulted when the text of a tracked field was changed:
The Force.com SOAP API and the Force.com Metadata API can be used to programmatically access logic, data and metadata on Force.com. Before calls can be made to either API, an authenticated session needs to be established, and this session shares many of the same characteristics covered in the previous section. In particular:
The Quick Start section of the Force.com SOAP API Developer's Guide documentation shows how to login using Java code, as well as check for exceptions (such as an expired password).
The application code that you have running within your Force.com applications can also be restricted to a set of web addresses that they may contact. For example, you may only want to allow communication between Force.com and your own servers that host a Web service end point. Whenever you develop any code that does needs to perform an external communication, you will need to explicitly permit the action by adding the site on the Setup | Security Controls | Remote Site Settings page.
The email challenge mechanism is a way to allow a user to login from outside of an IP range. This challenge works somewhat differently for programmatic clients. If a client is run from a host outside the whitelisted IP ranges, the client has to append a security token to the password of the user that is being authorized. You can generate the security token by going to Setup | My Personal Information | Reset My Security token in the user interface, which will send an email to the user with the token.
Many tools built around the platform make use of the SOAP APIs, and as such may require the use of a security token, depending on whether you run them from a trusted IP range or not.
The SOAP APIs also support authenticating using OAuth 2.0. OAuth is an open protocol that allows a website to access resources of another website without having to expose a user's credentials. Instead of supplying a username and password, OAuth allows users to hand out security tokens to specific sites for access to specific resources for a defined duration. For more details, see Using OAuth to Authorize External Applications and Digging Deeper into OAuth 2.0 on Force.com.
There are many programmatic best practices that developers should enforce. Some of these can be caught using a source code analyser, and Force.com has a security source code scanner, available from the Security resource page. This service scans the source code in an org and produces a report about the security aspects of the code, (specifically Apex and Visualforce), using static analysis tools.
This section covers the following areas of security on the Force.com platform:
The following sections examine each of these aspects of security.
System permissions grant access to capabilities which apply to your entire Force.com environment. System permissions are granted to profiles. Every user is assigned to one profile. You can access profiles and their permissions through Setup | Manage Users | Profiles. The Force.com environment comes with a set of standard profiles which cannot be edited. You can also create your own custom profiles.
System permissions can be grouped in the following categories.
These permissions are typically established by an administrator, and determine broad system access, such as specifying who has access to critical Setup menu items. Here are some of the permissions that can be configured:
The following administrative permissions pertain to reports:
The following permissions regard data manipulation, but from an administrative perspective. See Record-based Sharing for a developer perspective:
Moving up from the low-level system permissions, the Force.com platform also allows you to set permissions on individual Force.com components. For the following components, you can allow or disallow access, based on profile:
Keep in mind that each of these permissions is separate. A user could be denied access to an application, but still have access to the tabs within that application. You can modify some of these settings on the Profiles page, whereas for others you have to visit the component itself. For example, to set the security for a Visualforce page, go to Develop | Pages, and choose the Security action for the page. You will then be able to choose the profiles that have access to the page. The same holds for Apex classes.
The Profile page also lets you set the standard Read, Create, Edit and Delete access for all Force.com objects, as shown in the figure above.
In addition, you can specify field level security for any individual field of an object, as the following figure shows. You can limit a user to read-only access to a field, or hide the field entirely. This setting can be found in Setup | Security Controls | Field Accessibility.
All data permissions extend throughout the entire Force.com platform. For instance, if a user does not have access to an object, they will not see the user interface for the object, as well as not being able to use the object in reports.
The permissions listed previously grant broad privileges to different components, such as the ability to access or not access a particular component. You can add a finer level of access control for your data through record-based sharing.
Record-based sharing is the ability to grant access to individual records within a particular object. You can allow no access, read only access or read and write access to a record through sharing that record with others. Of course, specifying sharing options for each individual record, although powerful and flexible, could be a complicated process. In order to simplify the use of sharing, the Force.com platform provides organization-wide defaults.
You can set organization-wide defaults for any Force.com object. As the name implies, the organization-wide default specifies the level of sharing for all records in that object, for all users within the organization. Organization-wide defaults can be private, which only allows an owner to access the record, public read-only, which allows everyone in the organization to read the records in the object, or read write, which allows all users to read an write all records in the object.
Organization-wide defaults specify the absolute minimum level of access to the records in an object. Everyone has at least the privileges granted by organization-wide defaults. You assign the organization-wide default for an object to represent the least amount of access for the least accessible record for the least privileged user. In other words, you use organization-wide default to lock down access to individual records.
You can access these settings on Setup | Security Controls | Sharing Settings.
Once you have locked down access with organization-wide defaults, you can open up access for others through sharing. You can use sharing to grant access to any set of privileges greater than those established by organization-wide defaults, such as granting read-write privileges for a user to a record that had either private or read-only established for its organization-wide default.
You can share a record with other users in one of three ways:
In order to maximize the efficiency of implementing and executing sharing, the Force.com platform provides two ways to group users. A user can have a role, which is meant to define the user's place in a role hierarchy. In a role hierarchy, all users automatically have all the sharing privileges granted to those in subordinate roles in the hierarchy. In other words, a user with a manager role has all sharing privileges granted to all users in roles which report to that manager role. You can only have one role hierarchy in an organization.
You can also combine users into public groups. All users within a public group have the sharing privileges of that group. Groups can share privileges with other groups, which means that both groups have the same sharing privileges. This reciprocal sharing is different from the hierarchical sharing implement with roles.
The following figure shows a sharing rule being created for a Question object. It allows Question records created by members of the Direct Sales role to be shared with all members and subordinates of the Channel Sales Team role. Moreover, the sharing is granted at a Read/Write access level. This is a powerful feature of the platform, and thought needs to be put into designing a set of sharing rules for your data.
All Force.com records have a matching sharing record, where appropriate, that lists the sharing privileges for the record. Sharing is based on record ownership, roles and hierarchies and group membership, as well as individual shares granted through Apex. When the owner of a record, their role, their place in a role hierarchy or membership in a group changes, the sharing is recalculated for all affected records.
Normally, you want all sharing to be recalculated to reflect the current conditions. However, there may be times when you have added shares through Apex that you do not want to lose, despite changes in ownership, roles or groups. To avoid losing these shares, you can indicate that share is associated with an Apex sharing reason. Shares associated with an Apex sharing reason are not recalculated by the platform due to changes which affect other shares which were granted. You can see assign a sharing reason to a share, as well as seeing existing shares, by clicking on the Sharing button on the detail page of a record. You must, however, create an Apex class that recalculates sharing for these objects.
Force.com provides an extremely powerful and flexible security architecture. This architecture lets you define how users log in, determining for example which IP ranges are acceptable, what hours of the day are allowed, how long sessions stay active for and so on. It also lets you define programmatic control: for example, which users may log in through a Web services API, and which end points a running application can connect to from the Force.com platform. The platform security architecture also lets you define administrative security permissions, and the security profiles lets you determine who has access to which features and components - ranging from the Setup menu all the way through to read-write settings on an object or field.
Finally, the record-sharing model lets you have an even finer level of security of your data - not only determining who has access to which records based on a user, role or group model, but also how these data records are shared among various users.
Jon says "Thank you to the awesome Platform Documentation team for their great documentation. Thanks also to Rick Greenwald for contributing a good chunk of this article, Leah Cutter and Peter Dapkus for their great suggestions and corrections. Please send me any feedback about the article!"