Security Implementation Guide

Transcription

1 Salesforce.com: Spring '10 Security Implementation Guide Last updated: January 31, 2010 Copyright salesforce.com, inc. All rights reserved. Salesforce.com is a registered trademark of salesforce.com, inc., as are other names and marks. Other marks appearing herein may be trademarks of their respective owners.

2

3 Table of Contents Table of Contents Chapter 1: Security Overview...3 Security Infrastructure...3 Trust and Salesforce.com...4 User Security...5 User Authentication...5 Network-based Security...5 CAPTCHA Security for Data Exports...6 Session Security...6 Securing Data Access...6 Key Profile Permissions...8 Auditing...9 Chapter 2: Securing and Sharing Data...10 Managing Profiles...10 User Permissions on Profiles...11 Setting Field-Level Security...25 Setting Your Organization-Wide Default Sharing Model...26 Managing Roles...28 About Sharing Rules...29 Granting Access to Records...30 Chapter 3: Configuring Salesforce.com Security Features...32 Setting Password Policies...32 Expiring Passwords...33 Setting Login Restrictions...34 Restricting Login IP Ranges for Your Organization...35 Restricting Login Hours...36 Restricting Login IP Ranges on Profiles...36 Setting Session Security...37 Chapter 4: Enabling Single Sign-On...39 Chapter 5: Monitoring Your Organization's Security...42 Monitoring Logins...42 Tracking Field History...43 Monitoring Setup Changes...46 Chapter 6: Security Tips for Apex and Visualforce Development...49 Cross-Site Scripting (XSS)...49 S-Control Template and Formula Tags...51 Cross-Site Request Forgery (CSRF)...52 SOQL Injection...53 i

4 Table of Contents Data Access Control...55 Index...56 ii

5 Chapter 1 Security Overview Salesforce.com is built with security as the foundation for the entire service. This foundation includes both protection for your data and applications and the ability to implement your own security scheme to reflect the structure and needs of your organization. The security features of Salesforce.com provide both strength and flexibility. However, protecting your data is a joint responsibility between you and salesforce.com. The security features in Salesforce.com enable you to empower your users to do their jobs efficiently, while also limiting exposure of data to the users that need to act upon it. You should implement the security controls that you think are appropriate for the sensitivity of your data. Your data is protected from unauthorized access from outside your company, and you should also safeguard it from inappropriate usage by your users. See the following topics to get more information about the various security components in Salesforce.com: Security Infrastructure on page 3 Trust and Salesforce.com on page 4 User Security on page 5 User Authentication on page 5 Network-based Security on page 5 CAPTCHA Security for Data Exports on page 6 Session Security on page 6 Securing Data Access on page 6 Key Profile Permissions on page 8 Auditing on page 9 Portal Health Check Overview in the Salesforce.com online help Security Infrastructure 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. Salesforce.com protects your organization's data from all other customer organizations by using a unique organization identifier, which is associated with each user's session. Once you log in to your organization, your subsequent requests are associated with your organization, using this identifier. Salesforce.com utilizes some of the most advanced technology for Internet security available today. When you access the application using a Salesforce.com-supported browser, Secure Socket Layer (SSL) technology protects your information using both server authentication and data encryption, ensuring that your data is safe, secure, and available only to registered users in your organization. For more information about supported browsers, see Getting Started FAQ in the Salesforce.com online help. 3

6 Security Overview Trust and Salesforce.com In addition, Salesforce.com is hosted in a secure server environment that uses a firewall and other advanced technology to prevent interference or access from outside intruders. Trust and Salesforce.com Trust starts with transparency and that is why salesforce.com displays real-time information on system performance and security on the trust site at On this site, you can find live data on system performance, current and recent phishing and malware attempts, and tips on best security practices for your organization. The Security tab on the trust site includes valuable information that can help you to safeguard your company's data. In particular, phishing and malware are Internet scams on the rise. Phishing is a social engineering technique that attempts to acquire sensitive information such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication. Phishers often direct users to enter details at a fake website whose URL and look-and-feel are almost identical to the legitimate one. As the salesforce.com community grows, it has become an increasingly appealing target for phishers. You will never get an or a phone call from a salesforce.com employee asking you to reveal a password, so you should refuse to reveal it to anyone. You can report any suspicious activities by clicking the Report a Suspicious link under the Trust tab at Malware is software designed to infiltrate or damage a computer system without the owner's informed consent. It is a general term used to cover a variety of forms of hostile, intrusive, or annoying software, and it includes computer viruses and spyware. What Salesforce.com Is Doing Customer security is the foundation of customer success, so salesforce.com will continue to implement the best possible practices and technologies in this area. Recent and ongoing actions include: Actively monitoring and analyzing logs to enable proactive alerts to customers who have been affected. Collaborating with leading security vendors and experts on specific threats. Executing swift strategies to remove or disable fraudulent sites (often within an hour of detection). Reinforcing security education and tightening access policies within salesforce.com. Evaluating and developing new technologies both for our customers and for deployment within our infrastructure. What Salesforce.com Recommends You Do Salesforce.com is committed to setting the standards in software-as-a-service as an effective partner in customer security. So, in addition to internal efforts, salesforce.com strongly recommends that customers implement the following changes to enhance security: Modify your Salesforce.com implementation to activate IP range restrictions. This will allow users to access Salesforce.com only from your corporate network or VPN, thus providing a second factor of authentication. For more information, see Setting Session Security on page 37 and Restricting Login IP Ranges for Your Organization on page 35. Educate your employees not to open suspect s and to be vigilant in guarding against phishing attempts. Use security solutions from leading vendors such as Symantec to deploy spam filtering and malware protection. Designate a security contact within your organization so that salesforce.com can more effectively communicate with you. Contact your salesforce.com representative with this information. Consider using two-factor authentication techniques, such as RSA tokens, to restrict access to your network. Salesforce.com has a Security Incident Response Team to respond to any security issues. To report a security incident with Salesforce.com, contact [email protected]. Describe the incident in detail, and the team will respond promptly. 4

7 Security Overview User Security User Security Salesforce.com provides each user in your organization with a unique username and password that must be entered each time a user logs in. Salesforce.com issues a session cookie only to record encrypted authentication information for the duration of a specific session. The session cookie does not include either the username or password of the user. Salesforce.com does not use cookies to store other confidential user and session information, but instead implements more advanced security methods based on dynamic data and encoded session IDs. There are several settings you can configure to ensure that your users' passwords are strong and secure. If needed, you can force the expiration of passwords for all users. See Setting Password Policies on page 32 and Expiring Passwords on page 33. User Authentication Salesforce.com has its own system of user authentication, but some companies prefer to use an existing single sign-on capability to simplify and standardize their user authentication. You have two options to implement single sign-on federated authentication using Security Assertion Markup Language (SAML) or delegated authentication. Federated authentication using Security Assertion Markup Language (SAML) allows you to send authentication and authorization data between affiliated but unrelated Web services. This enables you to sign-on to Salesforce.com from a client application. Federated authentication using SAML is enabled by default for your organization. Delegated authentication single sign-on enables you to integrate Salesforce.com with an authentication method that you choose. This enables you to integrate authentication with your LDAP (Lightweight Directory Access Protocol) server, or perform single sign-on by authenticating using a token instead of a password. You manage delegated authentication at the profile level, allowing some users to use delegated authentication, while other users continue to use their Salesforce.com-managed password. Delegated authentication is set by profile, not organization wide. You must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated authentication single sign-on for your organization. The primary reasons for using delegated authentication include: - Using a stronger type of user authentication, such as integration with a secure identity provider - Making your login page private and not part of the general Internet, but rather, part of your corporate network, behind your corporate firewall - Differentiating your organization from all other organizations that use Salesforce.com in order to reduce phishing attacks For more information, see About Single Sign-On in the Salesforce.com online help. Network-based Security User authentication determines who can log in, while network-based security limits where they can log in from and when. Use network-based security to limit the window of opportunity for an attacker by restricting the origin of user logins. Network-based security can also make it more difficult for an attacker to use stolen credentials. To enhance network-based security, Salesforce.com includes the ability to restrict the hours during which users can log in and the range of IP addresses from which they can log in. If IP address restrictions are defined for a user's profile and a login originates from an unknown IP address, Salesforce.com does not allow the login. This helps to protect your data from unauthorized access and phishing attacks. 5

8 Security Overview CAPTCHA Security for Data Exports To set the organization-wide list of trusted IP addresses from which users can always log in without a login challenge, see Restricting Login IP Ranges for Your Organization on page 35. To restrict login hours by profile, see Restricting Login Hours on page 36. To restrict logins by IP addresses for specific profiles, see Restricting Login IP Ranges on Profiles on page 36. CAPTCHA Security for Data Exports By request, salesforce.com can also require users to pass a user verification test to export data from Salesforce.com. This simple, text-entry test helps prevent malicious programs from accessing your organization's data, as well as reducing the risk of automated attacks. CAPTCHA is a type of network-based security. To pass the test, users must type two words displayed on an overlay into the overlay's text box field, and click a Submit button. Salesforce.com uses CAPTCHA technology provided by recaptcha to verify that a person, as opposed to an automated program, has correctly entered the text into the overlay. CAPTCHA stands for Completely Automated Public Turing Test To Tell Computers and Humans Apart. Session Security After logging in, a user establishes a session with the platform. Use session security to limit exposure to your network when a user leaves their computer unattended while still logged on. It also limits the risk of internal attacks, such as when one employee tries to use another employee's session. You can control the session expiration time window for user logins. Session expiration allows you to select a timeout for user sessions. The default session timeout is two hours of inactivity. When the session timeout is reached, users are prompted with a dialog that allows them to log out or continue working. If they do not respond to this prompt, they are automatically logged out. Note: When a user closes a browser window or tab they are not automatically logged off from their Salesforce.com session. Please ensure that your users are aware of this, and that they end all sessions properly by clicking Logout. By default, Salesforce.com uses SSL (secure sockets layer) and requires secure connections (HTTPS) for all communication. It is not required. The Require secure connections (HTTPS) setting determines whether SSL (HTTPS) is required for all access to Salesforce.com. If you disable this setting and you change the URL from to you can still access the application. However, you should require all sessions to use SSL for added security. For more information, see Setting Session Security on page 37. Securing Data Access Choosing the data set that each user or group of users can see is one of the key decisions that affects data security. You need to find a balance between limiting access to data, thereby limiting risk of stolen or misused data, versus the convenience of data access for your users. To enable users to do their job without exposing data that they do not need to see, Salesforce.com provides a flexible, layered sharing design that allows you to expose different data sets to different sets of users. To specify the objects and tabs that a user can access, you can assign a profile. To specify the fields that a user can access, you can use field-level security. To specify the individual records that a user can view and edit, you can set your organization-wide defaults, define a role hierarchy, and create sharing rules. 6

9 Security Overview Securing Data Access Tip: When implementing security and sharing rules for your organization, make a table of the various types of users in your organization. In the table, specify the level of access to data that each type of user needs for each object and for fields and records within the object. You can refer to this table as you set up your security model. The following describes these security and sharing settings: Object-Level Security (Profiles) Object-level security provides the bluntest way to control data in Salesforce.com. Using object-level security you can prevent a user from seeing, creating, editing, or deleting any instance of a particular type of object, such as a lead or opportunity. Object-level security allows you to hide whole tabs and objects from particular users, so that they do not even know that type of data exists. You specify object-level security settings on profiles. A profile is a collection of settings and permissions that determine what a user can do in the application, similar to a group in a Windows network, where all of the members of the group have the same folder permissions and access to the same software. Profiles are typically defined by a user's job function (for example, system administrator or sales representative), but you can have profiles for anything that makes sense for your organization. A profile can be assigned to many users, but a user can be assigned to only one profile at a time. It is worth spending the necessary time up-front to align your various user sets with profiles, depending on what they need to see and do in the application. Field-Level Security Once you have restricted access to objects as a whole with profiles, you may want to limit access to individual object fields. Field-level security controls whether a user can see, edit, and delete the value for a particular field on an object. It allows you to protect sensitive fields without having to hide the whole object from certain profiles. Field-level security is controlled within profiles. Unlike page layouts, which only control the visibility of fields on detail and edit pages, field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results. To be absolutely sure that a user cannot access a particular field, it is important to use the field-level security page for a given object to restrict access to the field. There are no other shortcuts that provide the same level of protection for an individual field. Important: Field-level security does not prevent searching on the values in a field. If you do not want users to be able to search and retrieve records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support for assistance with setting up your organization to prevent unwanted access to those field values. Record-Level Security (Sharing) After setting object- and field-level access permissions for your various profiles, you need to configure the access permissions for the actual records themselves. Record-level security allows you to grant users access to some object records, but not others. To specify record-level security, set your organization-wide defaults, define a role hierarchy, and create sharing rules: The first step in record-level security is to determine the organization-wide defaults for each object. Organization-wide defaults specify the default level of access to records and can be set separately for accounts (including assets and contracts), activities, contacts, campaigns, cases, leads, opportunities, calendars, price books, and custom objects. For most objects, organization-wide defaults can be set to Private, Public Read Only, or Public Read/Write. You use organization-wide defaults to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools (role hierarchies, sharing rules, and manual sharing) to open up the data to other users who need to access it. For example, for users whose profiles allow them to see and view opportunities, you can set the default to Read-Only. Those users are able to read all opportunity records, but cannot edit any unless they own the record or are granted additional permissions. The first way you can share access to records is by defining a role hierarchy. Similar to an organization chart, a hierarchy represents a level of data access that a user or group of users needs.the role hierarchy ensures that a manager 7

10 Security Overview Key Profile Permissions always has access to the same data as his or her employees, regardless of the organization-wide default settings. Role hierarchies do not have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs. You can also use a territory hierarchy to share access to records. A territory hierarchy grants users access to records based on criteria such as zip code, industry, revenue, or a custom field that is relevant to your business. For example, you could create a territory hierarchy in which a user with the North America role has access to different data than users with the Canada and United States roles. Note: Although it is easy to confuse profiles with roles, they control two very different things. Profiles control a user's object- and field-level access permissions. Roles primarily control a user's record-level access permissions through role hierarchy and sharing rules. Sharing rules let you make automatic exceptions to organization-wide defaults for particular sets of users to give them access to records they do not own or cannot normally see. Sharing rules, like role hierarchies, are only used to open up record access to more users, and can never be stricter than your organization-wide default settings. Sharing rules work best when they are defined for a particular set of users that you can determine or predict in advance, rather than a set of users that is frequently changing. A set of users can be a public or personal group, a role, a territory, or a queue. Sometimes it is impossible to define a consistent group of users who need access to a particular set of records. In those situations, record owners can use manual sharing to give read and edit permissions to users who would not have access to the record any other way. Although manual sharing is not automated like organization-wide defaults, role hierarchies, or sharing rules, it gives record owners the flexibility to share particular records with users that need to see them. If sharing rules and manual sharing do not give you the control you need, you can also use Apex managed sharing. Apex managed sharing allows developers to use Apex to programmatically share custom objects. When you use Apex managed sharing to share a custom object, only users with the Modify All Data permission can add or change the sharing on the custom object's record, and the sharing access is maintained across record owner changes. Key Profile Permissions Profiles contain administrative permissions and general user permissions, which in turn control what actions a user can take. There are several permissions that are particularly powerful, and deserve special discussion. Caution: Permissions are very powerful. They greatly expand access to data. Exercise caution when deciding to enable these permissions for a profile. Manage Users A user with this permission can grant any other permission to themselves and other users. This permission makes a user a super administrator. Customize Application This permission grants a broad range of permissions that allow a user to control all aspects of an application from creating, editing, and deleting custom fields, to implementing workflow rules. Application developers need this permission, but you should be aware of the range of operations this permission grants. 8

11 Security Overview Auditing Modify All Data This permission overrides any restrictions on modifying data in all objects. It also circumvents the entire system of record-based sharing. If you only need to give users the ability to modify all data for a particular object, you can assign the object-level permission Modify All. View All Data This permission overrides any restrictions on viewing data in all objects. It also circumvents the entire system of record-based sharing. If you only need to give users the ability to view all data for a particular object, you can assign the object-level permission View All. Edit Read Only Fields This permission allows users to edit fields marked as read-only by field-level security or by the page layout. View Encrypted Data This permission allows users to view data in encrypted fields as plain-text data. For more information about encrypted fields, see About Encrypted Custom Fields in the Salesforce.com online help. Auditing Auditing features do not secure your organization by themselves, but these features provide information about usage of the system, which can be critical in diagnosing potential or real security issues. It is important that someone in your organization perform regular audits to detect potential abuse. The other security features provided by Salesforce.com are preventative. To verify that your system is actually secure, you should perform audits to monitor for unexpected changes or usage trends. Auditing features include: Record Modification Fields All objects include fields to store the name of the user who created the record and who last modified the record. This provides some basic auditing information. Login History You can review a list of successful and failed login attempts to your organization for the past six months. See Monitoring Logins on page 42. Field History Tracking You can also enable auditing for individual fields, which will automatically track any changes in the values of selected fields. Although auditing is available for all custom objects, only some standard objects allow field-level auditing. See Tracking Field History on page 43. Setup Audit Trail s can also view a Setup Audit Trail, which logs when modifications are made to your organization's configuration. See Monitoring Setup Changes on page 46. 9

12 Chapter 2 Securing and Sharing Data Review the following sections for detailed instructions and tips on securing access to your data in Salesforce.com. Managing Profiles User Permissions Needed To create, edit, or delete profiles: Manage Users A profile contains the user permissions that control different functions within Salesforce.com, the partner portal, and the Customer Portal. Profiles also control: Which standard and custom apps the user can view (depending on user license) Which tabs the user can view (depending on user license and other factors, such as access to Salesforce CRM Content) Which permissions a user is granted to create, read, edit, and delete records for each object Which page layouts the user sees Which console layouts the user sees The field-level security access that the user has to view and edit specific fields Which record types are available to the user The hours during which and IP addresses from which the user can log in Which desktop clients users can access and related options Note: This functionality is not available in Developer Edition. Whether the user can edit Apex Which users can execute methods in a particular top-level Apex class (see Setting Apex Class Security in the Salesforce.com online help) The public access settings for Force.com Sites users To create, edit, and delete profiles, click Setup Manage Users Profiles. There are standard profiles in every Salesforce.com organization. In Contact Manager, Group, and Professional Edition organizations, you can assign the standard profiles to your users. However, you cannot view or edit the standard profiles or create custom profiles. In Enterprise, Unlimited, and Developer Edition organizations, you can use the standard profiles or create, edit, and delete custom profiles. For the standard profiles, only certain settings can be changed. Each standard or custom profile belongs to exactly one user license type. 10

13 Securing and Sharing Data User Permissions on Profiles User Permissions on Profiles User Permissions Needed To create, edit, or delete profiles: To view profiles: Manage Users View Setup and Configuration User permissions are divided into the following: Administrative Permissions General Permissions Standard and Custom Object Permissions Desktop Integration Client Permissions Apex Class Permissions Administrative Permissions The following table shows the administrative permissions associated with each standard profile. Administrative Permissions Permission Name Affected by Divisions API Enabled Functions Controlled Filter a user s search results, list views, and reports by division. With this permission deselected, a user s searches, list views, and reports always show records in all divisions. Enterprise, Unlimited, and Developer Edition organizations can edit this user permission on standard and custom profiles Grants access to the API, Bulk API, and Metadata API Profiles Standard User Solution Manager Marketing User Contract Manager API Only User Author Apex Customize Application Prevents access to Salesforce.com except via the API or Bulk API Can modify and deploy Apex classes and triggers, set security on Apex classes, and create services Edit messages and custom links; Modify standard picklist values; Create, edit, and delete custom fields; Create, edit, and delete page layouts (also requires the Edit permission for the record, for example, Edit on accounts); None 11

14 Securing and Sharing Data User Permissions on Profiles Permission Name Administrative Permissions Functions Controlled Set field-level security; Create, edit, and delete custom links; Edit the Lead Settings; Activate big deal alerts; Create record types; Set up Web-to-Case and response rules; Set up Web-to-Lead and response rules; Set up assignment and escalation rules; Set up business hours; Set up -to-Case or On-Demand -to-Case; Edit Self-Service page layouts and portal color theme (also requires the Manage Self-Service Portal permission to set up and maintain Self-Service settings and delete your organization's Self-Closed Case Status value); Set up and enable multilingual solutions; Set up team selling; Set up account teams; Map custom lead fields; Manage queues; Create, edit, and delete workflow rules, tasks, field updates, outbound messages, and alerts; Create, edit, and delete custom s-controls, custom objects, and custom tabs; Rename tabs; Manage custom apps; Create and edit public calendars and resources; Set up the console; Enable, set up, and modify the Salesforce.com Customer Portal; Profiles 12

15 Securing and Sharing Data User Permissions on Profiles Permission Name Administrative Permissions Functions Controlled Set up and schedule analytic snapshots to run; Create communities for ideas and answers; Create Visualforce templates Profiles Delegated Portal User Edit HTML Templates Edit Read Only Fields Manage Analytic Snapshots Manage Billing Allows Customer Portal and Partner None Portal users to create, edit, deactivate, and reset passwords for other portal users (also requires Portal Super User to create and view cases for Customer Portal users) Create, edit, and delete both custom HTML templates and HTML templates using letterheads Edit fields marked as read-only (by field-level security or by the page layout) for all other users Set up and schedule analytic snapshots to run (also requires the Schedule Dashboards, Run Reports, and View Setup and Configuration permissions) Add user licenses; Edit billing and credit card information Marketing User Manage Business Hours Holidays Manage Call Centers 'Manage Categories Manage Custom Report Types Create and edit business hours; create, edit, and delete holidays (also requires View Setup and Configuration ) Import, view, edit, and delete a call center (also requires View Setup and Configuration ) Define and modify solution categories; Edit Solution Settings to enable solution browsing This permission only applies to solution categories, not data categories Create, edit, and delete custom report types (also requires View Setup and Configuration to view the organization Setup pages where custom report types are managed) 13

16 Securing and Sharing Data User Permissions on Profiles Permission Name Manage Dashboards Manage Data Categories Manage Data Integrations Administrative Permissions Functions Controlled Create, edit, and delete dashboards (also requires Modify All Data to edit a dashboard created by another user) Create, edit, and delete data categories This permission only applies to data categories, not solution categories Monitor Bulk API jobs Profiles Manage Client Configurations Manage Letterheads Create, edit, and delete Outlook configurations for Salesforce CRM for Outlook. Salesforce CRM for Outlook is available through a pilot program. For information on enabling Salesforce CRM for Outlook for your organization, contact salesforce.com. Create, edit, and delete letterheads for HTML s Marketing User Manage Mobile Configurations Manage Package Licenses Manage Partners Manage Public Documents Manage Public List Views Edit the Mobile User checkbox on a user's personal information. Enabling the Mobile User checkbox allocates one Salesforce Mobile license to the user, granting the user access to Salesforce Mobile capabilities. Grant or revoke user licenses for an installed app in a managed package Create partner accounts and partner users; Disable partner accounts and partner users; Merge partner users (also requires Delete on contacts) Create, update, and delete public document folders Create, edit, and delete public list views Marketing User 14

17 Securing and Sharing Data User Permissions on Profiles Permission Name Manage Public Reports Manage Public Templates Manage Synonyms Manage Salesforce CRM Content Manage Salesforce Knowledge Manage Translation Manage Users Administrative Permissions Functions Controlled Create, edit, and delete public reports; Customize the Reports tab Create, edit, and delete text and mail merge templates; Edit public folders for templates and store templates in folders Create, edit, and delete synonym groups Create, edit, and delete workspaces; Edit workspace membership Enable Salesforce Knowledge Create, edit, and delete article types Edit settings Add supported languages and translators; Enter translated values for any supported language; Translate solution categories Create, edit, and deactivate users; Define and assign user roles; Define sharing model and sharing rules; View storage use; View login history; View training history; Manage and assign profiles; Assign page layouts to profiles; Set password policies; Activate or deactivate opportunity update reminders; Set login restrictions Profiles Marketing User Modify All Data Create, edit, and delete all data; Import accounts and contacts for organization; Mass update addresses (also requires Activate Contract and Activate Order 15

18 Securing and Sharing Data User Permissions on Profiles Permission Name Password Never Expires Portal Super User Schedule Dashboards Schedule Reports Send Outbound Messages Tag Manager Transfer Record Administrative Permissions Functions Controlled to update the addresses of contracts and orders); Mass delete data; Undelete other users data; Create and edit divisions, and transfer divisions for multiple records Create an organization-wide address Prevent password from ever expiring Allows Customer Portal users to view and edit all cases for their account Schedule when dashboards refresh and send notifications to users that include refreshed dashboards in HTML format Schedule reports to run and have the results automatically ed in HTML format to Salesforce.com users Allows you to send outbound messages, such as when you close an opportunity and need to send an outbound API message to another server to generate an order. See Setting Up Outbound Messaging in the Force.com Web Services API Developer's Guide. Rename, delete, or restore public tags (available only when public tags are enabled) Transfer ownership of one or more accounts, campaigns, cases, contacts, contracts, leads, and custom objects that are owned by another user. To transfer records owned by another user, you must also have at least the Edit object permission and access to view the records. Profiles None None Standard User Solution Manager Marketing User Read Only Contract Manager Standard Platform User Standard Platform One App User 16

19 Securing and Sharing Data User Permissions on Profiles Permission Name Use Team Reassignment Wizards View All Data View Data Categories View Encrypted Data View Setup and Configuration Weekly Data Export Administrative Permissions Functions Controlled Mass reassign account team and opportunity team members View all data owned by other users View the Setup Customize Data Categories page This permission only applies to data categories, not solution categories View the value of encrypted fields in plain text View the organization setup details on the Setup pages; Run user reports; View the setup audit trail; Check field accessibility for users Run the weekly data export service Profiles None Standard User Solution Manager Marketing User Read Only Contract Manager General Permissions The following table shows the general permissions associated with each standard profile. General User Permissions Permission Name Activate Contracts Approve Contracts Convert Leads Functions Controlled Change contract status to Activate; Create, edit and delete contracts Apply an approved status to a contract Convert leads into accounts, contacts, and opportunities Profiles Contract Manager Contract Manager Standard User 17

20 Securing and Sharing Data User Permissions on Profiles Permission Name Create and Customize Reports Create AppExchange Packages Create Workspaces Delete Activated Contracts General User Permissions Functions Controlled View the Reports tab; Run, create, edit, save, and delete reports; View dashboards based on reports Create AppExchange packages Create Salesforce CRM Content workspaces Delete contracts regardless of status; Activate, create, and edit contracts Profiles Solution Manager Marketing User Contract Manager Standard User Solution Manager Marketing User Read Only Contract Manager Deliver Uploaded Files and Personal Content Enables non-content users to create content deliveries and enablessalesforce CRM Content users to create content deliveries using documents in their Standard User personal workspaces. Note that Salesforce Solution Manager CRM Content users do not need this perm to create content deliveries in Marketing User shared workspaces. Read Only Contract Manager Download AppExchange Packages Install or uninstall AppExchange packages from the AppExchange Edit Case Comments Edit Events Enables users to edit and delete case comments that they have added to cases (also requires Edit on cases) Create, edit, and delete events None Standard User Solution Manager Marketing User 18

21 Securing and Sharing Data User Permissions on Profiles Permission Name General User Permissions Functions Controlled Profiles Contract Manager Edit Forecasts Create, edit, and delete forecasts. This permission is not available for customizable forecasts. When you convert to customizable forecasts, custom Standard User profiles that have the Edit Forecasts Solution Manager permission get the Edit Personal Quota and Override Forecasts permissions. Marketing User Contract Manager Edit Opportunity Product Sales Prices Edit Personal Quota Enable users to change the sales price on products Change your individual quota (available only for customizable forecasts) Standard User Solution Manager Marketing User Contract Manager Standard User Solution Manager Marketing User Contract Manager Edit Self-Service Users For the Self-Service portal: enable and deactivate contacts; For the Salesforce.com Customer Portal: Standard User enable, disable, and deactivate contacts; disable accounts; merge Customer Portal Solution Manager users (also requires Delete on contacts) Marketing User Edit Tasks Create, edit, and delete tasks Contract Manager Standard User Solution Manager Marketing User Contract Manager 19

22 Securing and Sharing Data User Permissions on Profiles Permission Name Export Reports Import Leads Import Personal Contacts Import Solutions Manage Articles Manage Cases General User Permissions Functions Controlled Use Export Details and Printable View to export reports Import leads and update campaign history using import wizards Import personal accounts and contacts Import solutions for the organization Create, edit, assign, publish, delete, and archive Salesforce Knowledge articles This permission provides full access to the Article Management tab Modify support settings Close multiple cases Profiles Standard User Solution Manager Marketing User Contract Manager Marketing User Standard User Solution Manager Marketing User Contract Manager Solution Manager None Manage Content Permissions Create, edit, and delete workspace permissions in Salesforce CRM Content Manage Content Properties Manage Content Types Create, edit, and delete custom fields in Salesforce CRM Content Create, edit, and delete content types in Salesforce CRM Content 20

23 Securing and Sharing Data User Permissions on Profiles General User Permissions Permission Name Manage Entitlements Functions Controlled Set up and maintain entitlement management; Enable and disable entitlement management, including entitlements, service contracts, and contract line items; Create, edit, and delete entitlement templates; Create, edit, and delete milestones; Create, edit, and delete entitlement processes Profiles Manage Leads Manage Published Solutions Manage Self-Service Portal Manage Territories Mass Change Status of multiple leads in a list view Create, edit, and delete solutions that are accessible to the public on your Self-Service portal or website; Categorize solutions Set up and maintain Self-Service settings (also requires the Customize Application permission to modify Self-Service page layouts and delete your organization's Self-Closed Case Status value); Run Self-Service reports Create and edit territories; Add and remove users from territories; Create and edit account assignment rules; Manually assign accounts to territories; Configure organization-wide territory management settings Send bulk s to contacts and leads Solution Manager Standard User Solution Manager Marketing User Contract Manager 21

24 Securing and Sharing Data User Permissions on Profiles Permission Name Mass Edit from Lists Override Forecasts Products Show in Offline Run Reports Send General User Permissions Functions Controlled Allow users to edit two or more records simultaneously from a list with inline editing Override your own forecast, as well as forecasts for users that report directly to you in the role hierarchy (available only for customizable forecasts) Specify if products and price books are available in Connect Offline View the Reports tab; Run reports; View dashboards based on reports Send to a single contact or lead; Send Stay-in-Touch update s Profiles Standard User Solution Manager Marketing User Contract Manager, Standard Platform User Standard Platform One App User Standard User Solution Manager Marketing User Contract Manager Standard User Solution Manager Marketing User Read Only Contract Manager Standard User Solution Manager Marketing User Read Only Contract Manager Standard User Solution Manager Marketing User 22

25 Securing and Sharing Data User Permissions on Profiles Permission Name Send Stay-in-Touch Requests General User Permissions Functions Controlled Send Stay-in-Touch requests Profiles Contract Manager Standard User Solution Manager Marketing User Contract Manager Show Custom Sidebar On All Pages Transfer Cases Transfer Leads Upload AppExchange Packages If you have custom home page layouts None that include components in the sidebar, displays your custom sidebar on all pages in Salesforce.com. If the Show Custom Sidebar Components on All Pages user interface setting is selected, the Show Customer Sidebar On All Pages permission is not available. Transfer one or more cases that are owned by another user, if you also have at least the Edit object permission and access to view the records Transfer one or more leads that are owned by another user, if you also have at least the Edit object permission and access to view the records Upload AppExchange packages to AppExchange; Create test drives Uses Single Sign-On View All Forecasts Username and password authentication is delegated to a corporate database such as Active Directory or LDAP, instead of the Salesforce.com user database. See About Single Sign-On in the Salesforce.com online help. View any user s forecast regardless of the forecast role hierarchy. This permission is only available for customizable forecasts. When you convert to customizable forecasts, custom profiles that have the View All Data permission get the View All Forecasts permissions. None 23

26 Securing and Sharing Data User Permissions on Profiles Permission Name View Articles View Content in Portals General User Permissions Functions Controlled Read articles in Salesforce Knowledge This permission provides full access to the Articles tab Allows Customer Portal and Partner Portal users to view Salesforce CRM Content Profiles Standard User Solution Manager Marketing User Contract Manager None Standard and Custom Object Permissions The following permissions specify the access that users have to standard and custom objects. These permissions either respect the sharing model, or override sharing: Object-Level Permissions that Respect Sharing Read users can only view records of this type Create users can read and create records Edit users can read and update records Delete users can read, edit, and delete records Object-Level Permissions that Override Sharing for Delegated Data Administration View All users can view all records associated with this object, regardless of sharing settings Modify All users can read, edit, delete, transfer, and approve all records associated with this object, regardless of sharing settings Modify All on documents allows access to all shared and public folders, but not the ability to edit folder properties or create new folders. To edit folder properties and create new folders, users must have the Manage Public Documents permission. View All and Modify All are not available for ideas, price books, and products. The View All and Modify All permissions ignore sharing rules and settings, allowing administrators to quickly grant access to records associated with a given object across the organization. View All and Modify All are for delegated administrators who are responsible for managing the records belonging to a given object, while the global permissions View All Data and Modify All Data are for the administrator of your entire organization. Tasks where these permissions may be applicable include data cleansing, deduplication, mass deletion, mass transferring, and managing record approvals. If providing the View All Data or Modify All Data administrative permission is too permissive for a particular profile, consider using the View All or Modify All object-level permission to restrict data access and management on an object basis. See Comparing Security Models in the Salesforce.com online help. Note: The View All and Modify All permissions allow for delegation of object permissions only. To delegate some user administration and custom object administration duties, you can define delegated administrators. 24

27 Securing and Sharing Data Setting Field-Level Security If your organization has deployed Salesforce Mobile, you can edit the mobile object properties to prevent mobile users from creating, editing, and deleting records in the mobile application, regardless of their standard object permissions in Salesforce.com. Desktop Integration Client Permissions Connect for Outlook, Connect Offline, Connect for Office, and Connect for Lotus Notes are desktop clients that integrate Salesforce.com with your PC. As an administrator, you can control which desktop clients your users can access as well as whether users are automatically notified when updates are available. See Setting User Permissions for Desktop Clients in the Salesforce.com online help. Apex Class Permissions In Unlimited, Enterprise, and Developer Edition organizations, users can use profiles to control which users can execute methods in a particular top-level Apex class. Setting Field-Level Security User Permissions Needed To set field-level security: Customize Application You can define which fields users can access. Field-level security settings let administrators restrict users access to view and edit specific fields on detail and edit pages and in related lists, list views, reports, Connect Offline, search results, and mail merge templates, custom links, the PRM portal, the Salesforce.com Customer Portal, and when synchronizing data or importing personal data. The fields that users see on detail and edit pages are a combination of page layouts and field-level security settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read only in the field-level security settings, the field-level security overrides the page layout and the field will be read only for the user. Important: Field-level security does not prevent searching on the values in a field. If you do not want users to be able to search and retrieve records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support for assistance with setting up your organization to prevent unwanted access to those field values. You can define field-level security from a profile or from a particular field. To define field-level security: 1. Do one of the following: To set field-level security for all fields on a particular profile: a. Select Setup Manage Users Profiles. b. Select a profile to change the field access for users with that profile. c. In the Field-Level Security section, click View next to the tab you want to modify, and then click Edit. To set field-level security for a particular field on all profiles: a. Select Setup Customize, click a tab or activity link, and click Fields. b. Select the field you want to modify. c. Click Set Field-Level Security. 25

28 Securing and Sharing Data Setting Your Organization-Wide Default Sharing Model 2. Specify whether the fields should be visible, hidden, read only, or editable (visible without read only) for users based on their profile. Note that these field access settings apply throughout Salesforce.com. The settings also override any less-restrictive field access settings on the page layouts or article-type layouts. 3. Click Save. After setting field-level security for users based on their profiles, you can: Create page layouts to organize the fields on detail and edit pages; see Managing Page Layouts in the Salesforce.com online help. Tip: Use field-level security as the means to restrict users access to fields; then use page layouts primarily to organize detail and edit pages within tabs. This reduces the number of page layouts for you to maintain. Verify users access to fields by checking the field accessibility grid; see Checking Field Accessibility in the Salesforce.com online help. Set the fields that display in search results, in lookup dialog search results, and in the key lists on tab home pages; see Customizing Search Layouts in the Salesforce.com online help. Note: Roll-up summary and formula fields are always read only on detail pages and not available on edit pages. They may also be visible to users even though they reference fields that your users cannot see. Universally required fields always display on edit pages regardless of field-level security. The relationship group wizard allows you to create and edit relationship groups regardless of field-level security. For more information on the behaviors of relationship group members, see Relationship Group Considerations in the Salesforce.com online help. Setting Your Organization-Wide Default Sharing Model User Permissions Needed To set default sharing access: Manage Users AND Customize Application An administrator can define the default sharing model for your organization by setting organization-wide defaults. Organization-wide defaults specify the default level of access to records and can be set separately for accounts (including assets and contracts), activities, contacts, campaigns, cases, leads, opportunities, calendars, price books, and custom objects. For most objects, organization-wide defaults can be set to Private, Public Read Only, or Public Read/Write. See Sharing Model Fields in the Salesforce.com online help for the various options. Tip: Developers can use Apex to programmatically share custom objects. For more information, see Apex Managed Sharing in the Salesforce.com online help and the Force.com Apex Code Developer's Guide. By default, Salesforce.com uses hierarchies, like the role or territory hierarchy, to automatically grant access of records to users above the record owner in the hierarchy. Professional, Enterprise, Unlimited, and Developer Edition organizations can disable this for custom objects using the Grant Access Using Hierarchies checkbox next to the organization-wide defaults setting. 26

29 Securing and Sharing Data Setting Your Organization-Wide Default Sharing Model If you deselect this checkbox next to a custom object, only the record owner and users granted access by the organization-wide defaults receive access to the records. Note: If the Grant Access Using Hierarchies checkbox is deselected, users that are higher in the role hierarchy do not receive any access based on role. Still, users can gain access to records they do not own through other means, such as the View All and Modify All object permissions, and the View All Data and Modify All Data permissions. In environments where the sharing model for an object is set to Private or Public Read Only, an administrator can grant users additional access to records by setting up a role hierarchy or defining sharing rules. However, sharing rules can only be used to grant additional access they cannot be used to restrict access to records beyond what was originally specified with the sharing model through organization-wide defaults. The default organization-wide settings are: Object Accounts Activities Assets Calendar Campaigns Cases Contacts Contracts Custom Objects Leads Opportunities Price Books Service Contracts Default Access Public Read/Write Private Public Read/Write Hide Details and Add Events Public Full Access Public Read/Write/Transfer Controlled by Parent Public Read/Write Public Read/Write Public Read/Write/Transfer Public Read Only Use Private Changing Organization-Wide Default Settings To change organization-wide settings for an object: 1. Click Setup Security Controls Sharing Settings. 2. Click Edit in the Organization-Wide Defaults area. Note: When a custom object is on the detail side of a master-detail relationship with a standard object, its organization-wide default is set to Controlled by Parent and it is not editable. To disable automatic access using your hierarchies, deselect Grant Access Using Hierarchies for any custom object that does not have a default access of Controlled by Parent. Important: Before you enable contacts to access the Salesforce.com Customer Portal for your organization, set the organization-wide defaults on accounts, contacts, contracts, assets, and cases to Private so that your customers can only view their own data. If you set the organization-wide defaults for these objects to Private, you can still grant your Salesforce.com users Public Read/Write access to them by creating sharing rules in which owners equal Internal Users 27

30 Securing and Sharing Data Managing Roles who share with Internal Users. For more information, see Setting Up Your Customer Portal in the Salesforce.com online help. Note: You can't change the organization-wide default setting for some objects: Solutions are always Public Read/Write. Service contracts are always Private. The ability to view or edit a document is based on a user's access to the folder in which the document is stored. There is no organization-wide default for customizable forecast sharing. Users can only view the forecasts of other users who are placed below them in the role hierarchy, unless forecast sharing has been enabled. For more information, see Manually Sharing a Forecast in the Salesforce.com online help. You can't change the organization-wide default settings from private to public for a custom object if an Apex script uses the sharing entries associated with that object. For example, if a script retrieves the users and groups who have sharing access on a custom object Invoice c (represented as Invoice share in the code), you can't change the organization-wide sharing default from private to public for this object. For more information, see Force.com Apex Code Overview in the Salesforce.com online help. Managing Roles User Permissions Needed To create, edit, and delete roles: To assign users to roles: Manage Users Manage Users Depending on your sharing settings, roles can control the level of visibility that users have into your organization s data. Users at any given role level can view, edit, and report on all data owned by or shared with users below them in the hierarchy, unless your organization s sharing model for an object specifies otherwise. Specifically, in the Organization-Wide Defaults related list, if the Grant Access Using Hierarchies option is disabled for a custom object, only the record owner and users granted access by the organization-wide defaults receive access to the object's records. Note: The following information applies to roles for your organization's users. For information about roles for partner users and Salesforce.com Customer Portal users, see About Partner Portal Channel Manager User Management in the Salesforce.com online help and Managing Customer Portal Users in the Salesforce.com online help. Working with Roles To view and manage your organization's roles, click Setup Manage Users Roles. Choose one of the following list view options: Show in tree view See a visual representation of the parent-child relationships between your roles. Click Expand All to see all roles, or Collapse All to see only top-level roles. To expand or collapse an individual node, click the plus (+) or minus (-) icon. Show in sorted list view See a list that you can sort alphabetically by role name, parent role (Reports to), or report display name. If your organization has a large number of roles, use this view for easy navigation and filtering. 28

31 Securing and Sharing Data About Sharing Rules To show a filtered list of items, select a predefined list from the View drop-down list, or click Create New View to define your own custom view. To edit or delete any view you created, select it from the View drop-down list and click Edit. Show in list view See a list of roles and their children, grouped alphabetically by the name of the top-level role. The columns are not sortable. This view is not available for hierarchies with more than 1,000 roles. To create a role, click New Role or Add Role, depending whether you are viewing the list view or tree view of roles, then edit the role fields as needed. You can create up to 500 roles for your organization. To edit a role, click Edit next to a role name, then update the role fields as needed. To delete a role, click Delete next to the role name. To assign other users to a role, click Assign next to the role name. To view detailed information about a role, click a role name. If you are a Salesforce Knowledge user, you can modify category visibility settings on the role detail page. Tip: To simplify user management in organizations with large numbers of users, enable delegated administrators to manage users in specified roles and all subordinate roles. Notes on Roles Every user must be assigned to a role, or their data will not display in opportunity reports, forecast roll-ups, and other displays based on roles. If your organization uses territory management, forecasts are based on the territory hierarchy rather than the role hierarchy. All users that require visibility to the entire organization should belong to the highest level in the hierarchy. It is not necessary to create individual roles for each title at your company, rather you want to define a hierarchy of roles to control access of information entered by users in lower level roles. When you change a user s role, any relevant sharing rules are evaluated to add or remove access as necessary. When an account owner is not assigned a role, the sharing access for related contacts is Read/Write, provided the organization-wide default for contacts is not Controlled by Parent. Sharing access on related opportunities and cases is No Access. Users that gain access to data due to their position in hierarchies do so based on a setting in your organization-wide defaults. About Sharing Rules Sharing rules allow you to make automatic exceptions to your organization-wide default for defined sets of users. For example, use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rules can never be stricter than your organization-wide default settings. They simply allow greater access for particular users. You can create the following types of sharing rules: Account Sharing Rules Based on who owns the account, set default sharing access for accounts and their associated cases, contracts, opportunities, and, optionally, contacts. Account Territory Sharing Rules Based on territory assignment, set default sharing access for accounts and their associated cases, contacts, contracts, and opportunities. See Territory Management Overview in the Salesforce.com online help. Campaign Sharing Rules Based on who owns the campaign, set default sharing access for individual campaign records. Case Sharing Rules Based on who owns the case, set default sharing access for individual cases and associated accounts. Contact Sharing Rules Based on who owns the contact, set default sharing access for individual contacts and associated accounts. 29

32 Securing and Sharing Data Granting Access to Records Custom Object Sharing Rules Based on who owns the custom object, set default sharing access for individual custom object records. Lead Sharing Rules Based on who owns the lead, set default sharing access for individual leads. Opportunity Sharing Rules Based on who owns the opportunity, set default sharing access for individual opportunities and their associated accounts. Granting Access to Records Users can manually grant access to certain types of records. In some cases, granting access includes access to all associated records. For example, if you grant another user access to your account, the user will automatically have access to all the opportunities and cases associated with that account. To grant sharing privileges for a record, you must be the record owner, any user granted Full Access, an administrator, or (provided your sharing settings control access through hierarchies) a user in a role above the owner in the hierarchy. Note: Users that gain access to data due to their position in hierarchies do so based on a setting in your organization-wide defaults. To grant access to a record: 1. Click Sharing on the record you want to share. 2. Click Add. 3. From the drop-down list, select the type of group, user, role, or territory to add. Your choices are: Type Public Groups Personal Groups Users Roles Roles and Subordinates Roles and Internal Subordinates Roles, Internal and Portal Subordinates Territories Description All public groups defined by your administrator. All personal groups defined by the record owner. Only the record owner can share with his or her personal groups. All users in your organization. Does not include portal users. All roles defined for your organization. This includes all of the users in that role. This includes all of the users in the role plus all of the users in roles below that role. Only available when no portals are enabled for your organization. All roles defined for your organization. This includes all of the users in the specified role plus all of the users in roles below that role, excluding PRM portal, partner portal, and Customer Portal roles. Adding a role and its subordinate roles, includes all of the users in that role plus all of the users in roles below that role. Only available when a partner or Customer Portal is enabled for your organization. Includes portal roles and users. All territories defined for your organization. This includes all users in that territory.this option is only available if your organization uses territory management. 30

33 Securing and Sharing Data Granting Access to Records Type Territories and Subordinates Description Includes all users in the territory plus the users below that territory. This option is only available if your organization uses territory management. 4. Choose the specific groups, users, roles, or territories who should have access by adding their names to the New Sharing list. 5. Choose the access level for the record you are sharing and any associated records that you own. For example, if you are sharing an account, specify the level of access the selected user should have to associated contact, opportunity, and case records you own. The possible access levels are: Access Level Full Access Read/Write Read Only Private Description User can view, edit, delete, and transfer the record. User can also extend sharing access to other users; however, the user cannot grant Full Access to other users. User can view and edit the record, and add associated records, notes, and attachments to it. User can view the record, and add associated records to it. They cannot edit the record or add notes or attachments. User cannot access the record in any way. Note: When sharing an opportunity or case, users must also have at least read access to the associated account (unless you are sharing a case via a case team). If you also have privileges to share the account, users are automatically given read access to the account. If you do not have privileges to share the account, you must ask the account owner to give the users read access to it. Contact Access is not available when the organization-wide default for contacts is set to Controlled by Parent. For sharing rules that specify access for associated object records, the given access level applies only to that sharing rule. For example, if an account sharing rule specifies Private as the access level for associated contacts, a user may still have access to associated contacts via other means, such as organization-wide defaults, the Modify All Data or View All Data administrative permission, or the Modify All or View All object permission. 6. When sharing a forecast, select Submit Allowed to enable the user, group, or role to submit the forecast. 7. Select the reason for the share to allow users and administrators to understand the source of the sharing. For more information on sharing reasons, see Creating Apex Sharing Reasons in the Salesforce.com online help. 8. Click Save. Editing or Deleting Record Access To edit the access levels for a record, click Sharing on the record, and then click Edit next to the group, user, role, or territory whose access you want to modify. To delete the sharing access for a group, user, role, or territory, click Sharing on the record, and then click Del next to the group, user, role, or territory whose access you want to remove. 31

34 Chapter 3 Configuring Salesforce.com Security Features Review the following sections for detailed instructions and tips on setting up and configuring Salesforce.com security features. Setting Password Policies User Permissions Needed To set password policies: Manage Users For your organization s security, you can set various password and login policies. 1. Click Setup Security Controls Password Policies. 2. Customize the password settings. Field User passwords expire in Enforce password history Minimum password length Password complexity requirement Password question requirement Description Length of time until all user passwords expire and must be changed. Users with the Password Never Expires permission are immune from this setting. The default is 90 days. Setting to save users previous passwords so that they must always reset their password to a new, unique password. Password history is not saved until you set this value. The default is 3 passwords remembered. You cannot select the No passwords remembered option unless you select the Never expires option for the User passwords expire in field. Minimum number of characters required for a password. When you set this value, existing users are not affected until the next time they change their passwords. The default is 8 characters. Restriction on which types of characters must be used in a user s password. Must mix alpha and numeric is the default option. This option requires at least one alphabetic character and one number. Setting to require that a user s answer to the password hint question not contain the password itself. 32

35 Configuring Salesforce.com Security Features Expiring Passwords Field Maximum invalid login attempts Lockout effective period Description Number of bad logins allowed by a user before he or she becomes locked out. Duration of the login lockout. Note: User passwords cannot exceed 16,000 bytes. 3. Click Save. Note: If a user becomes locked out, he or she can wait until the lockout period expires, or the administrator can view the user s information and click Unlock. This button is only available when a user is locked out. Expiring Passwords User Permissions Needed To expire all passwords: Manage Users To expire passwords for all users, except those with the Password Never Expires permission: 1. Click Setup Security Controls Expire All Passwords. 2. Select the Expire all user passwords checkbox. 3. Click Save. The next time each user logs in, he or she will be prompted to reset his or her password. Tips on Expiring Passwords Consider the following when expiring passwords: After you expire passwords, users may need to activate their computers to successfully log in to Salesforce.com. For more information, see Setting Login Restrictions on page 34. You can expire passwords for all users any time you want to enforce extra security for your organization. For more options you can set to ensure password security, see Setting Password Policies on page

36 Configuring Salesforce.com Security Features Setting Login Restrictions Setting Login Restrictions User Permissions Needed To set login restrictions: Manage Users To help protect your organization's data against unauthorized access, you can restrict users ability to log in to Salesforce.com by customizing user profiles and your organization's list of trusted IP addresses. Profile-Based Login Hours and IP Addresses For each profile, you can set the hours when users can log in and the IP addresses from which they can log in. Organization-Wide Trusted IP Address List For all users, you can set a list of IP address ranges from which they can always log in without receiving a login challenge. When users log in to Salesforce.com, either via the user interface, the API, or a desktop client such as Connect for Outlook, Salesforce CRM for Outlook, Connect Offline, Connect for Office, Connect for Lotus Notes, or the Data Loader, Salesforce.com confirms that the login is authorized as follows: 1. Salesforce.com checks whether the user's profile has login hour restrictions. If login hour restrictions are specified for the user's profile, any login outside the specified hours is denied. 2. Salesforce.com then checks whether the user's profile has IP address restrictions. If IP address restrictions are defined for the user's profile, any login from an undesignated IP address is denied, and any login from a specified IP address is allowed. 3. If profile-based IP address restrictions are not set, Salesforce.com checks whether the user is logging in from an IP address they have not used to access Salesforce.com before: If the user's login is from a browser that includes a Salesforce.com cookie, the login is allowed. The browser will have the Salesforce.com cookie if the user has previously used that browser to log in to Salesforce.com, and has not cleared the browser cookies. If the user's login is from an IP address in your organization's trusted IP address list, the login is allowed. If the user's login is from neither a trusted IP address nor a browser with a Salesforce.com cookie, the login is blocked. Whenever a login is blocked or returns an API login fault, Salesforce.com must verify the user's identity: For access via the user interface, the user is prompted to click a Send Activation Link button to send an activation to the address specified on the user's Salesforce.com record. The instructs the user to copy and paste an activation link into their browser to activate their computer for logging in to Salesforce.com. The activation link included in the is valid for up to 24 hours from the time the user clicked the Send Activation Link button. After 24 hours, the activation link expires, and users must repeat the activation process to log in. Note: The first time a user logs into Salesforce.com, they do not have to activate their computer. However, the next time a user logs in, they must activate their computer using the Send Activation Link button. For access via the API or a client, the user must add their security token to the end of their password in order to log in. A security token is an automatically-generated key from Salesforce.com. For example, if a user's password is mypassword, and their security token is XXXXXXXXXX, then the user must enter mypasswordxxxxxxxxxx to log in. Users can obtain their security token by changing their password or resetting their security token via the Salesforce.com user interface. When a user changes their password or resets their security token, Salesforce.com sends a new security token to the address on the user's Salesforce.com record. The security token is valid until a user resets their security token, changes their password, or has their password reset. 34

37 Configuring Salesforce.com Security Features Restricting Login IP Ranges for Your Organization Tip: It is recommended that you obtain your security token via the Salesforce.com user interface from a trusted network prior to attempting to access Salesforce.com from a new IP address. Tips on Setting Login Restrictions Consider the following when setting login restrictions: When a user's password is changed, the user's security token is automatically reset. The user may experience a blocked login until he or she adds the automatically-generated security token to the end of his or her password when logging in to Salesforce.com via the API or a client. Partner portal and Customer Portal users are not required to activate computers to log in. For more information on API login faults, see the Core Data Types Used in API Calls topic in the Force.com Web Services API Developer's Guide. If single sign-on is enabled for your organization, API and desktop client users cannot log in to Salesforce.com unless their IP address is included on your organization's list of trusted IP addresses or on their profile, if their profile has IP address restrictions set. Futhermore, the single sign-on authority usually handles login lockout policies for users with the Is Single Sign-On Enabled permission. However, if the security token is enabled for your organization, then your organization's login lockout settings determine the number of times a user can attempt to log in with an invalid security token before being locked out of Salesforce.com. The following events count toward the number of times a user can attempt to log in with an invalid password before being locked out of Salesforce.com, as defined in your organization's login lockout settings: - Each time a user is prompted to click the Send Activation Link button - Each time a user incorrectly adds their security token to the end of their password to log into the API or a client Restricting Login IP Ranges for Your Organization User Permissions Needed To view network access: To change network access: Login Challenge Enabled Manage Users To help protect your organization's data from unauthorized access, you can specify a list of IP addresses from which users can always log in without receiving a login challenge: 1. Click Setup Security Controls Network Access. 2. Click New. 3. Enter a valid IP address in the Start IP Address field and a higher IP address in the End IP Address field. The start and end addresses define the range of allowable IP addresses from which users can log in. If you want to allow logins from a single IP address, enter the same address in both fields. For example, enter as the start address and the end address to allow logins from only that IP address. The start and end IP addresses must include no more than 33,554,432 addresses (2 25 ). For example, the following ranges are valid: to to to However, ranges like to or to are too large. 35

38 Configuring Salesforce.com Security Features Restricting Login Hours 4. Click Save. Note: For organizations that were activated before December 2007, Salesforce.com automatically populated your organization's trusted IP address list in December 2007, when this feature was introduced. The IP addresses from which trusted users had already accessed Salesforce.com during the past six months were added. Restricting Login Hours User Permissions Needed To set login hours: Manage Users You can set the hours when users with a particular profile can use the system. 1. Click Setup Manage Users Profiles, and select a profile. 2. Click Edit in the Login Hours related list. 3. Set the days and hours when users with this profile can use the system. The hours are exact times based on the Default Time Zone of the company as specified at Setup Company Profile Company Information. The hours are always applied at those exact times even if a user is in a different time zone or if the company's Default Time Zone is changed. Select None for the start and end times to allow users to be logged in at any time. To prohibit users from using the system on a specific day, set the start and end times to the same value. 4. Click Save. Note: If a user logs in before the restricted hours, the system ends the user s session when the restricted hours begin. Restricting Login IP Ranges on Profiles User Permissions Needed To set login IP ranges: Manage Users You can set the IP addresses from which users with a particular profile can log in. When you define IP address restrictions for a profile, any login from an undesignated IP address is denied, and any login from a specified IP address is allowed. To set IP addresses on profiles: 1. The procedure you use to restrict the range of valid IP addresses on profiles depends on your Edition: For Enterprise Edition, Unlimited Edition, and Developer Edition, click Setup Manage Users Profiles, and select a profile. Then click New in the Login IP Ranges related list. For Professional Edition, Group Edition, and Personal Edition, click Setup Security Controls Session Settings, and then click New in the Login IP Ranges related list. 2. Enter a valid IP address in the IP Start Address and a higher IP address in the IP End Address field. The start and end addresses define the range of allowable IP addresses from which users can log in. If you want to allow logins from a single IP address, enter the same address in both fields. For example, enter as the start address and the end address to allow logins from only that IP address. 36

39 Configuring Salesforce.com Security Features Setting Session Security The start and end IP addresses must include no more than 33,554,432 addresses (2 25 ). For example, the following ranges are valid: to to to However, ranges like to or to are too large. 3. Click Save. Note: The mobile application bypasses IP range definitions set up for profiles. When accessing dashboards and Visualforce pages, the mobile application initiates a secure connection to Salesforce.com over the mobile carrier's network, but the mobile carrier's IP addresses might be outside of the IP ranges allowed on the user's profile. Setting Session Security User Permissions Needed To set session security: Customize Application You can modify session security settings to control the session timeout warning and to prevent IP shifting for users that are logged in. 1. Click Setup Security Controls Session Settings. 2. Customize the session security settings. Field Timeout value Disable session timeout warning popup Lock sessions to the IP address from which they originated Description Length of time after which the system prompts users who have been inactive to log out or continue working. Select a value between 30 minutes and 8 hours. Choose a shorter timeout period if your organization has sensitive information and you want to enforce stricter security. Determines whether the system prompts users with a timeout warning message after any length of inactivity. Select this option to provide extra security. Determines whether user sessions are locked to the IP address from which the user logged in, helping to prevent unauthorized persons from hijacking a valid session. Selecting this option prevents you from registering any Force.com AppExchange packages, see Registering Apps in the Force.com AppExchange online help. In addition, you cannot use this option with partner relationship management. 37

40 Configuring Salesforce.com Security Features Setting Session Security Field Require secure connections (HTTPS) Description Determines whether logins and all access to Salesforce.com are required to use HTTPS. This option is enabled by default, but it can be disabled to allow HTTP connections too. You should require HTTPS connections for enhanced security. Note: The forgotten password page can only be accessed using HTTPS. Force Relogin After Login-As-User Determines whether an administrator that is logged in as another user is returned to their previous session after logging out as the secondary user. For more information, see Logging In as Another User in the Salesforce.com online help. If the option is checked, an administrator must log in again to continue using Salesforce.com after logging out as the user; otherwise, the administrator is returned to their original session after logging out as the user. Enable caching and password autocomplete on login page Determines whether users' browsers can store usernames and passwords, and, after an initial log in, automatically enter this information on the login page. By default, caching and autocomplete is enabled. Login IP Ranges Specifies a range of IP addresses. Users must log in from IP addresses within the range (inclusive), or the login will fail, and users will have to activate their computers to successfully log in. For more information, see Setting Login Restrictions on page 34. To specify a range, click New and enter a lower and upper IP address to define the range. This field is not available in Enterprise, Unlimited, and Developer Editions. In those editions, you can specify valid IP addresses per profile; see Restricting Login IP Ranges on Profiles on page Click Save. 38

41 Chapter 4 Enabling Single Sign-On Salesforce.com offers two ways to use single sign-on: Delegated Authentication: When delegated authentication is enabled, salesforce.com does not validate a user's password. Instead, salesforce.com makes a Web services call to your organization to establish authentication credentials for the user. You must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated authentication single sign-on for your organization. For more information, see Understanding Delegated Authentication Single Sign-On in the Salesforce.com online help. Federated Authentication: When federated authentication is enabled, salesforce.com does not validate a user's password. Instead, salesforce.com verifies an assertion in the HTTP POST request, and allows single sign-on if the assertion is true. This is the default form of single sign-on. Federated authentication is available in all Editions. For more information, see Configuring SAML Settings for Single Sign-On in the Salesforce.com online help. Benefits of Single Sign-On Implementing single sign-on can offer the following advantages to your organization: Reduced Administrative Costs: With single sign-on, users only need to memorize a single password to access both network resources or external applications and Salesforce.com. When accessing Salesforce.com from inside the corporate network, users are logged in seamlessly, without being prompted to enter a username or password. When accessing Salesforce.com from outside the corporate network, users' corporate network login works to log them in. With fewer passwords to manage, system administrators receive fewer requests to reset forgotten passwords. Leverage Existing Investment: Many companies use a central LDAP database to manage user identities. By delegating Salesforce.com authentication to this system, when a user is removed from the LDAP system, they can no longer access Salesforce.com. Consequently, users who leave the company automatically lose access to company data after their departure. Time Savings: On average, a user takes five to 20 seconds to log in to an online application; longer if they mistype their username or password and are prompted to reenter them. With single sign-on in place, the need to manually log in to Salesforce.com is avoided. These saved seconds add up to increased productivity. Increased User Adoption: Due to the convenience of not having to log in, users are more likely to use Salesforce.com on a regular basis. For example, users can send messages that contain links to information in Salesforce.com such as records and reports. When the recipients of the message click the links, the corresponding Salesforce.com page opens automatically. Increased Security: Any password policies that you have established for your corporate network will also be in effect for Salesforce.com. In addition, sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data. Delegated Authentication Best Practices Consider the following best practices when implementing delegated authentication single sign-on for your organization. Your organization s implementation of the Web service must be accessible by salesforce.com servers. This means you must deploy the Web service on a server in your DMZ. Remember to use your server s external DNS name when entering the Delegated Gateway URL in the Delegated authentication section at Setup Security Controls Single Sign-On Settings in Salesforce.com. 39

42 Enabling Single Sign-On If salesforce.com and your system cannot connect, or the request takes longer than 10 seconds to process, the login attempt fails. An error is reported to the user indicating that his or her corporate authentication service is down. Namespaces, element names, and capitalization must be exact in SOAP requests. Wherever possible, generate your server stub from the WSDL to ensure accuracy. For security reasons, you should make your Web service available by SSL only. You must use an SSL certificate from a trusted provider, such as Verisign or Thawte. For a full list of trusted providers, contact salesforce.com. The IP address that originated the login request is sourceip. Use this information to restrict access based on the user s location. Note that the Salesforce.com feature that validates login IP ranges continues to be in effect for single sign-on users. For more information, see Restricting Login IP Ranges on Profiles on page 36. You may need to map your organization s internal usernames and Salesforce.com usernames. If your organization does not follow a standard mapping, you may be able to extend your user database schema (for example, Active Directory) to include the Salesforce.com username as an attribute of a user account. Your authentication service can then use this attribute to map back to a user account. We recommend that you do not enable single sign-on for the system administrator s profile. If your system administrators are single sign-on users and your single sign-on server has an outage, they have no way to log in to Salesforce.com. System administrators should always be able to log in to Salesforce.com so they can disable single sign-on in the event of a problem. We recommend that you use a Developer Edition account or a sandbox when developing a single sign-on solution before implementing it in your organization. To sign up for a free Developer Edition account, go to developer.force.com. Make sure to test your implementation with Salesforce.com clients such as Connect for Outlook, Connect for Office, and Connect Offline. For more information, see Single Sign-On for Salesforce.com clients. Federated Authentication using SAML Best Practices Consider the following best practices when implementing federated single sign-on with SAML for your organization. Obtain the Recipient URL value from the configuration page and put it in the corresponding configuration parameter of your Identity Provider. Your identity provider must allow you to set the Service Provider's Audience URL, and it must be set to Salesforce.com allows a maximum of three minutes for clock skew with your IDP server, make sure your server's clock is up-to-date. If you are unable to log in with SAML assertion, always check the login history and note the error message. You need to map your organization s internal usernames and Salesforce.com usernames. You have two choices to do this: add a unique identifier to the FederationIdentifier field of each Salesforce.com user, or extend your user database schema (for example, Active Directory) to include the Salesforce.com username as an attribute of a user account. Choose the corresponding option for the SAML User ID Type field and configure your authentication service to send the identifier in SAML assertions. Before allowing users to log in with SAML assertions, enable the SAML organization preference and provide all the necessary configurations. We recommend that you use Developer Edition account or a sandbox when testing a SAML single sign-on solution. To sign up for a free Developer Edition account, go to developer.force.com. All sandbox copies are made with federated authentication with SAML disabled. Any configuration information is preserved, except the value for Recipient URL changes to The Recipient URL is updated to match your sandbox URL, for example after you re-enable SAML. To enable SAML in the sandbox copy, click Setup Security Controls Single Sign-On Settings; then click Edit, and select SAML Enabled. Single Sign-On for Portals Best Practices Only SAML version 2.0 can be used with portals. Only Customer Portals and partner portals are supported. Service provider initiated login is not supported. 40

43 Enabling Single Sign-On Both the portal_id and organization_id attributes are required for single sign-on for portals. If only one is specified, the user receives an error. If both the portal_id and organization_id attributes are populated in the SAML assertion, the user is directed to that portal login. If neither is populated, the user is directed to the regular SAML Salesforce.com login. More than one portal can be used with a single organization. 41

44 Chapter 5 Monitoring Your Organization's Security Review the following sections for detailed instructions and tips on monitoring the security of your Salesforce.com organization. Monitoring Logins User Permissions Needed To monitor logins: Manage Users s can monitor the successful and failed login attempts for their organization and enabled portals, as well as the type of login, such as Application, SAML, Remote Access Client, and so on. Contact Manager, Group, Professional, Enterprise, Unlimited, and Developer Editions 1. Click Setup Manage Users Login History. 2. Click one of the following links: Excel csv file: This downloads a CSV file of all user logins to your Salesforce.com organization for the past six months. This report includes logins through the API. gzipped Excel csv file: This downloads a CSV file of all user logins to your Salesforce.com organization for the past six months. This report includes logins through the API. The file is compressed and this is the preferred option for quickest download time. Note: The following links are located after the Login History section on the page. Download login history for the last six months, including logins from outside the website, such as API logins (Excel.csv file): This downloads a CSV file of all user logins to your Salesforce.com organization for the past six months. This report includes logins through the API. Download login history, including logins from the website only (Excel.csv file): This only download the user logins that originated from the salesforce.com website. Note: Older versions of Microsoft Excel cannot open files with more than 65,536 rows. If you cannot open a large file in Excel, see the Microsoft Help and Support article about handling large files. To see the last ten successful and failed logins for a specific user, navigate to Setup Manage Users Users, click on the Full Name for the user, and scroll to the Login History section. 42

45 Monitoring Your Organization's Security Tracking Field History Personal Edition To view your personal login history: 1. Click Setup My Personal Information Personal Information. 2. Scroll down to the Login History related list to view your last ten logins. 3. To download a CSV file of your login history for the past six months, click the Download... link. Note: For security purposes, Salesforce.com may require users to pass a user verification test to export data from their organization. This simple, text-entry test helps prevent malicious programs from accessing your organization's data. To pass the test, users must type the two words displayed on the overlay into the overlay's text box field, and click the Submit button. Note that the words entered into the text box field must be separated by a space. Salesforce.com uses CAPTCHA technology provided by recaptcha to verify that a person, as opposed to an automated program, has correctly entered the text into the overlay. CAPTCHA is an acronym that stands for Completely Automated Public Turing Test To Tell Computers and Humans Apart. Single Sign-On with SAML If your organization has set up single sign-on using identity provider certificates (written in SAML), you may see login history messages specific to single sign-on. My Domain If you are using My Domain, you can identify which users are logging in with the new login URL, and when. Click Setup Manage Users Login History and look at the Username and Login URL columns. Tracking Field History User Permissions Needed To set up which fields are tracked: Customize Application You can select certain standard and custom fields to track on the History related list of accounts, cases, contacts, contracts, leads, opportunities, solutions, and custom objects. Modifying any of these standard or custom fields adds a new entry to the History related list. All entries include the date, time, nature of the change, and who made the change. History data does not count against your organization s storage limit. Note that not all fields types are available for history tracking.. For more information on tracking field history, see the following: Tracking Field History for Standard Objects Tracking Field History for Custom Objects Notes on History Tracking Tracking Field History for Standard Objects You can track field history for: Accounts Cases Contacts Entitlements 43

46 Monitoring Your Organization's Security Tracking Field History Service contracts Contract line items Contracts Leads Opportunities Solutions To set up field history tracking: 1. Click Setup Customize and select the object you want to configure. 2. Click Fields. 3. Click Set History Tracking. For accounts, contacts, leads, and opportunities, select the Enable Account History, Enable Contact History, Enable Lead History, or Enable Opportunity Field History checkbox. Deselect the checkbox if you do not want to track any changes. If you deselect the checkbox, the History related list is automatically removed from associated page layouts. This checkbox is not available for cases, solutions, or contracts because you cannot disable their history tracking. Certain changes, such as case escalation, are always tracked. When you choose the fields you want to track, Salesforce.com begins tracking history from that date and time forward. Changes made before that date and time are not included. Note that some case, solution, and contract fields are preselected for history tracking, so changes to those fields are automatically tracked from the time your organization began using Salesforce.com. 4. Choose the fields you want tracked. 5. Click Save. Tracking Field History for Custom Objects To track field history for custom objects: 1. Click Setup Create Objects and click Edit next to the name of the custom object. 2. Select the Track Field History checkbox. Deselect the checkbox if you do not want to track any changes. If you deselect the checkbox, the History related list is automatically removed from the custom object's page layouts. 3. Click Save. 4. Select the name of the custom object. 5. Click Set History Tracking in the Custom Fields & Relationships section. This section allows you to set a custom object's history tracking for both standard and custom fields. When you choose the fields you want to track, Salesforce.com begins tracking history from that date and time forward. Changes made before that date and time are not included. If you deselected the Track Field History checkbox, the Set History Tracking button does not display. 6. Choose the fields you want tracked. 7. Click Save. Notes on History Tracking When you enable history tracking for an object, be sure to customize your page layouts to include the object's history related list. For more information, see Customizing Page Layouts in the Salesforce.com online help. You can select a combination of up to 20 standard and custom fields per object. You cannot track the following fields: - History of formula, roll-up summary, or auto-number 44

47 Monitoring Your Organization's Security Tracking Field History - Created By and Last Modified By - Expected Revenue field on opportunities - Master Solution Title or the Master Solution Details fields on solutions; these fields display only for translated solutions in organizations with multilingual solutions enabled. You cannot customize which opportunity fields are tracked in the opportunities' Stage History related list; however, you can choose which opportunity fields are tracked in the Opportunity Field History related list. You cannot customize the History related list because it does not store data. The History related list links to data stored elsewhere. Changes to fields with more than 255 characters are tracked as edited, and their old and new values are not recorded. For example, changes to long text area fields are tracked as edited. Tracked field values are not automatically translated; they display in the language in which they were made. For example, if a field value is changed from Green to Verde, Verde is displayed no matter what a user's language is, unless the field value has been translated into other languages via the translation workbench. This also applies to record types and picklist values. Changes to date fields, number fields, and standard field labels are shown in the locale of the user viewing the History related list. For example, a date change to August 8, 2005 shows as 8/5/2005 for a user with the English (United States) locale and as 5/8/2005 for a user with the English (United Kingdom) locale. Changes to custom field labels that have been translated via the translation workbench are shown in the locale of the user viewing the History related list. For example, if a custom field label is Red and translated into Spanish as Rojo, then a user with a Spanish locale will see the custom field label as Rojo. Otherwise, the user will see the custom field label as Red. Changes to the Amount and Quantity fields on opportunities are tracked even when the field is updated as the result of a change to an opportunity's products or schedules. Changes to the Closed When Created field on cases are only tracked when the field is updated via the Force.com API. Field updates are tracked in the History related list if you have set history tracking on those fields. When you delete a custom field, all of the field history data is deleted and changes are no longer tracked. If you disable field history tracking on a custom object, then you cannot report on its field history. If you disable field history tracking on an object, you can still report on its history data up to the date and time you disabled tracking. You can report on activated contracts whose fields are tracked by clicking New Custom Report on the Reports tab, selecting Contract Reports as the data type, and choosing Contract History. You cannot disable field history tracking for an object if a field on the object is referenced in an Apex script. For more information, see Force.com Apex Code Overview in the Salesforce.com online help. If you use both business accounts and person accounts, review the following before enabling account field history tracking: - Field history tracking for accounts affects both business accounts and person accounts. - A maximum of 20 account fields can be tracked. This limit includes fields on person accounts and business accounts. - Enabling field history tracking on person accounts does not enable field history tracking on personal contacts. - To report on person account history, run the Account History report. If the parent record in a lookup relationship is deleted, the field history tracking for the child record does not record the deletion. For example, if a parent account is deleted, the Account History related list for the child account does not show the deletion. 45

48 Monitoring Your Organization's Security Monitoring Setup Changes Monitoring Setup Changes User Permissions Needed To view audit trail history: View Setup and Configuration The setup audit trail history helps you track the recent setup changes that you and other administrators have made to your organization. This can be especially useful in organizations with multiple administrators. To view the setup audit trail history, click Setup Security Controls View Setup Audit Trail. To download your organization s full setup history for the past 180 days, click the Download link. The setup audit trail history shows you the 20 most recent setup changes made to your organization. It lists the date of the change, who made it, and what the change was. The setup audit trail history tracks the following types of changes: Setup Changes Tracked Administration Company information, default settings such as language or locale, and company message changes Multiple currency setup changes User, portal user, role, and profile changes address changes for any user Record type changes, including creating or renaming record types and assigning record types to profiles Changes to divisions, including creating and editing divisions, transferring divisions, and changing users default division Adding or deleting certificates Domain name changes Enabling or disabling Salesforce.com as an identity provider Customization Changes to user interface settings, such as collapsible sections, Quick Create, hover details, or the related list hover links Page layout and search layout changes Changes made using inline editing Custom field and field-level security changes, including changes to formulas, picklist values, and custom field attributes like the format of auto-number fields or masking of encrypted fields Changes to lead settings, lead assignment rules, and lead queues Changes to activity settings Changes to support settings, business hours, case assignment and escalation rules, and case queues Any changes made by salesforce.com Customer Support at your request Changes to tab names, including tabs that you reset to the original tab name Changes to custom apps, custom objects, and custom tabs Changes to contract settings Changes to forecast settings Enabling or disabling -to-Case or On-Demand -to-Case Changes to custom buttons, links, and s-controls, including standard button overrides Enabling or disabling drag-and-drop scheduling 46

49 Monitoring Your Organization's Security Monitoring Setup Changes Setup Security and Sharing Changes Tracked Enabling, disabling, or customizing similar opportunities Enabling or disabling quotes Changes to data category groups and data categories Changes to article types Changes to category groups and categories Changes to ideas settings Changes to answers settings Changes to field tracking in feeds Changes to campaign influence settings Activating or deactivating critical updates Enabling or disabling Salesforce Chatter notifications Public groups, sharing rule changes, and organization-wide sharing, including the Grant Access Using Hierarchies option Password policy changes Session settings changes, such as changing the session timeout setting Changes to delegated administration groups and the items delegated administrators can manage. Setup changes made by delegated administrators are tracked as well. How many records a user emptied from their Recycle Bin and from the organization's Recycle Bin Changes to SAML (Security Assertion Markup Language) configuration settings Changes to Salesforce.com certificates Data Management Mass delete use, including when a mass delete exceeds the user's Recycle Bin limit of 5000 deleted records. The oldest, excess records will be permanently removed from the Recycle Bin within two hours of the mass delete transaction time. Weekly data export requests Use of the campaign member import wizard Mass transfer use Changes to analytic snapshots, including defining, deleting, or changing the source report or target object on an analytic snapshot Import wizard use Development Changes to Apex classes and triggers Changes to Visualforce pages, custom components, or static resources Changes to custom settings Changes to remote access definitions Changes to Force.com Sites settings Various Setup Creation of an API usage metering notification Changes to territories Changes to Workflow & Approvals settings Changes to approval processes Creation and deletion of workflow actions Packages from Force.com AppExchange that you installed or uninstalled 47

50 Monitoring Your Organization's Security Monitoring Setup Changes Setup Using the application Changes Tracked Changes to account team and opportunity team selling settings Activation of Google Apps services Changes to mobile configuration settings, including data sets, mobile views, and excluded fields A user with the Manage Partners permission logging into the partner portal as a partner user A user with the Edit Self-Service Users permission logging into the Salesforce.com Customer Portal as a Customer Portal user Enabling or disabling a partner portal account Disabling a Salesforce.com Customer Portal account Enabling or disabling a Salesforce.com Customer Portal and creating multiple Customer Portals Creating and changing entitlement processes and entitlement templates Enabling or disabling self-registration for a Salesforce.com Customer Portal Enabling or disabling Customer Portal or partner portal users 48

51 Chapter 6 Security Tips for Apex and Visualforce Development Available in: Group, Professional, Enterprise, Unlimited, and Developer Editions Understanding Security The powerful combination of Apex and Visualforce pages allow Force.com developers to provide custom functionality and business logic to Salesforce.com or create a completely new stand-alone product running inside the Force.com platform. However, as with any programming language, developers must be cognizant of potential security-related pitfalls. Salesforce.com has incorporated several security defenses into the Force.com platform itself. However, careless developers can still bypass the built-in defenses in many cases and expose their applications and customers to security risks. Many of the coding mistakes a developer can make on the Force.com platform are similar to general Web application security vulnerabilities, while others are unique to Apex. To certify an application for Force.com AppExchange, it is important that developers learn and understand the security flaws described here. Cross-Site Scripting (XSS) Cross-site scripting (XSS) attacks cover a broad range of attacks where malicious HTML or client-side scripting is provided to a Web application. The Web application includes malicious scripting in a response to a user of the Web application. The user then unknowingly becomes the victim of the attack. The attacker has used the Web application as an intermediary in the attack, taking advantage of the victim's trust for the Web application. Most applications that display dynamic Web pages without properly validating the data are likely to be vulnerable. Attacks against the website are especially easy if input from one user is intended to be displayed to another user. Some obvious possibilities include bulletin board or user comment-style websites, news, or archives. For example, assume the following script is included in a Force.com page using a script component, an on* event, or a Visualforce page. <script>var foo = '{!$CurrentPage.parameters.userparam}';script>var foo = '{!$CurrentPage.parameters.userparam}';</script> This script block inserts the value of the user-supplied userparam onto the page. The attacker can then enter the following value for userparam: 1';document.location=' 49

52 Security Tips for Apex and Visualforce Development Cross-Site Scripting (XSS) In this case, all of the cookies for the current page are sent to as the query string in the request to the cookie.cgi script. At this point, the attacker has the victim's session cookie and can connect to the Web application as if they were the victim. The attacker can post a malicious script using a Web site or . Web application users not only see the attacker's input, but their browser can execute the attacker's script in a trusted context. With this ability, the attacker can perform a wide variety of attacks against the victim. These range from simple actions such as opening and closing windows, to more malicious attacks such as stealing data or session cookies, allowing an attacker full access to the victim's session. For more information on this attack in general, see the following articles: Within the Force.com platform there are several anti-xss defenses in place. For example, salesforce.com has implemented filters that screen out harmful characters in most output methods. For the developer using standard classes and output methods, the threats of XSS flaws have been largely mitigated. However, the creative developer can still find ways to intentionally or accidentally bypass the default controls. The following sections show where protection does and does not exist. Existing Protection All standard Visualforce components, which start with <apex>, have anti-xss filters in place. For example, the following code is normally vulnerable to an XSS attack because it takes user-supplied input and outputs it directly back to the user, but the <apex:outputtext> tag is XSS-safe. All characters that appear to be HTML tags are converted to their literal form. For example, the < character is converted to < so that a literal < displays on the user's screen. <apex:outputtext> {!$CurrentPage.parameters.userInput} </apex:outputtext> Disabling Escape on Visualforce Tags By default, nearly all Visualforce tags escape the XSS-vulnerable characters. It is possible to disable this behavior by setting the optional attribute escape="false". For example, the following output is vulnerable to XSS attacks: <apex:outputtext escape="false" value="{!$currentpage.parameters.userinput}" /> Programming Items Not Protected from XSS The following items do not have built-in XSS protections and you should take extra care when using these tags and objects. This is because these items were intended to allow the developer to customize the page by inserting script commands. It does not makes sense to include anti-xss filters on commands that are intentionally added to a page. Custom JavaScript If you write your own JavaScript, the Force.com platform has no way to protect you. For example, the following code is vulnerable to XSS if used in JavaScript. <script> var foo = location.search; document.write(foo); </script> 50

53 Security Tips for Apex and Visualforce Development S-Control Template and Formula Tags <apex:includescript> The <apex:includescript> Visualforce component allows you to include a custom script on the page. In these cases, be very careful to validate that the content is safe and does not include user-supplied data. For example, the following snippet is extremely vulnerable because it includes user-supplied input as the value of the script text. The value provided by the tag is a URL to the JavaScript to include. If an attacker can supply arbitrary data to this parameter (as in the example below), they can potentially direct the victim to include any JavaScript file from any other website. <apex:includescript value="{!$currentpage.parameters.userinput}" /> S-Control Template and Formula Tags S-Controls give the developer direct access to the HTML page on which they appear and include an array of variables that can be used to insert data into the pages. As described above, s-controls do not use any built-in XSS protections. When using the template and formula tags, all output is unfiltered and must be validated by the developer. Caution: S-controls will be desupported in a future release. Salesforce.com strongly suggests you create custom user interface elements using Visualforce instead of s-controls. For more information, see How Do Visualforce Pages Compare to S-Controls? The general syntax of these tags is:{!function()} or {!$OBJECT.ATTRIBUTE}. For example, if a developer wanted to include a user's session ID in a link, they could create the link using the following syntax: <a href=" Go to portal</a> Which renders output similar to the following: <a href=" SlYiOfRzpM18huTGN3jC0O1FIkbuQRwPc9OQJeMRm4h2UYXRnmZ5wZufIrvd9DtC_ilA&server= /services/soap/u/13.0/4f0900d jsbi">go to portal</a> Formula expressions can be function calls or include information about platform objects, a user's environment, system environment, and the request environment. An important feature of these expressions is that data is not escaped during rendering. Since expressions are rendered on the server, it is not possible to escape rendered data on the client using JavaScript or other client-side technology. This can lead to potentially dangerous situations if the formula expression references non-system data (that is potentially hostile or editable data) and the expression itself is not wrapped in a function to escape the output during rendering. A common vulnerability is created by the use of the {!$Request.*} expression to access request parameters. <html> <head> <title>{!$request.title}</title> </head> <body>hello world!</body> </html> Unfortunately, the unescaped {!$Request.title} tag also results in a cross-site scripting vulnerability. For example, the request: 51

54 Security Tips for Apex and Visualforce Development Cross-Site Request Forgery (CSRF) results in the output: <html><head><title>adios</title><script>alert('xss')</script></title></head><body>hello world!</body></html> The standard mechanism to do server-side escaping is through the use of the SUBSTITUTE() formula tag. Given the placement of the {!$Request.*} expression in the example, the above attack could be prevented by using the following nested SUBSTITUTE() calls. <html> <head> <title>{! SUBSTITUTE(SUBSTITUTE($Request.title,"<","<"),">",">")}</title> </head> <body>hello world!</body> </html> Depending on the placement of the tag and usage of the data, both the characters needing escaping as well as their escaped counterparts may vary. For instance, this statement: <script>var ret = "{!$Request.retURL}";script>var ret = "{!$Request.retURL}";</script> requires that the double quote character be escaped with its URL encoded equivalent of %22 instead of the HTML escaped ", since it is probably going to be used in a link. Otherwise, the request: foo%22%3balert('xss')%3b%2f%2f results in: <script>var ret = "foo";alert('xss');//";</script> Additionally, the ret variable may need additional client-side escaping later in the page if it is used in a way which may cause included HTML control characters to be interpreted. Formula tags can also be used to include platform object data. Although the data is taken directly from the user's organization, it must still be escaped before use to prevent users from executing code in the context of other users (potentially those with higher privilege levels). While these types of attacks must be performed by users within the same organization, they undermine the organization's user roles and reduce the integrity of auditing records. Additionally, many organizations contain data which has been imported from external sources and may not have been screened for malicious content. Cross-Site Request Forgery (CSRF) Cross-Site Request Forgery (CSRF) flaws are less of a programming mistake as they are a lack of a defense. The easiest way to describe CSRF is to provide a very simple example. An attacker has a Web page at This could be any Web page, including one that provides valuable services or information that drives traffic to that site. Somewhere on the attacker's page is an HTML tag that looks like this: <img src=" height=1 width=1 /> In other words, the attacker's page contains a URL that performs an action on your website. If the user is still logged into your Web page when they visit the attacker's Web page, the URL is retrieved and the actions performed. This attack succeeds 52

55 Security Tips for Apex and Visualforce Development SOQL Injection because the user is still authenticated to your Web page. This is a very simple example and the attacker can get more creative by using scripts to generate the callback request or even use CSRF attacks against your AJAX methods. For more information and traditional defenses, see the following articles: Within the Force.com platform, salesforce.com has implemented an anti-csrf token to prevent this attack. Every page includes a random string of characters as a hidden form field. Upon the next page load, the application checks the validity of this string of characters and does not execute the command unless the value matches the expected value. This feature protects you when using all of the standard controllers and methods. Here again, the developer might bypass the built-in defenses without realizing the risk. For example, suppose you have a custom controller where you take the object ID as an input parameter, then use that input parameter in an SOQL call. Consider the following code snippet. <apex:page controller="myclass" action="{!init}"</apex:page> public class myclass { public void init() { Id id = ApexPages.currentPage().getParameters().get('id'); Account obj = [select id, Name FROM Account WHERE id = :id]; delete obj; return ; } } In this case, the developer has unknowingly bypassed the anti-csrf controls by developing their own action method. The id parameter is read and used in the code. The anti-csrf token is never read or validated. An attacker Web page may have sent the user to this page using a CSRF attack and could have provided any value they wish for the id parameter. There are no built-in defenses for situations like this and developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example. A possible work-around could be to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated. SOQL Injection In other programming languages, this flaw is known as SQL injection. Apex does not use SQL, but uses its own database query language, SOQL. SOQL is much simpler and more limited in functionality than SQL. Therefore, the risks are much lower for SOQL injection than for SQL injection, but the attacks are nearly identical to traditional SQL injection. In summary SQL/SOQL injection involves taking user-supplied input and using those values in a dynamic SOQL query. If the input is not validated, it may include SOQL commands that effectively modify the SOQL statement and trick the application into performing unintended commands. For more information on SQL Injection attacks see:

56 Security Tips for Apex and Visualforce Development SOQL Injection SOQL Injection Vulnerability in Apex Below is a simple example of Apex and Visualforce code vulnerable to SOQL injection. <apex:page controller="soqlcontroller" > <apex:form> <apex:outputtext value="enter Name" /> <apex:inputtext value="{!name}" /> <apex:commandbutton value="query" action="{!query} /> </apex:form> </apex:page> public class SOQLController { public String name { get { return name;} set { name = value;} } public PageReference query() { String qrystring = 'SELECT Id FROM Contact WHERE (IsDeleted = false and Name like \'%' + name + '%\')'; queryresult = Database.query(qryString); return null; } } This is a very simple example but illustrates the logic. The code is intended to search for contacts that have not been deleted. The user provides one input value called name. The value can be anything provided by the user and it is never validated. The SOQL query is built dynamically and then executed with the Database.query method. If the user provided a normal value, the statement executes as expected: name = Bob sqystring = SELECT Id FROM Contact WHERE (IsDeleted = false and Name like '%Bob%') However, what if the user provided unexpected input, such as: name = test%') or (Name like ' In that case, the query string becomes: SELECT Id FROM Contact WHERE (IsDeleted = false and Name like '%test%') or (Name like '%') Now the results show all contacts, not just the non-deleted ones. A SOQL Injection flaw can be used to modify the intended logic of any vulnerable query. SOQL Injection Defenses To prevent a SOQL injection attack, avoid using dynamic SOQL queries. Instead, use static queries and binding variables. The vulnerable example above could be re-written using static SOQL as follows: public class SOQLController { public String name { get { return name;} set { name = value;} } public PageReference query() { String queryname = '%' + name + '%'; queryresult = [SELECT Id FROM Contact WHERE (IsDeleted = false and Name like :queryname)]; return null; 54

57 Security Tips for Apex and Visualforce Development Data Access Control } } If you must use dynamic SOQL, use the escapesinglequotes method to sanitize user-supplied input. This method adds the escape character (\) to all single quotation marks in a string that is passed in from a user. The method ensures that all single quotation marks are treated as enclosing strings, instead of database commands. Data Access Control The Force.com platform makes extensive use of data sharing rules. Each object can have unique permissions for which users and profiles can read, create, edit, and delete. These restrictions are enforced when using all standard controllers. When using an Apex class, the built-in profile permissions and field-level security restrictions are not respected during execution. The default behavior is that an Apex class has the ability to read and update all data with the organization. Because these rules are not enforced, developers who use Apex must take care that they do not inadvertently expose sensitive data that would normally be hidden from users by profile-based permissions, field-level security, or organization-wide defaults. This is particularly true for Visualforce pages. For example, consider the following Apex pseudo-code: public class customcontroller { public void read() { Contact contact = [Select id from Contact where Name = :value]; } } In this case, all contact records are searched, even if the user currently logged in would not normally have permission to view these records. The solution is to use the qualifying keywords with sharing when declaring the class: public with sharing class customcontroller {... } The with sharing keyword directs the platform to use the security sharing permissions of the user currently logged in, rather than granting full access to all records. 55

58 Index Index A Auditing fields 43 B browsers 3 C Code security 49 Cookies 5 Custom objects permissions 24 D Development security 49 F Field-level security 7 setting 25 Fields auditing 43 field-level security 25 history 43 tracking changes 43 H History fields 43 I IP addresses trusted 34 whitelist 34 L Login activation 34 failures 42 history 42 identity confirmation 34 IP address whitelist 34 restricting IP addresses organization-wide 35 restricting login hours 36 restricting login IP addresses on profiles 36 session security 37 trusted IP addresses 34 Login IP Ranges restricting 5 M Manual sharing 8 N Network access 35 O Object-level security 7 Organization-wide defaults 26 about 7 P Passwords expiring 5 expiring all passwords 33 policies 5 settings and controls 32 Permissions 11 Profiles field-level security 25 key user permissions 8 managing 10 object-level security 7 permissions 11 restricting login hours 36 R restricting login IP ranges 5 Role hierarchies about 7 Roles managing 28 viewing 28 Rules, sharing See Sharing rules 8 S Security auditing 9 CAPTCHA 6 code 49 cookies 5 field-level security 7, 25 infrastructure 3 login challenge 5 login restrictions 34 manual sharing 8 network 5 object-level security 7 organization-wide defaults 7 overview 3 record-level security 7 restricting IP addresses organization-wide 35 restricting login IP addresses on profiles 36 56

59 Security (continued) role hierarchies 7 session 6 sharing rules 8 single sign-on 5 SSL 6 timeout 6 token 34 trust 4 user 5 user authentication 5 Security and sharing managing 6 Session security 37 Setup monitoring changes 46 Sharing about sharing rules 29 organization-wide defaults 26 setting the sharing model 26 Sharing rules 8 about 29 Sharing, manual See Manual sharing 8 single sign-on 5 T Territories hierarchies 7 trust 4 U User profiles See Profiles 10 User roles See Roles 28 Users permissions 11 Index 57