Federations in Blip

What are federations?

The process of federation in identity systems refers to the ability to establish a trust relationship between different domains or organizations. This allows users to log in to third-party systems using their existing credentials, without needing to create new accounts. This communication between identity providers (IdPs) and service providers (SPs) enables authentication to be centralized and reusable across distinct systems.

Federations allow our clients to use their existing accounts to access their respective company's resources and log in to the Blip platform. This enables clients to manage access controls and security protocols as they prefer, in addition to simplifying user onboarding and offboarding. This not only streamlines the user experience but also reduces administrative effort and enhances security, as authentication data remains under the control of the original IdP.

What are they for and which use cases are they suitable for?

Federation solves common problems such as account duplication, decentralized credential management, and the risk of password leaks. Instead of a user maintaining dozens of logins and passwords, they authenticate once with their trusted IdP, and federation ensures that other systems accept this authentication through protocols like SAML and OpenID Connect.

Ultimately, federation is an essential component for enabling Single Sign-On (SSO) scenarios between independent systems, facilitating the use of social identities (like Google or Facebook) in web applications, and integrating legacy systems with modern authentication platforms. It is especially relevant in modern architectures based on microservices or multiple front-ends that rely on a common identity to function in an integrated manner.

Protocols supported by Blip

Blip currently supports two widely recognized industry protocols: OpenID Connect and SAML 2.0.

OpenID Connect (OIDC)

OpenID Connect (OIDC) is a modern authentication protocol built on top of the OAuth 2.0 protocol. It was created to allow applications to verify a user's identity based on authentication performed by a trusted provider. OIDC is widely used in the modern web for being lightweight, secure, interoperable, and easy to integrate.

One of OIDC's advantages is its simplicity for developers. With few standardized endpoints, JSON support, and extensive use of HTTPS, it adapts well to web, mobile, and API applications. Furthermore, being based on open standards, it is compatible with various identity providers, such as Google, Entra ID (formerly Azure AD), Okta, and many others.

SAML 2.0 (Under homologation/testing)

SAML 2.0 (Security Assertion Markup Language) is a popular authentication protocol in corporate environments and legacy systems. However, being based on XML and involving more complex configuration (such as metadata exchange, certificates, and endpoints), SAML 2.0 is considered "heavier" compared to OpenID Connect. Still, it remains extremely relevant in contexts where a SAML authentication infrastructure already exists or where compatibility with older systems is a requirement.

How it works

Regardless of the protocol used, the general operation is practically the same and is described in the diagram below. The diagram has been simplified for easier understanding, removing components not directly linked to the process in question.

The user accesses one of the Blip products (BlipPortal or BlipDesk), which checks for an active session. If yes, the user gains access to the system; if not, they proceed to step 2.

The user is directed to Blip's Identity Provider (IdP). If there is an active session for this user, the Blip IdP returns access tokens (SSO) to the client application. If there is no active session, they proceed to step 3.

The Blip IdP identifies that a federation is registered for the contract and directs the user to the client's Federation Provider.

The Federation Provider directs the user to their own Sign-In page where the authentication process takes place.

The user enters their username, password, performs MFA, and follows the authentication process defined by the client.

With the user authenticated, the Federation Provider returns access tokens containing user data, such as email, to the Blip IdP.

The Blip IdP returns access tokens to the client application, allowing a session to be opened for the user.

Limitations

The federations process in Blip currently has the following limitations:

The email field is mandatory and must be provided by the client's Federation Provider, being used in Blip as the user identifier.

We do not automatically synchronize user permissions between the client's Federation Provider and Blip's Identity Provider.

We do not automatically remove/deactivate accounts when they are removed/deactivated in the client's Federation Provider. However, we are in the process of developing an API that will allow automating the removal of all platform accesses during the offboarding process, for example.

For more information, visit the discussion on the subject at our community or videos on our channel. 😃