1. Use Cases
In chapter authentication methods we presented only briefly some use cases for the IdP. Let’s dive a bit deeper in different scenarios one might have. This is not exhaustive list and given examples are only examples.
Olevi IdP is very versatile product and can adapt to many different scenarios that we (the developers) have not even invented yet. If you have a problem, please, let us know so that we can study if it can be solved or alleviated using authentication.
Authentication Method Consolidation
With Id Brokering one can connect multiple Identity Providers to single broker entity and connect services to that broker.
Typical example is where two companies have merged but user migration is still unfinished. Company A) uses Google Workspaces and company B) uses Azure AD. Both companies have vast amount of users that need to migrate to use common platform. It may have been decided that merged company uses only Azure AD going forward, but company A) has vast amount of files and documents on Google Workspaces so that migration takes time.
Also, company A) has connections to multiple external services using Google Identity Platform so that users in company A) can use Google Credentials to access thir party services.
During migration period and even after migration preparing for the future it might help that instead of connectin third party service authentication to either identity platforms (Google or Azure AD), an Identity Provider will be taken in to use so that users from both platforms can access same services using their old credentials in their own company platform before the merger.
More difficult option to handle the merger case is to connect both platforms directly to both platforms. Many application providing Single Sign On (SSO) can connect only to one IdP. This is not lost cause still, as one can either expedite migration of group of those users that need to access the service most or try to find methods to federate another platform using second one.
Also, in worst case scenario where all applications need to be connected to both platforms, authentication provider selection need to be implemented to each service separately. In broker case the authentication method selection can be done on the broker IdP instead of implementing it differently on each service.
Authentication Flow Actions
In modern service architectures many such things can be achieved with only authentication and during authentication that have previously needed pre-provisioning or user data synchronisation before user can access a service. Olevi, powered by Shibboleth IdP, can do Actions during authentication flow to fulfill tasks that have traditionally been handled using Identity Management Systems (IdM) or syncing and replication services. There are two main possibilities:
- authentication flow Context-Check intecept mechanism
- completely customised authentication flows using Spring Web Flow (SWF)
Many modern authentication providers provide similar functionality through web-hooks that trigger external functions to add extra functionality. While this can be done using Olevi as well, being a code product, also more complicated functionalities can be programmed to be processed during authentication.
However, as we have stated elswhere in this document, one should still keep tools to what they are purposed to. Olevi is mostly a tool for authentication. It is fine line between overusing your tool for something it is not. While planning authentication flows, deep understanding in overall architectural big picture need to be maintained for not to step over that fine line. Stepping over the line might not harm immediately, but hinder future development or migration to other products.
Just In Time (JIT) User Provisioning
One example of authentication flow action step might be creating and updating user profile to a service that requires pre-provisioned user profiles.
JIT provisioning brings us an excellent real world use case example. As per documentation, Salesforce tells us that JIT Provisioning is possible for SSO-users that are able to connect their IdP to Salesforce using SAML2. What if an organisation has only OpenId Connect (OIDC) provider, or a strategical ground rule that only OIDC will be used in connecting to services?
SalesForce also states that OIDC providers can be connected, but that requires expensive license. Also, JIT user provisioning is currently documented only for SAML2 connections, not for OIDC.
Olevi can act as a protocol adapter between organisations actual Identity Provider and the service adapting one protocol to another.
In use case that SalesForce has documented, organisation can save moving from one license edition to another by connecting authentication with SAML2 instead of OIDC that requires different license edition.
Also, it might be that the service that organisation relies on supports only one kind of protocol. It might be that services migrate to modern architectures and support only OIDC where organisation has only SAML2 capable Identity Provider in use.