Design identity and security

Skill 2.2: Design authorization

Authorization is the process of granting permissions for authenticated parties. It encompasses what data the user can access and what the user can do with the data. Microsoft Identity Platform implements the OAuth 2.0 protocol to handle authorization, as discussed in the “Design authentication” section earlier in this chapter. In this section, we will cover key concepts for delegating authorization for Azure services in the most seamless way.

Choose an authorization approach

The Microsoft identity platform implements authorization for application developers by providing open-source libraries for different platforms. In the Microsoft identity platform, the Azure Active Directory (Azure AD) acts as a single pane of glass for authentication (AuthN) and authorization (AuthZ) using industry-standard protocols Open ID Connect (OIDC) and OAuth 2.0.

The Microsoft identity platform issues the following types of security tokens used by the OAuth2 and OpenID Connect protocols

• Access token An access token is a security token that is issued by an authorization server (Azure AD) as part of an OAuth 2.0 flow.

• Refresh token Refresh tokens are timebound access tokens; authorization servers sometimes issue a refresh token while the access token is issued to allow the client app to use it while requesting a new access token.

• ID token ID tokens are sent to the client application as part of an OpenID Connect flow.

Depending upon the type of client application, such as Web apps, Web APIs, Mobile Apps, Desktop Apps, and the application architecture, it can use more than one of the authentication flows supported by the Microsoft identity platform. These flows can issue one or more security tokens and authorization codes for the client application to work. The Microsoft identity platform supports the following implementation of OAuth2 and Open ID Connect flows for different app scenarios

• Authorization Code flow: The OAuth 2.0 authorization code grant flow is recommended and can be used in native mobile or desktop apps, single-page apps, and web apps to gain access to protected resources, such as web APIs. In this flow, the client app securely acquires the access tokens that can be used to access protected resources and refresh tokens to get additional access tokens and ID tokens for the signed-in user.

• Implicit Flow: The implicit grant is a simplified version of authorization code flow that is optimized for single-page applications. Instead of issuing the client an authorization code in the implicit flow, the client is issued an access token directly. The silent SSO features of the implicit flow do not work across different browsers because of the removal of third-party cookies, causing applications to break when they attempt to get a new access token. Therefore, the authorization Code flow is recommended because it now supports single-page applications as well.

Hierarchical structure

As you can infer from the section organizing Azure resources on page 4 of Chapter 01, nearly everything in Azure security can be viewed in a hierarchical manner. Depending on your business rules and compliance, you can choose from a variety of levels in Azure to efficiently manage access, polices, and compliances. Following are the levels available in Azure:

• Tenant This represents an organization when signing up for Azure. Organizations may purchase more than one Azure account and can have several tenants. Also, private government tenants can be purchased, such as Azure Germany, Azure US, and so on.

• Management Group(s) This is considered to be the top-level management in Azure and allows the management of one or more subscriptions. There is a single top-level “root” management group in Azure for each directory. All other management groups and subscriptions fold up into this root management group. The root management group allows the application of global polices and role assignments at the directory level.

• Subscription(s) Subscriptions are logical containers that are used to provision resources for an organization. Companies can have one or more subscriptions that are categorized in various ways. Cost can be managed for large companies much more easily when separate subscriptions are created based on department, region, budget group, and so on.

• Resource Group(s) Resource groups are logical containers for related Azure resources. You can create resource groups if it makes sense for your specific grouping needs. Resources in a resource group can be deployed and deleted as a group. Also, RBAC can be applied at the resource group level to control access to the resources within the resource group.

• Resource Group Locking Resource groups are required for all Azure resources, and when a resource is created, it must belong to a resource group. From a security perspective, resource groups can be locked, which can help protect them from user deletion.

• Read-Only Read-only lock means authorized users can read a resource, but they can’t delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role. The great news is that Azure shows a very visible pop-up warning to any user who is trying to violate the read-only lock. If users attempt to edit a read-only resource group, they will receive a warning.

• Delete locking Setting this option prevents the resource group from being deleted, as shown in Figure 2-9.

  

  FIGURE 2.9 The Delete option is unavailable

• Resource(s) These are the individual IaaS and PaaS services, such as VMs, databases, functions, and so on, that have been created in a resource group.

Azure’s hierarchical structure is flexible in the sense that different organizations may structure and categorize management groups, subscriptions, resource groups, and resources, in any way they see fit. The planning of said architecture is often based upon business rules, or compliance. The planning should be carefully orchestrated by teams of people, including stakeholders. Once the architecture is in place, manipulating it can be a daunting task.

Table 2-3 shows an example of the hierarchical structure for the fictitious company, Lucerne Publishing:

TABLE 2-3 Azure hierarchical structure

RBAC (role-based access control)

Azure role-based access control (RBAC) assists administrators by allowing them to manage who can access resources and what they can do with those resources. By designating groups or individual roles, Azure will circumvent confusion and misplaced access. RBAC is built on top of Azure Resource Manager and provides granular access management of Azure resources. In addition, administrators have a central place to create and manage role-based access control from within Azure Active Directory.

Security Principal

A security principal is an object that is representative of users, groups, services, or managed identities that are requesting access to Azure Resources.

Role Definitions/Role Assignments

A role definition is set of permissions that are simply called roles. These permissions indicate what a user associated with a particular role has access to and what they can do. There are built-in roles (such as Owner, Contributor, Reader, and so on), but administrators can create custom roles in Azure RBAC as well. There are many ways to create custom role definitions, including PowerShell, Azure CLI, REST API, and the Azure portal. Custom roles in Azure have an orange resource icon, which makes them stand out from built-in roles. Listing 2-2 shows how to make a custom role in Azure with JSON:

LISTING 2-2 JSON custom role

//JSON Custom Role Definition
{
 
 "Name": "Resource Group Custom Editor",
 
 "Id": "00000000-00000000-00000-0000000000000",
 
 "IsCustom": true,
 
 "Description": "Can monitor resource groups, read resources, start resources, edit and
add resources. In addition the Custom Editor can create alert rules, and read/write or
delete diagnostic settings.",
 
 "Actions": [
 
  "Microsoft.Storage/*/read",
 
  "Microsoft.Network/*/read",
 
  "Microsoft.Compute/*/read",
 
  "Microsoft.Compute/virtualMachines/start/action",
 
  "Microsoft.Compute/virtualMachines/restart/action",
 
  "Microsoft.Authorization/*/read",
 
  "Microsoft.ResourceHealth/availabilityStatuses/read",
 
  "Microsoft.Resources/subscriptions/resourceGroups/write",
 
  "Microsoft.Insights/alertRules/*",
 
  "Microsoft.Insights/diagnosticSettings/*",
 
  "Microsoft.Support/*"
 
 ],
 
 "NotActions": [],
 
 "DataActions": [],
 
 "NotDataActions": [],
 
 "AssignableScopes": [
 
  "/subscriptions/{subscriptionId1}",
 
  "/subscriptions/{subscriptionId2}",
 
  "/providers/Microsoft.Management/managementGroups/{groupId1}"
 
 ]
 
}