In last article, we have seen how to access the Azure key vault using service principal.

Before we begin

You may want to go through some of the previous articles in this series. Below blog posts will guide you to create a key vault, add secrets to it and then access it from the .NET Core web application.

• Creating your first Azure key vault instance
• Use Azure Key Vault in .NET Core Web Application
• Azure web app and managed identity to access key vault (Optional)
• User assigned managed identity with Azure key vault (Optional)
• Managing Azure Key Vault and Secrets with Azure CLI (Optional)

Now, you have a web application that accesses secrets from key vault. This web application is hosted as Azure web app which is probably using managed identity to access the key vault.

FYI – The web application allows user to upload documents. These documents are then uploaded to storage account. The credentials of storage account are stored in key vault.

What is service principal ?

Service principal is nothing but an identity created for your application. There are two ways by which service principal can be created:

• You can create the service principal by using Azure CLI.
• There is one more way – the service principal is also created when an application is registered in Azure AD.

This service principal can be used to access the Azure resources. The level of access is restricted by the roles which are assigned to service principal. This role decides which resources can be accessed and what would be the level of access.

So, if you want to use service principal, there are two ways to authenticate – certificates AND client secret

Plan of Action

As we already know, there are two ways to create service principal – by using CLI or by registering application in Azure AD. In this article, we will register application in Azure AD, which will automatically generate service principal for our application. This service principal would be used by our .NET Core web application to access key vault.

We are going to perform below steps:

• Register web application which will create service principal for the application
• Generate client secret for new app registration. This client secret is kind of authenticating identity of application. Only the application which possesses this will have access to the key vault.
• Add access policy in key vault, which will allow access to newly created service principal
• Modify .NET Core web application to use new connection string which uses service principal to connect to key vault

Sit tight and let’s get into action…!

App Registration

Login to Azure portal and select Azure Active Directory from the left navigation. Select App registrations from the left side navigation of Azure AD menu and then select New registration.

On the new panel, enter below information:

• Name – A display name, e.g. Key Vault Sample
• Supported account types – This should be carefully selected depending on nature of your application. For now, you can keep the default selected option
• Platform Configuration – this is optional, but you can specify the platform of your application (Web App, background application, Web API, etc.). You can also change this configuration latter. As we want to configure web application select first radio button (Client Application) which covers web applications too.

Then click on Register button. So, we have just created an Azure AD app registration and a service principal.

Generate Client Secret

In Azure portal, go to Azure AD and open the app registration which we just now created. On the overview panel, Application (Client) ID and Directory (tenant) ID would be shown. Note them down as they would be required in our application.

Next, select Certificates and secrets option from the left side navigation and click on New client secret to generate new secret.

A new popup will be shown. We need to enter  Description  and  Expiry  duration. Expiry duration of 1 year is sufficiently long. Also, in my opinion, it is better to keep the secret changing, so that guessing it becomes more and more difficult.

After entering these two inputs, click on Add button.

This would generate the new client secret. Now, copy the new client secret value. You won’t be able to retrieve it after you perform another operation or leave this blade.

Add access policy in key vault

Now, again in Azure Portal, go to the key vaults and select the key vault which the Azure app service will connect to for reading the secrets.

Select Settings-> Access policies from the left navigation and then click on Add Access Policy link to add new access policy.

On the new panel, make sure to select two permissions – Get and List – for key permissions, secret permissions and certificate permissions inputs.

Then click on Select principal which should open a new panel on right side. On this new panel, search for the name of the app registration which we created in previous steps and then click on Select button.

Then click on Add button to add the access policy. You will be redirected to access policies panel. And last but not least, do not forget to hit Save button on Access Policies panel.

Application Configurations

There are two important modifications which needs to be done on the application side.

Optional – Remove managed identities

If you have followed all steps in the pre-requisites, your web application may be able to access the key vault using either system-assigned (or user-assigned) managed identity.

Please make sure you have disabled system-assigned managed identity and user-assigned managed identity on the app service from Azure portal.

Also if you have added a connected service for allowing access on key vault from visual studio, then remove all the files inside ConnectedServices folder from solution explorer.

After managed identities are removed and there are no connected services, the application (i.e. app service) will not be able to access key vault and if you try to access application, below error would be shown.

Update connection string

The access to key vault is granted by Azure AD. So, our application should have valid details, which can be presented to Azure AD so that our app can get authenticated. Can you guess what are those details ?

We already noted them down in our previous steps:

• Client ID – uniquely identifies our application in Azure AD
• Tenant ID – uniquely identifies our Azure AD tenant
• Client Secret – the password that our application can present to Azure AD

The AzureServiceTokenProvider instance can accept the connection strings. We need to provide a connection string in below format which will use all above details.

RunAs=App;AppId={ClientId};TenantId={Tenant-Id};AppKey={ClientSecret}

Below code snippet shows complete view of program.cs file. It shows how CreateHostBuilder is passing the connection string in above format while instantiating AzureServiceTokenProvider .

Run and Verify

Now, if you run the application from Visual studio, the application would be successfully able to upload documents from our application.

Also, if you publish this application to Azure app service and try to browse the application, then also, the application would be successfully able to work.

We have seen how service principal can be used with Azure key vault. Also, if we use service principal, same mechanism can allow Visual Studio as well as hosted app service to access the key vault.

I hope you enjoyed this article. Let me know your thoughts.