Document how to use the plugin (v6) with Managed Identity

[SeanFeldman]

Details: #181 (comment)

How to construct StorageCredentials for Managed Identity in the code below:

var azureServiceTokenProvider = new AzureServiceTokenProvider();
var state = (azureServiceTokenProvider, settings);
var tokenAndFrequency = await TokenRenewerAsync(state, CancellationToken.None).ConfigureAwait(false);
var tokenCredential = new TokenCredential(tokenAndFrequency.Token, 
  TokenRenewerAsync, 
  state, 
  tokenAndFrequency.Frequency.Value);
var storageCredentials = new StorageCredentials(tokenCredential);

And the method for token renewer:

static async Task<NewTokenAndFrequency> TokenRenewerAsync(object state, CancellationToken token = default)
{
	var (azureServiceTokenProvider, settings) = (ValueTuple<AzureServiceTokenProvider, Settings>)state;

	// Use the same token provider to request a new token.
	var resourceUri = settings.BlobEndpoint;
	var result = await azureServiceTokenProvider.GetAuthenticationResultAsync(resourceUri, cancellationToken: token).ConfigureAwait(false);

	// Renew the token before it expires.
	var next = (result.ExpiresOn - DateTimeOffset.UtcNow) - settings.RenewalTimeBeforeTokenExpires;
	if (next.Ticks < 0)
	{
		next = default;
	}

	return new NewTokenAndFrequency(result.AccessToken, next);
}

This could be all simplified and embedded into the plugin, but still, there'd be a need in a new configuration overload that takes in RenewalTimeBeforeTokenExpires to override the default the plugin would set. Initially, this could be just captured in the documentation, similar to how service and container SAS authentication is documented.

[SeanFeldman]

@CasperWSchmidt are you interested in taking a stab at that?

[CasperWSchmidt]

I know you are not keen on more constructor overloads or additional parameters for the existing constructors. Perhaps this should just be included in some helper class (or library like the Key Vault provider) that helps set up the credentials used to create the configuration?

[SeanFeldman]

It's not about what I like but more about striking a balance. This is not a paid project and I don't have any supporters, so it's pretty much me supporting it. Sometimes it makes sense to expand public APIs and sometimes it's not. Take this request for example. Can you achieve what you want w/o code changes? Yes, document how to pass a properly constructed StorageCredentials into the plugin. It's already there, just needs to be documented.

Assuming documentation is not the right approach and it should be added to the plugin, then configuration API needs to be considered. Should the token refreshing period be configurable or not? If yes, then how will it be passed in? And if this code change moves forward, will it be needed if the plugin switches to Storage SDK v12, which is going to be a breaking change as v11 and v12 are not compatible?

This is why I suggested the simplest thing first, document how to enable MSI using the existing API.
Thoughts?

[SeanFeldman]

@CasperWSchmidt ping

[CasperWSchmidt]

@SeanFeldman Sorry, haven't had the time to do this yet :(

[SeanFeldman]

No worries, there's no rush. Did it make sense though to turn this into documentation update?