Suppose you are a cloud service provider delivering multiple Software as a Service (SaaS) offerings to your customers. All of your services follow a multi-tenant architecture and implement modern authentication mechanisms such as Single Sign On (SSO) protocols. Currently, all of your customers have to use your identity provider, which is itself built on a multi-tenant architecture. However, some of your customers have asked to use their own identity providers, such as Active Directory Federation Services (ADFS).

The Use-Case

The scenario outlined above requires some kind of intermediary service that can manage multiple Identity Providers (IdPs) and connect them to your services. The first obvious challenge to overcome is trust. Your service is a Service Provider (SP) from any Identity Provider's point of view, but if you have e.g. 10 SaaS offerings and 7 different customers, you and your customers do not want to implement all possible trust relationship combinations. An Identity Broker (IB) solves this problem because your services only need to trust the central Identity Broker and your IB only needs to trust your customers' IdPs. This greatly simplifies configuration and agreements.

Using an identity broker also solves a second challenge, and that's the identity boundary or realm. An identity broker can manage identities from different security contexts or realms. It can correlate user identities across different applications or services, as users may have different identifiers in different systems. The identity broker then links or maps these identities.

A More Technical Perspective

To successfully set up an identity broker, your services are required to adopt contemporary authentication protocols like SAML v2 or OpenID Connect. These protocols are ideal for the creation of an intermediary service that acts as a man in the middle (MitM), which is what is desired in this scenario.

Additionally, your services must be able to differentiate between customers, which is crucial. A multi-tenant architecture may not be obligatory, although it is often necessary to segregate clients to meet the demands for autonomy or isolation to comply with frameworks such as GDPR. However, occasionally, using an identity provider can facilitate identity linkage within your service. As an instance, you offer a platform for educators to exchange teaching material. A school district with numerous schools, each having their own IdP, may display interest. An IB can now integrate all teacher identities into the portal's security context, enabling information sharing among teachers from various schools.

Considerations Regarding Technology and Processes

When incorporating an identity broker into the system design, it is essential to become acquainted with authentication protocols such as SAML v2 or OpenID Connect. This is crucial because the specific authentication procedures and techniques vary between and within protocols. For instance, OpenID Connect features an implicit flow and a basic/authentication flow. The former is employed in the absence of a backend, such as in Single Page Applications, whilst the latter is reserved for situations where a token is not transmitted via the user agent because there is a backend. Being familiar with these distinctions ensures more secure authentication is provided.

A crucial next step involves identifying the attributes that your service providers require, as well as those that identity providers must transmit, to facilitate authorization within the services.

It is important to ensure that a method for discovering the correct IdP is in place. When a service requires an authenticated user, the user will be directed to the identity broker. It is necessary for the identity broker to know which IdP to contact in order to enable authentication. This can be achieved through the use of buttons, dropboxes, or identification of the IdP from the user's network. Other methods include asking for an email address to identify the IdP.

Other matters to contemplate include the onboarding and off-boarding procedures for service and identity providers. It is important to ensure that cryptographic information and certificates, as well as changing endpoints, are updated as needed.

How to Implement

There are numerous identity brokering tools available on the market. One of the prominent open-source tools is Keycloak. Alternatively, you can also create your own identity broker. From a technical point of view, an identity broker serves as a service provider for your customers' IdPs and as an IdP for your services. In addition to implementing endpoints for the supported protocols such as SAML v2 or OpenID Connect, it is also necessary to implement a discovery service.

Regardless of whether you are using existing tools or developing your own identity broker, the following aspects should be considered during implementation:

• Service/Application Integration
• Authentication Protocols and Identity Standards
• Linking or Mapping Identities
• Logging and Monitoring
• Scalability and Availability

Conclusion and Further Considerations

As previously outlined, an identity broker has some advantages when it comes to providing multiple services to customers, or when identities need to be linked or shared across security contexts. However, integrating an identity broker into your application/service landscape requires careful consideration. Processes for connecting identity providers and service providers are essential. Processes must be established to maintain up-to-date configuration and to control trust relationship. Both technical and business aspects should be considered, such as having contracts in place.

Additional security measures can be implemented for an optimized information barrier.

One valuable security feature is to offer step-up authentication in situations where the IdP providing the identity lacks a strong two-factor or multi-factor authentication (2FA/MFA). Essentially, the user presents a confirmed identity from an insecure IdP. The identity broker then initiates step-up authentication, which requires the user to provide a second factor such as a one-time password (OTP). The identity provider issues a token only after the user has provided the second factor for authentication, enabling them to access the services.

Furthermore, the authorization aspect plays a crucial role. The identity broker can be improved to verify if the user has the necessary rights to utilise a service. If they do not, the IB will not issue a token for that service. However, it is advisable not to rely solely on this type of authorization.