Suppose we have developed a cloud-native web application that is offered as a software-as-a-service. The application is capable of handling multitenancy, with each tenant having their own user store by default.
However, since our target audience consists mainly of larger enterprises, they prefer a single sign-on using their existing identities. Therefore, we need to add functionality for an external identity provider (IdP). This enables us to utilise identity federation.
The most common protocols for this scenario are SAML or OpenID Connect, where we act as a service provider and our customers provide their own identities.

For a better understanding, it is not necessary to have a deep knowledge of modern authentication protocols, but some basic knowledge is required. Typically, users are authenticated against the tenant's user store. However, if we use federated identities, we will trust another party to authenticate identities. This is done by redirecting a login to the customer's IdP. If authentication is successful, we receive a digital attestation in the form of an assertion or identity token.

Using Federated Identities

After implementing a federation trust and configuring it for the customer's tenant and their identity provider, we need to determine how to utilise their identities in our web application.

The concept of provisioning is important here. It involves managing access to resources for users by granting or revoking access rights, permissions, and necessary resources based on their roles.

The most intuitive way to provision users and their identities is to extend the attestation with attributes that contain access rights and permissions. As a service provider, we predetermine the attributes we expect and the allowed values for them. The identity provider must configure their system to add the necessary information to the attestation. 

This process can only run when an authenticated user accesses our application, making it a just-in-time provision. The application temporarily holds the user's information during the session, but it is lost once the session ends. This approach is beneficial from a data privacy perspective.

The Challenges of Employing a Just-In-Time Approach

However, this method of utilising identities presents certain challenges. For instance, if a global address list (GAL) is required or if some user identity information needs to be retained for future processing, an identity stub must be stored. This stub should be linked to a unique identifying attribute of the attestation, such as an email address or a universally unique identifier.

As we only receive information once a user has successfully authenticated, we can only update the identity stub when we receive a new attestation. This brings us to the second challenge, which is potentially outdated identity data. This is a serious issue, especially if a user has left the customer's company and may never log in again. The identity stub is never deleted if we do not implement a mechanism to delete them after a period of inactivity. However, this can result in losing information that we may need beyond this period.

Additionally, we have information on all identities that have logged into our web application. Populating the global address list can be challenging if some users never log in, resulting in an incomplete list that may cause customer complaints if they cannot find all their identities in the GAL.

Ahead-of-Time Solutions

One way to address this issue is through ahead-of-time provisioning. This proactive approach aims to ensure that the necessary setup and configurations are in place when users require access to our web application. Additionally, our GAL example would be populated with all the identities of the customer's employees.

As a service provider, we offer provisioning interfaces such as RESTful APIs (e.g. SCIMv2) or more traditional approaches like a LDAPS interface. This allows the customer to create, modify, and delete identities whenever there is a change on their side.

This approach addresses our three challenges, but it significantly increases the complexity of the overall system. For one, as a service provider, we must implement the necessary interfaces. But also the customer is responsible for deploying a provisioning solution on their identity provider side.

Conclusion

Using modern authentication protocols enables single sign-on experiences for customers, provided they have a centralised identity provider. However, when developing an application, one must consider how to handle the volatile identity information transported in an attestation. Sometimes no storage is necessary, while other times seldomly updated stubs are sufficient. Occasionally, the application may require provisioning before usage. Therefore, it is important to carefully consider the advantages and disadvantages, such as the trade-off between simplicity of the overall system and integrity of the stored identity information.