What triggers the authentication to pop the QT browser window?

[tozachroberts]

Hello @yuezk (and everyone else who enjoys this client),

Recently something changed in my client + VPN situation, and the gpclient is no longer popping open the QT browser window which allows my VPN's 2-factor system to authenticate (Duo). This was working prior to my most recent apt update so I am trying to debug, and curious what actually triggers the decision in gpclient to choose to pop the native dialog window with username + password fields versus popping the QT browser window with the 3rd party (saml?) auth challenge?

Current state (where the native username + password dialog is presented) logs attached
gpclient-terminal-out.txt

[yuezk]

It will launch the browser if it detects the SAML-related fields (<saml-auth-method> and <saml-request>) in the prelogin response.

GlobalProtect-openconnect/GPClient/gatewayauthenticator.cpp

Lines 102 to 104 in 2069b7f

	if (response.hasSamlAuthFields()) {
	samlAuth(response.samlMethod(), response.samlRequest(), reply->url().toString());
	} else if (response.hasNormalAuthFields()) {

The following response will trigger the SAML authentication.

<?xml version="1.0" encoding="UTF-8"?>
<prelogin-response>
    <status>Success</status>
    <ccusername></ccusername>
    <autosubmit>false</autosubmit>
    <msg></msg>
    <newmsg></newmsg>
    <license>yes</license>
    <authentication-message>Enter login credentials</authentication-message>
    <username-label>Username</username-label>
    <password-label>Password</password-label>
    <panos-version>1</panos-version>
    <saml-default-browser>yes</saml-default-browser>
    <cas-auth></cas-auth>
    <saml-auth-status>0</saml-auth-status>
    <saml-auth-method>REDIRECT</saml-auth-method>
    <saml-request-timeout>600</saml-request-timeout>
    <saml-request-id>0</saml-request-id>
    <saml-request>
        aHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbm......
    </saml-request>
    <auth-api>no</auth-api>
    <region>HK</region>
</prelogin-response>

[tozachroberts]

SEE FOLLOWING MESSAGES, this one remains just to show what a native working client receives as a pre-login response.

It appears that for my specific VPN, the pre-login response has a different XML root element. Caveat, this response was taken from a working client's logs, not from gpclient output (working on that next). My working client's response looks like:

<response>
	<type>saml-pre-login</type>
	<status>Disconnected</status>
	<protocol/>
	<portal-config-version>4100</portal-config-version>
	<error-must-show/>
	<error-must-show-level>error</error-must-show-level>
	<error/>
	<product-version>6.0.0-262</product-version>
	<product-code/>
	<portal-status>User authentication failed</portal-status>
	<user-name>USERNAME-REDACTED</user-name>
	<username-type>saml</username-type>
	<state>Retrieving configuration...</state>
	<check-version>no</check-version>
	<portal>DOMAINREDACTED.gpcloudservice.com</portal>
	<discover-ready>no</discover-ready>
	<mdm-is-enabled>no</mdm-is-enabled>
	<saml-auth-status>0</saml-auth-status>
	<saml-auth-method>REDIRECT</saml-auth-method>
	<saml-request>...REDACTED...</saml-request>
	<prelogin-cookie/>
	<saml-prelogin-portal>yes</saml-prelogin-portal>
	<saml-chrome-sso-support/>
	<cas-auth>no</cas-auth>
	<saml-default-browser>yes</saml-default-browser>
	<saml-request-id>0</saml-request-id>
</response>

It appears that the expected fields are present, although the root xml element is different: mine is instead of and therefore doesn't find the necessary <saml-auth-method> and <saml-request>.

I am not fluent in cpp, but it doesn't look like the parsing logic should care about the root element difference as long as the child elements are properly named and exist. Is the root element difference possibly the cause and I am just missing it, or is there possibly some variation of the values of saml-auth-method and saml-request which are causing it to fail the .hasSamlAuthFields() test?

[tozachroberts]

Ok, disregard the above example, I figured out how to snag the pre-login-response that gpclient is getting (curl'd the URL from the stdout messages.)

<?xml version="1.0" encoding="UTF-8" ?>
<prelogin-response>
<status>Success</status>
<ccusername></ccusername>
<autosubmit>false</autosubmit>
<msg></msg>
<newmsg></newmsg>
<license>yes</license>
<authentication-message>Enter login credentials</authentication-message>
<username-label>Username</username-label>
<password-label>Password</password-label>
<panos-version>1</panos-version>
<saml-default-browser>yes</saml-default-browser><connected-ip>REDACTED</connected-ip><auth-api>no</auth-api><region>US</region>
</prelogin-response>

So, it appears that gpclient is receiving a very different pre-login-response than the native client. I'll start digging in to what is sent to the earlier calls, but any pointers are appreciated @yuezk.