Implement application authorization

Understanding Application Authorization in Azure AD

Application authorization in Azure Active Directory involves configuring who can access an application and what resources within that application they can use. In the context of Azure and Microsoft 365 services, this typically relates to managing access to web applications and software-as-a-service (SaaS) applications that integrate with Azure AD.

Authorization can be handled through a variety of methods:

• Role-Based Access Control (RBAC)
• Azure AD Conditional Access
• Azure AD App Roles
• OAuth and OpenID Connect permissions

Implementing Role-Based Access Control (RBAC)

RBAC in Azure focuses on the “roles” that users or service principals (applications) are assigned. These roles define what resources the user or service principal can access and what they can do with those resources. RBAC is mainly focused on the actions within Azure services, but it directly impacts application authorization when dealing with Azure-managed applications.

For example, you could grant a user the “Application Administrator” role, which authorizes them to manage all aspects of applications within Azure AD.

Azure AD Conditional Access

Conditional Access policies in Azure AD are if-then statements, if a user wants to access a resource, then they must complete an action. For example:

• IF a user wants to access Application A,
• THEN they must provide multi-factor authentication (MFA).

Conditional Access allows for granular control through conditions such as sign-in risk, location, device state, and more.

Azure AD App Roles

App roles are a feature of Azure AD that allows developers to declare roles within their applications. Administrators can then assign these roles to users, groups, or even other applications. This directly implements authorization in applications that are registered in Azure AD.

For example, an application could define the following roles:

OAuth and OpenID Connect Permissions

When dealing with modern authentication, OAuth 2.0 and OpenID Connect protocols provide authorization and authentication, respectively. OAuth 2.0 lets you define scopes and permissions for your application, while OpenID Connect works on top of OAuth 2.0 to add the authentication layer.

For instance, when a user logs into a third-party application using their Microsoft account, the application may request consent to read the user’s profile or send email on their behalf. These permissions are defined using OAuth 2.0 scopes.

Implementing Authorization in Practice

To implement application authorization, an Identity and Access Administrator might go through the following steps:

1. Register the Application in Azure AD: This is the first step, which involves setting up the application in the Azure portal and configuring its integration with Azure AD.
2. Define App Roles: Create roles within the application registration that define specific permissions and responsibilities within the application.
3. Assign Roles: Assign the defined roles to users or service principals that require access to the application. This can be done through the Azure portal or using PowerShell scripts.
4. Create Conditional Access Policies: Set up policies that define what conditions must be met for a user to access the application. This might involve requiring a compliant device, location-based rules, or forcing MFA.
5. Configure OAuth and OpenID Connect: Ensure that the application is correctly using OAuth and OpenID Connect to request the necessary permissions and authenticate users.
6. Testing: Before rolling out the application to a broader audience, thorough testing should be conducted to ensure that authorization rules are working as expected.

Implementing application authorization requires a thorough understanding of Azure AD and its capabilities. By controlling who has access to what applications and under which conditions, SC-300 certified Identity and Access Administrators play a pivotal role in the security and efficiency of an organization’s identity management strategy.