Azure AD: Identity & Access Management
Before we jump into the world of Azure AD, let’s make sure we are clear about some basic terms —
Authentication — The process of establishing the identity of a person or service looking to access a resource i.e. confirming if they are who they say they are. It involves the act of challenging a party for legitimate credentials, and provides the basis for creating a security principal for identity and access control use.
We’ll spend a LOT of time discussing security principal below so just relax for now ;)
Authorization — The process of establishing what level of access an authenticated person or service has. It specifies what data they’re allowed to access and what they can do with it.
Azure provides services to manage both authentication and authorization through Azure Active Directory (Azure AD)
Azure AD
Azure AD (AAD) is a cloud-based, Identity and Access Management (IAM) system. As an Identity server, AAD provides a single place to store information about digital identities. Azure AD can also performs Access Management functions for applications registered with it, such as authentication and authorization for users, services as well as hardware.
AAD can be used stand-alone or be synchronized with your existing on-premises Active Directory. This means that all your applications, whether on-premises, in the cloud (including Microsoft 365), or even mobile can share the same credentials.
Azure AD provides services such as:
- Authentication — This includes verifying identity to access applications and resources, and providing functionality such as self-service password reset, multi-factor authentication (MFA), a custom banned password list, and smart lockout services etc.
- Single-Sign-On (SSO) — SSO enables users to remember only one ID and one password to access multiple applications. A single identity is tied to a user, simplifying the security model.
- Application management — You can manage your cloud and on-premises apps using Azure AD Application Proxy, SSO, the My apps portal (also referred to as Access panel), and SaaS apps.
- Business to business (B2B) Identity services — Manage your guest users and external partners while maintaining control over your own corporate data.
- Business-to-Customer (B2C) Identity services — Customize and control how users sign up, sign in, and manage their profiles when using your apps with services.
- Device Management — Manage how your cloud or on-premises devices access your corporate data.
PRO TIP: MFA SHOULD be used for users in the Global Administrator role in Azure AD, because these are highly sensitive accounts.
Service Principals — Providing Identity to Services
While users have identities to authenticate themselves, services too need identities to authenticate and be authorized to access data. Often, and against best practices, credential information is embedded in configuration files. With no security around these configuration files, anyone with access to the systems or repositories can access these credentials and risk exposure. Azure AD addresses this problem through two methods: service principals (just a fancier term for service accounts) and managed identities for Azure services.
To understand service principals, it’s useful to first understand the words Identity and Principal.
Identity — An Identity is just an entity that can be authenticated. Obviously, this includes users with a user name and password, but it can also include applications or other servers, which might authenticate with secret keys or certificates.
Principal or Security Principal — A Principal is an identity acting within a security context i.e. with certain roles or claims. Usually, it is not useful to consider identity and principal separately, but think of using ‘sudo’ on a Bash prompt in Linux or on Windows using “run as Administrator.” In both those cases, you are still logged in as the same identity as before, but you’ve changed the role under which you are executing. Groups are often also considered principals because they can have rights assigned.
A Service Principal, therefore, is an identity that is used by a service or application, and which can be assigned roles (just like other identities).
Both people and services authenticate via a security principal to access resources; for a person, it’s called a user principal, and for a service, it’s called a service principal.
Azure AD Applications
PRO TIP: In Azure AD, a service and an application are synonymous
In order for any service or application to integrate with and delegate Identity and Access Management functions to Azure AD, it must first be ‘registered’ as an Azure AD Application. The act of registration essentially creates an identity configuration for your application that allows it to integrate with Azure AD and use it Identity & Access Management functions. When you register an app in the Azure portal, you choose whether it’s a single tenant (only accessible in your tenant) or multi-tenant (accessible to in other tenants) and can optionally set a redirect URI (where the access token is sent to).
Once you’ve completed the app registration, you can add secrets or certificates and scopes to make your app work, customize the branding of your app in the sign-in dialog, and more.
The App registrations blade in the Azure portal is used to list and manage the application objects in your home tenant.
PRO TIP: In order to register an app in App Registrations, you must have sufficient permissions. If you have a User Role, then make sure that even as you’re a non-administrator you can still register an app. You can do this by going to Azure Portal > Azure AD > User Settings > App Registrations Settings
PRO TIP: See available roles and role permissions to learn about available administrator roles and the specific permissions in Azure AD that are given to each role.
Application Object
An app registration in Azure AD results in an Application object, which describes *** three aspects of an application ***:
- how should tokens be issued in order to access the application
- the resources that the application might need to access, and
- the actions that the application can take
Each AAD Application has the following attributes which we’ll discuss at length in the sections below
- Object Id
- Application Id (a.k.a Client Id) — The unique identifier Azure AD issues to the application which identifies the specific application when performing authentication requests i.e. in various sign-in and token flows (e.g.
client_idin OAuth 2.0 and OpenID Connect). The application ID (client ID) is not a secret, and is provided to authentication libraries during development.
NOTE: All objects in Azure AD have an object Id, which you can use to identify the specific object when making API requests.
GET https://graph.windows.net/{tenant-id}/applications/{object-id}?api-version=1.6
Service Principals & Azure AD Applications
To access resources that are secured by an Azure AD tenant, a service (or an application) must be represented by a service principal in that tenant, which needs to be granted appropriate roles that define the access policy and permissions for the service/application in that Azure AD tenant i.e. what resources the service is allowed to access in that tenant. Therefore, a service principal is created in every tenant where the application is used.
When you register an application through the Azure portal, an application object and service principal are automatically created in your home directory or tenant.
An application object is used as a template or blueprint to create one or more service principal objects. The relationship between application object and service principal is such that the application object is the global representation of your application across all tenants, and the service principal is the local representation/‘instance’ for use in a specific Azure AD tenant.
The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.
PRO TIP: There is no way to directly create a service principal using the Azure portal. If you register an application using the Azure PowerShell, Azure CLI, Microsoft Graph APIs, creating the service principal object is a separate step.
If the service only ever needs to access resources within its own subscription then its AAD application will have just one associated service principal — in the service’s home tenant — the one that’s automatically created and consented to when the app is registered.
However, applications sometimes need access to resources within other AAD tenants, and in each of these other tenants it will need a different service principal i.e. one service principal per tenant that the app needs access to. The service principal is created in each tenant where a user from that tenant has consented to its use.
The Enterprise applications blade in the portal is used to list and manage the service principals in a tenant. You can see the service principal’s permissions, user consented permissions, which users have done that consent, sign in information, and more.
Set up an Azure AD application and service principal to access resources
The following posts on docs.microsoft.com are excellent and a MUST-READ , especially for the sections on Authentication —
Here’s a 2-part series that explores the app registration and permission granting parts with a use-case.
App Registrations vs Enterprise Applications
App Registrations
Applications that are registered through Azure Portal (or programmatically) in your Azure Tenant appear in the App Registrations blade.
- You can change Reply URL for these app so long as you’re an owner
- You can use the Get-AzureADApplication cmdlet to list all the registered apps
- For applications in App Registrations, you can configure OpenId-Connect (OpenID/OAuth) based authentication
- By default, all users can create application registrations.
Enterprise Applications
Entries listed in the Enterprise Applications blade are simply Service Principal objects that mirror the apps which are generally published by other companies i.e. in a different tenant. Btw, this list also includes service principals of apps registered in your home tenant. You can assign required permissions to the service principal object.
- You can’t configure Reply URL for the apps that are registered in other company tenants.
- You can use the Get-AzureADServicePrincipal cmdlet to list all the Enterprise Applications
- For Enterprise Apps, you can configure SAML based authentication
- In order to add an Application from the Azure AD app gallery as an Enterprise App, the user would need be in one of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.
The workflow is you create the App Registration (Application), say a Wiki app, in your tenant, which also creates the Enterprise Application (Service principal) in your tenant. Say some other app, registered in another tenant, want to integrate with your wiki app, then when another tenant user wants to sign in to your app (the Wiki app), they grant your app the permissions it requires in their tenant and an Enterprise Application (Service Principal) is created in their tenant. This effectively mirrors your application in their tenant.
To learn how to register an app, understand permissions needed to register apps, assigning a role to the application’s service principal, authentication using certificates, and authentication using application secret, configuring access policy on resources see — How to: Use the portal to create an Azure AD application and a service principal that is allowed interact with resources.
Managed Identities for Azure Services
The creation of service principals can be a tedious process, and there are a lot of touch points that can make maintaining them difficult. Managed identities for Azure services are much easier and will do most of the work for you.
A managed identity can be instantly created for any Azure service that supports it — and the list is constantly growing. When you create a managed identity for a service, you are creating an account on your organization’s Active Directory (a specific organization’s Active Directory instance is known as an “Active Directory Tenant”). The Azure infrastructure will automatically take care of authenticating the service and managing the account. You can then use that account like any other Azure AD account, including allowing the authenticated service secure access of other Azure resources.
References
- Application and service principal objects in Azure Active Directory
- Microsoft Identity Platform developer glossary
- Demystifying Azure AD Service Principal
- Difference between App Registrations and Enterprise Applications
- Difference between App Registrations and Enterprise Applications — StackOverflow
https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
