OneAuth integration on Windows#3216
Conversation
...but not logout --debug because some work is needed to propagate the global debug option
go linker can't handle a 32-bit syso in a 64-bit build
|
This is awesome! IMHO, I would rather see the OneAuth as an external binary (instead of embedded library). Is there a reason why that approach wouldn't work? Probably a tool on azure-sdk-tools repo (or its own repo) which publishes a 64-binary and a 64-arm binary on github. The tool would become beneficial for other cli as well, like az. And we could let azd to chose interactive-browser or OneAuth with app-configuration, instead of build-arg... |
|
Thanks @chlowell, This is some work that Charles did to get Charles is going to take these learnings back to the OneAuth team and see if we can make some improvements to their library to make it easier for tools like us to consume. I asked @chlowell to open this PR because the stuff is behind a build flag so there should be no impact to the standard AZD builds. I think we will want to take and merge this code (still behind a flag) and maintain it because we might need to integrate with OneAuth at one point (for one thing, it gives us an answer for WAM support, something people mention from time to time internally). |
|
Thanks for the context @ellismg Still curious about the "why" around making azd to consume a |
|
Thanks for adding context @ellismg. To add some more, this is part of an effort to unify DevDiv tools on a single authentication stack to reduce duplicate effort, unify UX, and make single sign-on possible.
The OneAuth team doesn't ship binaries because the project is for first-party use only. |
ellismg
left a comment
There was a problem hiding this comment.
Did an initial pass and made some notes. I suspect that we'll want to be archiving the PDBs for bridge.dll and perhaps doing something so they are cataloged by a symbol server (at least for our official builds).
@chlowell , if I understand correctly, we are introducing a go-layer to azd to call the C++ library (think we call it Either way, looks like we would be signing to maintain Let me pull @JeffreyRichter and ask for advising here. |
Sorry, I don't understand. |
For what I'm reading in the code, we are not creating an I am wondering if we can move the c++ code to its own repo and update the code to create an exe file (having a main() entry point for the OS to init :). Then, from azd, we would use the |
Co-authored-by: Matt Ellis <matt.ellis@microsoft.com>
ellismg
left a comment
There was a problem hiding this comment.
Thanks again for doing all this gnarly work, @chlowell. I owe you a coke or something for shielding us from having to write a CMakeLists.txt file.
I would of course still prefer if we could get to a world where we could statically link the one-auth library into our binary and not have to do all this gross stuff around embedding dlls and then dropping them into a folder - but I understand why we are where we are today. Hopefully you'll have some luck pushing on upstream to make something that's a little more palatable for go devs to consume.
I'm happy for us to land this change behind the build flag and have us pay the cost of maintaining this for now. I'm still not sure I want to enable this by default in azd but having the code here for when we are ready to turn it on makes sense.
It would be nice to get at least some coverage of the build (I don't think we need to run tests - and also, I think running these tests in CI would be "hard"). Maybe @danieljurek can help get another leg of our pipeline that passes a path to the msys2 shell and skips the tests.
|
Thanks for all the feedback. I'll mark this ready to review when I think it's ready to merge. I'm still debugging MSA authentication, which looks like it should work but doesn't.
👍 I agree, today this is a lot of complexity for not much benefit. How would you feel about shipping it in a beta?
Once you've got build automation the tests should just work in CI--they don't require user interaction--provided the agent can write %LocalAppData%. Setting up the build is hard though 😞 |
|
Late to the train here :) But I'd +1 to OneAuth either exposing static linking via C ABI or an out-of-proc execution model. This would also benefit Rust programs as well for FFI (which seems to have increasing adoption). |
I would be fine with this - just nervous about making it the default on windows right away, but happy to let folks opt into the world. I'd also be happy with us flighting it to say 20% of our windows users for the default interactive login mode and doing a progressive rollout that way. We have the technology now to do such things (and we did it for some earlier work) so happy to do that here as well. |
|
@chlowell curious, what are the file sizes of these dependencies? |
Their release builds add up to ~4.3 MB. |
|
I made a few changes to better support MSA scenarios:
|
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSIContainerDocumentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
This adds a build tag (
oneauth) that replaces browser auth on Windows with OneAuth i.e., when this tag is set, azd will open OneAuth's login window instead of a browser. Other platforms and auth flows aren't affected. OneAuth is a C++ library, so calling into it from Go requires cgo and a C ABI. cgo requires a gcc compiler; I've used MSYS2 to install and configure MinGW. OneAuth doesn't have a C ABI, so this PR includes a bridge library that does. Building OneAuth for Windows (and hence the bridge library) requires MSVC. The go link tool can't link MSVC objects, so static linking is out of the question and distribution is awkward. I have azd embed the bridge DLL and write it to%LocalAppData%/azdat runtime when needed.