An Overview of Force.com Security

Abstract

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.

Introducing Platform Security

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.

Users and Security

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.

Users

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.

  • Setup | Manage Users | Users lets administrators create users (depending on license). An important aspect of establishing a set of users includes establishing a password policy.
  • Setup | Security Controls | Password Policies lets you determine password expiration, minimum password complexity requirements and lockout periods.
  • Setup | Manage Users | Users also lets you reset password of selected users.
  • Setup | Security Controls | Expire All Passwords does what it says.

All users are assigned to a user profile, which is examined in more detail in the section on user-based permissions below.

User Authentication

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:

  • Delegated Authentication - With this approach, a user logs into the platform as usual, but the platform uses a web service callout to submit the user name and password to an external authorization authority. Once that authority approves the logon, the approval is passed back to the platform and the user can proceed. If you want to use delegated authentication, you will have to contact salesforce.com to enable this feature for your organization.
  • Security Assertion Markup Language (SAML) - Using SAML, your request goes to the SAML "identity provider", a login page hosted by your organization that validates your identity and returns a token. The token is passed to the platform, which verifies the user by validating that it is signed by the appropriate identity provider. This approach is typically used when your users are accessing your platform applications through a portal, which would handle the initial authentication and avoid the need to log into Force.com again. You can configure SAML for your organization through the Setup | Security Controls | Single Sign-On page.

Network-based Security

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.

Security trusted.jpg

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.

Session Security

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.

Auditing

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.

Data Auditing

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:

  1. From Setup | Create | Objects, click Edit next to the name of the object you want to change.
  2. Check the Track Field History checkbox and click Save.
  3. Select the object by clicking on the object name. From the object detail page, under the Custom Fields and Relationships section, click Set History Tracking to specify which fields you want to track.

The following figure shows the automatically generated history that resulted when the text of a tracked field was changed:

Security field track.jpg

Programmatic Security

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:

  • Password can still expire. However, you have to programatically check for an expired password when you log in.
  • A session can expire as well. However, unlike the online user interface, no warning is given.
  • The network-based security allows clients to login to their environments from within the accepted IP ranges. However, if the client logs in from outside of these IP ranges, the client has to append a security token to their password.

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.

Security Tokens

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.

OAuth

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.

Force.com Security Source Code Scanner

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.

Platform Security Framework

This section covers the following areas of security on the Force.com platform:

  • System permissions, which give users in your organization the ability to perform various actions and access parts of the Force.com platform
  • Component permissions, which grant access to different components within your organization
  • Record-based sharing, which grants access to individual records in an object

The following sections examine each of these aspects of security.

System Permissions

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.

Administrative Permissions

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:

  • Manage Users - allows user to modify all user attributes. A holder can assign any of the other permissions to other users with this permission, so this permission should only be granted to very few users.
  • API-enabled - Without this permission, a user cannot access the Force.com system from outside of the environment.
  • API-Only User - prevents users with this permission in their profile from logging into the Force.com platform, except through one of the Web services APIs.
  • View Setup and Configuration - allows users to view complete Setup menu, without the ability to make changes.
  • Password never expires - as it says.
  • Customize application - allows complete editing access to options for Force.com applications. A powerful permission that developers require, but one that should be granted sparingly to others.
  • Edit HTML Templates, Manage Letterheads, Manage Public Templates - all related to components used for Force.com messages.
  • Author Apex - allows users with this permission in their profile to create and edit Apex. Requires the Modify All Data permission as a prerequisite.

Reports

The following administrative permissions pertain to reports:

  • Create and Customize Reports - grants access to create new reports or modify existing reports.
  • Run Reports - allows users to access the reports tab.
  • Export Reports - allows users to export data from reports to an Excel spreadsheet format.
  • Manage Custom Report Types, Manage Dashboards, Manage Public Reports, Schedule Dashboards - allows users to manage and modify the respective component types.

Data

The following permissions regard data manipulation, but from an administrative perspective. See Record-based Sharing for a developer perspective:

  • Modify All Data - a very powerful permission that, if granted globally, allows users to modify all data in the Force.com organization. You can also grant this permission for an object.
  • View All Data - allows user to see all data in the Force.com organization, if granted globally. You can grant this permission for an object.
  • Edit Read-Only Fields - allows users with this permission in their profile to edit read-only limitations set in a page layout.
  • View Encrypted Data - allows users with this permission in their profile to see plain text representation of encrypted data.
  • Weekly Data Export - allows users with this permission in their profile to perform a weekly data export.
  • Disable Outbound Messaging - prevents the use of outbound messaging for the profile.

Component Permissions

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.

Security crud.jpg

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.

Security field.jpg

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.

Record-based Sharing

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.

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.

Security sharing org.jpg

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.

Sharing

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:

  • Manually, which are implemented through the Share button on the record detail page. This button is on all detail pages by default, although the button can be removed from a page layout. The Share button will not appear for records whose organization-wide default is set to Public Read-Write, as there is no need to grant further sharing privileges for records in this object.
  • Sharing rules, which automatically share records owned by users in one grouping with users in another grouping. You can share records to a role or a group, which are described in the next paragraph, or with a territory, which is designed to support CRM implementations.
  • Apex, either by automatically assigning sharing when a record is created, or by using the Apex managed sharing (which only applies to custom objects.)

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.

Security sharing.jpg

Changes that Affect Sharing

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.

Summary

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.

References


About the Author

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!"