Session Security. salesforce Salesforce

PDF

Document

Set Up and Maintain Your Salesforce Organization Session Security

•

Mailing City—22 non_ASCII characters

Note:

This page is about Shield Platform Encryption, not Classic Encryption. What's the difference?

SEE ALSO:

Encrypt Fields

Back to Parent Topic

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 the computer unattended while still logged in. It also limits the risk of internal attacks, such as when one employee tries to use another employee’s session. Choose from several session settings to control session behavior.

You can control when an inactive user session expires. 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 don’t respond to this prompt, they are logged out.

Note:

When users close a browser window or tab, they aren’t automatically logged off from their Salesforce session. Ensure that your users are aware of this behavior and that they end all sessions properly by selecting

Your Name

> Logout.

By default, Salesforce uses TLS (Transport Layer Security) and requires secure connections (HTTPS) for all communication. The

Require secure connections (HTTPS)

setting determines whether TLS (HTTPS) is required for access to Salesforce, apart from Force.com

sites, which can be accessed using HTTP. If you ask Salesforce to disable this setting and change the URL from https://

to http://

, you can still access the application. However, for added security, require all sessions to use TLS. For more information, see

Modify Session

Security Settings

on page 608.

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. For details, see

Session-level Security on page 612.

You can control whether your org stores user logins and whether they can appear from the Switcher with the settings

Enable caching and autocomplete on login page

Enable user switching

, and

Remember me until logout

IN THIS SECTION:

Modify Session Security Settings

You can modify session security settings to specify session connection type, timeout settings, and IP address ranges to protect against malicious attacks and more.

Set Trusted IP Ranges for Your Organization

Trusted IP Ranges define a list of IP addresses from which users can log in without receiving a login challenge for verification of their identity, such as a code sent to their mobile phone.

User Sessions

Monitor and protect your Salesforce org by reviewing active sessions and session details on the User Session Information page. You can create custom list views, view details about a user associated with a specific session, and easily end suspicious sessions. Salesforce admins can view all user sessions for an org; non-admins see only their own sessions.

575

Set Up and Maintain Your Salesforce Organization Session Security

Understanding Session Types

Learn about the session types in the User Session Information page to help you monitor and protect your organization.

Identity Verification History

Modify Session Security Settings

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

IP address ranges to protect against malicious attacks and more.

1. From Setup, enter

Session Settings

in the Quick Find box, then select Session Settings.

2. Customize the session security settings.

Field

Timeout value

Description

Length of time after which the system logs out inactive users. For Portal users, the timeout is between 10 minutes and 24 hours even though you can only set it as low as 15 minutes. Select a value between 15 minutes and 24 hours. Choose a shorter timeout period if your org has sensitive information and you want to enforce stricter security.

Note: The last active session time value isn’t updated until halfway through the timeout period. So if you have a 30-minute timeout, the system doesn’t check for activity until 15 minutes have passed. For example, if you update a record after 10 minutes, the last active session time value isn’t updated because there was no activity after 15 minutes. You’re logged out in 20 more minutes (30 minutes total), because the last active session time wasn’t updated. Suppose that you update a record after 20 minutes. That’s

5 minutes after the last active session time is checked. Your timeout resets, and you have another 30 minutes before being logged out, for a total of 50 minutes.

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. The browser refreshes and returns to the login page. To access the org, the user must log in again.

EDITIONS

Available in: Both Salesforce

Classic and Lightning

Experience

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

To modify session security settings:

•

Customize Application

576

Set Up and Maintain Your Salesforce Organization Session Security

Field Description

Note: Do not select

Disable session timeout warning popup

when using this setting.

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.

Note:

This setting can inhibit various applications and mobile devices.

Lock sessions to the domain in which they were first used

Require secure connections

(HTTPS)

Require HttpOnly attribute

Associates a current UI session for a user, such as a community user, with a specific domain. The setting helps prevent unauthorized use of the session

ID in another domain. This setting is enabled by default for orgs created with the Spring ’15 release or later.

Determines whether HTTPS is required to log in to or access Salesforce, apart from Force.com sites, which can be accessed using HTTP.

This setting is enabled by default for security reasons. This setting does not apply to API requests. All API requests require HTTPS.

Note: The Reset Passwords for Your Users page can only be accessed using HTTPS.

Require secure connections

(HTTPS) for all third-party domains

Determines whether HTTPS is required for connecting to third-party domains.

This setting is enabled by default on accounts created after the Summer ’17 release.

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 setting 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 setting is enabled by default for new orgs beginning with the Summer ’14 release.

Restricts session ID cookie access. A cookie with the HttpOnly attribute is not accessible via non-HTTP methods, such as calls from JavaScript.

Note: If you have a custom or packaged application that uses

JavaScript to access session ID cookies, selecting

Require

HttpOnly attribute

breaks your application. It denies the application access to the cookie. If

Require HttpOnly attribute

is selected, the AJAX Toolkit debugging window isn’t available.

Use POST requests for cross-domain sessions

Sets the org to send session information using a POST request, instead of a

GET request, for cross-domain exchanges. An example of a cross-domain exchange is when a user is using a Visualforce page. In this context, POST requests are more secure than GET requests because POST requests keep the

577

Set Up and Maintain Your Salesforce Organization Session Security

Field Description

session information in the body of the request. However, if you enable this setting, embedded content from another domain, such as:

<img src="https://acme.force.com/pic.jpg"/> sometimes doesn’t display.

Enforce login IP ranges on every request

Restricts the IP addresses from which users can access Salesforce to only the

IP addresses defined in

. If this setting is enabled, login

IP ranges are enforced on each page request, including requests from client applications. If this setting isn’t enabled, login IP ranges are enforced only when a user logs in. This setting affects all user profiles that have login IP restrictions.

Enable caching and autocomplete on login page

Allows the user’s browser to store usernames. If enabled, after initial login, usernames are auto-filled into the

Username

field on the login page. If the user selected Remember me on the login page, the username persists after the session expires or the user logs out. The username also appears on the

Switcher. This setting is selected by default for all orgs.

Note: If you disable this setting, the Remember me option doesn’t appear on your org’s login page or from the Switcher.

Enable secure and persistent browser caching to improve performance

Enable user switching

Enables secure data caching in the browser to improve page reload performance by avoiding extra round trips to the server. This setting is selected by default for all orgs. We don’t recommend disabling this setting, but if your company’s policy doesn’t allow browser caching even if the data is encrypted, you can disable it.

Determines whether the Switcher appears when your org’s users select their profile picture. This setting is selected by default for all organizations. The

Enable caching and autocomplete on login page

setting must also be enabled. Deselect the

Enable user switching

setting to prevent your org from appearing in Switchers on other orgs. It also prevents your org users from seeing the Switcher when they select their profile picture.

Remember until logout

Normally, usernames are cached only while a session is active or if a user selects Remember Me. For SSO sessions, the remember option isn't available.

So, once the session expires, the username disappears from the login page and the Switcher. By enabling

Remember me until logout

, the cached usernames are deleted only if the user explicitly logs out. If the session times out, they appear on the Switcher as inactive. This way, if the users are on their own computer and allow a session to timeout, they can select the username to reauthenticate. If they're on a shared computer, the username is deleted immediately when the user logs out.

This setting applies to all your org’s users. This option isn't enabled by default.

However, we encourage you to enable it as a convenience to your users. Keep

578

Set Up and Maintain Your Salesforce Organization Session Security

Field Description

this setting disabled if your org doesn't expose all your SSO or authentication providers on your login page.

Enable the SMS method of identity confirmation

Allows users to receive a one-time PIN delivered via SMS. If this setting is selected, administrators or users must verify their mobile phone number before taking advantage of this feature. This setting is selected by default for all orgs.

Require security tokens for API logins from callouts (API version

31.0 and earlier)

In API version 31.0 and earlier, requires the use of security tokens for API logins from callouts. Examples are Apex callouts or callouts using the AJAX proxy. In

API version 32.0 and later, security tokens are required by default.

(for Contact Manager,

Group, and Professional Editions)

Specifies a range of IP addresses users must log in from (inclusive), or the login fails.

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.

Let users use a security key

(U2F)

Allows users to use a U2F security key for two-factor authentication and identity verification. Instead of using Salesforce Authenticator, a one-time password generated by an authenticator app, or one-time passwords sent by email or

SMS, users insert their registered U2F security key into a USB port to complete verification.

Require identity verification during two-factor authentication registration

Requires users to confirm their identities to add a two-factor authentication method, such as Salesforce Authenticator, instead of requiring a relogin as before.

Require identity verification for change of email address

Requires users to confirm their identities to change email addresses instead of requiring a relogin as before.

Note: To get the emails to confirm identity, make sure that users have access to their previously registered email accounts.

Allow location-based automated verifications with Salesforce

Authenticator

Allow only from trusted IP addresses

Allows users to verify identity by automatically approving notifications in

Salesforce Authenticator, whenever users are in trusted locations such as a home or office. If you allow automated verifications, you can allow them from any location or restrict them to only trusted IP addresses, such as your corporate network.

Allow Lightning Login

Enable clickjack protection for

Setup pages

Allows users to use Lightning Login for password-free Salesforce logins, relying on Salesforce Authenticator for identity verification.

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.)

579

Set Up and Maintain Your Salesforce Organization Session Security

Field

Enable clickjack protection for non-Setup Salesforce pages

Enable clickjack protection for customer Visualforce pages with standard headers

Description

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 orgs.

Protects against clickjack attacks on your Visualforce pages with headers enabled. Clickjacking is also known as a user interface redress attack.

Warning: If you use custom Visualforce pages within a frame or iframe, you sometimes see a blank page or the page displays without the frame. For example, Visualforce pages in a page layout don’t function when clickjack protection is on.

Enable clickjack protection for customer Visualforce pages with headers disabled

Protects against clickjack attacks on your Visualforce pages with headers disabled when setting showHeader="false"

on the page. Clickjacking is also known as a user interface redress attack.

Enable CSRF protection on GET requests on non-setup pages

Enable CSRF protection on POST requests on non-setup pages

Enable XSS protection

Enable Content Sniffing protection

Logout URL

Protects against Cross Site Request Forgery (CSRF) attacks by modifying non-Setup pages. Non-Setup pages 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. The application doesn’t execute the command unless the value found matches the expected value. This setting is selected by default for all orgs.

Protects against cross-site scripting attacks. If a reflected cross-site scripting attack is detected, the browser shows a blank page with no content.

Prevents the browser from inferring the MIME type from the document content. It also prevents the browser from executing malicious files (JavaScript,

Stylesheet) as dynamic content.

Redirects users to a specific page after they log out of Salesforce, such as an authentication provider’s page or a custom-branded page. This URL is used only if no logout URL is specified in the identity provider, SAML single sign-on, or external authentication provider settings. If no value is specified for

Logout

URL

, the default is https://login.salesforce.com

, unless

MyDomain is enabled. If My Domain is enabled, the default is https://customdomain.my.salesforce.com

3. Click Save.

580

Set Up and Maintain Your Salesforce Organization Session Security

Session Security Levels

The different authentication methods are assigned these security levels, by default.

•

Username and Password — Standard

•

Delegated Authentication — Standard

•

Activation — Standard

•

Lightning Login — Standard

•

Two-Factor Authentication — High Assurance

•

Authentication Provider — Standard

•

SAML — Standard

Note: 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

HIGH_ASSURANCE

To change the security level associated with a login method:

1. From Setup, enter

Session Settings

in the

Quick Find

box, then select Session Settings.

2. Under Session Security Levels, select the login method.

3. To move the method to the proper category, click the Add or Remove arrow.

Currently, the only features that use session-level security are reports and dashboards in Salesforce and connected apps. You can set policies requiring High Assurance on these types of resources. You can also specify an action to take if the session used to access the resource is not High Assurance. The supported actions are:

•

Block — Blocks access to the resource by showing an insufficient privileges error.

•

Raise session level — Prompts users to complete two-factor authentication. When users authenticate successfully, they can access the resource. For reports and dashboards, you can apply this action when users access reports or dashboards, or just when they export and print them.

Warning: Raising the session level to high assurance by redirecting the user to complete two-factor authentication is not a supported action in Lightning Experience. If your org has Lightning Experience enabled, and you set a policy that requires a high assurance session to access reports and dashboards, Lightning Experience users with a standard assurance session are blocked from reports and dashboards. Also, they don’t see the icons for these resources in the navigation menu. As a workaround, users with a standard assurance session can log out and log in again using an authentication method that is defined as high assurance by their org. Then they have access to reports and dashboards. Or, they can switch to Salesforce Classic, where they’re prompted to raise the session level when they attempt to access reports and dashboards.

To set a High Assurance required policy for accessing a connected app:

1. From Setup, enter

Connected Apps

in the

Quick Find

box, then select the option for managing connected apps.

2. Click Edit next to the connected app.

3. Select High Assurance session required.

4. Select one of the actions presented.

5. Click Save.

To set a High Assurance required policy for accessing reports and dashboards:

1. From Setup, enter

Access Policies

in the

Quick Find

box, then select Access Policies.

581

Set Up and Maintain Your Salesforce Organization Session Security

2. Select High Assurance session required.

3. Select one of the actions presented.

4. Click Save.

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

SEE ALSO:

Session Security

Identity Verification History

Set Trusted IP Ranges for Your Organization

Trusted IP Ranges define a list of IP addresses from which users can log in without receiving a login challenge for verification of their identity, such as a code sent to their mobile phone.

EDITIONS

Note: Who Sees What: Organization Access (Salesforce Classic)

Watch how you can restrict login through IP ranges and login hours.

To help protect your organization’s data from unauthorized access, you can specify a list of IP addresses from which users can log in without receiving a login challenge. However, this does not restrict access, entirely, for users outside of the Trusted IP Range. After these users complete the login challenge (usually by entering a code sent to their mobile device or email address), they can log in.

1. From Setup, enter

Network Access

in the

Quick Find

box, then select Network

Access.

2. Click New.

Available in: both Salesforce

Classic and Lightning

Experience

Available in all editions

USER PERMISSIONS

To view network access:

•

To change network access:

•

Manage IP Addresses

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, including the start and end values. If you want to allow logins from a single IP address, enter the same address in both fields.

The start and end IP addresses must be in an IPv4 range and include no more than 33,554,432 addresses (2

, a /7 CIDR block).

4. Optionally, enter a description for the range. For example, if you maintain multiple ranges, enter details about the part of your network that corresponds to this range.

5. Click Save.

Note: For organizations that were activated before December 2007, Salesforce 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 during the past six months were added.

SEE ALSO:

Session Security

Restrict Where and When Users Can Log In to Salesforce

Security Implementation Guide

582

Set Up and Maintain Your Salesforce Organization Session Security

User Sessions

Monitor and protect your Salesforce org by reviewing active sessions and session details on the

User Session Information page. You can create custom list views, view details about a user associated with a specific session, and easily end suspicious sessions. Salesforce admins can view all user sessions for an org; non-admins see only their own sessions.

When you manually end a user’s session by clicking the Remove button, the user must log in again to the organization.

The following table contains information about the fields you can view on this page. Due to the nature of geolocation technology, the accuracy of geolocation fields (for example, country, city, postal code) may vary.

Field

City

Country

Country Code

Created

Latitude

Location

Longitude

Parent Session ID

Postal Code

Session ID

Session Type

Source IP

Subdivision

User Type

Username

Updated

EDITIONS

Available in: both Salesforce

Classic and Lightning

Experience

Available in all editions

Description

The city where the user’s IP address is physically located. This value is not localized.

The country where the user’s IP address is physically located. This value is not localized.

The ISO 3166 code for the country where the user’s IP address is physically located. This value is not localized. For more information, see Country Codes - ISO 3166 .

The date and time stamp of when the session began.

The latitude where the user’s IP address is physically located.

The approximate location of the IP address from where the user logged in. To show more geographic information, such as approximate city and postal code, create a custom view to include those fields.

This value is not localized.

The longitude where the user’s IP address is physically located.

The type of login associated with the session. Some login types include Application, SAML, and Portal.

If a session has a parent, this ID is the parent’s unique ID.

The postal code where the user’s IP address is physically located. This value is not localized.

The unique ID for the session.

The type of session the user is logged in to. For example, common ones are UI, Content, API, and

Visualforce.

The IP address associated with the session.

The name of the subdivision where the user’s IP address is physically located. This value is not localized.

The profile type associated with the session.

The username used when logged in to the session. To view the user’s profile page, click the username.

The date and time stamp of the last session update due to activity. For example, during a UI session, users make frequent changes to records and other data as they work. With each change, both the

Updated

and

Valid Until

date and time stamps are refreshed.

583

Set Up and Maintain Your Salesforce Organization Session Security

Field

Valid Until

Description

If you don’t end the session manually, the date and time stamp of when the session automatically expires.

SEE ALSO:

The Elements of User Authentication

Understanding Session Types

Learn about the session types in the User Session Information page to help you monitor and protect your organization.

You can view the session type for a specific user on the User Session Information page. To access the page from Setup, enter

Session Management

in the

Quick Find

box, then select

Session Management.

Session types indicate the type of session a user is utilizing to access an organization. Session types can be persistent or temporary and accessed via the user interface, API, or other methods, such as an OAuth authentication process.

The following table describes the session types.

EDITIONS

Available in: both Salesforce

Classic and Lightning

Experience

Available in all editions

Session Type

API

APIOnlyUser

Chatter Networks

ChatterNetworksAPIOnly

Content

OauthApprovalUI

Oauth2

SiteStudio

SitePreview

SubstituteUser

TempContentExchange

TempOauthAccessTokenFrontdoor

Description

Created when accessing an organization through the API.

Created to enable a password reset in the user interface for API-only users.

Created when using Chatter Networks or Chatter Communities.

Created when using the Chatter Networks or Chatter Communities API.

Created when serving user-uploaded content.

A session that only allows access to the OAuth approval page.

Created via OAuth flows. For example, if you use OAuth authentication for a connected app, this type of session is created.

Created when using the Sites Studio user interface.

A session that is initiated when an internal canvas app is invoked. This will always be a child session with a UI parent session.

A session created when one user logs in via another user. For example, if an administrator logs in as another user, a SubstituteUser session is created.

A temporary user interface session to switch to the content domain, such as the user interface into which users type in their credentials.

A temporary session via the OAuth access token assertion flow that cannot be refreshed and must be mapped to a regular session type.

584