"Why am I being prompted so frequently for authentication using SAML with WSS Agent?"

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users running WSS Agent with SAML based authentication get an authentication popup multiple times per day.

WSS Agent with SAML based authentication has a default session timeout of 24 hours, yet users are asked to re authenticate less than 24 hours from the last successful authentication.

How can I reduce the number of authentication requests a user experiences with WSS Agent and SAML authentication?

Environment

WSS Agent.

SEP Agent in tunnel mode.

SAML-based authentication enabled for the agent.

Cause

User does not have an active session on the Identity Provider (IdP) server, which triggers reauthentication.

Resolution

With WSS Agent release 9.7.1+, the WSS Agent session restore feature will prevent the user from having to re-authenticate with every new connection to the Cloud SWG service as long as the previous WSS Agent connection to this service was within the past 12 hours unless the following conditions hold true:

• the previous session is shared in Cloud SWG within a single site. Therefore, switching from one site to another (for example, switching from GUSDM to GUSLA) does not preserve the session.
• the session token is stored in-memory in the agent only. When the following actions occur, the session token is not persisted and the session cannot be restored:
  • The agent is restarted after it stops responding.
  • The operating system is rebooted.
  • The agent has been upgraded.
  • (macOS only) The network extension is reloaded.
• The session token is delivered to the agent using the whoami response. Therefore, if a whoami failure occurs, the subsequent connection has no session to restore.
• If the Cloud SWG proxy cannot retrieve the token for any reason (for example, the token is expired or purged from the cache), the subsequent connection has no session to restore.

 

Any time the agent connects or reconnects, the user is redirected to the SAML IdP server to authenticate. The agent first connects shortly after the user logs into their machine. Reconnects can subsequently occur for various reasons, such as:

• A user moving through an office building with spotty WiFi coverage
• A laptop waking from its sleep state
• Manual reconnects

Certain networking environments will trigger more agent reconnects than others, which can result in more user-visible authentication prompts. Whether or not the user sees an authentication prompt following a connect/reconnect event is dependent on your IdP settings.

When reconnects occur, if the user has an active session on the IdP server, the user is not prompted for login, and authentication proceeds automatically. If there is no active session on the IdP server, the user will be prompted for credentials.

Most IdP servers offer a variety of ways to control and manage the user sessions, which can help moderate the number of login events experienced by end users. To learn more about the session controls offered by your IdP and how to implement them, please consult directly with your IdP vendor. Some relevant session controls that might be made available by the IdP include:

Session Cookie: While running, WSS Agent will maintain a single, sandboxed browser session which is separate from the user’s browser session. This session preserves and reuses any session that the IdP stores in a session cookie, sending it to the IdP each time authentication is required. The IdP then uses that session cookie to reuse the user’s session without prompting the user. However, the browser session used by WSS Agent is stored in memory and will be reinitialized upon reboot, invalidating the session cookie, resulting in the user being prompted for their credentials each time there is a reboot.

Persistent Cookie: Useful if your goal is to only prompt users to authenticate very infrequently. WSS Agent has a sandboxed persistent cookie store which is separate from the user’s browser cookie store. The persistent cookie store preserves and reuses any session that the IdP stores in a persistent cookie and sends it to the IdP each time it requires authentication. The IdP then uses that persistent cookie to reuse the user’s session without prompting the user. Persistent cookies survive reboots and can only be revoked by invalidating the session on the IdP server or with an IdP-provided timeout setting, if supported.

In the event that a session does not exist on the IdP or if the provided cookies are expired or invalid, the IdP authenticates the user. The following mechanisms may be supported by your IdP to simplify the user’s signon experience:

Azure AD SSO (Windows-only): If you are using Azure Active Directory as your Windows logon provider, you can configure the Azure AD IdP to use Single Sign On.  When WSS Agent sends the authentication request to Azure AD, it will include your Windows SSO information as well, allowing Azure AD to create a corresponding session.  This functionality requires WSS Agent 8.2.2 or later.

Client Certificate Authentication: If the IdP supports client certificate authentication, a certificate can be issued from the IdP and distributed to the endpoint. WSS Agent sends any client certificates configured for identifying web requests to the IdP during the SSL/TLS handshake, and the IdP uses that certificate to create or reuse a user’s session without prompting the user.

Kerberos / NTLM (Windows only): If the IdP supports Kerberos or NTLM authentication and the device is configured to properly send Kerberos / NTLM tickets to the IdP, WSS Agent sends the current Kerberos / NTLM ticket to the IdP during its authentication process. This has the effect of automatically logging into the IdP without prompting the user for credentials.

Web-based prompt: If none of the above session identification or autologin mechanisms are configured or available in the IdP, then the IdP will prompt the user for credentials via a web form. Multi-factor authentication is supported via this mechanism as well. Some IdPs tie a user’s session to their egress IP address and will likely require credentials when the user changes location or gets assigned a new NAT’d IP address by their ISP. In these cases, a web-based prompt will be displayed even if using other session control mechanisms.

If the user has a valid session on the IdP server, or they are successfully authenticated, the SAML IdP server will send an assertion back to the WSS proxy with user specific information (user name and user group memberships). The WSS proxy validates the assertion and, assuming it is valid, updates the SAML realm table with the user’s information with a session lifetime of 24 hours. All subsequent requests coming from the WSS Agent host will be authenticated for 24 hours or until the agent reconnects.  After 24 hours, or upon agent reconnect (whichever occurs first), authentication is requested again from the IdP, and the above mechanisms will be used to automatically provide credentials or reuse the previously-established user session.

When tuning the IdP settings to reduce authentication prompts, be sure to take into consideration the impact to your organization’s security posture. Very long session persistence could expose the organization to additional risk.

Additional Information

By design, WSS Agent has no visibility into the IdP’s session or persistent cookies that are used for login, nor does it have access to the SAML session duration.  WSS Agent facilitates the SAML transaction by opening a webview component or the system browser, and that component handles the cookie lifetime, storage, and negotiation of the user's login session that occurs between the Cloud SWG Proxy and the SAML IdP server.