Closed savannahostrowski closed 8 months ago
This is really interesting. I do agree it's something we need to do short-term.
I wonder what Azure Tools is using under the covers. If it's az
, I wonder if this is signaling the fact that we have started to diverge away from az auth
is causing friction.
Long-term, the complex web of "Azure developer tool 1" needs to understand and work with "Azure developer tool 2" and "Azure developer tool 3" in a 3-way graph seems an impossible engineering task, and I think this further solidifies the need for a central auth tool.
I've chatted a bit with @bwateratmsft about this. He'll have the specifics here.
Long story short, when the Azure Account extension moved to using VSCode's built-in credential storage, it broke VisualStudioCodeCredential
in the Azure SDK--which further broke DefaultAzureCredential
. We really need a unified solution for developers to work across many tools without needing to sign in many times. I think this is going to primarily be a job for the Azure SDK team.
A related ask if we're doing work to unify the auth experience - it would be great to have a shared telemetry property across VS Code Azure events that indicates if the user has authenticated with the Azure extensions/azd. This would enable us to surface different getting started content based on the user's authentication status (i.e., prompt unauthenticated users to sign-in/create an account & nudge authenticated users to become more deeply engaged)
I talked about a prototype solution here with @bwateratmsft that I would like to build. I'm envisioning a way for azd
to delegate token fetching to an external process by doing something similar in spirt to MSI where we request a token from a local endpoint (protected by a shared ephemeral key).
We want to prototype something like this during the 1.2.0 timeframe, not committed to shipping it yet, but we want to start getting some investment in some prototypes to show some end to end scenarios.
@savannahostrowski , I still need to run some tests for multi-tenant scenarios.
@vhvb1989 moving it back to @ellismg to work with @bwateratmsft on this.
@ellismg @vhvb1989 @bwateratmsft seeing the POC https://github.com/Azure/azure-dev/pull/2541 has been merged. Can we release this for Nov release 1.5.0?
Should be fine. When do we want to release the ADE / environment changes?
@savannahostrowski @ellismg @bwateratmsft Not a must-fix for 1.5.0. Moving it to Jan milestone.
I think @ellismg's PR actually does this though. I don't know if there is any work remaining.
Is this completed and just unreleased then?
Remember @vhvb1989 mentioning about the multi-tenant scenarios. May be its out of scope for now and release what we have? Also, should we enable the feature by default in VSCode? @bwateratmsft
What do you think @ellismg @bwateratmsft
We should be able to run it as an A/B experiment
I think @ellismg's PR actually does this though. I don't know if there is any work remaining.
The PR went in another direction, @bwateratmsft , by having azd using its own authentication within VSCode, and not by re-using the authentication from the azure-account extension. This was because we were told that the azure-account was going to change and eventually move to do what azd is doing on the PR. But, we can't release it if the azure-account is not there, as the main story we want to have for customers here is that, if they log in with the azure-account extension, they don't need to log in with azd
The Azure Account extension is eventually going to be deprecated. There is no timeline yet but the current guidance is to use the builtin Microsoft authentication provider.
@v-xuto can we test this and make sure it works?
Currently the feature is toggled off. Can be enabled from vscode azd extension
settings, I guess @bwateratmsft? Refer PR for more details https://github.com/Azure/azure-dev/pull/2541
cc: @gkulin for capturing it in docs FAQ may be?
@rajeshkamal5050 @ellismg @bwateratmsft Enabled azure-dev.auth.useIntegratedAuth
from vscode azd extension
settings, and try to run azd auth login
and deploy resource. At this point, my Azure tools display as not logged in and unable to see any resources.
When click "Sign in to Azure", we can see the resources created by azd
.
This is expected. There is no way currently for sign in from azd
to make its way up to VSCode.
This is expected. There is no way currently for sign in from
azd
to make its way up to VSCode.
@v-jiaodi please validate it the other way around. Post signing into Azure from VSCode
should not require signing into azd
@rajeshkamal5050 When signing into Azure from VSCode
, you can see Azure Resources, but when executing azd up
, it prompts: not logged in, run azd auth login to login
The exact steps are a little different. The extension launches azd
processes with a nonce that gives access to the token server. So only processes launched by the extension can benefit from the shared authentication.
azure-dev.auth.useIntegratedAuth
:
azd auth logout
in the terminal to ensure AZD is not signed in.azd up
command, this should succeed. It has obtained auth information from the extension.@bwateratmsft Following the steps you mentioned, it works.
We need to figure out how we can leverage the same token/credentials for the
azd
extension in VS Code as the Azure Tools extension pack.Right now, this inconsistency means that I can open a project/start a project in VS Code that leverages my work subscription via
azd
but Azure Tools is logged into my personal subscription. As such, I cannot "Show resource group" for my current project until I log out of my personal sub and reauthenticate with my work sub via the Azure Tools extension pack.