Support AZURE_AUTH_LOCATION
#9312
Conversation
|
I'm not 100% sure on the design here, @schaabs, but I think this is good enough to land. I could image creating an actual SdkAuthCredential type that would be constructed with a file path, and EnvironmentCredential could create that. We could consider exposing that type as way to allow folks to use these files without setting environment variables. The reason I didn't take that approach at first is that I believe that this new token would need to be an IExtendedTokenCredential and we would have to change EnvironmentCredential to handle calling the IExtendedTokenCredential when delegating to an underlying credential if they exist, in order to not end up double wrapping errors in some cases. It started to feel like a bunch of machinery and it wasn't clear it was worthwhile. I also know that you were already a little worried regarding the number of credentials types we had and throwing more public ones into the picture didn't seem so great. Note that this does yet support a SDK Auth file that uses clientCertificate instead of clientSecret. When we end up supporting that (I assume the major blocker is going to be parsing the .pem file into an X509Certificate2) it will be easy to plug that same support in here. |
ellismg
force-pushed
the
ellismg/add-sdk-auth-env-var-support
branch
from
49c517c
to
d42018a
Compare
ellismg
requested review from
amnguye,
annelo-msft,
chidozieononiwu,
danieljurek,
erich-wang,
JoshLove-msft,
jsquire,
kinelski,
KrzysztofCwalina,
mitchdenny,
pakrym,
seanmcc-msft,
serkantkaraca,
tg-msft and
weshaggard
as code owners
ellismg
changed the base branch from
ellismg/add-sdk-auth-env-var-support
to
master
ellismg
removed request for
mitchdenny,
jsquire,
tg-msft,
pakrym,
danieljurek,
kinelski and
weshaggard
ellismg
requested review from
jianghaolu and
schaabs
and removed request for
serkantkaraca,
erich-wang,
annelo-msft,
chidozieononiwu,
seanmcc-msft,
amnguye and
JoshLove-msft
|
@schaabs I made the changes you and I discussed in person, could you please take another look? Note that at this time I have SdkClientAuthCredential as public. Do we need to do some surface area review? |
ellismg
force-pushed
the
ellismg/add-sdk-auth-env-var-support
branch
2 times, most recently
from
9f53d5d
to
a58e964
Compare
This change introduces a new type, `SdkAuthFileCredential` which can be used to support authenticating with an "SDK Auth File", which the `az` CLI can write. The file itself is just a JSON document that has information about the Tenent, Client ID and Client Secret. Under the hood, we just create a ClientSecretCredential with the information from the SDK Auth File. We also add `AZURE_AUTH_LOCATION` to the list of environment variaibles that the `EnvironmentCredential` considers.
ellismg
force-pushed
the
ellismg/add-sdk-auth-env-var-support
branch
from
a58e964
to
c2317e2
Compare
sdk/identity/Azure.Identity/api/Azure.Identity.netstandard2.0.cs
Outdated
Show resolved
Hide resolved
This reverts commit 324fdf9. There is ongoing discussion about the best way to surface this support, either in Azure.Identity itself, as a standalone sample or some other way.
This reverts commit 324fdf9. There is ongoing discussion about the best way to surface this support, either in Azure.Identity itself, as a standalone sample or some other way.
This change adds support to EnvironmentCredential so that it can
consider
AZURE_AUTH_LOCATIONas a location to get credentials. Thisfile can be generated with the Azure CLI.
The invasive part of the change here is refactoring things such that
instead of constructing the inner credential object eagerly when
EnvironmentCredentialis constructed we build it on the first call toGetToken or GetTokenAsync. This is done so that we do not have do
preform IO when constructing the credential object.
Contributes to #9309