Identity protocols

About claims-based identity protocols

Claims-based identity refers to a number of different protocols sharing a common undercurrent - they make authentication happen through boundaries. Those protocols differ from one another in various aspects, for example in the token formats they mandate or prefer, the exact message shape and sequence, metadata formats etc.

An outline of what an application should expect from a claims-based identity protocol is:

• Ability to read metadata
• Authentication and the ability to obtain tokens
• Token validation
• The ability to establish an application session (optional)

The first protocols that can be classified as claims-oriented appeared in the early 2000s. Two of them, SAML-P (Security Assertion Markup Language Protocol) and WS-Federation (Web Services Federation), are still widely used and supported in Windows Server AD and Azure AD.

Unit4 Identity Services (U4IDS) implements the OpenID Connect protocol that is considered to be a modern claims oriented protocol. U4IDS can act as a federation gateway and has support for connecting to external identity providers that implement one of the following identity protocols:

• OpenID Connect
• WS-Federation
• SAML-P

It is crucial to understand that any application using the features of U4IDS will communicate strictly using the OpenID Connect protocol.

This section provides an outline of the claims oriented protocols and how this area has evolved over time. For further details see the specifications. OpenId Connect is described in further detail here.

SAML Protocol

The Security Assertion Markup Language Protocol (SAML-P) dates back to the early 2000s as a concerted effort of various industry players who wanted to establish an interoperable solution to the SSO (Single Sign-On) problem. SAML 2.0 - P is the most widely adopted version and its most widely adopted use case is web-browser SSO.

SAML-P sidesteps the shortcoming of domain-bound cookies by adding an extra abstraction layer. Instead of relying on browser automatism, SAML-P introduces a sequence of application-level messages that enables an application to send authentication requests and obtain tokens that can be sent across domains. Once these tokens successfully cross domain boundaries they can be validated by the target app and used to initialize a session with the new domain.

U4IDS can perform federated authentication over the SAML 2.0 protocol to external Identity Providers. The implementation relies on the Sustainsys SAML 2 middleware.

Note

The SAML Protocol should not be confused with the SAML token format. WS-Federation uses SAML format for their tokens. The SAML 2.0 - P also uses SAML as its token format.

WS-Federation

Web applications were not the only type of applications that suffered from cross-boundary integration problems back in the early 2000s. Non-browser flows between remote components, such as server-to-server requests and calls from rich-clients to back-end resources also had to resolve the fact that any two entities could be separated by organizational and network boundaries.

A number of companies got together to create a set of protocols, languages and frameworks that defined how to ensure interoperable, reliable, and secure communications between software components regardless of their location, development stack and similar factors.

WS-Federation is one of the specifications that was produced as part of this effort. Its specific role was to define how to make possible for a user in a given organization to access resources managed by another organization. The WS-Federation also covered how to achieve its goal through browser-based application. This relatively minor section of the specification is what most people identify with WS-Federation today because it is the part still widely in use.

WS-Federation addresses many of the same scenarios as SAML-P but it does this with a significately simpler set of messages.

OAuth2

SAML-P and WS-Federation emerged from the needs of business applications. During the mid-2000s the rise of the public web and consumer applications showed there was a need for a different type of authentication and integration.

Say that web app A wanted to access the resources that one of its users keeps in web app B. Web app A simply asks its user to reveal his or her credentials for web app B to app A. App A would then use these credentials to access B and somehow retrieve the desired resources. Of course this approach is wrong, but those were the requirements that eventually led to the creation of OAuth (Open Authentication), an authorization framework designed to enable these scenarios while eliminating the need for sharing credentials.

OAuth 1.0 solved the delegated-access scenario between web apps but had many shortcomings. The OAuth working group quickly decided to build a new version on top of it - OAuth2.

OpenID Connect

The emergence of OAuth offered a solution for authorizing server-to-server access to resources, but that was not the only identity-related issue to be solved: the consumer web was not immune to the cross-domain single sign-on problem.

The desire to use the same account for sign-in purposes across multiple applications grew. Efforts were made to devise a general protocol to be used across vendors and applications. Despite initial support from multiple important vendors, the original OpenID formulation and its successor OpenID 2.0, never succeeded in becoming the de facto standard.

The OpenID working group decided to formalize the sign-in patterns introduced in OpenID 2.0 and position the new version named OpenID Connect as an extension to OAuth 2.0. OpenID Connect augmented the bare bones OAuth2 specification with various key extensions:

• OpenID Connect explicitly defines an authentication-request message type, layered on top of OAuth2's authorization request. It includes many new parameters meant to allow developers to control important aspects of the authentication experience.

• OpenID Connect extended OAuth 2.0 with a new token named ID token, which is meant to communicate to the client information about the authentication operation that took place in the context of an OAuth grant flow. OpenID Connect is normative about the ID token content, defining a set of claim types that must be present, their semantics, and how to use them for validation. Note that the ID token is often used to carry information about the user that authenticated and gave consent.

• Open ID Connect defines a formulaic API (Application Program Interface) which has the explicit purpose of obtaining information about a subject after the token-aquisition operation takes place. This API is exposed via the endpoint UserInfo.

• Whereas SAML-P and WS-Federation emphasized the advertisement of authority coordinates in the metadata documents to help apps consume their services, OAuth2.0 did not offer direct counterparts. OpenID Connect defined a document format for publishing endpoints, key material, identifiers and various other information that provides to apps the means to automate trust establishment, automatically keep track of endpoint changes and key rolling as well as many other functions expected in a modern sign-in solution.

U4IDS federation gateway implements these features and more.