Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.37k stars 4.79k forks source link

[QUERY] Is it possible to passthrough MSAL.NET authorization to Azure.Identity? #17014

Closed crwells closed 3 years ago

crwells commented 3 years ago

Query/Question Azure.Identity is only supported in a few client libraries at the moment, which means we also need to use Microsoft.Identity.Client to authenticate to the other client libraries. For interactive users, this means we use IPublicClientApplication (msal.net) and InteractiveBrowserCredential.

This makes it so a user has to potentially log in twice; once for IPublicClientApplication and once for InteractiveBrowserCredential (IBC). I have tried using DefaultAzureCredentials with IBC enabled, and with SharedTokenCache enabled.

1.) Is there some way to initialize an Azure.Identity credential with an MSAL.NET class that would let them share credentials (to get rid of the multiple login problem)? I probably don't understand what the SharedTokenCacheCredential is, or how it works -- but thought this might be the way to accomplish this. It seems to use code from msal.net, though it doesn't take on Microsoft.Identity.Client as a dependency.

2.) MSAL.NET allows you to cache the user's credentials so they don't have to re-enter their username/password at all until their token expires -- this is done via UserTokenCache.SetBeforeAccess() and .SetAfterAccess(). It seems like Azure.Identity's InteractiveBrowserCredential always requires the user to enter their password when the application restarts. I believe the only thing the cache does here is save a list of users that have logged in previously so that the user can click their account name instead of typing it in...but they always seem to have to enter a password. Am I doing something wrong, or is this correct? I've tried DefaultAzureCredentials with explicit options, and also tried InteractiveBrowserCredentials directly with explicit options (and every variation I could). I believe this was on 1.3.0-beta.2 that I tried most of these things. At some point I was also experimenting on 1.4.0-beta.1, and I cannot remember why I changed back to 1.3.0.

3.) We are installing our application on a Windows Virtual Desktop that is domain joined to an Azure AD (with Domain Services). Is there some way use Windows Authentication with Azure.Identity?

Environment: Azure.Identity 1.3.0-beta-1 Windows Virtual Desktop - Windows 10 Multisession .NET Framework 4.8

jsquire commented 3 years ago

Thank you for your feedback. Tagging and routing to the team member best able to assist.

christothes commented 3 years ago

1.) Is there some way to initialize an Azure.Identity credential with an MSAL.NET class that would let them share credentials (to get rid of the multiple login problem)? I probably don't understand what the SharedTokenCacheCredential is, or how it works -- but thought this might be the way to accomplish this. It seems to use code from msal.net, though it doesn't take on Microsoft.Identity.Client as a dependency.

For any cached credentials in MSAL, they should be used by default by Azure.Identity as long as the default cache options are used.

2.) MSAL.NET allows you to cache the user's credentials so they don't have to re-enter their username/password at all until their token expires -- this is done via UserTokenCache.SetBeforeAccess() and .SetAfterAccess(). It seems like Azure.Identity's InteractiveBrowserCredential always requires the user to enter their password when the application restarts. I believe the only thing the cache does here is save a list of users that have logged in previously so that the user can click their account name instead of typing it in...but they always seem to have to enter a password. Am I doing something wrong, or is this correct? I've tried DefaultAzureCredentials with explicit options, and also tried InteractiveBrowserCredentials directly with explicit options (and every variation I could). I believe this was on 1.3.0-beta.2 that I tried most of these things. At some point I was also experimenting on 1.4.0-beta.1, and I cannot remember why I changed back to 1.3.0.

To clarify, are you asking if the behavior to require login again after the application restarts is expected?

3.) We are installing our application on a Windows Virtual Desktop that is domain joined to an Azure AD (with Domain Services). Is there some way use Windows Authentication with Azure.Identity?

Not yet, but this is being tracked in #12219

ghost commented 3 years ago

Hi, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

ShrutiJaiswal1494 commented 2 years ago

Hi @crwells, I am facing the same issue with my Desktop Application where I am authenticating my user using MSAL.NET and I need to access storage in Azure that requires Azure.Identity credential. Were you able to figure out a way to do this/