Federation
Introducing federation
Imagine three applications exist in an enterprise:
Sales system
Order system
AWS
The following would likely be a correct visual representation of the architecture:
In other words, each application has its own authentication logic (the purple part) and a (shared) user database where passwords are stored. This authentication logic is likely very similar in all three applications. Changes to it would require redundant code changes (for example, adding multi-factor authentication would impact the authentication component of all three applications).
A much better solution would be to decouple the authentication logic from the rest of the application logic, like so:
The applications now have to trust the authentication component. The existence of trust is why this pattern is called federation. Applications trust a central authentication component, to which they federate the authentication responsibility.
The PEP on the image is the Policy Enforcement Point. This is a generic term for the small part of logic that has to remain in each application to make sure a user went through the central authentication component before trying to access the application.
Federation concepts
Tokens
Typically, when the authenication component is separated from the other applications, security tokens are used to communicate identity information from the authentication component to the other applications.
A security token contains claims about a user
A claim is a statement that one subject makes about itself or another subject. Claims are issued by a provider, and are given one or more values. Examples of claims:
name: michael
role: app1_admin, app2_admin
email: michael@someapdomain.be
Security tokens can be self-contained or by reference. Self-contained tokens have all claims encoded inside the security token, whereas by reference tokens contain a database identifier. An application receiving a by reference token therefore still has to make a round-trip to the authentication component in order to request the claims identified by the reference. Self-contained tokens are most widely used currently.
Token formats
Many security token formats exist. The most known format in modern development is the JSON Web Token (JWT). An example of a token is this:
These tokens can easily be decoded by any Base64 decoding utility.
Another format, used commonly in traditional environment is a SAML token. These are based on XML and an example is provided here:
This is a bit more difficult to decode, since SAML uses inflation and deflation techniques. An online SAML decoder can easily handle this though.
Digital signatures
Self-contained tokens must be signed by the issuer to protect their authenticity and integrity. Unsigned tokens can easily be modified. Both the JWT as well as the SAML token example provided above were signed. Digital signatures will be covered in more detail later in the course.
Protocols to implement federation
Multiple federation protocols exist. Each protocol describes different alternative ways (called flows or grants) to communicate identity information using tokens. Typically, there are only a few alternative ways that are actually being used in practice.
SAML
Describes 12 different protocol flows
Uses the SAML token format (note that SAML is both a token format and a protocol)
OAuth2
Describes 4 different protocol flows
The token format can be freely chosen by the developer, typically JWT
OpenId Connect
Describes 3 different protocol flows
Issues two tokens: identity token (JWT) and access token (format can be freely chosen)
We won't cover SAML in this course, but much of the underlying principles that exist in OpenId Connect, were copied over from SAML.
OAuth2
What we have called authentication component until now is actually called Authorization Server in OAuth2. This may be confusing: authorization is different from authentication as we've seen in the chapter about basic authentication concepts.
OAuth2 is actually an authorization protocol, and not an authentication protocol. To make things even more confusing, this protocol was often tailored to make it work for authentication. Tailoring a protocol to make it work for something it was not intended is never a good idea. That is why, pretty soon after its release, the OpenId Connect (OIDC) protocol was invented. OIDC builds further upon OAuth2 and adds an authentication layer on top of it.
OpenId Connect (OIDC)
In OpenId Connect (OIDC) the authentication component is called OpenId Connect Provider. Since OIDC builds further upon OAuth2, two security tokens are issued:
identity token
access token (the OAuth2 part of the flow)
OIDC is mainly used in applications using a JavaScript front-end calling back-end APIs, but may be used in other environments as well. A complete example flow is displayed below. In this example, a JavaScript front-end (the demo app - called Relying Party in OIDC) calls a secured back-end (the API - called Resource Server).
The flow used in the example is called the Authorization Code flow. It is currently best practice to use this flow in favor of its deprecated alternative (the implicit flow). Also note that the identity token is used by the relying party, and is never used to call an API. Calling an API requires the use of the access token.
Refresh tokens, while an important part of the protocol flows discussed, are out of scope for the course. If you want to know more about them, here's a good start.
Single Sign On
Single Sign On is defined differently depending on the source you consult, but it basically means that a user has to authenticate once and is then able to use many (if not all) applications without having to authenticate again.
Federation protocols (such as OIDC) help in creating a Single Sign On (SSO) environment. In case multiple applications trust the same authentication component, a user will only have to authenticate once against that authentication component.
Last updated
