Entra App Registration FAQ

02 Feb 2024 🔖 security tutorial
💬 EN

Below are a few frequently asked questions about Entra App Registrations (“app reg”).

Many thanks to colleagues who helped me a lot with editing the wording when I wrote a similar document for internal training.

What is an App Registration?

An App Registration is a type of Entra identity meant to represent a nonhuman actor.

When do I need an App Registration?

No SMI support

An App Registration might be used to represent an Azure resource (👥) when the resource’s SMI is not easily able to be granted authorization (🔐) to perform a certain type of task.

(I hear from trusted colleagues that although Microsoft is closing the gap, there are some things that SMI’s can’t do but App Registrations can.)

Antipattern

An App Registration should not be used to represent an Azure cloud resource when a SMI would do.

For example, do not use an App Registration to permit an Azure Data Factory to read files from an Azure Storage Account.

Instead:

1. The Azure Data Factory’s SMI should be the principal of…
2. a “Storage Blob Data Reader” Azure RBAC role assignment…
3. that targets the Azure Storage Account as a scope.

Non-Azure non-human resources

An App Registration is often used to represent a non-Azure resource that needs to perform actions against your company’s Microsoft services (such as Entra, Azure, or resources accessible through the Graph API).

Examples:

1. A code-deployment automation (“CI/CD pipeline”) running in a service such as Azure DevOps Pipelines, GitHub Actions, etc.
   • (Preferably using Federated Identity Credentials to log into it over OIDC.)
2. A 3rd-party service not maintained by Microsoft.
3. An on-premises workload.

Single-sign-on

An App Registration might be used to represent a nonhuman resource, whether Azure or non-Azure, that needs to leverage your company’s Entra directory to offer humans the opportunity to log into itself via Single Sign On (“SSO”).

Privilege separation

An App Registration might be used to represent a nonhuman workload that is merely one of many running on a given Azure resource.

For example:

1. Consider a given “Azure Automation” resource that will contain 4 “runbooks” that each need to be authorized to perform actions against a different set of the your company’s Microsoft SaaS resources.
2. Suppose that each “runbook” will be maintained by a different team of corporate staff.
3. With separation: Creating 4 unique authentication mechanisms in the form of 4 App Registrations may facilitate adherence to the “principle of least privilege” and to the idea of “privilege separation” when granting authorization.
4. Without separation: On the other hand, granting all 4 sets of specialized authorizations to the 1 System-Assigned Managed Identity (“SMI”) attached to the entire “Azure Automation” resource could give each runbook privileges against the other runbooks’ intended target resources.
   • Such a tightly-coupled access control design could facilitate destructive accidents or malicious behavior.

Naming standards

Carefully choose a meaningful name when creating an Application Registration / Service Principal pair.

For example:

1. If the workload is being developed by staff in your company’s “xyz” subdepartment of its “abc” department, and the workload was known as the “hello world” software application - then a name like “abc-xyz-helloworld-automated-deployment” may be appropriate.
   • (Or, since “cicd” is often used as a shorthand for “deployment automation,” perhaps “abc-xyz-helloworld-cicd” if such language is preferred by the team’s developers.))
2. If your “hello world” application’s web frontend will need to let colleagues log into it over SSO, you may also need to create a second App Registration with a name like “abc-xyz-helloworld-sso.”

Research

Also look through existing App Registrations created by others to see if any standards seem that your team might want to imitate.  For comparison, you can find existing App Registrations in the “All applications” tab of your company’s Entra’s web portal’s “App Registrations” page (as long as you have appropriate “application developer” Entra privileges while you attempt to browse – Entra Privileged Identity Management (“PIM”) may apply).

Create an App Registration

In a corporate environment, you might not be allowed to create an App Registration yourself.

1. If your company includes identity and access designs in workload solution designs, you might find that all of the App Registrations that you will need to build your solution were already provisioned for you when your infrastructure was provisioned. Ask the colleagues who helped you design your solution.
2. Your help desk ticketing system might have a ticket type that you can open to request that an App Registration be created/edited/deleted on your behalf.

Otherwise:

1. Follow the first subsection of these instructions on Microsoft Learn, entitled “Register a Microsoft Graph API application instructions on Microsoft Learn, but…
2. Stop before reaching the second subsection titled “Grant API Access to your application.”
3. In the navigation menu at left, click “Owners,” and then select “Add” until you have enough Entra human IDs or – better yet – Entra groups of humans representing your team or other teams – capable of serving as “owners” who can manage your new App Registration to provide redundancy in an emergency.
4. Document the existence of your App Registration and its intended purpose in all places appropriate to your teammates and other stakeholders in the project you are working on.
   • The best implementation is a well-documented implementation.

Federated Identity Credentials

If you are creating an App Registration for the purpose of authenticating an CI/CD platform (e.g. Azure DevOps Pipelines, GitHub Actions) into your company’s Microsoft services, please do not set up certificates or secrets on your Entra App Registration.

Instead, please set up a “federated” identity credential that your CI/CD platform can use to authenticate over the Open Identity Connect (“OIDC”) protocol.

Federated credentials are convenient for authenticating trusted services such as Azure DevOps Pipelines (owned by Microsoft) and GitHub Actions (owned by Microsoft) because:

1. You do not have to worry about securely storing secrets.
2. They never expire, which can prevent outages.