5.2. Authorization.md

Authorization

• Evolution
  • 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.

Claims-based authorization

• 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
• 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.

Role-based access control (RBAC) authorization

• An identity can belong to one or more roles.
• Access is granted or denied based on roles.
• In ASP .NET
  • 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"));
  • On actions and controllers you can then use [Authorize(Policy = "RequireAdministratorRole")]
• ❗ RBAC is built in ARM so classic deployment cannot use it
• Best practice: Grant users/team least privileges to get their work done.
• Role assignment Grant 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