TokenCredential support for ShareClient

[Kruti-Joshi]

Query/Question
I'm using Azure.Identity package to use Managed Service Identity for authorization between the different Azure components in our project. One requirement is to connect to a File Share from an Azure Function. I notice that there is TokenCredential support in BlobClient, QueueClient and the DataLakeClients, but not in ShareClient. Is there any plan of adding this support in the near future? To use MSI for File Share, should I use the AppAuthentication library instead?

Environment:

• Name and version of the Library package used: Azure.Storage.Files.Share 12.7.0; Azure.Identity 1.4.0
• Hosting platform or OS and .NET runtime version:

• IDE and version : Visual Studio 2019 Version 16.10.2

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.

Issue Details

---

Query/Question
I'm using Azure.Identity package to use Managed Service Identity for authorization between the different Azure components in our project. One requirement is to connect to a File Share from an Azure Function. I notice that there is TokenCredential support in BlobClient, QueueClient and the DataLakeClients, but not in ShareClient. Is there any plan of adding this support in the near future? To use MSI for File Share, should I use the AppAuthentication library instead?

Environment:

• Name and version of the Library package used: Azure.Storage.Files.Share 12.7.0; Azure.Identity 1.4.0
• Hosting platform or OS and .NET runtime version:

• IDE and version : Visual Studio 2019 Version 16.10.2

Author:	Kruti-Joshi
Assignees:	-
Labels:	Client, Service Attention, Storage, customer-reported, needs-team-attention, needs-triage, question
Milestone:	-

[kasobol-msft]

@Kruti-Joshi None of File Share Data Plane REST API (which is what that SDK calls behind the scenes) support Azure AD (and MSI). Therefore lack of TokenCredential in ShareClient.

[Kruti-Joshi]

Got it. Thanks @kasobol-msft. Closing this.

May I ask, what is teh reason behind File Share not supporting AAD but the other offerings do?

[kasobol-msft]

@Kruti-Joshi At this moment File Shares offer AAD support if used via SMB protocol, see here. It's just not an option in the REST API. The mainstream scenario for shares is that users (who are granted limited permissions) would mount them to a VM rather than interact over REST. Therefore REST API is available for account owner only (one that has access to account keys) to perform administrative actions (automated or not).

[Matthewsre]

@kasobol-msft,

I thought TokenCredential support was going to be standard in all of the Azure.* SDKs. I believe it was ServiceBus that had the same type of challenge where keys are used, but they were still able to handle leveraging TokenCredential to get the keys and handle getting the required credentials under the hood. I just want to use my TokenCredential with the proper role assignments that would enable getting the proper credentials for this to work. Is this something that could be added to align with the rest of the Azure.* SDKs?

It looks like this was an option in the V11 SDK using StorageCredentials(TokenCredential).

https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.storage.auth.storagecredentials?view=azure-dotnet

Could that approach also be used in V12 SDK to bridge the gap?

[kasobol-msft]

Such magic didn't exist in prior Storage SDK versions. I.e. SDK would never attempt to exchange one credential for the other one. The user is responsible for providing one.
Implicitly exchanging token credential for shared key might bring unwanted elevation of privilege. I.e. having shared key in hand is an equivalent of superuser access and if leaked it poses significant threat. Having said that there are APIs that require it and won't accept token credential which ultimately requires caller to have shared key in hand, but this should be an explicit action of the caller to do so.
/cc @schaabs

[Matthewsre]

Such magic didn't exist in prior Storage SDK versions. I.e. SDK would never attempt to exchange one credential for the other one. The user is responsible for providing one.
Implicitly exchanging token credential for shared key might bring unwanted elevation of privilege. I.e. having shared key in hand is an equivalent of superuser access and if leaked it poses significant threat. Having said that there are APIs that require it and won't accept token credential which ultimately requires caller to have shared key in hand, but this should be an explicit action of the caller to do so.
/cc @schaabs

@kasobol-msft,

From the link I referenced, it looks like you can use the StorageCredential(TokenCredential) and get a CloudFileShare.

Here is the StorageCredential(TokenCredential) constructor:

Copied the relevant code samples from the link and only changed the StorageCredential to use the new Constructor:

// Changing storageCredential to use constructor with TokenCredential (only change in this code)
// StorageCredentials storageCredentials = new StorageCredentials(myAccountName, myAccountKey);
StorageCredentials storageCredentials = new StorageCredentials(tokenCredential);
CloudStorageAccount cloudStorageAccount = new CloudStorageAccount(storageCredentials, useHttps: true);

...

// Create a CloudFileClient object from the storage account.
// This object is the root object for all operations on the 
// file service for this particular account.
CloudFileClient fileClient = cloudStorageAccount.CreateCloudFileClient();

...

// Get a reference to a CloudFileShare object in this account. 
// This object can be used to create the share on the service, 
// delete the share, list files and directories, etc. This operation 
// does not make a call to the Azure Storage service. It neither 
// creates the share on the service, nor validates its existence.
CloudFileShare share = fileClient.GetShareReference("share1");

Would this not work in the V11 SDK when the alternative constructor was used?

[kasobol-msft]

The code might compile but will produce an error in runtime. The credentials model in prior versions of SDK was not coherent with underlying service capability.

CloudFileClient ctors for reference:
https://github.com/Azure/azure-storage-net/blob/cbe605f9faa01bfc3003d75fc5a16b2eaccfe102/Lib/Common/File/CloudFileClient.Common.cs#L71

[Matthewsre]

@kasobol-msft , thanks for clarifying and providing quick responses! I'm glad the new solution didn't carry over that issue. :)

To enable this to work in V12 would your team consider taking inspiration for how this was solved in the cosmos SDK?
Azure/azure-cosmos-dotnet-v3#1971 (comment)

In my case I would expect to grant "Storage Account Contributor" role to my MSI (or other TokenCredential depending on my environment) since this role has access to the keys:

I know I could grant the permissions and lookup the keys myself, but it would be nice if the SDK could take care of that for me automatically like it does for Cosmos. This approach would also promote using TokenCredential and keep a consistent experience across all of the Azure.* SDKs.

[kasobol-msft]

As far as this comment goes Azure/azure-cosmos-dotnet-v3#1971 (comment) cosmos didn't and is not going to implement anything like this.