-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Update MSAL libraries and use new MSALRuntime-based broker implementation #1191
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
Conversation
Use the new Windows broker which is based on the MSALRuntime; an export wrapper around a native, cross-platform MSAL library. In this new set up, we drop the `.Desktop` package in favour of the `.Broker` package that also means we drop the WebView2Loader.dll, which we didn't make use of anyway. There are a few new binaries to be distrubuted in the new model, including a P/Invoke layer, IdentityModel abstractions library, and the native msalruntime_x86.dll. Note that GCM still only support x86 on Windows, and only supports broker use on Windows. For this reason we don't bother adding the broker package on non-.NET Framework builds to keep the sizes on Mac/Linux to a minimium.
Always set the parent window handle for MSAL on Windows. Previously we only set this if provided a handle by the user/config. Now however we must always try and provide a handle because using the new MSALRuntime-based Windows broker means we must do so - MSAL no longer provides us with a 'dummy' handle to use. Use the parent console window handle, as recommended by the MSAL docs: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/wam#parent-window-handles
6d7d7e1 to
134e622
Compare
|
@bgavrilMS could a member of the MSAL team have a quick glance over our usage of the new broker implementation on Windows, to make sure we're not doing something wrong? Thanks! |
ldennington
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! This allowed for a lot of nice cleanup.
3f1b017 to
cffba7a
Compare
ldennington
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest commit looks good, just a few small comments. Overall, though, I think this solution is all right until (hopefully) the issue is handled in MSAL.
If we are unable to get a parent window handle; because for example, we don't have a console, then create a small 'dummy' window using WinForms that we can use to pass a handle to MSAL.
Update the large block comment on how we select which types of flows to use for Microsoft authentication.
cffba7a to
68acbc9
Compare
|
@ldennington I've updated that outdated block comment in _MicrosoftAuthentication.cs`; did you want to have another 👀 over it? Thanks! |
ldennington
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment updates look good - thanks for doing that!
Use the new Windows broker which is based on the MSALRuntime; an export wrapper around a native, cross-platform MSAL library.
In this new set up, we drop the
.Desktoppackage in favour of the.Brokerpackage that also means we drop the WebView2Loader.dll, which we didn't make use of anyway. There are a few new binaries to be distributed in the new model, including a P/Invoke layer, IdentityModel abstractions library, and the nativemsalruntime_x86.dll.Note that GCM still only support x86 on Windows, and only supports broker use on Windows. For this reason we don't bother adding the broker package on non-.NET Framework builds to keep the sizes on Mac/Linux to a minimum.
Also update the MSAL extensions library whilst we are here to pick up various bug fixes, and drop workarounds that are no longer required for this new broker implementation!