How single sign-on works

The following diagram illustrates how Forcepoint authenticates users via your identity provider.

The user requests a web page via the cloud proxy.

The cloud service identifies the user's account.

For local users, this is based on the user's IP address.

For roaming users, this typically requires the user to enter an email address.

The service redirects the user's browser to the identity provider configured for the account.

The user's browser makes an authentication request to the identity provider.

The identity provider authenticates the user.

An authentication token is posted to the user's browser.

The token is forwarded to the Forcepoint cloud service.

The token is validated against the identity provider's metadata, and the user is identified. Policy settings for the user are checked, and the request is permitted or blocked.

The cloud service redirects the user's browser back to the requested URL.

10.

Account identification and authentication cookies are set in the user's browser. The next time the user accesses the service, the user's account is identified and the session authenticated via the cookie, without redirecting to the IdP.

11.

The browser requests the URL for the second time.

12.

The URL is retrieved and served to the user.


	Note The cloud service caches authentication sessions and sets a cookie in the user's browser upon successful authentication. Steps 3-10 above are performed only once per authenticated session. Users will only be re-authenticated if they clear their browser cookies, use a different browser, or do not re-authenticate for the session timeout duration, causing the cookie to expire. The session timeout duration is defined on the Access Control tab of your policy.

If the user's policy does not force authentication for requests with known IP addresses, the authentication process for local users happens without user interaction.

If the user's policy is set to Always authenticate users on first access, or if the user is requesting a category that requires authentication, the user receives the identity provider's sign in page. The sign in page below is an example from Microsoft AD FS. (This page can usually be customized via your identity provider's management console.)

After entering valid credentials, the user is redirected to the requested website.

Authentication for roaming or remote users

When roaming or remote users first connect from an unknown IP address, the cloud service must identify which account the user belongs to. In a default configuration, users connecting from an unknown IP address are required to identify themselves by entering their email address in a login form. This allows the proxy to match the roaming user to an account, in order to use the correct identity provider.

When the user submits a valid email address, the corresponding account is identified, and identity provider details are used to generate an authentication request and redirect the user to the provider for authentication. (If a user enters an unrecognized email address, an error will be displayed on the form and they will have to retry.)

Users are typically only required to carry out this step once; following a successful authentication, a long-lived cookie containing the user's account ID is set, allowing the service to recognize the user's account without user interaction. This step will be required again if the user connects using a different browser, clears the browser's cookies, or does not re-authenticate for a long period, causing the cookie to expire. The default lifetime duration for the account identifier cookie is 6 months.


	Note: dedicated ports (limited availability) For organizations that do not wish their roaming users to enter an email address upon first login, Forcepoint can configure a dedicated port for SSO authentication. This allows the service to identify the account for roaming users without requiring them to provide an email address. The use of a dedicated port for SSO is a limited availability feature. Please contact Technical Support if you require further information about this option.

SSO with tunneling

Single sign-on is supported for use with tunneling connectivity to the cloud service (IPsec Advanced, GRE, and EasyConnect).


	Important SSO with tunneling works only with GRE, IPsec Advanced, EasyConnect, etc. It does not work with Legacy IPsec.

Authentication fallback

If the service cannot communicate with the identity provider, users have the option to authenticate with the cloud service using a different mechanism. During the identity provider redirect process, a redirection page is shown. The page has a link that allows the user to cancel the single sign-on process and try a different authentication method.

When the user clicks this link, the service will first attempt to identify the user via transparent NTLM identification, before falling back to manual authentication (depending on the settings enabled in the user's policy). See Forcepoint Web Security Cloud Help - Access Control tab.


	Note For roaming users, manual form authentication is the only alternative method available. Authentication fallback is not supported when using a dedicated port for SSO.

Auto-provisioning

Users that are unknown to the system can be auto-provisioned to a cloud policy following successful authentication with your identity provider. Auto-provisioned users are added to the policy using either the user's email address or NTLM ID contained in the authentication token provided by your identity provider.

Auto-provisioning is supported for local users, and roaming users browsing via a dedicated port. Auto-provisioning is not supported for roaming users identifying via the account identification page.


	Note The use of a dedicated port for SSO is a limited availability feature. Please contact Technical Support if you require further information. In order to auto-provision users to a specific policy when using dedicated ports, please contact Technical Support.

Authentication decryption

When single sign-on is enabled for an account, the cloud service performs authentication decryption by default for HTTPS traffic, regardless of whether SSL decryption is enabled in the policy. This is required in order to identify users.

Consequently, customers must download the Forcepoint root certificate and install it on all client machines that will use single sign-on. This ensures that end users browsing to HTTPS sites can be authenticated seamlessly via your identity provider. If the certificate is not installed, users will see a browser error stating that the site certificate is not valid.

Supported decryption and proxy bypass settings

Because of the way single sign-on works, some bypass settings are either not supported, or may function differently for local and roaming users. Affected features are:

Authentication decryption bypass (accessed via the Web > Bypass Settings > SSL tab). This setting is used to disable authentication decryption for certain categories across all policies.

Authentication bypass by user agent or destination (accessed via the Web > Bypass Settings > Authentication Bypass tab). This setting completely bypasses authentication for specified user agents or hostnames across all policies.

SSL decryption bypass (accessed via Web > Policies > [policy name] > Web Categories > SSL Decryption Bypass). This setting is used to disable SSL decryption for specified hostnames within each policy.


	Note Non-proxied destinations are supported for both local and roaming users with SSO. Non-proxied domains are set globally on the Web > Bypass Settings > Proxy Bypass tab, or per policy under Web > Policies > [policy name] > Connections > Proxy Bypass. Non-proxied domains bypass the proxy service entirely.

Behavior differences when these features are used alongside single sign-on are detailed in the following table.


Feature	Supported for local users?	Supported for roaming users?
Authentication decryption bypass	Supported. Authentication is not performed: users can browse anonymously for policy enforcement and reporting purposes.	Not supported. All HTTPS requests for roaming users are decrypted for authentication purposes in order to identify the user. Since the bypass setting can only be applied when the user's account has been identified, this setting is not applicable; roaming users will be authenticated.
Authentication bypass by user agent or hostname	Supported. Authentication is bypassed for specified user agents or hostnames. Users can browse anonymously for policy enforcement and reporting purposes.	Not supported. All HTTPS requests for roaming users are decrypted for authentication purposes in order to identify the user. Since the bypass setting can only be applied when the user's account has been identified, this setting is not applicable; roaming users will be authenticated.
SSL decryption bypass	Not supported. If SSL decryption is bypassed for a hostname, SSO cannot be used. Users see the manual authentication welcome page.	Not supported. If SSL decryption is bypassed for a hostname, SSO cannot be used. Users see the manual authentication welcome page.