How do I keep/store my azure credentials?

Question

I have this web app which access a keyvault stored in Azure cloud.

To access this KeyVault I use the IConfigurationBuilder Extension

configuration.AddAzureKeyVault(new Uri(KeyvaultUri), new DefaultAzureCredential(true));

I have created an managed identity for all the user who need access to this, meaning they should be able to run the application and have access to the keyvault once they are logged in via SSO, which they currently are forced to do everytime they start the application due to new DefaultAzureCredential(true) What I don't understand is why it everytime need to be requested everytime, and not store the credentials somewhere after it has been entered once, and use that stored credential, can I somehow locally store the required credentials after the initial login?

It is sort of inconvenient to always login when one start their application, and debugging application becomes a bit lengthy with the required login.

Is somehow possible to let the login happen in the background - or somehow store the credentials after first login?

I feel a bit this is getting off tracked - the solution I am seeking should be applicable for those running the solution via a terminal, outside of visual studio. Such as frontend developers - who just need a backend to make reqeuest to a nothing else.

Answer 1

It has no sense to cache the token since it is used only once at startup, what you are looking for is to exclude in your credentials all the wrong ways you are trying to grab the token to connect to your AKV except the one you are really using.

To configure it correcly and do not wait 15 seconds in your startup you should configure DefaultAzureCredentials this way:

        DefaultAzureCredential credentials = new DefaultAzureCredential(new DefaultAzureCredentialOptions
        {
            ExcludeEnvironmentCredential = true,
            ExcludeInteractiveBrowserCredential = true,
            ExcludeAzurePowerShellCredential = true,
            ExcludeSharedTokenCacheCredential = true,
            ExcludeVisualStudioCodeCredential = true,
            ExcludeVisualStudioCredential = true,
            ExcludeAzureCliCredential = true,
            ExcludeManagedIdentityCredential = false,
        });

Exclude all posibilities to grab the token except the one you are using, in this case "Managed Identity" or in other cases AzureCliCredentials.

Regards.

Answer 2

Can you share a small full code example ? What about using DefaultAzureCredentialOptions. Like:

.ConfigureAppConfiguration((context, config) =>
        {
            var appSettings = config.Build();
            var credentialOptions = new DefaultAzureCredentialOptions();
            var credential = new DefaultAzureCredential(credentialOptions);
            config.AddAzureKeyVault(new Uri(appSettings["Url:KeyVault"]), credential);
        })

Answer 3

I assume you've got different Azure subs for non-prod and prod (that contain a non-prod and prod key vault instances).

In the non-prod key vault instance, create a new role assignment with the required members i.e. the developer AAD accounts.

Given you're using DefaultAzureCredential, these members will be able to leverage Azure service authentication in Visual Studio or Visual Studio Code (or EnvironmentCredential) as DefaultAzureCredential will cycle through these various credential types including VisualStudioCredential and VisualStudioCodeCredential (and EnvironmentCredential) respectively.

Developers can authenticate in their IDE e.g. in Visual Studio by going to Tools > Options > Azure Service Authentication where they can authenticate using their Azure credentials.

Assuming their AAD accounts have been granted access to the (non-prod) key vault instance, they will be able to get access.

The deployed application - presumably running in Azure - would use a different credential type e.g. ManagedIdentityCredential or EnvironmentCredential. Given these are also handled by the DefaultAzureCredential, no code changes would be required for this to work for the deployed instance of your app.

The only difference with the prod key vault instance is that you probably wouldn't create role assignments for the developer accounts.

the solution I am seeking should be applicable for those running the solution via a terminal, outside of visual studio. Such as frontend developers - who just need a backend to make reqeuest to a nothing else.

For these type of users that just want to run the app from the terminal, they could set some environment variables that will get picked up by the EnvironmentCredential (which is another one of the credential types included in the DefaultAzureCredential) e.g. if they're running the app in docker they could specify AZURE_USERNAME and AZURE_PASSWORD environment vars (or alternatively AZURE_CLIENT_ID and AZURE_CLIENT_SECRET for more of a 'machine' context) e.g. docker run -e AZURE_USERNAME=username -e AZURE_PASSWORD=password ...

Answer 4

Based upon your question, I am assuming the following:

• The web application has a managed identity and has permissions to your key vault.
• The users are logging in as themselves in the front end of the web application.

The new DefaultAzureCredential(true) just grabs the users current credentials. This will be the front end user. These are cached automatically based upon your organization's security policy. I assume this is working correctly.

The login frequency is out of your control as a developer. The issue you are having is in the organizational settings in Azure Active Directory. Your sign in frequency may be set to one of these:

Require reauthentication every time

Sign-in frequency control every time risky user

To fix your issue, set the sign-in frequency to be less than that and you should be good. (I don't have access to this or I would post better pictures)

Here is the link to the full article on how to do this:

Configure authentication session management with Conditional Access

Answer 5

This was what I was looking for

https://github.com/Azure/azure-sdk-for-net/issues/23896

A silent authentication step that stores the credentials first time it is entered into a cache file and then reuses it when rerunning the application the second time without prompting the user to enter credentials.

Thus ensuring credentials arent stored in git, and cache file stored locally on each developers local machine.