Security Implementation Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Setting Session Security

The Lock sessions to the IP address from which they originated setting is available in: Enterprise, Performance, Unlimited, Developer, and Database.com Editions

All other settings available in: Personal, Contact Manager, Group, Professional, Enterprise, Performance, Unlimited, Developer, and Database.com Editions

User Permissions Needed
To set session security: “Customize Application”

You can modify session security settings to specify connection type, timeout settings, and more.

  1. From Setup, click Security Controls | Session Settings.
  2. Customize the session security settings.
    Field Description
    Timeout value Length of time after which the system logs out inactive users. For Portal users, the timeout is between 10 minutes and 12 hours even though you can only set it as low as 15 minutes. Select a value between 15 minutes and 12 hours. Choose a shorter timeout period if your organization has sensitive information and you want to enforce stricter security.

    The last active session time value isn’t updated until halfway through the timeout period. That is, if you have a 30 minute timeout, the system won’t check for activity until 15 minutes have passed. For example, assume you have a 30 minute timeout value. If you update a record after 10 minutes, the last active session time value won’t be updated because there was no activity after 15 minutes. You’ll be logged out in 20 more minutes (30 minutes total) because the last active session time wasn’t updated. Suppose you update a record after 20 minutes. That’s five minutes after the last active session time is checked, so your timeout resets and you have another 30 minutes before being logged out, for a total of 50 minutes.

    Note
    Disable session timeout warning popup Determines whether the system prompts inactive users with a timeout warning message. Users are prompted 30 seconds before timeout as specified by the Timeout value.
    Force logout on session timeout Requires that when sessions time out for inactive users, current sessions become invalid. Browsers are automatically refreshed and return to the login page. To access the organization again when this occurs, users must log in again.

    Do not select Disable session timeout warning popup when enabling this option.

    Note
    Lock sessions to the IP address from which they originated 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.

    This may inhibit various applications and mobile devices.

    Note
    Require secure connections (HTTPS) Determines whether HTTPS is required to log in to or access Salesforce, apart from Force.com sites, which can still be accessed using HTTP.

    This option is enabled by default for security reasons.

    The Resetting Passwords for Your Users page can only be accessed using HTTPS.

    Note
    Force relogin after Login-As-User Determines whether an administrator who is logged in as another user is returned to their previous session after logging out as the secondary user.

    If the option is enabled, an administrator must log in again to continue using Salesforce after logging out as the user; otherwise, the administrator is returned to the original session after logging out as the user. This option is enabled by default for new organizations beginning with the Summer ‘14 release.
    Require HttpOnly attribute Restricts session ID cookie access. A cookie with the HttpOnly attribute is not accessible via non-HTTP methods, such as calls from JavaScript.

    If you have a custom or packaged application that uses JavaScript to access session ID cookies, selecting Require HttpOnly attribute breaks your application because it denies the application access to the cookie. The Developer Console and AJAX Toolkit debugging window are also not available if the Require HttpOnly attribute is selected.

    Note
    Use POST requests for cross-domain sessions Sets the organization to send session information using a POST request, instead of a GET request, for cross-domain exchanges, such as when a user is using a Visualforce page. In this context, POST requests are more secure than GET requests, because POST requests keep the session information in the body of the request. However, if you enable this setting, embedded content from another domain, such as:
    1<img src="https://acme.force.com/pic.jpg"/>
    might not display.
    Enable caching and password autocomplete on login page Allows the user’s browser to store usernames. If enabled, after an initial log in, usernames are auto-filled into the User Name field on the login page. This preference is selected by default and caching and autocomplete are enabled.
    Enable SMS-based identity confirmation Enables users to receive a one-time PIN delivered via SMS. Once enabled, administrators or users must verify their mobile phone number before taking advantage of this feature. This setting is selected by default for all organizations.
    Require security tokens for API logins from callouts (API version 31.0 and earlier) Requires the use of security tokens for API logins from callouts, such as Apex callouts or callouts using the AJAX proxy, in API version 31.0 and earlier. In API version 32.0 and later, security tokens are required by default.
    Login IP Ranges (for Contact Manager, Group, and Professional Editions) Specifies a range of IP addresses users must log in from (inclusive), or the login will fail.

    To specify a range, click New and enter a Start IP Address and End IP Address to define the range, which includes the start and end values.

    This field is not available in Enterprise, Unlimited, Performance, and Developer Editions. In those editions, you can specify a valid Login IP Range in the user profile settings.
    Enable clickjack protection for setup pages Protects against clickjack attacks on setup Salesforce pages. Clickjacking is also known as a user interface redress attack. (Setup pages are available from the Setup menu.)
    Enable clickjack protection for non-setup Salesforce pages Protects against clickjack attacks on non-setup Salesforce pages. Clickjacking is also known as a user interface redress attack. Setup pages already include protection against clickjack attacks. (Setup pages are available from the Setup menu.) This setting is selected by default for all organizations.
    Enable clickjack protection for non-setup customer Visualforce pages Protects against clickjack attacks on your Visualforce pages. Clickjacking is also known as a user interface redress attack.

    If you use custom Visualforce pages within a frame or iframe, you may see a blank page or the page may display without the frame. For example, Visualforce pages in a page layout do not function when clickjack protection is on.

    Warning
    Enable CSRF protection on GET requests on non-setup pages Protects against Cross Site Request Forgery (CSRF) attacks by modifying non-setup pages to include a random string of characters in the URL parameters or as a hidden form field. With every GET and POST request, the application checks the validity of this string of characters and doesn’t execute the command unless the value found matches the value expected. This setting is selected by default for all organizations.
    Enable CSRF protection on POST requests on non-setup pages
  3. Click Save.

Session-level Security

You can restrict access to certain types of resources based on the level of security associated with the authentication (login) method for the user’s current session. By default, each login method has one of two security levels: Standard or High Assurance. You can change the session security level and define policies so specified resources are only available to users with a High Assurance level.

The different authentication methods are assigned these security levels, by default.
  • Username and Password — Standard
  • Delegated Authentication — Standard
  • Two-Factor Authentication — High Assurance
  • Authentication Provider — Standard
  • SAML — Standard

    The security level for a SAML session can also be specified using the SessionLevel attribute of the SAML assertion sent by the identity provider. The attribute can take one of two values, STANDARD or HIGH_ASSURANCE.

    Note

To change the security level associated with a login method:
  1. From Setup, click Security Controls | Session Settings.
  2. Under Session Security Levels, select the login method.
  3. Click the Add or Remove arrow to move it to the proper category.
Currently, the only features that use session-level security are connected apps, reports, and dashboards. You can set policies requiring High Assurance on these types of resources and specify an action to take if the session used to access the resource is not High Assurance. The two supported actions are:
  • Block — This blocks access to the resource by showing an insufficient privileges error.
  • Raise session level — This redirects you to a Two-Factor Authentication flow for raising the session’s security level to High Assurance. Once you complete the flow successfully, you can access the resource.
To set a High Assurance required policy for accessing a connected app:
  1. From Setup, go to Administer | Manage Apps | Connected Apps.
  2. Click Edit next to the connected app.
  3. Select High Assurance session required.
  4. Select one of the two actions presented.
  5. Click Save.
To set a High Assurance required policy for accessing reports and dashboards:
  1. From Setup, go to Build | Customize | Reports & Dashboards | Access Policies.
  2. Select the High Assurance session required.
  3. Select one of the two actions presented.
  4. Click Save.

The session levels have no impact on any resources in the app other than connected apps, reports, and dashboards for which explicit security policies have been defined.