Could you please tell me about the Embedded Browser Framework Upgrade, an enhancement of GlobalProtect version 6.3?

[y.saitou]

Attention: JAPAC TPM team
Hello Team,

I wanted to reduce the amount of user interaction with GlobalProtect's SAML authentication, so I did some research and found the following feature.
https://svc-desc.paloaltonetworks.com/mobile-users/gp/gp-agent/#embedded-browser-framework-upgrade
◇Embedded Browser Framework Upgrade
As part of pre-implementation testing, we verified the actual operation, but the results were different from what we expected, so we would like to ask a question.
On a user's Windows device, we set Chrome as the default browser and verified the following:
*The test was performed with versions of GlobalProtect before and after the version supported by this function.
*The expected operation could not be confirmed, so GlobalProtect was uninstalled, reinstalled, and the test was performed again.

◆Authentication > Use default browser for SAML authentication
-ON
-OFF
I thought that when it was ON, the browser would launch in Chrome, and when it was OFF, it would launch in Edge (WebView2),
but in both cases, the browser launched in Chrome.

◆About the behavior seen from the user's side
From the user's perspective, I think this function is whether the landing page (welcome page) displayed after connecting to GlobalProtect is automatically closed.

In the environment we tested, the landing page was not displayed to begin with,
so there was no difference in behavior from the user's perspective.

Even if my understanding was wrong and the target was a page with "click here" when connecting to GlobalProtect,
we tested with Edge as the default browser and <Use default browser for SAML authentication> disabled, but we still had to close the browser manually.

We apologize for the inconvenience, but we would appreciate it if you could also let us know if you experienced unexpected behavior.
Should you encounter any unforeseen issues with this feature's functionality, your feedback would be greatly appreciated.

[Mudhireddy · Accepted solution]

You've provided excellent detail about your testing and observations regarding the GlobalProtect "Embedded Browser Framework Upgrade" and the "Use default browser for SAML authentication" setting. It's clear you've approached this systematically, and your findings are indeed unexpected based on the documentation's typical interpretation.

Let's break down the expected behavior versus what you observed, and offer some troubleshooting insights.

Understanding the Expected Behavior:

The "Embedded Browser Framework Upgrade" leverages Microsoft Edge WebView2. The Authentication > Use default browser for SAML authentication setting is supposed to control which browser engine is used for the SAML authentication flow:

• Use default browser for SAML authentication = ON (checked):

  • Expected: GlobalProtect should launch the user's system default browser (e.g., Chrome in your test case) for the SAML authentication. This is for users who prefer or require their full browser environment for authentication.

• Use default browser for SAML authentication = OFF (unchecked):

  • Expected: GlobalProtect should use its embedded browser framework, which, with the upgrade, is based on WebView2. This means the SAML authentication prompt appears in a dedicated, lightweight window controlled by GlobalProtect, without launching a full browser application like Chrome or Edge.

Your Observed Behavior vs. Expected:

Your core observation is the unexpected part:

• You observed: When Use default browser for SAML authentication was OFF, Chrome (your default browser) still launched.

• Expected: With this setting OFF and the feature enabled, the WebView2 embedded browser should have been used.

This is a significant deviation from the documented intent.

Possible Reasons for Your Observation:

1. WebView2 Runtime Issue/Availability:

   • Is WebView2 Runtime installed? While GlobalProtect should handle this, ensure the Microsoft Edge WebView2 Runtime (Evergreen Standalone Installer) is properly installed and up-to-date on your test Windows machines. You can check in "Add or Remove Programs." If it's missing or corrupted, GP might fall back.

   • Architecture Mismatch: Less common, but ensure the WebView2 Runtime architecture (x64, x86) matches your GlobalProtect client and OS.

2. GlobalProtect Client Version & Feature Activation:

   • You mentioned testing "before and after the version supported." While you've done this, confirm the exact GlobalProtect client version on your test machine. Even if it supports the feature, sometimes specific client or portal configurations are needed to fully enable it.

   • Portal/Gateway Configuration: Double-check your GlobalProtect Portal and Gateway configurations to ensure the feature is actually enabled and pushed down to the client. The setting Authentication > Use default browser for SAML authentication is part of the client configuration.

3. SAML IdP Redirection/Compatibility:

   • Some Identity Providers (IdPs) might have specific configurations or behaviors that cause them to interact differently with embedded browsers. For instance, if the IdP's redirection logic isn't fully compatible with WebView2, GlobalProtect might be forced to fall back to the default browser.

   • IdP Configuration: Review your SAML IdP's configuration (e.g., Okta, Azure AD, PingFederate) for any settings related to browser interactions, SSO, or specific user-agent requirements for embedded vs. full browsers.

4. Licensing/Entitlement:

   • While unlikely, ensure your GlobalProtect license includes all necessary components for advanced features like the embedded browser upgrade.

5. Unforeseen Software Conflicts:

   • Less common, but other security software, browser extensions, or system policies on the test machine could potentially interfere with GlobalProtect's ability to launch or use the WebView2 control.

Regarding "Behavior Seen From the User's Side" (Landing Page vs. Authentication Page):

You're right to differentiate.

• The "Embedded Browser Framework Upgrade" primarily targets the SAML authentication page (where you enter credentials and MFA). The goal is to provide a smoother, more controlled experience for that specific process.

• The "landing page" or "welcome page" displayed after a successful GlobalProtect connection is a separate configuration in the Portal settings.

Your observation that the landing page was "not displayed to begin with" indicates that your GlobalProtect Portal might not be configured to show a post-connection welcome page, which is fine and doesn't directly impact the SAML authentication browser behavior.

Regarding the "click here" scenario:

• This "click here" prompt usually signifies that the IdP has successfully authenticated the user, but the final redirection back to the GlobalProtect client application isn't fully automatic or requires user confirmation within the browser.

• The purpose of the embedded browser (WebView2) when Use default browser for SAML authentication is OFF is precisely to eliminate this manual interaction, allowing GlobalProtect to automatically capture the successful SAML assertion and close the embedded window without user intervention.

• If you still had to manually close the browser (even with Edge as default and the setting disabled, implying an attempt at embedded browser), this strongly suggests that the WebView2 embedded browser framework is not functioning as expected, and GlobalProtect is either falling back to the default browser, or the redirection back to the GP client itself is failing to be fully automatic regardless of the browser type.

Your Next Steps (for Troubleshooting and Feedback):

1. Collect GlobalProtect Client Logs (Crucial!): This is the most important step.

   • Enable debug logging on your GlobalProtect client (often found in the client's settings or by running a debug utility).

   • Reproduce the issue where Chrome launches even when "Use default browser" is OFF.

   • Collect the complete client logs.

   • Examine these logs for keywords like SAML, webview, browser, default browser, embedded browser, launch, error, fallback. The logs should indicate which browser mechanism GlobalProtect is attempting to use and why it might be choosing Chrome.

2. Verify WebView2 Runtime: Explicitly check for its presence and version on the client machine.

3. Confirm IdP Configuration: Review if your IdP has any specific settings that might influence the return URL or browser behavior after authentication.

4. Engage Palo Alto Networks Support:

   • Given your thorough testing and the discrepancy with documented behavior, this is an ideal scenario for opening a support case with Palo Alto Networks.

   • Provide them with all your detailed observations, client versions (both before and after the feature's support), browser versions, screenshots, and most importantly, the GlobalProtect client debug logs.

   • They can analyze the logs and provide definitive answers on why the fallback to Chrome is occurring and why the "click here" interaction persists.

[y.saitou]

Hello,@Mudhireddy 

I appreciate your advice.
I'll update the case file with the information you provided.
Thank you.