Authentication and Authorization

Purpose

This page covers notes, labs, personal setup items, deviations, etc. covered in the Design authentication and authorization solutions Learn module.

Purpose
Authentication and Authorization

Authentication and Authorization

Authentication: Control who can access a system
Authorization: Control actions taken by authenticated entity (permission levels)

Design For Identity and Access Management (IAM)

Try to keep identity management:
- centralized
  - central location improves visibility and control
- seamless
  - Keep it easy and fast for users - reduce wasted time and productivity
- adaptive
  - Risk-based adaptive policies, conditional access, etc.
- simple
  - control access to apps and data for all users/admins. Only authorized users have access

Design For Microsoft Entra ID

Pretty cool little site demo of how a web application can utilize the Entra ID B2B and B2C options. Information on how it was done on the back end can be obtained by going through the demo OR:

Take a look at the GitHub page and make note of the page name of a relevant topic
go to https://woodgrovedemo.com/help``[pagename]
- e.g. https://woodgrovedemo.com/help/addAdmins
Take a look at how the feature was created
Cloud only or hybrid?
Keeps things centralized
- In hybrid: manage all users from on-prem
B2B, B2C and guest users allows for single, seamless logins for all users
Keep admin/sensitive accounts out of AD/Entra - maintain an air gap of administration
Single sign-on (SSO) keeps things simple and seamless

Design For Microsoft Entra Business-To-Business (Microsoft Entra B2B)

B2B divides the authentication and authorization between the two business entities
- Their authentication service provides authentication, you authorize what they have access to
- Any password resets, primary account data management, etc. is all through their identity provider
- They can use a multitude of identity providers
With MFA - you can enforce it on your side even if their identity provider doesn’t require it
Restricted to the SaaS tier or higher (web apps, mobile apps, etc.)
- Cannot peak into the IaaS authentication - e.g. No authenticating into Windows or Linux VMs

Design For Azure Active Directory B2C (Azure AD B2C, Business-To-Customer)

Very different vs B2B
A separate, unique Azure AD B2C tenant is created for the identities (different from business tenant)
Separates organization accounts from customer accounts
Allows for storing custom attributes in Entra ID
Pre-built or custom User Flows
- How customers navigate through sign-up, sign-in, etc.

Design For Conditional Access

When a user signs in, Conditional Access examines who the user is, where the user is, and from what device the user is requesting access. Based on these signals, Conditional Access can allow access, enforce multifactor authentication (MFA), or deny access.

Conditional access requires P1 or P2 licenses
It may not be a good fit inn the scope of a webapp or similar customer facing app
Consider triggering MFA for internal users/applications around:
- Geographical areas (eh. VPNs kind of get around this)
- Managed devices
- Approved client applications
  - e.g. Outlook only for email, no third party email client
- ALL users with the exception of a break-glass admin account should be enrolled
  - The break-glass account should NOT be used in regular day to day
  - Hard copy password stored in a secure location (could even do a split where 1/2 to one location 1/2 to another location)
  - This should be tested on a regular basis to ensure that the account can still authenticate (what if you’re compromised and this account is modified)
- Automatically take action based on risk discoveries
  - Manual intervention is too slow

Design For Identity Protection

Risk docs

Automate detection and take action
Investigate risks
Export data to other tools (SIEM)

Two risk policies are evaluated: user and sign-in
- User risk represents the probability that a user account is compromised
  - Calculated realtime and offline
  - Leaked credentials - Microsoft actively checks for these
  - Actual user activities are analyzed for unusual behavior
- Sign-in risk
  - Data around the actual sign in event like geographical locations where travel time is impossible, IP address linked to malicious actors, etc.
Not all risk detections make a sign-in event or user risky

Design For Access Reviews

Access reviews can be performed manually
Keep in mind any compliance audits and just schedule reviews around those
- Or one-off events where a mass hiring/layoff is done
Determine the scope of resources and the correct reviewer(s)
- What resources to include
- Who is the “subject authority”
- Timeline for review completion
- Automatic remediation?

Design For Managed Identities

IAM Overview

Basically - RBAC is based on Entra ID accounts. Apps and systems need a way to authenticate to other Azure services securely. The Entra ID mechanism is used to grant resources an Entra ID which is then be used in the typical RBAC process to access protected resources.

Managed identities eliminate the need for developers to maintain credentials inside their application code.
- This eliminates password leaks
Any resource that supports AD authentication can use the identity for authentication against Entra ID and obtain tokens to access non-Entra protected resources (i.e. storage accounts, key vault)
Two types.
- System vs User is not what it applies to, but what creates and managed the identity.
  - e.g. Azure manages the assignment of the system assigned, admins create and assign the user-assigned.
1. System-assigned
  - Created as part of resource deployment (VM, App Service, etc.) which then creates the service principal in Entra
    - Only that specific resource can use the identity
  - Removed when the resource is removed
  - Tied to a single resource/service instance (1:1)
  - Grants access to 1:n Azure services (same credential allows access to storage and key vault)
2. User-assigned
  - Created independent of a resource and then assigned to one ore more resources (1:n)
  - Removed separate from resources it is assigned to - own independent lifecycle

IAM Design Considerations

Build the application with an Azure service(s)
- VM, App Service, Azure Function, AKS, Container Instances, Logic App, Storage, etc.
- Target the service without having to manage credentials
System assigned identities for single workloads or independent identities
User assigned identities for workloads where resources are recycled frequently, but the permissions are consistent

Design For service principals for applications

Design For Azure Key Vault

Azure key vault manages access to secrets, certificates, tokens, passwords, etc.
Easily create and control keys to encrypt/decrypt data
Can also be used for TLS certificates
Premium tier required for hardware security module (HSM) keys
Granular app and individual access control
Centralized management
Monitor how/when sensitive data is access
Keep in mind the blast radius of a security event
- Separate key vaults by application is common
Cover who/what has access in policy
Use firewall and network service endpoints as well
Enable soft delete and purge protection