,

Force Platform Security

Justifiably or not, a multi-tenant, on-demand platform is the subject of more doubt in the area of security than an in-house platform. To guarantee the security of your own organization, the Force Platform includes a range of security defenses that are automatically used to guard your data resources.

Organization Security

One of the core features of a multi-tenant platform is the use of a single pool of computing resources to service the needs of many different customers. The Force Platform protects your organization from all other customer organizations by using a unique organization identifier that is associated with your Force Platform session.

Once you log into your Force Platform organization, your subsequent requests are associated with your organization, and only your organization, using this identifier. With this safeguard, all access to your organization is protected by the user authentication.

User Security

Users are identified to the Force Platform by their user name and password. You can specify the password policies through the Setup Security Controls Password Policies as shown below.

This page gives you the ability to set policies involving how frequently passwords must be changed, whether a user can re-use a recent password, password complexity requirements and how the platform treats invalid login attempts. These password domain settings are usually handled by administrators, but you can rest assured that your deployment environment can be secured with these settings.

Security settings and API access The focus of this book is on applications running on the Force Platform, rather than applications accessing the platform through the Force Platform API. But you should be aware that some of the standard security features discussed in this section work somewhat differently for API access. For instance, if a user logs into an application running on the Force Platform and their password has expired, they are prompted to change the password. An expired password prevents access through the API, but applications that access the platform through the API have to detect this problem procedurally. The session timeout discussed later in this section is sensitive to any user interaction through the standard Force Platform user interface, but the time limit on a session is enforced on an entire API session, regardless of user interaction. In addition, there is no warning given before an API session is terminated. Because of this, access through the Force Platform API should not assume the existence of an active session.

Administrators can force the expiration of passwords for one or more users through the Setup Manager Users Users page, or force the expiration of all passwords for all users with the Expire All Passwords option in the Security Control area of the Administrative Setup section of the Setup menu.

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

User Authentication

The Force Platform has its own system of user authentication, but some companies would like to use an existing single sign-on capability to simplify and standardize their user security.

You have two options to implement single sign-on with the Force Platform: delegated authentication and Security Assertion Markup Language (SAML).

• Delegated Authentication- With this approach, a user logs into the Force 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 Force 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 and then create a Web Service callout to the authentication authority.

• SAML- Using SAML, your request goes to the SAML authority that validates your identity and returns a token. The token is passed to the Force Platform that verifies the user with the authority. This approach is typically used when your users are accessing your Force Platform applications through a portal, which would handle the initial authentication and avoid the need to log into the Force Platform environment again. You can configure SAML for your organization through the Setup Security Controls Single Sign-On Page.

Both of these single sign-on options are described in much more detail in the online documentation and in articles available at the developer.force.com site.

Network-based Security

To provide a level of network-based security, the Force Platform includes the ability to limit access to your organization based on the IP address of your client in two different ways.

You can use a whitelist to indicate the IP address ranges that are allowed to access an organization by default. You can define a whitelist for an entire organization clicking Setup Security Controls Network Access New, as shown in the following figure.

You can define multiple IP ranges for your organization. You cannot use this feature to whitelist all IP addresses since there is a limit on the number of IP addresses that can be defined in a range; however, the limit is generous enough to allow for a broad range of specified IP addresses.

If you define a set of allowable IP addresses for your organization, all login attempts from those IP addresses are accepted by default. If a user tries to log in from an IP address that is not specified for the org, they are challenged by the Force Platform, which then sends them an email. The user must click on a link in the email to allow access from the new IP address. Once this reply is sent, the user can log in from the current IP address in the future.

If no IP addresses are defined for the organization, a user must respond to this challenge the first time they log in from an IP address.

This challenge mechanism is fine if a user is actually attempting to log into the platform, but does not work if a user or application is trying to access the organization through the Web Services API, described in the next chapter. In this situation, a login request must include a security token appended to the password for the user. The user generates a security token through the Setup My Personal Information Reset My Security Token option that sends an email to the user with the security token. Some utilities, such as Data Loader, use the Web Services API to access the Force Platform, so use of these utilities from an unfamiliar IP address requires the use of a security token.

Profiles can also be used to define a range of acceptable IP addresses, although the IP addresses defined for a profile are restrictive, rather than acceptable defaults. If a profile has IP addresses defined, any user with that profile cannot log into the Force Platform from any other IP address.

Profiles are also 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 Administrative 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

The final area of security for the Force Platform revolves around an individual Force Platform session. The Setup Security Controls Session Settings page, shown below, allows you to require secure connections to the platform or to lock a session to the originating IP address.

You can also set the time limit for an individual session to between 15 minutes and 8 hours. Once a user’s session is inactive for this length of time, the user has to respond to a warning popup. If the user does not respond, the session ends and the user has to log back into the Force Platform. You can also suppress the use of the warning popup.

The session timeout provides some protection from unauthorized access caused by leaving your computer while still logged into the Force Platform.

Auditing

Auditing features do not secure your Force Platform environment by themselves, but these features provide information about client usage of the platform that can be critical in diagnosing potential or real security issues. All objects include fields to store the name of the users who created the record and who last modified the record, providing some basic auditing information, but the Force Platform has features to extend the auditing capabilities of your application and data.

The Setup Manage Users Login History page displays the last 20 logins to your organization, as well as giving you the ability to download 6 months worth of logins in a comma separated variable file. This file includes session-specific attributes, such as IP address and browser type, which are not available in record and field auditing.

As mentioned earlier, 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.

Under Setup Security Controls, administrators can use View Setup Audit Trail to monitor when meta-data definitions for objects have changed. With this feature, you can track the evolution of your application over time.