Closed Bug 1695693 Opened 3 years ago Closed 3 years ago

Implement Windows 10 SSO on Firefox

Categories

(Core :: Networking, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: mkaply, Assigned: mkaply)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

Microsoft Edge and Internet Explorer support authenticating automatically to Microsoft websites if you are logged in with a Microsoft identity on Windows 10.

To support this on Chrome, they built an extension called Windows 10 Accounts:

https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji?hl=en

For Firefox, someone ported the extension but it is not officially supported:

https://addons.mozilla.org/firefox/addon/windows-10-accounts-port/

I would like to propose that we add this support to Firefox.

I've communicated with the Microsoft team and the implementation is quite straightforward.

When a URL is loaded, you call the Windows API IProofOfPossessionCookieInfoManager::GetCookieInfoForUri documented here:

https://docs.microsoft.com/en-us/windows/win32/api/proofofpossessioncookieinfo/nf-proofofpossessioncookieinfo-iproofofpossessioncookieinfomanager-getcookieinfoforuri

If there are cookies for that URI, we attach them to the URL. If the cookies begin with x-ms-, we add them as headers.

The Microsoft team has indicated that this API is quite fast and as such can be done for every URL, but if we don't want to do that we can either enable it via policy or only do it for login.microsoftonline.com and live.com.

Enabling this functionality in Firefox will give us a clear advantage over Chrome and position us better in Microsoft environments.

I have Microsoft contacts if we need more info.

I'm looking to implement myself with guidance from the Necko team.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]
Assignee: nobody → mozilla
Status: NEW → ASSIGNED

Here's some code that shows the API calls.

https://github.com/leechristensen/RequestAADRefreshToken

This looks interesting, Mike.
I'm currently doing some light refactoring of some of our authentication code in bug 1705659.
Right now we handle HTTP authentication in nsHttpChannelAuthProvider
Not sure exactly if this maps exactly to the existing auth methods, but that's a good place to start.
If you get blocked on anything let me know and I'll try to help.

This wouldn't touch auth per say. It's really just about querying cookies/headers from Windows for a given URL, and attaching them if they exist.

Right now they only exist for Microsoft sites.

We had already chat about this.

Do you need help creating a new xpcom API fro this?

Do you need help creating a new xpcom API fro this?

In that discussion, we were trying to decide if it should go front end or backend and we never came to a conclusion :).

It really boils down to if one day, this API will be called for every URL (which is what Microsoft is asking for).

I guess what I can do is implement it, profile it and see how it affects things.

I would only need an XPCOM API if I was going to call it from JS.

Let's do it in c++:
Have the implementation in a separate file that will be called from nsHttpChannel.
I think we only need API with one function: input parameter should be URI and output parameter should be nsACString to set or empty string if we do not need to set a cookie (or somtething similar)

It seems to me from the extension code that we don't really need to run it for all URLs, only for https://login.microsoftonline.com/* ?
So it should not really affect general performance.

Also, they seem to be changing the UA string so we get the SSO option:

// Let Microsoft think we're using Chrome, so the SSO option will be available.
let ua = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36';

I assume we can address this later with Microsoft.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)

It seems to me from the extension code that we don't really need to run it for all URLs, only for https://login.microsoftonline.com/* ?
So it should not really affect general performance.

That's what the extension is doing, but not technically correct. That API from Microsoft is a generic "See if the OS has cookies to add to this URL"

Also, they seem to be changing the UA string so we get the SSO option:

// Let Microsoft think we're using Chrome, so the SSO option will be available.
let ua = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36';

That's unnecessary. Microsoft has indicated that if the proper headers are attached, this won't be necessary.

Our implementation will be better than what the extension is doing.

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

That's what the extension is doing, but not technically correct. That API from Microsoft is a generic "See if the OS has cookies to add to this URL"

That's interesting. There are a few things I'd like us to consider going forward.

  • if the channel has mLoadFlags & LOAD_ANONYMOUS we should not add the cookies for it. I suspect we'll need a similar thing for private browsing.
  • do we need to worry about this interface misbehaving and creating a sort of global tracking cookie?
  • if a website is misbehaving because of these cookies, is there a way to clear them?

Also, they seem to be changing the UA string so we get the SSO option:
That's unnecessary. Microsoft has indicated that if the proper headers are attached, this won't be necessary.

Excellent!

Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/878cf854fd73
Add support for Windows 10 SSO on Firefox. r=valentin,necko-reviewers,dveditz,johannh
Regressions: 1716834
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
Depends on: 1800971
Depends on: 1802325
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: