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:
In the next section, we will talk about the key facts of the SAML 2.0 protocol.
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 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...
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...
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.
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...