Skip to content

Latest commit

 

History

History
206 lines (179 loc) · 9.95 KB

File metadata and controls

206 lines (179 loc) · 9.95 KB

Authentication

  • Act of verifying someone's identity.
  • Who are you?

Certificate-based authentication

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

Active Directory Domain Services (AD DS)

  • 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

Azure Active Directory

  • 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

Managed Identity

  • Also known as Managed Service Identity, formerly called Azure Active Directory Managed Service Identity (MSI)
  • A way to keep credentials outside of code.
    1. Your code calls a local MSI endpoint to get an access token (OAuth2)
    2. MSI uses the locally injected credentials to get an access token from Azure AD
    3. 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.

AD DS vs Azure AD

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

Azure AD Connect

  • 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
      1. Resource Server (e.g. AD DS):
        • Authenticates & issues a token.
      2. Federation server (AD FS): identity provider
        • Validates token & issues identity token for other local servers to accept.
    • 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.

Legacy authentication methods

Forms-based authentication

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

Windows-based authentication

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

Token-based authentication

Claims-based authentication in .NET

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

App Service authentication and authorization

  • It's built-in, no code or SDK is required
    • Runs separately as easyauth.dll
  • 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.

Multi-factor authentication (MFA)

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

Implementing OAuth2

  • 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
  • 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 the client-app -> Client secret: type secret you created in client app -> Copy redirect_url -> Create -> Go to Settings page of the client-app -> Reply URLs => Paste redirect_url
    • 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.