In this post I want to list all identity protocols AD FS supports.


This post is split into multiple parts

Part 1 … will cover the installation from the internal ADFS Server

Part 2 … will cover the installation from the ADFS Reverse Proxy Server in the perimeter network

Part 3 … will cover all about certificates for an ADFS environment

Part 4 … we will create an ASP.NET Web Application (.NET Framework -Web Forms) and configure it to be claim aware using WS-FED.

Part 5 … we will create an ASP.NET Core Web Application (MVCs) and configure it to be claim aware using WS-FED.

Part 6 … we will create an ASP.NET Web Application (.NET Framework – MVC) and configure it to be claim aware by using OAuth 2.0 and OpenID Connect.

Part 7 … we will create an ASP.NET Core Web Application (MVC) and configure it to be claim aware by using OAuth 2.0 and OpenID Connect.

Part 8 … will explain and list all identity protocols, AD FS supports.




Table Of Contents
  1. Introduction
  2. WS-Trust
  3. WS-Federation (WS-Fed)
  4. SAML
  5. SAML 2.0 Web Browser Single-Sign-On
  6. OpenID Connect (OIDC)
  7. OAuth
  8. Links


Introduction

For most cases you will create a Relying Party Trusts in order to authenticate users for a web application which trusts the federation server (identity provider IdP).

AD FS supports the WS-Trust, WS-Federation (WS-Fed) and SAML 2.0 Web SSO protocols for relying parties.

AD FS uses for relying party trust web applications the SAML 2.0 Web Browser profile.
The Web Browser SSO profile defines how to use SAML messages and bindings to support the web SSO

SAML 2.0 specifies a Web Browser SSO profile involving an identity provider (IdP), a service provider (SP), and a principal wielding an HTTP user agent

Source: https://en.wikipedia.org/wiki/SAML_2.0#Web_browser_SSO_profile


Active Directory Federation Services (AD FS) Protocols Overview
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adfsod/a11c94b0-3952-412c-8a93-d2412dd063e1


WS-Trust

WS-Federation operates directly on top of the HTTP protocol and, specifically for AD FS, only with passive requesters, that is, web browsers. There is a class of applications that is not covered in the WS-Federation scenarios as implemented in AD FS, namely SOAP-based applications. These applications can also benefit from federation and the use of security tokens for purposes that are similar to those for WS-Federation.

The Web Services Trust Language [WSTrust] is available in AD FS to accommodate SOAP-based applications.

Source: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adfsod/e29e94c8-2e59-45ae-9b1c-943de1966ae8

WS-Trust is a WS-* specification and OASIS standard that provides extensions to WS-Security, specifically dealing with the issuing, renewing, and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange.

The WS-Trust specification was authored by representatives of a number of companies, and was approved by OASIS as a standard in March 2007.

Using the extensions defined in WS-Trust, applications can engage in secure communication designed to work within the Web services framework.

Source: https://en.wikipedia.org/wiki/WS-Trust

WS-Federation (WS-Fed)

WS-Federation is part of the larger Web Services Security (WS-Security) framework which provides a means for applying security to web services through the use of security tokens. WS-Security describes how to attach signature and encryption headers as well as security tokens (including binary security tokens such as X.509 certificates and Kerberos tickets) to SOAP messages. WS-Trust, another specification in the WS-Security framework, provides for federation by defining a Security Token Service (STS) and a protocol for requesting and issuing the security tokens. WS-Federation, as implemented in OpenSSO Enterprise, uses the OpenSSO Enterprise Security Token Service (modelled on the WS-Trust specification) to allow providers in different security realms to broker trust using information on identities, identity attributes and authentication, and provider federation. A principal requests a token from the Security Token Services. This token, which may represent the principal’s primary identity, a pseudonym, or the appropriate attributes, is presented to the service provider for authentication and authorization. WS-Federation uses several security tokens as well as the mechanism for associating them with messages. This release of OpenSSO Enterprise has implemented the following features of the WS-Federation specification.

Source: https://docs.oracle.com/cd/E19316-01/820-3740/ggkkw/index.html

Web Services Federation Language (WS-Federation) 
http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html



WS-Federation comes with a passive and active profile.

WS-Federation Passive Requestor Profile
https://en.wikipedia.org/wiki/WS-Federation_Passive_Requestor_Profile
Passive Clients (Browser )

WS-Federation Active Requestor Profile
https://en.wikipedia.org/wiki/WS-Federation_Active_Requestor_Profile
Smart Active Clients (SOAP)

Active, Passive and Passive-Aggressive
https://www.cloudidentity.com/blog/2008/06/05/active-passive-and-passive-aggressive/


A great post about passive authentification you will find below.

Passive Federation Basics
https://docs.microsoft.com/en-us/archive/msdn-magazine/2010/august/federated-identity-passive-authentication-for-asp-net-with-wif#passive-federation-basics

Passive federation scenarios are based on the WS-Federation specification. This describes how to request security tokens and how to publish and acquire federation metadata documents, which makes establishing trust relationships easy. WS-Federation also describes single sign-on and sign-out procedures and other federation implementation concepts.

While WS-Federation discusses many details about federation, there are sections devoted to browser-based federation that rely on HTTP GET and POST, browser redirects and cookies to accomplish the goal.

Some aspects of passive federation messaging are based closely on the WS-Trust specification. For example, passive federation employs a browser-compatible form of Request Security Token (RST) and RST Response (RSTR) when a security token is requested of an STS. In the passive federation scenario, I’ll call the RST a sign-in request message and the RSTR a sign-in response message. The WS-Trust specification focuses on SOAP-based (active) federation, such as between Windows clients and WCF services.


Simple Passive Federation Scenario

Users authenticate to their domain and are granted access to a Web application according to their roles. The participants in this authentication scheme include the user (the subject), a Web browser (the requester), an ASP.NET application (the relying party or RP), an IdP responsible for authenticating the users within its domain and an STS belonging to the user’s domain (IP-STS). A sequence of browser redirects ensures that the user is authenticated at her domain prior to accessing the RP.

Source: https://docs.microsoft.com/en-us/archive/msdn-magazine/2010/august/federated-identity-passive-authentication-for-asp-net-with-wif#passive-federation-basics



SAML

Security Assertion Markup Language (SAML) is an OASIS open standard for representing and exchanging user identity, authentication, and attribute information. SAML is fast becoming the technology of choice to provide cross-vendor single sign-on (SSO) interoperability.

OASIS
https://www.oasis-open.org/
https://en.wikipedia.org/wiki/OASIS_(organization)

The Organization for the Advancement of Structured Information Standards (OASIS) is a global nonprofit consortium that works on the development, convergence, and adoption of open standards for cybersecurity, blockchain, Internet of Things (IoT), emergency management, cloud computing, legal data exchange, energy, content technologies, and other areas.

A SAML assertion is an XML-formatted token that is used to transfer user identity and attribute information from the identity provider of a user to a trusted service provider as part of the completion of a single sign-on request. A SAML assertion provides a vendor-neutral means of transferring information between federation business partners.

As a protocol, SAML has three versions: SAML 1.0, SAML 1.1, and SAML 2.0. SAML 2.0 is an enhancement to the previous SAML 1.x specifications, but is not backwards compatible.

SAML 2.0 defines several request-response protocols, which all correspond to the action being communicated in the message. These protocols are HTTP-redirect based and involve the user’s browser. SAML 2.0 has defined several binding options, HTTP redirect, HTTP POST, HTTP artifact, and SOAP. These options specify the way in which messages can be transported. SAML 2.0 HTTP POST enables SAML protocol messages to be transmitted within an HTML form using base64-encoded content. SAML 2.0 HTTP POST enables the SAML provider and consumer to communicate using an HTTP user agent as an intermediary. HTTP POST is sometimes called Browser POST, particularly when used in single sign-on operations. SAML 2.0 Web Browser SSO Profile is defined to support web single sign-on. A web user either accesses a resource at a service provider, or accesses an identity provider such that the service provider and desired resource are understood or implicit. The web user authenticates to the identity provider, which then produces an authentication assertion, and the service provider consumes the assertion to establish a security context for the web user.

Source: https://www.ibm.com/docs/en/was-zos/9.0.5?topic=users-saml-web-single-sign


SAML defines XML-based assertions and protocols, bindings, and profiles. The term SAML Core refers to the general syntax and semantics of SAML assertions as well as the protocol used to request and transmit those assertions from one system entity to another. SAML protocol refers to what is transmitted, not how (the latter is determined by the choice of binding). So SAML Core defines “bare” SAML assertions along with SAML request and response elements.

Detailed documentation about SAML 2.0 you will find directly in wikipedia under the link https://en.wikipedia.org/wiki/SAML_2.0


SAML 2.0 Web Browser Single-Sign-On

SAML Web Browser Single-Sign-On (SSO) enables web applications to delegate user authentication to a SAML identity provider instead of a configured user registry.

Security Assertion Markup Language (SAML) is an OASIS open standard for representing and exchanging user identity, authentication, and attribute information. A SAML assertion is an XML formatted token that is used to transfer user identity and attribute information from the identity provider of a user to a trusted service provider as part of the completion of a single sign-on request. A SAML assertion provides a vendor neutral means of transferring information between federation business partners. Using SAML, an enterprise service provider can contact a separate enterprise identity provider to authenticate users who are trying to access secure content.

The SAML web SSO flow includes three actors: the end user, the identity provider (IdP), and the service provider (SP). The user always authenticates to the IdP, and the SP relies on IdP assertion to identify the user.


Source: https://www.ibm.com/docs/en/was-liberty/base?topic=authentication-saml-20-web-browser-single-sign

More about the Web Browser SSO Profile you will also find under


Besides the three protocols above for relying party (RP), AD FS support further protocols with OpenID Connect (OIDC) and OAuth. OIDC is an extension of the OAuth2 authorization framework and provides authentication on top. OpenID Connect specifies a RESTful HTTP API and is based on simple HTTPS flows.

Every OAuth client (native or web app) or resource (web api) configured with AD FS needs to be associated with an application group. The clients in an application group can be configured to access the resources in the same group. An application group can contain multiple clients and resources.

OpenID is supported since Windows Server 2016 AD FS.

AD FS OpenID Connect/OAuth Concepts
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-openid-connect-oauth-concepts

AD FS OpenID Connect/OAuth flows and Application Scenarios
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-openid-connect-oauth-flows-scenarios


To use OpenID/OAuth you have to create an Application Group.

OpenID Connect (OIDC)

Published in February 2014 by the OpenID Foundation, OpenID Connect is the third generation of OpenID technology. It is an authentication layer on top of the OAuth 2.0 authorization framework. It allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain the basic profile information about the end-user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.

OpenID Connect allows a range of parties, including web-based, mobile and JavaScript clients, to request and receive information about authenticated sessions and end-users. The OpenID Connect specification is extensible, supporting optional features such as encryption of identity data, discovery of OpenID providers, and session management.

Source: https://en.wikipedia.org/wiki/OpenID#OpenID_Connect

OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols


OAuth

OAUTH is used when there is a need to pass authorization from one service to another service without sharing the actual credentials, like the password and username. Using OAUTH, users can sign in on a single service, access the resources of other services, and perform actions on the service. OAUTH is the best method used to pass authorization from a Single Sign On platform to another service or platform, or between any two web applications.

Source: https://linuxhint.com/saml_vs_oauth/

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is used by companies such as Amazon, Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites.

Generally, OAuth provides clients a secure delegated access to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without providing credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

Source: https://en.wikipedia.org/wiki/OAuth

OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols



Details about OAuth 2.0 and OpenID Connect you will find in my following post.

How OAuth 2.0 and OpenID Connect works





Links

Active Directory Federation Services (AD FS) Protocols Overview
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adfsod/a11c94b0-3952-412c-8a93-d2412dd063e1

Identity management
https://en.wikipedia.org/wiki/Identity_management

Security Assertion Markup Language (SAML)
https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

SAML 2.0
https://en.wikipedia.org/wiki/SAML_2.0

SAML 2.0 Web browser SSO profile
https://en.wikipedia.org/wiki/SAML_2.0#Web_browser_SSO_profile

WS-Trust
https://en.wikipedia.org/wiki/WS-Trust

Web Services Federation Language (WS-Federation) 
http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html

OASIS
https://www.oasis-open.org/
https://en.wikipedia.org/wiki/OASIS_(organization)

AD FS OpenID Connect/OAuth Concepts
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-openid-connect-oauth-concepts

AD FS OpenID Connect/OAuth flows and Application Scenarios
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-openid-connect-oauth-flows-scenarios

ADFS Deep-Dive: Comparing WS-Fed, SAML, and OAuth
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/adfs-deep-dive-comparing-ws-fed-saml-and-oauth/ba-p/257584