- Act of verifying if someone has access to a certain operation/subsystem.
- What can you do?
- Authorization in past
- Protocols like LDAP or tools like AD DS.
- Application queried database whenever a user attempted to access an application.
- Today
- Identity is managed by 3rd parties (Azure AD, Facebook, Google)
- Information needs to be shared in a standardized way to applications.
- Simplest solution
- Once users are logged in, ID provider is trusted by application and can share claims.
- To grant or deny access is based on arbitrary logic that uses data available in claims to make the decision
- Claim
- Name/value pair that represents what the subject is and not what the subject can do
- E.g.
DateOfBirth = June 8, 1970
- Claim
- Implementation in .NET
- Claim-based authorization checks are declarative
- Embedded in code against an action/controller, specifying claims required for current user, and optionally values of claims.
- Claims requirements are defined in policies.
-
Define policies in
Startup.ConfigureServices
.-
Require claim(s)
services.AddAuthorization(options => options.AddPolicy("EmployeeOnly", policy => policy.RequireClaim("EmployeeNumber")));
-
Require claim values
services.AddAuthorization(options => options.AddPolicy("Founders", policy => policy.RequireClaim("EmployeeNumber", "1", "2", "3", "4", "5")));
-
-
Apply policies on action/controller using
[Authorize(Policy = "EmployeeOnly")]
- 💡 Action overrides controller.
-
- Claim-based authorization checks are declarative
- An identity can belong to one or more roles.
- Access is granted or denied based on roles.
- ❗ RBAC is built in ARM so classic deployment cannot use it
- 💡 Grant users/team least privileges to get their work done.
- Authorize per role
[Authorize(Roles = "HRManager")]
or[Authorize(Roles = "HRManager,Finance")]
- 💡 Actions overrides controller declarations.
- For only authenticating, you can use
[Authorize]
and[AllowAnonymous]
- You can declare policies based on roles.
- In
Startup.ConfigureServices
- Require single role:
options.AddPolicy("RequireAdministratorRole", policy => policy.RequireRole("Administrator"))
- Require multiple roles:
options.AddPolicy("ElevatedRights", policy =>policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator"));
- Require single role:
- In
- On actions and controllers you can then use
[Authorize(Policy = "RequireAdministratorRole")]
- Granting access by assigning a Security Principal, a Role at a Scope
- Security principal. User, group or service principal.
- Role : Built-in or custom role
- Roles are specific to level, app type (VM, storage)
- Scope : Subscription, resource group or resource
- Azure has 70 built-in roles.
- Fundamental roles that apply all resource types:
- Owner: Root, can delegate, can be scoped.
- Contributor: Creates & manages but cannot delegate.
- Reader: Read only access
- User access administrator: Manages user access to Azure resources