- Act of verifying someone's identity.
- Who are you?
- Client establish its identity to a server by using a digital certificate.
- 💡 Good as additional security for user authentication.
- In Azure, its handled by AAD.
- You can authenticate to e.g. custom services, Microsoft 365, Skype for Business, API Management, SharePoint..
- Good when multiple front-ends to back-ends architecture is in place.
- Solutions
- Traditionally: Install certificate on each server to establish trust.
- In cloud native for hybrid scenarios:
- Restrict access to Azure web app.
- You can use over SSL/TLS
- You can set API Management to use client certifications.
- Introduced with Windows 200 server.
- Hierarchical structure based on X.500
- DNS for locating objects, LDAP for interactions, Kerberos for authentication.
- Create trusts between domains
- With Organizational Units (OUs) and Group Policy Objects (GPOs) and joining machine
- IDaaS: Identity as a Service
- Identity & access management on Azure with directory services, identity governance and application access management (access control).
- Quickly enables SSO to commercial apps in marketplace and custom apps.
- Can be communicated through
- Microsoft Graph
- Azure AD Graph API (❗ obselete, use Microsoft Graph)
- Seamless, risk-based data protection controls
- Backed by ML and in-depth reporting
- Also known as Managed Service Identity, formerly called Azure Active Directory Managed Service Identity (MSI)
- A way to keep credentials outside of code.
- Your code calls a local MSI endpoint to get an access token (OAuth2)
- MSI uses the locally injected credentials to get an access token from Azure AD
- Your code uses this access token to authenticate to an Azure service
- When you enable MSI for an Azure service:
- Azure creates a Service Principal for the instance of the service in Azure AD
- Injects the credentials (client ID and certificate) for the Service Principal into the instance of the service
- Two types:
- System assigned: Added & managed by azure.
- Turn on / off: Resource -> Identity blade -> On/Off
- Enables Azure resources to authenticate to cloud services (e.g. Azure Key Vault) without storing credentials in code.
- RBAC permissions can be controlled in Azure AD
- User assigned: User assignes identities
- First create Managed Identity
- It's an ARM object where you can add/remove role assigments.
- Managed Identities > +Add
- Resource -> Identity -> User assigned -> +Add
- You can use this identity to authenticate to services that support Azure AD authentication, without needing credentials in your code.
- First create Managed Identity
- System assigned: Added & managed by azure.
- Both store directory data and manage communication including logon processes, authentication and directory sources.
- Azure AD is not domain controller in cloud, new way of thinking.
- ADDS is not the solution for cloud because
- Perimeterless enterprises requires new solution
- Perimeter Network (DMZ) : exposing external services to an untrusted network (e.g. internet).
- Cloud handles security instead of corporate firewall. to a domain.
- Perimeterless enterprises requires new solution
- Azure AD differs from AD DS as
- Has no OUs (organizational units) or GPOs (group policy objects).
- Uses SAML, WS-Federation or OAuth protocols for authentication.
- Does not use LDAP but REST API calls to Azure AD or Microsoft Graph API for interaction.
- Works over HTTP/HTTPS.
- Azure AD supports managed identities
- Integrates on-premises directories with Azure AD.
- Three primary components:
- Health monitoring
- Synchronization
- Creates users, groups and other objects.
- Ensures match between on-prem <=> cloud
- Active Directory Federation Services (AD FS)
- Configures hybrid environment with on-prem AD FS.
- Good for organizations with complex deployments:
- domain-joins SSO, enforce Azure AD sign-in policy, smart card + third party MFA.
- Features
- Filtering: Limit objects to be synced by filtering by domains, OUs or attributes.
- Password hash synchronization: On-prem AD is the authority so you can use your own password policy.
- Password writeback: Users can reset & change their passwords in cloud and have on-prem policies applied.
- Device writeback: Registered device in Azure AD is written in on-prem AD so it can be used for conditional access.
- Prevent accidental deletes: Limits delete operations (default: 500 per run)
- Automatic upgrade: Updates itself to the latest AD Connect.
- More about AD FS
- Part of AD DS. Uses it as an identity provider.
- Consists of two machines that trust each other
- Resource Server (e.g. AD DS):
- Authenticates & issues a token.
- Federation server (AD FS): identity provider
- Validates token & issues identity token for other local servers to accept.
- Resource Server (e.g. AD DS):
- Flow: App -> Resource Server (AD DS) -> Federation Server (ID provider) (AD FS)
- Provides SSO across organizational boundaries.
- Uses claims-based access-control and implement federated identity.
- Uses HTML from to send user's credentials to the server.
- Disadvantages:
- Requires user to interact with HTML web application.
- Requires measures to prevent cross-site request forgery (CSFR)
- User credentials are sent in plaintext as part of a request.
- Users log in with Windows credentials using Kerberos or NTLM.
- Credentials are sent in Authorization header.
- Best suited for intranet.
- Disadvantages:
- Difficult to use in internet without exposing all user dictionary.
- Can't be used for BYOD (bring your own device)
- Requires Kerberos or NTLM (Integrated Windows Authentication) support in client browser or device.
- Client must be joined to Active Directory Domain.
- In hybrid environment, it can be used to manage physical machines and to enable simple Windows-based authentication.
- Evolution
- Before: Federation with SQL DB for user names, passwords, profile data.
- Today: Hard to handle social identity providers when many of them implement storage, tokens & claims
- Identity: a set of claims
- More expressive than roles (booleans)
- Returned as series of claims by most social providers
- .NET identity implemantation
- Unified identity solution for ASP .NET applications.
- Implement provider model for logins
- You can simply add, remove or replace providers (e.g. AD DS, Azure AD, Facebook, Google)
- Supports claims-based authentication
- Integrates with most social providers including Azure AD.
- It's built-in, no code or SDK is required
- Runs separately as
easyauth.dll
- Runs separately as
- Claims are injected to .NET and other (e.g. PHP) applications.
- Runs in same sandbox as application code.
- Handles HTTP requests before application.
- Has built-in token store (token repository)
- You can collect & store & refresh tokens.
- E.g.:
- Post to authenticated user's Facebook timeline
- Read users data from Azure AD Graph API or event from Microsoft Graph.
- One factor (e.g. password) is weak.
- Recommended to have at least two of the following:
- Knowledge
- Something only the user knows.
- E.g. security questions, passwords, PIN.
- Possession
- Something only the user has.
- E.g. corporate badge, mobile device, security token.
- Inherence
- Something that user is.
- E.g. fingerprint, face, voice, iris.
- Knowledge
- Implement using Azure AD
- Two ways to enable
- Enable for each user:
- Two-step verification each time users sign in.
- Exceptions: Trusted IP addresses, remembered devices is turned on.
- Conditional access policy
- Uses the *Azure AD Identity Protection risk policy to require two-step verification based only on the sign-in risk for all cloud applications.
- Enable for each user:
- Available verification methods:
- Call to phone
- Text Message to phone
- Through Authenticator App (phone app from Microsoft):
- Notification through mobile app
- Verification code from mobile app
- 💡 Consider using Trusted IPs or named locations as a way to minimize two-step verification prompts.
- Two ways to enable
- Implement using .NET
- Multi-Factor Authentication SDK for C#, Java, Perl, PHP, Ruby.
- Each SDK includes a certificate & private key for encryption transactions that are unique to your MFA provider.
- ❗ Limitations:
- APIs have no access to users in Azure AD, you provide them.
- No enrollment & user management features.
- Multi-Factor Authentication SDK for C#, Java, Perl, PHP, Ruby.
- Tutorial
- In Azure AD
- App registrations -> Register server + client apps with URLs.
- For client: Settings -> Keys -> Passwords -> Create key with expiration date.
- Grant permissions to allow the client-app to call the backend-app.
- AD -> Application registrations -> client-app -> Settings -> Required permissions -> Add -> Select API (backend-app) -> Select permission
Access backend-app
- AD -> Application registrations -> client-app -> Settings -> Required permissions -> Add -> Select API (backend-app) -> Select permission
- App registrations -> Register server + client apps with URLs.
- In API Management instance
- Configure OAuth2.0 server
- OAuth 2.0 -> Add -> Type Token/Auth URL's (you can find in Endpoints page in AD) -> Add body parameter named resource, type Application ID of
backend-app
-> Client ID: use Application ID for theclient-app
-> Client secret: type secret you created inclient app
-> Copy redirect_url -> Create -> Go to Settings page of theclient-app
-> Reply URLs => Paste redirect_url
- OAuth 2.0 -> Add -> Type Token/Auth URL's (you can find in Endpoints page in AD) -> Add body parameter named resource, type Application ID of
- Protect API with OAuth 2.0
- APIs -> Select back-end app -> Settings -> Security -> Choose 2.0 -> Select OAuth2.0 server configured earlier -> Save
- Enable JWT validation for pre-authorizing requests: edit Policy XML add JWT logic.
- Configure OAuth2.0 server