Azure Managed Identities- the How

Some of the Microsoft-Azure developers might have used Azure Managed Identities and the rest might not have. Do you know what happens behind the scenes when you enable “Managed Identity” for a service?

Lets use a couple of scenarios to set the stage for this topic.

1. If you are not supposed to store the application ID and the corresponding Secret in the source code or the configuration files ( a straight NO considering the security guidelines and this could get into the source code repository)
2. If you decide to store the application credentials in a secure vault, the vault that guards all your secrets and certificates has to be stone walled for anonymous access. You now have to complete authorization to gain access to the vault

Applications that provide interaction with the end-user can use the “Delegated Authorization” principle. In this case, the user completes the authN (who?) and authZ (consent/permission to access the resource). Examples of applications that belong to this category include the Single-Page Apps and Web Applications. The application now acts on behalf of the users (using the user’s configured rights) to access protected resources.

What if we consider the case of an application that cannot enjoy the luxury of delegated authZ, a daemon app if I would. The conventional practice is to store the Client-Id and secret in the app’s config file. Since the credentials do not end up in the user’s browser, this might fit a “development environment only” solution. However we still find ourselves fighting the 2 issues stated above.

Before getting into the actual topic, lets quickly graze through a familiar but less common Oauth case — “Client Credentials Flow”. The client/app supplies the credentials (usually its Id and its secret)to the IDP and gets a token (access token or id token or both)in response. A variation of this is the usage of a Client Certificate in the place of a secret. Azure AD would be able to consider the client certificate for the assertion. I have seen this approach being used in IOT setup when the devices need a way to complete the authZ to be able to access the resource server.

For the curious and like-minded people, “How does this work under the hoods?”. Well, the beauty in software design is that we still stick to the basics. We use the core principles of cryptography when exchanging information between entities over the wire. Also, an unusual possibility of exchange — the client sends a JWT token to the AD . Yes , you read that right! that is what it looks like!!

So, one option of exchange as detailed in Microsoft's documentation

1. the application (client) sends a JWT token signed with its client certificate (signing portion of a cryptographic message exchange). Also if you observe carefully in the actual JWT payload, the “issuer is the client” and “audience is azure AD”
2. AD verifies the signature in the JWT with the certificate hash from the client’s certificate (added when application was registered in Azure AD). This confirms no tampering and non-repudiation. An usual validation of the payload section of the JWT is done to verify the issuer and the audience along with the token expiration values. On successful verification, an Oauth (access token) is then sent back to the client.

This is how the flow would look like

You can read the details of this message exchange from Microsoft’s documentation. I am going to use just the JWT to help correlate the information from the sequence diagram

For those nerds who have already thought about the HTTP request that happens in the background, here is how the request would look like

Excerpt from MS documentation — Notice that the client_secret parameter is no longer used. Instead, the client_assertion parameter contains a JWT token that was signed using the client certificate. The client_assertion_type parameter specifies the type of assertion — in this case, JWT token. The server validates the JWT token. If the JWT token is invalid, the token request returns an error.

We have now sorted out the working of a “Client Credentials flow using client certificates”. Time to get to the main topic :)

What if I tell you that the user need not register the application in Azure AD (to get the client-Id) and also create the certificate for the application ( to use as its secret). If Azure can do this for your apps and also managed the lifetime of the identities, how convenient would that be?

When you enable “Managed Identity” for a service, Azure registers the service with AD, gets a client ID, creates a certificate and makes them available to the service instance. If you have not realized yet, now the service is all set for a client credentials oauth flow. Only thing is that the Oauth flow happens in the background when managed identities are used.

An example of the process detailed above when done for a Virtual Machine →

src: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/media/overview/data-flow.png

The last dot to connect is the high level abstraction that MS provides to make use of this feature to get access tokens from code. The application executing this code should

1. Have its system-assigned managed identity enabled
2. Have been assigned a specific role (needed privileges alone) in the RBAC assignments of the target resource being accessed. In this example an azure key-vault.

src: https://docs.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=dotnet#asal

That’s all folks for this post. Hope you found this intriguing.

References

Basics of Oauth Client Credentials flow with certificates

Microsoft identity platform certificate credentials - Microsoft identity platform

Libraries from Azure GitHub for your play with

Azure-Samples/active-directory-dotnetcore-daemon-v2

Deeper understanding of the message exchanges in Client credentials flow

Use client assertion to get access tokens from Azure AD - Azure Architecture Center

Managed Identities- explained with an example

Managed identities for Azure resources