Reader small image

You're reading from  Mastering Identity and Access Management with Microsoft Azure - Second Edition

Product typeBook
Published inFeb 2019
PublisherPackt
ISBN-139781789132304
Edition2nd Edition
Tools
Right arrow
Author (1)
Jochen Nickel
Jochen Nickel
author image
Jochen Nickel

Jochen Nickel is a Cloud, Identity and Access Management Solution Architect with a clear focus and in-depth technical knowledge of Identity and Access Management. He is currently working for inovit GmbH in Switzerland leading and executing projects in the field of Identity and Access Management including Data Classification and Information protection. Jochen is focused on Microsoft Technologies, especially in the Enterprise Mobility + Security Suite, Office 365 and Azure. He is an established speaker at many technology conferences like Azure Bootcamps, TrustInTech Meetups or the Experts Live Switzerland and Europe.
Read more about Jochen Nickel

Right arrow

Chapter 6. Managing Authentication Protocols

In this chapter, we will provide you with an overview about the important authentication protocols you need to know in order to handle your configurations and projects in that field.

We see a lot of confusion in the usage of authentication protocols in our projects. It's very important to understand the different protocols, that you can discuss with application providers about the correct implementation tasks and requirements. We see very often that a lot of time is used for discussing authentication methods and solutions. It's clearly impossible to put all the material about the different authentication methods in only one chapter, as that would fill a complete book in the real world. We decided to provide you with essential summaries with extensive and working external examples. We will deploy many of the different authentication methods in the labs of this book. You will find specific labs to adapt your knowledge of technical configurations...

Microsoft identity platform


Microsoft provides an identity platform with two endpoints called V1.0 and V2.0 with two sets of client libraries to work with these endpoints. The following libraries are used: Azure AD Authentication Library (ADAL) SDK and the Microsoft Authentication Library (MSAL). In the Azure AD portal, we will find how to include applications built with ADAL or MSAL over the app registrations (preview), as shown in the following screenshot:

Microsoft identity platform overview

The following list describes the main use cases of the two endpoints:

  • The V1.0 endpoint allows only work and school accounts to sign in
  • The V2.0 endpoint allows work and school accounts from Azure AD and Microsoft Accounts (MSA) to sign in
  • The v2.0 endpoint does not support SAML or WS-Federation—only OIDC and OAuth 2.0
  • The v2.0 endpoint doesn't support the SAML assertion grant
  • Both endpoints accept sign-ins from guest users for single-tenant or multi-tenant applications

Now that we have an overview on the...

Common token standards in a federated world


When a digital identity is transferred across a network, it's only a collection of bytes. It's common to refer to a set of bytes containing identity information as a security token or just a token. In a claims-based world, a token contains one or more claims, each of which carries some piece of information about the user it identifies.

Today, the tokens come in different flavors, including the following token formats:

  • Security Assertion Markup Language (SAML):
    • XML-based
    • Very descriptive metadata
  • JSON Web Token (JWT):
    • Easily readable by humans
    • Smaller token size
  • Simple Web Token (SWT):
    • Form-encoded attribute/value pairs
    • Not very common
  • Kerberos

For the following protocol specifications, we recommend a good basic knowledge of claims-based authentication. You can download the Microsoft claims-based authentication handbook to prepare yourself. Use the following download linkto get the book: https://www.microsoft.com/en-us/download/details.aspx?id=28362.

We will...

Security Assertion Markup Language (SAML) 2.0


SAML is the foundation for much of the current identity federation activity. SAML 2.0 is preceded by SAML 1.0 and 1.1. SAML 1.1 was released in 2003 and had just two scenarios (also known as profiles), and both were IdP-initiated. Shibboleth 1.3 and Liberty Alliance—WS-FF 1.2 extended SAML 1.1, and SAML 2.0 was released by OASIS in 2005.

The following table shows the SAML core principles:

Assertions

Protocols

Bindings

Package of identityinformation

Request/response based

Associates a message (protocol) with transport (communication mechanism)

Synonym token

Defines the messaging requirements

Examples:

  • HTTP Redirect
  • HTTP POST
  • HTTP Artifact
  • SOAP

XML-based

Examples:

  • Authentication request
  • Single logout
  • Artifact resolution

 

In the next section, we will talk about the key facts of the SAML 2.0 protocol.

Key facts about SAML

The SAML standard provides accurate messages for the transfer of requests and assertions (claims). SAML offers several options for the transfer of information...

WS-Federation


WS-Federation was developed by an industry consortium and was released in December 2006, with Microsoft being a key contributor. WS-Federation is also part of a larger framework, WS-Security, and builds on the work of WS-Trust from February 2005, defining the following two key principles:

  • The protocol for requesting/receiving security tokens
  • How trust should be brokered between parties using an Security Token Service (STS)

It also defines two profiles:

  • Active Requestor Profile
  • Passive Requestor Profile

WS-* Federation Suite consists of:

  • WS-Trust
  • WS-Federation
  • WS-Policy

In the next section, we will describe the key elements of the WS-Federation specification.

Key facts about WS-Federation

In WS-Federation, in contrast to SAML, the token can be anything. Basically no defined messages are used. On the other hand, a suggestion is made for the use of a web service. The WS-Federation standard uses SOAP and makes the tunneling of SOAP available via the Web browser. The token for this standard...

OAuth 2.0


In simple words, authentication is the act of proving who you are, whereas authorization is the act of determining what you can do. OAuth 2.0 is about delegated authorization and not about authentication. It is not a protocol, it's an authorization framework defined in the RFC 6749, The OAuth 2.0 Authorization Framework. This can be confusing because there are many cases in which you use OAuth 2.0 to log in to a client web application.

The authentication process must end by figuring out and validating the identity of the end user, but OAuth doesn't do that. OAuth provides time-based tokens, which can be used to access a resource on behalf of the end user without providing any identity information about the end user.

OAuth 2.0 is the existing standard for API security and is a major breakthrough in identity delegation.

Key facts about OAuth 2.0

The following are the principal facts concerning OAuth 2.0:

  • It is an internet protocol/specification for creating and managing application identity...

OpenID Connect (OIDC)


OIDC was established as a standard by its membership in February 2014. OIDC provides a lightweight framework for identity interactions in a RESTful manner. The specification was developed under the OpenID Foundation and has its roots in OpenID; it was greatly affected by OAuth 2.0, because that specification was not intended for authentication. Microsoft was also a co-author of the OIDC specification.

Key facts about OIDC

It defines the following identity layers on top of OAuth 2.0:

  • It uses two OAuth 2.0 flows:
    • Authorization code flow
    • Implicit flow
  • Adds an ID token to OAuth 2.0 exchange
  • Adds the ability to request claims using an OAuth 2.0 access token

The following roles are used:

  • OpenID Connect Provider (OP): Authorization server issues the ID token
  • Relying Party: Client application that requests the ID token
  • ID token: Issued by the OP
  • Claim: Information about the user

The following figure shows the OpenID Connect flow:

OpenID Connect flow

The flow runs with the following steps...

Pass-through authentication and seamless SSO


Azure AD pass-through authentication provides an alternative to the Azure AD password hash synchronization and a local ADFS infrastructure if all claims-based applications are connected to the Azure AD. Microsoft offers with this service the capabilities to reduce the on-premise complexity and operations of ADFS. Furthermore, in combination with the password hash synchronization, customers get a redundant and flexible authentication environment. You are also able to include password protection features for your local Active Directory.

Pass-through authentication supports the Azure AD conditional access policies, Azure MFA, and the blocking of legacy authentications to secure your organization's or customer environment. The communication of the on-premise agent and the Azure AD service is protected with certificate authentication. The feature can support multi forest infrastructures if forest trusts are enabled and the UPN-suffix routing is configured...

Multi-factor authentication


Protecting sensitive information or application access with additional authentication is an important task, not just in the on-premise world. In particular, it needs to be extended to every sensitive cloud service used. There are a lot of variations for providing this level of security and additional authentication, such as certificates, smart cards, or biometric options. For example, smart cards depend on special hardware used to read the smart card and cannot be used in every scenario without limiting the access to a special device or hardware. The following table gives you an overview of different attacks and how they can be mitigated with a well-designed and implemented security solution:

Summary


Working through the chapter and the given references, you have worked through many aspects and practical examples of the most important authentication protocols. We have tried to provide you with a very crisp reference card with much valid additional information about this topic. You should be able to use WS-Federation, SAML, OAuth 2.0, and OIDC in your design or configuration work for customers or your own organization. As already mentioned at the beginning of the chapter, we will use the knowledge in the upcoming chapters.

In the next Chapter 7Deploying Solutions on Azure AD and ADFS, we start to work on it directly!

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Mastering Identity and Access Management with Microsoft Azure - Second Edition
Published in: Feb 2019Publisher: PacktISBN-13: 9781789132304
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at £13.99/month. Cancel anytime

Author (1)

author image
Jochen Nickel

Jochen Nickel is a Cloud, Identity and Access Management Solution Architect with a clear focus and in-depth technical knowledge of Identity and Access Management. He is currently working for inovit GmbH in Switzerland leading and executing projects in the field of Identity and Access Management including Data Classification and Information protection. Jochen is focused on Microsoft Technologies, especially in the Enterprise Mobility + Security Suite, Office 365 and Azure. He is an established speaker at many technology conferences like Azure Bootcamps, TrustInTech Meetups or the Experts Live Switzerland and Europe.
Read more about Jochen Nickel

Attacker

Possible security solution

Password brute force

Strong password policies

Shoulder surfing Key or screen logging

One-time password solution

Phishing or pharming

Server authentication (HTTPS)

Man-in-the-Middle Whaling (Social engineering)

Two-factor authentication Certificate...