1800971 - Enabling Windows SSO login in Firefox settings bypass container isolation

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[Danny Colin [:sdk]]

Steps to reproduce

1. Configure a Microsoft account on your Windows OS
2. Enable Windows SSO in Firefox (https://support.mozilla.org/en-US/kb/windows-sso)
3. Enable Firefox Containers manually or by installing Multi-Account Containers
4. Create a new container
5. Go to a website where you can login with your Microsoft account

What happened? (actual results)

You're automatically logged in your Microsoft account inside the newly created container

What should have happened? (expected results)

Enable Windows SSO in Firefox should respect the container isolation by not automatically login the user in if they are in a container.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Cloud Services::Server: Firefox Accounts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mike Kaply [:mkaply]]

Windows SSO is not bypassing container isolation because information is not shared between containers.

In each individual container, the information is queried from the operating system and used.

There's really no practical way to do what you are asking because we would have to build UI to enable Windows SSO on a per container basis.

Only using it for the main browser process would affect folks who need it for containers.

If you don't want the behavior, you should just turn off Windows SSO.

Comment 3

[Danny Colin [:sdk]]

A bit of context: I filed it on behalf of a few users who were finding this behavior unexpected when using Containers

There's really no practical way to do what you are asking because we would have to build UI to enable Windows SSO on a per container basis.

I understand that it isn't a trivial thing to implement or that it isn't something we want to implement at all. However, I feel that it still break the UX of Containers and we have no way on our side (Multi-Account Containers maintainer here) to detect this feature and let the user know why they are automatically logged to their MS account and that it doesn't bypass the isolation but connect them in every containers.

Would it be possible to consider adding something in about:preferences to let a user knows about that if we detect that Containers is also enabled when they enable MS SSO?

Comment 4

[Mike Kaply [:mkaply]]

Would it be possible to consider adding something in about:preferences to let a user knows about that if we detect that Containers is also enabled when they enable MS SSO?

What does "containers enabled" mean though? On nightly, it's always there, on release you have to have an addon. Do we have any way to know that someone is truly using containers?

I'm curious as to what users said as to why they didn't expect this behavior. They didn't login explicitly in either Firefox main or a container, so that wouldn't be what's carrying over to another container. They had to explicitly check the box (it's not on by default anywhere)

Comment 5

[Danny Colin [:sdk]]

I'm curious as to what users said as to why they didn't expect this behavior.

Users expect that the same account isn't logged in in multiple containers. For example, if I'm logged in to my gmail work account in my work container, I shouldn't be logged into it on my personal container. So your assumption that they expect to have explicitly logged in is right.

Further, I assume they may have enabled MS SSO and forgot about it or they thought it was only going to log them in the "No container" bubble. I haven't tested it myself but I guess MS SSO doesn't apply to private browsing right? Lots of container users are seeing them as a "private browsing from other container that persists reboots". So again, it breaks their expectation that something they consider only tied up to the "No container" is also affecting their containers.

Finally, they don't know that the login cookies for MS SSO aren't shared across containers but that they are logged with a new cookie "session" in each of them. That's where they might think the isolation is broken. On top of that, even if the cookies aren't shared, since you're logged to the MS account isn't it any risk now that data can be shared from one MS session to the other and in fact breaks the expected isolation?

Comment 6

[Mike Kaply [:mkaply]]

For example, if I'm logged in to my gmail work account in my work container, I should be logged into it on my personal container.

Unfortunately that statement alone shows the problem here because there's no way to target Windows SSO at a work container.

I'm starting to lean towards your original idea of not using Windows SSO in a container (maybe a hidden preference to turn it on)?

Is there an easy way to detect that we are in a container here?

https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#419

Comment 7

[Danny Colin [:sdk]]

Is there an easy way to detect that we are in a container here?

At a quick glance, I don't think there's anything to detect that but :baku is probably more familiar than me with the container implementation on Firefox side.

I'm starting to lean towards your original idea of not using Windows SSO in a container (maybe a hidden preference to turn it on)?

I'd prefer something easier for the user to toggle on/off. Maybe something in about:preferences#containers. However, it could use an hidden preference and work on the UI in a follow-up bug.

Also, I'll reopen the bug while we're still discussing this.

Comment 8

[Valentin Gosu [:valentin]]

(In reply to Mike Kaply [:mkaply] from comment #6)

Is there an easy way to detect that we are in a container here?

https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#419

if mLoadInfo->GetOriginAttributes().mUserContextId != nsIScriptSecurityManager::DEFAULT_USER_CONTEXT_ID I think that means we're in a container.

Comment 9

[:Gijs (he/him)]

There's really no practical way to do what you are asking because we would have to build UI to enable Windows SSO on a per container basis.

Why is that not practical? We could use a permissions system for non-default containers, and use our standard permissions prompt UI, I think? Or is there some reason that won't work?

I don't know specifically how Windows SSO works (ie what tracks the login state - is it all just in calls to Windows APIs?), and how we treat e.g. private browsing (I'm hoping we don't expose Windows login username etc. to private browsing content!), but in principle it seems possible to build UI for this with minimal UX input. We might not want to prioritize it based on data we have (how many people use Windows SSO vs how many people use containers, or something) but that seems like a separate question...

Comment 10

[Mike Kaply [:mkaply]]

Why is that not practical? We could use a permissions system for non-default containers, and use our standard permissions prompt UI, I think? Or is there some reason that won't work?

I was referring specifically to the idea of having a preference per container because the way you would want this to work is to say "Use Windows SSO for container X, but not for container Y" and the containers UI doesn't have an existing mechanism that we could hook onto to implement.

I don't know specifically how Windows SSO works (ie what tracks the login state - is it all just in calls to Windows APIs?), and how we treat e.g. private browsing (I'm hoping we don't expose Windows login username etc. to private browsing content!),

It reads the Windows API and attaches cookies/headers to reqeuests. It doesn't do this in private browsing.

https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#419

Comment 11

[Valentin Gosu [:valentin]]

Mike, do you want to take this bug, or should Necko handle it?

Comment 12

[Mike Kaply [:mkaply]]

If Necko could handle it that would be great. Not sure exactly what we're going to do though.

Comment 13

[perdjesk]

I would like to add the suggestion to align this per-container configuration for Windows SSO (i.e Win32 version) with the SSO of "integrated authentication (SPNEGO) .

Even if the implementations are widely different in both cases the SSO picks-up an identity from the host, thus the configuration per-container would carry the same meaning of whether SSO identity from host is available within a container.

The downside of having a common configuration at container level for both SSO types would be for users that have configured in main browser both Windows SSO and SPNEGO (and assuming each provide a different identity), and that wish to have only one of those available within a container. That could be considered a rare and edge case not covered by containers.

Comment 14

[info]

Hi,

Last remark in this bug/feature is now two months old. Could we get an update? Since company changed SSO policies the SSO checkmark is required to login to applications but the SSO should be limited to one -to define- container only.

Thanks in advance for your reply and possible fix :)

P.s. I'd love to help if any additional information is needed!

Comment 15

[Mike Kaply [:mkaply]]

This isn't currently a high priority as we don't have a good sense of container usage in enterprise.

The only thing we could reasonably do in the short term is have a preference to not use Windows SSO (or SPNEGO) in containers (only the main window). Doing it per container would take a lot more work.

Comment 16

[Valentin Gosu [:valentin]]

Attachment: Bug 1800971 - Limit windows-sso to the default container tab by default r=mkaply,edgul

This patch adds a check for the pref network.http.windows-sso.container-enabled.{containerID}.
We also default the pref for the no-container userContextId to true.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e6a701562ad6
Limit windows-sso to the default container tab by default r=mkaply,edgul

Comment 18

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/e6a701562ad6

Comment 19

[Ina Popescu, Desktop QA]

I've reproduced the issue using Firefox 112.0b6 on Windows 10x64 following STR from Comment 0.
The issue is no longer reproduceable in the latest Firefox 113.0b8 version where the Microsoft Accounts from Email & Accounts were not autocompleted on the Microsoft sites opened in containers.