The Microsoft identity platform allows developers to create apps where users can sign in using Microsoft or social accounts and get authorized access to various APIs.
Service Principals
For an application to utilize Azure’s Identity and Access Management capabilities, it must be registered with Azure Active Directory (Azure AD). This registration provides the app an identity within Azure AD. During registration in the Azure portal, you specify if the app is:
- Single tenant: Only usable within your organization.
- Multi-tenant: Usable across multiple organizations.
Post-registration, two objects are created in your Azure AD:
An application object: A unique representation of your app.
A service principal object: The app’s active instance in your tenant.
Additionally, your app receives a unique ID (app or client ID). Within the Azure portal, further configurations like adding authentication secrets/certificates, defining permission scopes, and customizing user sign-in visuals can be made.
Application Object
The Application object in Azure AD is the blueprint of an application. It defines the app’s global properties and behaviors. When the application is utilized in different parts of Azure (different tenants), individual instances called Service Principals are created, inheriting attributes from the Application object. These aspects dictate how the app obtains tokens, accesses resources, and performs actions. Think of the Application object as the master template, and Service Principals as its specific implementations across Azure.
Service Principal Object
In Azure AD, before a user or a software application tries to access a resource, it needs to have an identity representation in the directory. This representation is called a security principal.
User Principal:
Represents an individual user.
Example: If you’re an employee at a company using Azure AD, there’s likely a user principal that represents you in the directory. It contains information about you, such as your username and password.
Service Principal:
Represents an application or service.
Example: Imagine a web application that needs to access a database on Azure. That application will have its own identity, known as a service principal, in Azure AD.
Access Policy and Permissions
Once you have a security principal (either a user or service principal), Azure AD can determine what that principal can do. This is defined by the access policy and permissions.
There are three types of service principals in Azure
Application:
In the context of Azure AD, the “Application” type of service principal is a specific, localized instance of a general application definition (known as an application object).
If you have an application that is used in different departments of a company (each department can be thought of as a “tenant”), then each department would have its own specific version (or instance) of that application. Each of these instances is represented by an “Application” type service principal.
This specific service principal dictates:
- The permissions the app has in that department (tenant).
- Who can use the app within that department.
- What Azure resources the app can interact with.
Managed Identity:
Managed Identities are a special kind of identity in Azure that lets resources (like virtual machines) automatically have an identity. This identity can be used to securely access other resources.
When you use Managed Identities, behind the scenes, Azure automatically creates a service principal to represent the managed identity.
Legacy:
The “Legacy” type service principal represents these older applications. They were either created before the modern system was in place.
These three types are different ways of representing and managing application identities in Azure.
Relationship between Application Objects and Service Principals
Application Object:
It’s a blueprint of your application, which is intended for all the different regions (or “tenants” in Azure).
It sets the general standards and rules for your application everywhere.
Directly matches the software application. One software, one blueprint.
One blueprint can have multiple localized versions. So, one-to-many.
Service Principal:
This is the version of your app for a specific region or tenant, derived from the blueprint (Application Object). Acts as a local identity in a specific tenant. It handles sign-ins and accesses the resources in that tenant.
How is it used?
- Single-tenant Apps: Have just one service principal in their home tenant.
- Multi-tenant Apps: Have multiple service principals, one in each tenant where a user has given it permission.
Discover permissions and consent
Apps using the Microsoft identity platform use a specific authorization model, allowing both users and admins to manage data access. This system operates on the OAuth 2.0 protocol, letting third-party apps access online resources for a user. Each of these online resources has a unique ID or address. For instance, Microsoft Graph can be accessed at https://graph.microsoft.com, while the Microsoft 365 Mail API is available at https://outlook.office.com, and Azure Key Vault is at https://vault.azure.net.
Third-party resources integrated with the Microsoft identity platform can define specific permissions, breaking down their functionalities into manageable chunks. This allows apps to only request the specific permissions they require for their operations. This granular approach ensures that users and administrators have a clear understanding of the exact data and functionalities an app can access.
In the OAuth 2.0 framework, permission sets are known as “scopes”, which can also be termed “permissions”. On the Microsoft identity platform, each permission is depicted as a string. Applications specify required permissions using the “scope” parameter. This platform recognizes OpenID Connect scopes and specific resource-based permissions, identified by adding the permission string to a resource’s unique ID. For instance, the string https://graph.microsoft.com/Calendars.Read indicates a request to read users' calendars through Microsoft Graph.
Apps request access by sending specific “scopes” or permissions to the authorize endpoint. Some permissions, due to their sensitive nature, are labeled as high-privilege. These high-privilege permissions need special approval and cannot be granted by just any user. To request or grant these special permissions, apps use the administrator consent endpoint, ensuring that only authorized individuals (admins) can approve them.
Permission Types
Delegated Permissions:
Used by apps with a signed-in user.
Requires consent from the user or an administrator.
Allows the app to act on behalf of the signed-in user.
App-only Access:
Used by apps without a signed-in user, like background services.
Only an administrator can give consent.
Consent Types
Static User Consent:
Users give permission to the app for specific tasks when they sign in for the first time. Once given, this consent remains unless explicitly revoked by the user.
Incremental and Dynamic User Consent
Allows apps to request permissions as they are needed, rather than all at once.
Users consent to additional permissions over time as they use new features of the app.
More flexible and can enhance user trust as they’re only asked for permissions when necessary.
Admin Consent:
For permissions that are high-privileged or affect more than just the consenting user.
Requires an administrator of the Azure AD tenant to approve. Once given, the permissions apply to all users within the Azure AD tenant.
Understanding these consent types helps developers ensure that their apps access resources securely and in line with user or organization preferences.
Requesting Individual User Consent in OpenID Connect/OAuth 2.0
When an application needs specific permissions from a user, it sends a request to a specified endpoint. This is often done when a user first signs into an application.
The request is made using OpenID Connect or OAuth 2.0 authorization protocols.
GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=a5f9d7gh-12b7-56cd-89ef-7hij8kl90123
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fsampleapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcontacts.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&state=67890Explanation:
Endpoint: The URL https://login.microsoftonline.com/common/oauth2/v2.0/authorize is Microsoft's common endpoint where the request for user consent is directed.
client_id (a5f9d7gh-12b7-56cd-89ef-7hij8kl90123): This is a unique identifier for the application. It's essentially the application's "ID card" that tells Microsoft's service, "Hey, it's me, SampleApp, asking for these permissions."
response_type=code: By specifying this, the application is saying, “Once the user gives permission, send me back a code.” This code can later be exchanged for an access token.
redirect_uri (http://localhost/sampleapp/): After the user decides to give or deny permission, the service will send the response (containing the code or an error) back to this URL.
response_mode=query: The code (or error) will be attached to the redirect_uri as a query parameter.
scope: This is where the application specifies the exact permissions it needs.
https://graph.microsoft.com/contacts.read: The app wants to read the user's contacts.
https://graph.microsoft.com/mail.read: The app wants to read the user's emails.
state (67890): A random number or string for security. It helps prevent certain types of malicious attacks and ensures that the response you get is for the request you sent.
After this request, the user will see a screen asking if they’re okay with the application “SampleApp” reading their contacts and emails. If they agree, Microsoft’s service sends the redirect_uri an authorization code. This code is then used by the application to get the actual access token, which grants the requested permissions.
When an application needs to perform certain operations or access specific data on behalf of a user, it needs to request appropriate permissions. These permissions are called “delegated permissions” because the user “delegates” certain rights or privileges to the application.
To specify which permissions the application is seeking, Azure uses a parameter called scope.
The values provided in the scope are typically a list of strings separated by spaces. Each string specifies a particular permission that the application wants.
Example: If an app wants to read emails and access a calendar, the scope parameter might look something like this: https://graph.microsoft.com/mail.read https://graph.microsoft.com/calendars.read
Each permission value in the scope parameter is constructed by combining the resource's identifier (often called the "application ID URI") with the specific permission.
In the given example, https://graph.microsoft.com/ is the resource's identifier (for Microsoft Graph), and appending .mail.read or .calendars.read specifies the particular delegated permissions.
Once the user attempts to sign in to the application, the application redirects them to the Microsoft identity platform’s login page.
After entering their credentials, the platform checks if this user has previously consented to the permissions specified in the scope parameter.
If the user hasn’t granted those permissions before, or if an administrator hasn’t globally approved these permissions for all users, the platform will display a prompt asking the user for consent.
The prompt will describe each requested permission. For example, it might ask, “Do you allow the application to read your emails?” and “Do you allow the application to access your calendar?”.
The user can then choose to grant or deny those permissions. If granted, the application will be able to perform the specified operations on behalf of the user. If denied, the application won’t have access to those specific resources.
Discover conditional access
Azure Active Directory’s Conditional Access is a security feature designed to enhance app and service protection. It provides multiple layers of protection, including:
Multifactor Authentication (MFA):
An added security layer requiring users to verify their identity using multiple methods.
Intune Enrollment:
Only devices registered with Microsoft’s Intune can access specific services, ensuring adherence to organizational security protocols.
Location & IP Restrictions:
Access can be controlled based on a user’s physical location or the IP address, preventing unauthorized or suspicious access.
This feature empowers both developers and enterprises to implement robust and dynamic security measures tailored to their needs.
Impact of Conditional Access on Apps
Typically, Conditional Access doesn’t alter an app’s behavior, nor does it necessitate developer modifications.
If an app indirectly seeks a service token, code changes may be needed to address Conditional Access challenges, possibly involving an interactive sign-in prompt.
Scenarios Needing Code Adjustments
- Apps using the on-behalf-of flow.
- Apps interfacing with multiple services or resources.
- Single-page apps employing MSAL.js.
- Web apps making resource requests.
Both the app and any web API it interfaces with can be governed by Conditional Access policies. These policies are fluid, meaning enterprises can institute or rescind them as required. To ensure app consistency post-policy adjustments, it’s crucial to incorporate challenge response mechanisms.
Azure Conditional Access Examples
Single-Tenant iOS App
- Scenario: An iOS app is built for a single organization (tenant) with a Conditional Access policy applied.
- Action: When a user tries to sign in, the Conditional Access policy triggers automatically.
- Result: The user is prompted to undergo multifactor authentication (MFA) even if the app doesn’t request access to an external API.
App with Middle Tier Service:
- Scenario: The app is built to access a downstream API through a middle tier. An enterprise customer applies a Conditional Access policy specifically to this downstream API.
- Action: Upon user sign-in, the app communicates with the middle tier, sending a token. The middle tier then attempts to access the downstream API on behalf of the user.
- Result: The downstream API presents a “claims challenge” due to its Conditional Access policy. The middle tier relays this challenge to the front-end app, which must then satisfy the conditions of the Conditional Access policy (like MFA or other requirements)
Summary
Service Principals
Application Registration
All applications need to register with Azure Active Directory (Azure AD) to utilize Azure’s Identity and Access Management.
Registration assigns an identity to the app in Azure AD.
Tenancy Specification
- Single tenant: Restricted to use only within your organization.
- Multi-tenant: Available across multiple organizations.
Objects Created Post-Registration
- Application object: Represents the app uniquely in Azure AD.
- Service principal object: Denotes the active instance or manifestation of your app within the tenant.
Identification & Configuration
- Every app gets a unique ID, often referred to as the app or client ID.
Further configurations can be made in the Azure portal, such as
- Adding authentication secrets or certificates.
- Defining permission scopes.
- Customizing user sign-in visuals.
Application Object
The blueprint of an application within Azure AD.
Dictates the app’s global properties and behaviors.
Serves as the foundational template for the app.
Relationship with Service Principals
When the app is utilized in different Azure tenants, individual instances known as Service Principals are created.
Service Principals inherit properties from the Application object.
Application object acts as the master template, while Service Principals are its specific instances across Azure.
Service Principal Object
Represents the identity of a user or a software application before accessing resources in Azure AD.
Types of Security Principals
User Principal
- Represents individual users.
- Contains user-specific details like username and password.
- Example: An employee in a company using Azure AD will have a corresponding user principal in the directory.
Service Principal
- Represents applications or services.
- Serves as the identity of an application when it accesses Azure resources.
- Example: A web application needing to interact with an Azure database will have its own identity as a service principal.
Access Policy & Permissions in Azure AD
- Azure AD determines what actions a security principal (user or service principal) can perform based on access policy and permissions.
Types of Service Principals in Azure
Application
- Represents a specific, localized instance of a general application definition (application object).
- In a multi-department company (with each department seen as a “tenant”), each department has its own instance of an application. This instance is denoted by the “Application” type service principal.
This service principal specifies
- App permissions within the department (tenant).
- Who can access the app in that department.
- Azure resources the app can interface with.
Managed Identity
- Provides Azure resources (e.g., virtual machines) with an automatic identity for secure access to other resources.
- Azure creates a service principal behind the scenes when using Managed Identities.
Legacy
- Represents older application identities created before the establishment of the modern system in Azure.
