How SAML authentication works with GlobalProtect SSO
53256
Created On 09/13/21 17:50 PM - Last Modified 01/11/22 01:28 AM
Symptom
This article is designed to discuss how the authentication flow would look like when both SAML and GlobalProtect SSO are enabled
Environment
- GlobalProtect app
- Windows clients
- macOS clients
Resolution
GlobalProtect portal and external gateway have SAML authentication profile and SSO enabled.
Following are some common use-cases but not restricted to:
- When the user logs into the machine, GlobalProtect app would try using SSO credentials for portal authentication but when it detects SAML authentication, it would skip and clear the SSO credentials. The user would then be presented with a SAML login page for the very first connection or an existing SAML session cookie would be used if valid. This new (from portal authentication) or existing SAML session cookie would be used for external gateway authentication. SAML and GlobalProtect SSO username formats being the same or different will not change this behavior
- There is an internal gateway having an authentication profile with authentication types LDAP/Radius/Kerberos/Local authentication etc., other than SAML or client certificate-based authentication whose credentials are the same as SSO credentials. When the user is internal to the corporate network and logs into the machine, the portal authentication would be the same as explained in use-case scenario point 1. However when logging into the internal gateway, the following would happen:-
- User would be prompted to enter both username and password when Save User Credentials is set to Yes when it is the very first GlobalProtect connection and will not be prompted for consecutive connections
- User would be prompted to enter his/her password only as username is auto-populated when Save User Credentials is set to Save Username Only
- The reason for use-case scenario point 2 is that SSO credentials get cleared during portal SAML authentication and hence, cannot be used for internal gateway authentication
- GlobalProtect portal has Generate cookie for authentication override option checked and external/internal gateway has Accept cookie for authentication override option checked along with use-case scenario point 2 configuration. When SAML and GlobalProtect SSO username formats are different, internal gateway would end up using the portal SAML username due to the authentication cookie override. This may cause mapping issues if security policies are configured to use SSO username instead of SAML username. Hence, it is recommended that SAML and GlobalProtect SSO username formats should be the same to use portal generated authentication cookie override for external and internal gateways
Additional Information
The difference between GlobalProtect SSO and SAML authentication is as follows:
- SSO feature acquires the user’s credentials entered on their machine sign-in screen and passes onto the GlobalProtect app UI interface for authentication without user intervention. They are usually AD credentials
- SAML authentication is a browser-based authentication that uses either Cloud IdP vendors like Okta, Azure, PingID, OneLogin etc. or in-house IdP servers. GlobalProtect app uses a Web UI interface, different from its own UI interface