Support AccessToken in config for AddDistributedSqlServerCache

[MobesE46]

Is your feature request related to a problem? Please describe.

I'm trying to setup Distributed SQL Caching so that is uses an AccessToken to connect to an Azure SQL database instead of using other types of credentials.

Describe the solution you'd like

Now that Net Core 2.2 supports the AccessToken property on a SqlConnection, the AddDistributedSqlServerCache extension should be modified to support this as well. Perhaps an overload could be added that takes in a delegate to retrieve an AccessToken. The delegate would just need to be a simple factory method that does something like this:

        var tokenProvider = new AzureServiceTokenProvider();
        var accessToken = tokenProvider.GetAccessTokenAsync("https://database.windows.net/").Result;

In a web environment, the factory should be scoped to the session.

Or perhaps even build this AccessToken retrieval into the extension.

Describe alternatives you've considered

I've considered writing my own implementation of IDistributedCache that takes advantage of the AccessToken property but I'm not quite sure how to accomplish it and I don't have the time right now. At the moment, I'm just using the classic implementation of the extension which passes in a connection string that is transformed between environments in an Azure Devops pipeline.

Additional context

[DOMZE]

Same problem here. Impossible to pass an access token. How are we supposed to use managed identities otherwise, without overwriting the whole library? Workarounds are appreciated @Eilon

[jacqueskang]

Hi, this is a blocking issue for our Azure migration. Since our security team doesn't accept password-based SQL authentication, we will have to refactor and switch to another caching system. It would be nice if this can be solved in both 2.2 and 3.0

[Eilon]

I realize it's not ideal, but I think you can re-use a lot of the current cache system logic and probably types, but with a modified copy of the configuration logic. You could use the source code in this repo as a starting point and modify the code that creates the services to support other auth patterns.

[ghost]

As part of the migration of components from dotnet/extensions to dotnet/runtime (https://github.com/aspnet/Announcements/issues/411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days.

If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help!

[yonail]

It is still a blocking issue for our Azure migration. Any update when you plan to fix it for .net core 2.2?

[ghost]

Paging @dotnet/extensions-migration ! This issue has been revived from staleness. Please take a look and route to the appropriate repository.

[analogrelay]

@yonibauduin .NET Core 2.2 is end of life and no longer supported.

I’ll put this in the queue to consider in 5.0, which is the next opportunity to add functionality requiring new API such as this

[ckrempp91]

Is there any update on this?

[maryamariyan]

I believe this wouldn't make it to 5.0 as the window for that is closing this week and this is a feature request.

[ckrempp91]

If it can't make it into 5.0, then what is the next release that this can be included?

[Nisden]

Wow, this is still unsupported... :'(

[paul-oleary]

+1

This is a blocker for us disabling SQL authentication on our database

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[Nisden]

With the addition of https://github.com/dotnet/SqlClient/pull/730 explicit support for AccessToken is no longer required, as the SqlConnection can handle this on its own. Just be aware that its currently a little broken https://github.com/dotnet/SqlClient/issues/815

[hugoqribeiro]

While a better solution is not designed, wouldn't it be possible to at least provide a delegate on SqlServerCacheOptions to manipulate the SqlConnection?