Why should restrictions be imposed on GraphAPI access?

Granting permissions to Entra ID App registrations for access via the Graph API to Azure tenants can provide significant benefits, particularly in service automation scenarios.

However, managing unrestricted access to these registrations can be inconvenient and a known risk. It’s crucial to establish conditional restrictions to ensure controlled access to your Azure Tenant via the Graph API.

Enter… the Conditional Access for workload identities!

First, what are workload identities:
As Microsoft describes it, “A workload identity is an identity you assign to a software workload (such as an application, service, script, or container) to authenticate and access other services and resources.”

Microsoft now also offers ‘Entra Workload ID Premium’ to use workload identities within Conditional Access. These workload identities serve as the gateway, granting applications or service principals access to resources like the Graph API.

So, in this post, we connect to the Graph API as a workload identity via an IP restriction enforced by a Conditional Access policy.

Disclaimer

The instructions below assume that you have a Microsoft Entra Workload-ID license, which enables you to create Conditional Access policies based on workload identities, such as a service principal.

Creating the named location

The journey begins with creating a named location, the first step in defining the IPs we want to exclude from our conditional access policy.

To start this, navigate to the Conditional Access management blade. (The quick way, thanks to Merill Fernando from merill.net) and select named locations, as shown in the example below.

In the Named locations blade, I then create a new location as shown below.

Assigning the named location to a conditional access policy

To make the named location a requirement in the conditional access policy, we have to assign it to a new or existing conditional access policy.

For the purpose of this post, we are creating a new policy by navigating to the Conditional Access blade and selecting the workload identity we wish to control via Conditional Access.

After selecting the workload identity to which we want to apply the restrictions, we give the policy a name and select the earlier created named location as an exclusion, so that only that location is allowed to bypass the policy.

In the access controls, we select ‘Block access’ so that every other location other than the selected named location is blocked from access to the workload identity.

How does this work in practice?

As published in my earlier blog post to easily generate a Graph API access token, we are re-using some code.

When we request an access token via the trusted named location, we get the following result:

And then when we request an access token outside of our trusted named location, we get the next result back:

Conclusion

When creating workload identities to use in, for example, service automation products, we also need to pay attention to the access controls for these identities. This aspect can be overlooked, leading to unnecessary risk.

Unfortunately, this feature is not standard and requires additional licenses to configure.

In an upcoming post, I’ll delve into how to best maintain minimal permissions when creating a workload identity for use in automation products (scripts, etc.), as most workload identities typically do not need any more permissions than necessary.