In the days of Azure Active Directory (Azure AD), applications could authenticate to back-end services using a secret or a certificate. This past week, however, Microsoft announced a new feature that could provide a solution for Identity Admins: the public preview of Managed Identities as federated identity credentials for Entra ID. This new feature is and should be, a huge deal as the new SSO-type functionality provides vast possibilities and the increased potential for Entra ID apps to function without interruption due to credential expiration.
Until recently, workload identity federation was typically used only with Azure DevOps pipelines, GitHub Actions, and Azure Automation accounts. But why should Identity Admins use workload identity federation, and does this feature offer a true solution for application credentials?
Applications in your Microsoft Entra ID tenant usually consist of either an Enterprise Application (typical for multi-tenant applications), an Enterprise Application and an Application Registration (typical for single-tenant applications), or a mere Application Registration (typical for workload identities).
In multi-tenant applications, the Enterprise Application contains credentials for back-end services. In single-tenant applications, the Application Registration contains these credentials. These credentials are used to authenticate to the back-end service, as permissions and consents may vary between different applications towards the back-end service.
Until now, credentials for Enterprise Applications and Application Registrations in Entra ID consisted of either a client secret or a certificate. Entra ID can only use one at a time. Microsoft recommends certificates over client secrets.
Client secrets offer a flexible way to provide credentials, but these credentials are still passwords. It's a complex password, but it's still a password. It will only be shown at creation, which furthers information security, but if you haven't documented the client secret properly, you're bound to meet some lifecycle challenges. You'll typically meet these challenges anyway, as Microsoft recommends a maximum lifetime of 2 years for client secrets.
Right off the bat, certificates sound like a better choice than client secrets due to the common principles of public key infrastructure (PKI). Alas, in Entra ID, certificates used by applications do not need to be issued by a Certification Authority (CA).
Additionally, only their validity period is checked by Entra ID, not the certificate revocation status… It's no wonder that admins and developers frequently configure Entra ID applications with self-signed certificates: technically, they function the same as officially issued certificates.
Nowadays, most admins and developers no longer store credentials with their programming code; instead, they rely on Azure Key Vault to store credentials. With this approach, only the credentials or the identity to access the secrets in Key Vault need to be part of the code - simplifying the credential lifecycle management processes.
Interestingly, the back-end service that most Entra ID applications authenticate using their credentials is an application programming interface (API) called the Microsoft Graph API.
What started as the 'Office 365 Unified API' in November 2015 has grown to include programmatic access to everything, everyone, and their mothers. Even the Azure management portal and the Entra management portal now work completely over the Microsoft Graph API. All access (except for some obscure permissions deep in Microsoft 365 services) is governed through the Microsoft Graph API.
Previous APIs, typically accessed by Entra ID applications, once included the Azure AD Graph API. However, Microsoft is actively moving organizations away from this API with the intent of shutting it down, together with its AzureAD and MSOnline modules.
In recent months, Microsoft has released its federated workload identity functionality as part of Entra ID.
Luckily, this functionality has nothing to do with Active Directory Federation Services (AD FS) as a product, but its single sign-on philosophy applies. Instead of entering a username or password at a service, you get redirected to a trusted federation partner that handles the authentication part. The service itself then trusts the outcome of that and allows access.
Apart from the philosophy part, the federated workload identity feature is entirely different in its technology and implementation. Within the AD FS product, admins need to:
None of these apply to federated workload identities.
The federated workload identity feature offers identity managed by a service that provides effortless credential management for workload identities. Admins and developers no longer have to spend hours and even days manually managing certificates or client secrets. Federated workload identities act as part of the cloud platform and manage their credentials throughout the platform.
Of course, Azure is the cloud platform on which the federated workload identity works. Additionally, the service on this platform needs to support it.
To implement federated workload identities in the Enterprise Application (for multi-tenant applications) and the Application Registration (for single-tenant applications and workload identities), you'll navigate to a third tab in the Certificates & Secrets page next to Certificates and Client Secrets: Federated credentials.
On this tab, you specify the object ID of the user-managed managed identity you want to have connected to the Enterprise Application or Application Registration.
To answer whether federated workload identities finally solve the credentials problem for the Entra ID application, we need to determine the scope of applicability.
When we look at this scope, we see this feature applied in both Enterprise Applications and Application Registrations. This means federated workload identities can be used as workload identities (who would have guessed, huh?) for single-tenant and multi-tenant applications in any Microsoft Entra ID tenant.
But that's just one side of the coin here. To determine the scope, we need to go beyond Entra ID. We also need to look at the requirements for the compute part, the part that executes the action towards Entra. This is the application, service, or script that requests access. For the federated workload identity feature, the location of the application, service, or script matters.
Beyond Azure DevOps pipelines, GitHub Actions, and Azure Automation accounts – which all execute your requests on their cloud hardware – the application needs to be able to work with a (user-assigned) managed identity. Many Azure services have managed identity support, but this limits the application to resources in Microsoft Azure.
For organizations with a cloud-first, Microsoft-first focus, the requirement of working from Azure to be able to use federated workload identities in their applications, services, and scripts is not a big deal. I hope these organizations adopt managed identities throughout their infrastructure as they significantly reduce risks and the IT department's workload on changing client secrets and/or certificates. Their investments in Microsoft technologies pay dividends by leveraging the platform.
Organizations just looking to communicate with a specific back-end service in their Microsoft application, service, or script (especially when that service is Entra ID or a Microsoft 365 service) will now need an Azure subscription. Until now, they only had to license Entra, Microsoft 365, or Dynamics 365, but not Azure, as these products are all separately licensed). Their entire compute may be on-premises, at MSPs, AWS, Google Cloud, or another hyperscaler. Then, deploying the infrastructure becomes a huge hurdle, not just in terms of technology but also in knowledge management, management approval, financing, and purchasing.
Microsoft expanded the federated workload identity functionality, albeit in public preview. For organizations that leverage Microsoft's Azure compute, this feature expansion can be used to significantly reduce risk and time spent managing application credentials.
Alas, the feature does not offer a solution for every organization. Organizations that do not use Azure Compute, Azure DevOps, Azure Automation, or GitHub cannot use the federated workload identity functionality.
ENow's App Governance Accelerator helps organizations with alerts on expiring client secrets and certificates for Entra ID Enterprise Applications and Application Registrations. Suppose organizations can't benefit from federated workload identities because they cannot leverage their computing platforms. In that case, they can optimize their application governance processes with support from App Governance Accelerator to rotate client secrets and certificates promptly to avoid disruptions from expired application credentials. If you'd like to explore the AppGov Score utility, you can request your free AppGov Score to get an idea of the Entra ID security and governance data we help you uncover.