Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Problem/Bug]: AllowSingleSignOnUsingOSPrimaryAccount false doesn't work, systems microsoft account is always used! #4980

Open
haefele opened this issue Dec 9, 2024 · 0 comments
Assignees
Labels
bug Something isn't working

Comments

@haefele
Copy link

haefele commented Dec 9, 2024

What happened?

We have a application where users can login using OIDC and M365.

If the systems microsoft account is correct, setting AllowSingleSignOnUsingOSPrimaryAccount to true works great.
The user doesn't have to enter his credentials again, he is just logged in automatically - nice.

But, we also anticipated the opposite: What if the windows user should not be used and you want to login with a different microsoft account.
For this situation, we added a setting to our app where the user can basically enable/disable AllowSingleSignOnUsingOSPrimaryAccount.

It works fine for most of our machines and environments.
But one of our customers has a bunch of machines, where despite AllowSingleSignOnUsingOSPrimaryAccount being set to false, it still uses the systems microsoft account.

So basically, our user can't login, because the systems microsoft account is always used, no matter the value of AllowSingleSignOnUsingOSPrimaryAccount.

What we already tried:

  1. We added logging to the application, to make sure that AllowSingleSignOnUsingOSPrimaryAccount is definitely set to false - it is.
  2. I read here that you can also enable edge browser features through the registry or environment variables.
    In my own tests, I could reproduce the problem by setting the environment variable WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS to --enable-features=msSingleSignOnOSForPrimaryAccountIsShared.
    Now our application would always use my systems microsoft account, even if my application sets AllowSingleSignOnUsingOSPrimaryAccount to false - exactly what happens with our customer!
    Unfortunately, on the machines where this problem happens, this environment variable is not set, and also no registry value either.

This problem seems very similar to #1125 - but that bug has been fixed long ago, and we verified that on the machines with the problem, the latest evergreen WebView2 runtime is installed.

At this point, we are very much out of ideas. Are there any other ways additional browser args can be passed to WebView2 instances, that can overwrite our own configuration?

Is there any way I could check through injected JavaScript code whether the feature msSingleSignOnOSForPrimaryAccountIsShared is enabled?

Any help would be very much appreciated, so our customer is able to use our application again.

Our code

Here is the full code we use for the WebView2 initialization.
You can even see all our logging, and an attempt to work around the WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable.

protected override async Task OnViewAttached()
{
    this._userDataFolder = WebView2Helper.GetUserDataFolder(this._applicationOptions.CurrentValue, "OAuth");

    if (Environment.GetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS") is not null)
    {
        this._logger.LogWarning("Suspicious environment variable WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS is set, could impact our WebView2, so we clear the environment variable");
        Environment.SetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS", null); // Clear it, we don't want it to impact our WebView2
    }

    var options = new CoreWebView2EnvironmentOptions()
    {
        AllowSingleSignOnUsingOSPrimaryAccount = this._applicationOptions.CurrentValue.AllowSingleSignOnUsingOSPrimaryAccount,
    };
    var env = await CoreWebView2Environment.CreateAsync(
        browserExecutableFolder: null,
        this._userDataFolder,
        options);

    await this.View.WebView.EnsureCoreWebView2Async(env);
    this._logger.LogInformation("OAuth WebView2 ({Version}) environment created with SSO {SSO} at {UserDataFolder}", env.BrowserVersionString, options.AllowSingleSignOnUsingOSPrimaryAccount, this._userDataFolder);

    this.View.WebView.NavigationStarting += this.WebView_OnNavigationStarting;
    this.View.WebView.Source = new Uri(this._args.AuthorizeUrl);
}

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

131.0.2903.86

SDK Version

1.0.2792.45

Framework

WPF

Operating System

Windows Server

OS Version

No response

Repro steps

Create a new WPF application and initialize the WebView2 like this:

private async Task Loaded()
{
    var userDataFolder = WebView2Helper.GetUserDataFolder();

    var options = new CoreWebView2EnvironmentOptions()
    {
        AllowSingleSignOnUsingOSPrimaryAccount = false, // Important!
    };
    var env = await CoreWebView2Environment.CreateAsync(
        browserExecutableFolder: null,
        userDataFolder,
        options);

    await this.WebView.EnsureCoreWebView2Async(env);

    // Microsoft login page
    this.WebView.Source = new Uri("https://www.microsoft.com/cascadeauth/store/account/signin?ru=https%3A%2F%2Fwww.microsoft.com%2Fde-de%2F");
}

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response

@haefele haefele added the bug Something isn't working label Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants