The following is from Azure Developer Training lab for AZ-203

Claims

Authorization is the process of determining which entities have permission to change, view, or otherwise access a computer resource. For example, in a business, only managers may be allowed to access the files of their employees. In the past, this was simple toaccomplish with identity databases using protocols like Lightweight Directory Access Protocol (LDAP) or tools like Active Directory Domain Services. Whenever a user attempted to access an application, the application would query the identity database.

In a world where identity is usually managed by third-party providers, like Microsoft Azure Active Directory, Facebook, Google, LinkedIn, and Twitter, this information needs to be shared in a standardized way to applications. In the simplest workflow, the userneeds to access an application, so they first log in using their social identity. Once they are logged in, the identity provider is trusted by the organization’s application and can share claims about that user with the application.

When an identity is created, it may be assigned one or more claims issued by a trusted party. A claim is a name/value pair that represents what the subject is and not what the subject can do. For example, you may have a driver’s license issued by a local drivinglicense authority. Your driver’s license has your date of birth on it. In this case, the claim name would be DateOfBirth, the claim value would be your date of birth — for example, June 8, 1970 — and the issuer would be the driving license authority. An identitycan contain multiple claims with multiple values and can contain multiple claims of the same type.

Note: The terms authentication and authorization can be confusing. To keep it simple, authentication is the act of verifying someone’s identity. When you authenticate someone, you are determining who they are. Authorization is the act of verifying that someonehas access to a certain subsystem or operation. When you authorize someone, you are determining what they can do.

Claims-based authorization

Claims-based authorization is an approach where the authorization decision to grant or deny access is based on arbitrary logic that uses data available in claims to make the decision. Claims-based authorization, at its simplest, checks the value of a claim and allows access to a resource based on that value. For example, if you want access to a night club, the authorization process might be:

• The door security officer evaluates the value of your date of birth claim and whether they trust the issuer (the driving license authority) before granting you access.

In a relying party application, authorization determines what resources an authenticated identity is allowed to access and what operations it is allowed to perform on those resources. Improper or weak authorization leads to information disclosure and data tampering.

Claim-based authorization checks are declarative—the developer embeds them within their code, against a controller or an action within a controller, specifying claims that the current user must possess and optionally the value the claim must hold to access the requested resource. Claims requirements are policy based; the developer must build and register a policy expressing the claims requirements.

Claims-based authorization in Microsoft ASP.NET

The simplest type of claim policy looks for the presence of a claim and doesn’t check the value. First, you need to build and register the policy. This takes place as part of the authorization service configuration, which normally takes place in ConfigureServices()in your Startup.cs file:

public void ConfigureServices(IServiceCollection services) { services.AddMvc(); services.AddAuthorization(options => { options.AddPolicy("EmployeeOnly", policy => policy.RequireClaim("EmployeeNumber")); }); }

In this case, the EmployeeOnly policy checks for the presence of an EmployeeNumber claim on the current identity. You then apply the policy using the Policy property on the AuthorizeAttribute attribute to specify the policy name:

[Authorize(Policy = "EmployeeOnly")] 
public IActionResult VacationBalance() { 
  return View(); 
}

Alternatively, the AuthorizeAttribute attribute can be applied to an entire controller; in this instance, only identities matching the policy will be allowed access to any action on the controller:

[Authorize(Policy = "EmployeeOnly")] 
public class VacationController : Controller { 
  public ActionResult VacationBalance() { } 
}

If you have a controller that’s protected by the AuthorizeAttribute attribute but want to allow anonymous access to particular actions, you apply the AllowAnonymousAttribute attribute:

[Authorize(Policy = "EmployeeOnly")] 
public class VacationController : Controller { 

  public ActionResult VacationBalance() { } 

  [AllowAnonymous] 
  public ActionResult VacationPolicy() { } 
}

Most claims come with a value. You can specify a list of allowed values when creating the policy. The following example succeeds only for employees whose employee number is 1, 2, 3, 4 or 5:

public void ConfigureServices(IServiceCollection services) { 
  services.AddMvc(); services.AddAuthorization(options => { 
  options.AddPolicy("Founders", policy => policy.RequireClaim("EmployeeNumber", "1", "2", "3", "4", "5")); }); }

Role-based access control overview

Access management for cloud resources is a critical function for any organization that is using the cloud. Role-based access control (RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of resources in Azure.

What can I do with RBAC?

Here are some examples of what you can do with RBAC:

• Allow an application to access all resources in a resource group
• Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
• Allow a DBA group to manage SQL databases in a subscription
• Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets

Best practice for using RBAC

Using RBAC, you can segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions at a particular scope.

When planning your access control strategy, it’s a best practice to grant users the least privilege to get their work done. The following diagram shows a suggested pattern for using RBAC.

How RBAC works

The way you control access to resources using RBAC is to create role assignments. This is a key concept to understand – it’s how permissions are enforced. A role assignment consists of three elements: security principal, role definition, and scope.

Security principal

A security principal is an object that represents a user, group, service principal, or managed identity that is requesting access to Azure resources.

• User – An individual who has a profile in Azure Active Directory. You can also assign roles to users in other tenants.
• Group – A set of users created in Azure Active Directory. When you assign a role to a group, all users within that group have that role.
• Service principal – A security identity used by applications or services to access specific Azure resources. You can think of it as a user identity (username and password or certificate) for an application.
• Managed identity – An identity in Azure Active Directory that is automatically managed by Azure. You typically use managed identities when developing cloud applications to manage the credentials for authenticating to Azure services.

Role definition

A role definition is a collection of permissions. It’s sometimes just called a role. A role definition lists the operations that can be performed, such as read, write, and delete. Roles can be high-level, like owner, or specific, like virtual machine reader.

Azure includes several built-in roles that you can use. The following lists four fundamental built-in roles. The first three apply to all resource types.

• Owner – Has full access to all resources including the right to delegate access to others.
• Contributor – Can create and manage all types of Azure resources but can’t grant access to others.
• Reader – Can view existing Azure resources.
• User Access Administrator – Lets you manage user access to Azure resources.

The rest of the built-in roles allow management of specific Azure resources. For example, the Virtual Machine Contributor role allows a user to create and manage virtual machines. If the built-in roles don’t meet the specific needs of your organization, you can create your own custom roles.

Azure has introduced data operations (currently in preview) that enable you to grant access to data within an object. For example, if a user has read data access to a storage account, then they can read the blobs or messages within that storage account.

Scope

Scope is the boundary that the access applies to. When you assign a role, you can further limit the actions allowed by defining a scope. This is helpful if you want to make someone a Website Contributor, but only for one resource group.

In Azure, you can specify a scope at multiple levels: management group, subscription, resource group, or resource. Scopes are structured in a parent-child relationship.

When you grant access at a parent scope, those permissions are inherited to the child scopes. For example:

• If you assign the Owner role to a user at the management group scope, that user can manage everything in all subscriptions in the management group.
• If you assign the Reader role to a group at the subscription scope, the members of that group can view every resource group and resource in the subscription.
• If you assign the Contributor role to an application at the resource group scope, it can manage resources of all types in that resource group, but not other resource groups in the subscription.

Role assignments

A role assignment is the process of attaching a role definition to a user, group, service principal, or managed identity at a particular scope for the purpose of granting access. Access is granted by creating a role assignment, and access is revoked by removing a role assignment.

The following diagram shows an example of a role assignment. In this example, the Marketing group has been assigned the Contributor role for the pharma-sales resource group. This means that users in the Marketing group can create or manage any Azure resource in the pharma-sales resource group. Marketing users do not have access to resources outside the pharma-sales resource group, unless they are part of another role assignment.

You can create role assignments using the Azure portal, Azure CLI, Azure PowerShell, Azure SDKs, or REST APIs. You can have up to 2000 role assignments in each subscription. To create and remove role assignments, you must haveMicrosoft.Authorization/roleAssignments/* permission. This permission is granted through the Owner or User Access Administrator roles.

Deny assignments

Previously, RBAC was an allow-only model with no deny, but now RBAC supports deny assignments in a limited way. Similar to a role assignment, a deny assignment attaches a set of deny actions to a user, group, service principal, or managed identity at a particular scope for the purpose of denying access. A role assignment defines a set of actions that are allowed, while a deny assignment defines a set of actions that are not allowed. In other words, deny assignments block users from performing specified action seven if a role assignment grants them access. Deny assignments take precedence over role assignments. Currently, deny assignments are read-only and can only be set by Azure.

How RBAC determines if a user has access to a resource

The following are the high-level steps that RBAC uses to determine if you have access to a resource on the management plane. This is helpful to understand if you are trying to troubleshoot an access issue.

1. A user (or service principal) acquires a token for Azure Resource Manager.The token includes the user’s group memberships (including transitive group memberships).
2. The user makes a REST API call to Azure Resource Manager with the token attached.
3. Azure Resource Manager retrieves all the role assignments and deny assignments that apply to the resource upon which the action is being taken.
4. Azure Resource Manager narrows the role assignments that apply to this user or their group and determines what roles the user has for this resource.
5. Azure Resource Manager determines if the action in the API call is included in the roles the user has for this resource.
6. If the user doesn’t have a role with the action at the requested scope, access is not granted. Otherwise, Azure Resource Manager checks if a deny assignment applies.
7. If a deny assignment applies, access is blocked. Otherwise access is granted.

Classic subscription administrator roles, Azure RBAC roles, and Azure AD administrator roles

If you are new to Azure, you may find it a little challenging to understand all the different roles in Azure. This article helps explain the following roles and when you would use each:

• Classic subscription administrator roles
• Azure role-based access control (RBAC) roles
• Azure Active Directory (Azure AD) administrator roles

How the roles are related

To better understand roles in Azure, it helps to know some of the history. When Azure was initially released, access to resources was managed with just three administrator roles: Account Administrator, Service Administrator, and Co-Administrator. Later, role-based access control (RBAC) for Azure resources was added. Azure RBAC is a newer authorization system that provides fine-grained access management to Azure resources. RBAC includes many built-in roles, can be assigned at different scopes, and allows you to create your own custom roles. To manage resources in Azure AD, such as users, groups, and domains, there are several Azure AD administrator roles.

The following diagram is a high-level view of how the classic subscription administrator roles, Azure RBAC roles, and Azure AD administrator roles are related.

Classic subscription administrator roles

Account Administrator, Service Administrator, and Co-Administrator are the three classic subscription administrator roles in Azure. Classic subscription administrators have full access to the Azure subscription. They can manage resources using the Azure portal, Azure Resource Manager APIs, and the classic deployment model APIs. The account that is used to sign up for Azure is automatically set as both the Account Administrator and Service Administrator. Then, additional Co-Administrators can be added. The Service Administrator and the Co-Administrators have the equivalent access of users who have been assigned the Owner role (an Azure RBAC role) at the subscription scope. The following table describes the differences between these three classic subscription administrative roles.

Azure RBAC roles

Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management to Azure resources, such as compute and storage. Azure RBAC includes over 70 built-in roles. There are four fundamental RBAC roles. The first three apply to all resource types:

The rest of the built-in roles allow management of specific Azure resources. For example, the Virtual Machine Contributor role allows the user to create and manage virtual machines.

Differences between Azure RBAC roles and Azure AD administrator roles

At a high level, Azure RBAC roles control permissions to manage Azure resources, while Azure AD administrator roles control permissions to manage Azure Active Directory resources. The following table compares some of the differences.

Manage access using RBAC and the REST API

Role-based access control (RBAC) is the way that you manage access to resources in Azure. This lesson describes how you manage access for users, groups, and applications using RBAC and the REST API.

List access

In RBAC, to list access, you list the role assignments. To list role assignments, use one of the Role Assignments – List REST APIs. To refine your results, you specify a scope and an optional filter. To call the API, you must have access to theMicrosoft.Authorization/roleAssignments/read operation at the specified scope. Several built-in roles are granted access to this operation.

1. Start with the following request:

   GET https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments?api-version=2015-07-01&$filter={filter}

2. Within the URI, replace {scope} with the scope for which you want to list the role assignments.
   

   Scope	Type
   subscriptions/{subscriptionId}	Subscription
   subscriptions/{subscriptionId}/resourceGroups/myresourcegroup1	Resource group
   subscriptions/{subscriptionId}/resourceGroups/myresourcegroup1/providers/Microsoft.Web/sites/mysite1	Resource

3. Replace {filter} with the condition that you want to apply to filter the role assignment list.
   

   Filter	Description
   $filter=atScope()	List role assignments for only the specified scope, not including the role assignments at subscopes.
   $filter=principalId%20eq%20′{objectId}’	List role assignments for a specified user, group, or service principal.
   $filter=assignedTo(‘{objectId}’)	List role assignments for a specified user, including ones inherited from groups.

Grant access

In RBAC, to grant access, you create a role assignment. To create a role assignment, use the Role Assignments – Create REST API and specify the security principal, role definition, and scope. To call this API, you must have access to theMicrosoft.Authorization/roleAssignments/write operation. Of the built-in roles, only Owner and User Access Administrator are granted access to this operation.

1. Use the [Role Definitions – List(https://docs.microsoft.com/en-us/rest/api/authorization/roledefinitions/list)] REST API or see Built-in roles to get the identifier for the role definition you want to assign.
2. Use a GUID tool to generate a unique identifier that will be used for the role assignment identifier. The identifier has the format:00000000-0000-0000-0000-000000000000
3. Start with the following request and body:

   PUT https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentName}?api-version=2015-07-01

   { “properties”: { “roleDefinitionId”: “/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleDefinitionId}”, “principalId”: “{principalId}” } }

4. Within the URI, replace {scope} with the scope for the role assignment.
   

   Scope	Type
   subscriptions/{subscriptionId}	Subscription
   subscriptions/{subscriptionId}/resourceGroups/myresourcegroup1	Resource group
   subscriptions/{subscriptionId}/resourceGroups/myresourcegroup1/providers/Microsoft.Web/sites/mysite1	Resource

5. Replace {roleAssignmentName} with the GUID identifier of the role assignment.
6. Within the request body, replace {subscriptionId} with your subscription identifier.
7. Replace {roleDefinitionId} with the role definition identifier.
8. Replace {principalId} with the object identifier of the user, group, or service principal that will be assigned the role.

Remove access

In RBAC, to remove access, you remove a role assignment. To remove a role assignment, use the Role Assignments – Delete REST API. To call this API, you must have access to the Microsoft.Authorization/roleAssignments/delete operation.Of the built-in roles, only Owner and User Access Administrator are granted access to this operation.

1. Get the role assignment identifier (GUID). This identifier is returned when you first create the role assignment or you can get it by listing the role assignments.
2. Start with the following request:

3. Within the URI, replace {scope} with the scope for removing the role assignment.

4. Replace {roleAssignmentName} with the GUID identifier of the role assignment.

Role-Based authorization in ASP.NET

Roles are exposed to the developer through the IsInRole method on the ClaimsPrincipal class. Role-based authorization checks are declarative—the developer embeds them within their code, against a controller or an action within a controller,specifying roles that the current user must be a member of to access the requested resource.

For example, the following code limits access to any actions on the AdministrationController to users who are members of the Administrator role:

[Authorize(Roles = "Administrator")] 
public class AdministrationController : Controller { }

You can specify multiple roles as a comma separated list:

[Authorize(Roles = "HRManager,Finance")] 
public class SalaryController : Controller { }

This controller would be accessible only by users who are members of the HRManager role or the Finance role.

If you apply multiple attributes, an accessing user must be a member of all the roles specified. The following sample requires that a user be a member of both the PowerUser and ControlPanelUser roles:

[Authorize(Roles = "PowerUser")] 
[Authorize(Roles = "ControlPanelUser")] 
public class ControlPanelController : Controller { }

You can further limit access by applying additional role authorization attributes at the action level:

[Authorize(Roles = "Administrator, PowerUser")] 
public class ControlPanelController : Controller { 
  public ActionResult SetTime() { } 

  [Authorize(Roles = "Administrator")] 
  public ActionResult ShutDown() { } 
}

In the previous code snippet, members of either the Administrator role or the PowerUser role can access the controller and the SetTime action, but only members of the Administrator role can access the ShutDown action.

You can also lock down a controller but allow anonymous, unauthenticated access to individual actions:

[Authorize] 
public class ControlPanelController : Controller { 
  public ActionResult SetTime() { } 
  [AllowAnonymous] public ActionResult Login() { } 
}

Role requirements can also be expressed using the Policy syntax, where a developer registers a policy at startup as part of the authorization service configuration. This normally occurs in ConfigureServices() in your Startup.cs file:

public void ConfigureServices(IServiceCollection services) { 
  services.AddMvc(); 
  services.AddAuthorization(options => { 
    options.AddPolicy("RequireAdministratorRole", policy => policy.RequireRole("Administrator")); }); 
}

Policies are applied using the Policy property on the AuthorizeAttribute attribute:

[Authorize(Policy = "RequireAdministratorRole")] 
public IActionResult Shutdown() { return View(); }

If you want to specify multiple allowed roles in a requirement, you can specify them as parameters to the RequireRole method:

options.AddPolicy("ElevatedRights", policy => policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator"));

This example authorizes users who belong to the Administrator, PowerUser, or BackupAdministrator roles.

Note: You can mix and match both claims-based authorization and role-based authorization. Is it typical to see the role defined as a special claim. The role claim type is expressed using the following URI:http://schemas.microsoft.com/ws/2008/06/identity/claims/role.