Claims contain multiple statements the authenticated user or organization makes about itself or another subject. For example, a statement can relate to a name, group, buying preference, Citizenship, employment status, education level, or capability.

There are many different claims token formats, including SAML 1.1, SAML 2.0, Simple Web Token (SWT), and JSON Web Token (JWT).

Claims can provide extra data, which means the application is not required to communicate directly with the identity provider.

Claims tokens are signed to verify they have been issued by the correct Identity Provider (IdP).

A Security Token Service (STS) authenticates a user and returns a claims token.

To understand the concept of a security token service, envision an airport with a security checkpoint. The goal of the security officer is to allow only verified and valid passengers to pass through. To accomplish this, the officer requires passengers to present a passport or a state-issued ID (the token), which is granted by a trustworthy third party (the security token service), such as a government agency. This means the airport is absolved of the duty to authenticate the passenger's identity but rather trusts the issuing authority, while also ensuring the credibility of the presented document. Therefore, the airport can confirm the identity claim of the passenger.

Furthermore, the airport may offer different boarding processes for the economy and first-class passengers. The security officer might request an additional token, like a boarding pass, indicating the passenger's class. The trusted issuing authority for this token would typically be the airline itself. If the boarding pass indicates that the passenger is a first-class traveler, the airport can provide services accordingly, translating the authenticated first-class status to privileges such as fast-track security check or access to a luxury lounge.

The Identity Provider (IdP) provides an STS that authenticates users and returns a claims token.

Examples of IdPs:

• On-premise: Windows Server Active Directory with AD FS 2.0 (supports SAML 2.0 and other token formats).

• Public Cloud: Microsoft Entra ID, OneLogin, Ping Federate, and many others.

The Federation Provider (FP) provides an STS (also known as a Resource STS) that trusts other STSs. An FP can perform claims transformation on the token received from the trusted STS.

Examples of Federation Providers:

• On-premise: Windows Server Active Directory with AD FS 2.0 and Ping Federate.

• Public Cloud: Microsoft Entra ID and Microsoft Entra ID Access Control.

An application that relies on claims is a Relying Party (RP) application. Synonyms for an RP include “claims-aware application” and “claims-based application.” Web applications and Web services can both be RPs. A relying party (RP) application uses the tokens issued by a Security Token Service (STS) and extracts the claims from tokens to use them for identity-related tasks.

The TotalAgility application is the relying party in this instance.

• Decouples the authentication mechanism from applications and services.

• Replaces roles with claims as a more flexible, granular artifact for authorization.

• Reduces IT overhead related to provisioning and de-provisioning users.

• Grants trusted domains, possibly including external federated partners, access to application features, and functionality.

• Allows single sign-on to a single identity provider for multiple RP applications.

Three commonly used standards for single sign-on are Security Assertion Markup Language (SAML), Web Services Federation Language (WS-Federation), and OAuth2. They are very similar but also incompatible.

All these standards allow users that have already logged into one site to access another site without logging in again (single sign-on). They do this by allowing sites to present proof that a site and a user are who they say they are.

SAML and WS-Federation (WsFed) support single sign-out and support metadata to exchange SSO information between parties. They also support building large complex federations of many sites in a sophisticated web of trust. Single sign-on (SSO) is a subset of a federated security system in which a user's single authentication ticket or a claim token is verified across multiple IT systems or even organizations.

In reality, most people only use the “passive” features that allow single sign-on between web sites. WS-Federation is primarily championed by Microsoft, which has invested heavily in incorporating WS-Federation into its products. SAML is an older specification that is well-supported by many identity management vendors. However, most vendors, including Microsoft, are moving to support both standards. For solving single sign-on problems, there is not much difference between them. They use different terminology. One may be easier to set up depending on the environment. But either can be used for single sign-on.

SAML is an older protocol and enjoys widespread support. Software-as-a-Service (SaaS) vendors are more likely to support it than WS-Federation. On the other hand, if you are in a mostly Microsoft environment, WS-Federation is more ubiquitous. Microsoft’s Active Directory Federation Services (AD FS) comes with Active Directory support for both WS-Federation and SAML.

TotalAgility supports the following types of federations:

• Service Provider (SP) initiated federation

• Identity Provider (IdP) initiated federation

The difference between the two types of federation essentially depends on who started the logon sequence: TotalAgility or the Identity Provider.

For the Identity Provider, you must specify where you want to redirect to (Designer or Workspace) in the URL and also specify the logonprotocol query string parameter.

Configuring the federated security applies to both flows.

In a load-balanced environment, TotalAgility cannot correctly read the passed token from AD FS consistently as the load-balanced servers have unique machine Key identifiers by default. To configure TotalAgility with AD FS in a load-balanced environment, you must generate the machine key and propagate it to all servers.