Skip to content
adatum
  •  SCOM Web API
  • About adatum
microsoft social sign-in Azure

Azure Application registrations, Enterprise Apps, and managed identities

  • 04/03/202122/03/2021
  • by Martin Ehrnst

This post has been lurking in my drafts for almost two years now, and after a recent discussion with colleagues, it was about time I finish it.
Weekly I get questions about Azure AD application registrations and Enterprise Applications. And since you found this post, you are probably looking for a few answers yourself.

Over the years I have done a lot of work that requires playing around with authentication in Azure. Especially the case I had with the secure application model and Microsoft CSP gave me some good insight into this space. In general, I have limited knowledge of Oauth2, etc. And most of my work in this space has been related to integration with Azure Management APIs

The purpose of this post is to demystify everything around managed identities (MSI), Azure application registrations, and Enterprise Apps. Although Microsoft has this well documented, the context can be somewhat vague. Especially for new developers and IT Pros integrating with the Azure Control plane.

Azure Application registrations

Microsoft has a very robust identity platform in Azure AD. And by creating an application registration you can use this platform to authorize and authenticate various and multiple clients (Mobile, web apps, etc).

When creating an application registration you establish a trust relationship between the Microsofts identity platform and your custom application, meaning you trust Microsoft, but Microsoft does not trust your application in the same way.

You can create single-tenant, multi-tenant, and Microsoft (liveid) based app registrations or a combination of them. But the application definition is only tied to its home directory.

Azure ad application registration portal
  • Single-tenant configuration
    • Only principals in the “home” tenant can authenticate.
  • Multi-tenant application registrations
    • Allows users and applications in other Azure AD tenants to access your app.
  • Personal Microsoft accounts
    • Here you can allow Microsoft Live ID accounts to access.
Kahoot sign-in with microsoft google and apple

Enterprise applications – service principals

App registrations are not very functional on their own. Where App registrations is you custom application definition. Enterprise application is the application identity within your directory (Azure AD). The service principal (enterprise app) can only be assigned access to the directory it exists, and act as an instance of the application.

Relationship between app registrations and enterprise applications.

Enterprise applications (the service principal) have a reference to its Application registration. In most cases, you have one app registration and the service principal (enterprise application) in the same tenant.
When the application is accessible by multiple tenants, all tenants will have one enterprise application. However, the application registration itself will be in its “home” tenant

This can be confusing. But if you look in the enterprise application blade you can find applications from other app vendors being used by you or other users in your directory.

In short: Azure application registrations are the global representation of your custom application, and Enterprise Application is the local representation of the same application, bound to your tenant.

See this post on how to create Application registrations using PowerShell.

Conditional Access

Conditional Access is where you use signals to identify if a user can access your application or not. You then use these signals in an “if-this-then-that” format to decide whether the user can access your application.

Conceptual Conditional Access process flow
Image from Microsoft Docs

Conditional access is widely used for accessing cloud resources like the Azure Portal or Office 365. However, you can also use the service for your in-house developed applications as well.

Managed identities

Another player in the mix often causing confusion for developers and administrators is Managed Identities. When released, we used the name Managed Service Identities, in short MSI. But recently Microsoft renamed this service to Managed Identities.

Managed Identities is used to assign an identity (service principal) to an Azure resource. You can use this service principle to access other resources, leveraging the built-in authentication and authorization mechanisms you find in Azure.

Managed identities can access other Azure resources or custom applications.

Previously, when we did not have managed identities, we created an application registration for the resource. Using a secret or certificate to authenticate with Azure. This created a lot of overhead, as it required secret management, key rotation, etc. With managed identities, Azure takes care of this for us.

Managed Identities comes in two configurations. One fully managed and tied to a resource, or as an individual resource.

System-assigned managed identity

System-assigned is where you tie the identity to one specific resource. You configure this during resource deployment or assign an identity after it’s deployed.

The service principal created with system-assigned managed identity will follow the resource lifecycle. If you delete the resource, the identity will also be deleted.

User-assigned managed identity

User-assigned managed identities are individual resources. Multiple Azure resources can use one managed identity, or you can use multiple identities for one resource. Microsoft will still rotate keys and secrets. But with user-assigned managed identities you are in control of the service principal lifecycle and general governance.

Summary

There are a lot more to go through when talking about authentication. How to obtain Azure access tokens or how you add Azure login to your website is not covered here. However, I hope this post made the Azure application registrations, service principal, and managed identity space a bit more clear.

Share this:

  • LinkedIn
  • Twitter

Related

Speaking at Nordic Virtual Summit
Application Registrations Azure AzureAD Managed Identities

Related articles

gray laptop computer showing html codes in shallow focus photography
Azure Infrastructure As Code video…
flight sky earth space
Recording available: ARM template deployment…
Recording available: Complex ARM templates
Multiple Azure credentials in PowerShell
Jumpstart your Azure Monitor journey

Engage by commenting Cancel reply

Top Posts & Pages

  • Azure AD authentication in Azure Functions
  • Creating Azure AD Application using Powershell
  • Multi subscription deployment with DevOps and Azure Lighthouse
  • Script to add SCOM agent management group
  • Resource health through Azure Rest API
  • SCOM Alerts to Microsoft Teams and Mattermost
  • Azure Lighthouse why is it so important
  • Schedule maintenance mode for group (easy)
  • Azure Application registrations, Enterprise Apps, and managed identities
  • Remediate Azure Policy with PowerShell

Tags

agent announcements api ARM authoring Automation Azure AzureAD AzureFunctions AzureLighthouse AzureMonitor AzureSpringClean Bicep Community CSP database EventGrid ExpertsLive ExpertsLiveEU IaC Infrastructure as code Integrations LogAnalytics management pack monitoring MSIgnite MSIgnite2017 MSOMS MSP nicconf Nordic Virtual Summit OperationsManager OpsMgr Powershell QUickPublish rest SCDPM SCOM SCOM2016 SCVMM Serverless SquaredUP SysCtr system center Webasto

Follow Martin Ehrnst

  • Twitter
  • LinkedIn

RSS Feed RSS - Posts

RSS Feed RSS - Comments

Microsoft Azure MVP

Martin Ehrnst Microsoft Azure MVP

NiCE Active 365 Monitor for Azure

NiCE active 365 monitor for Azure
Adatum.no use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Cookie Policy
Theme by Colorlib Powered by WordPress