B2B: SAML Connections - JIT Provisioning and BYOI
8 min read
SAP Customer Data Cloud CIAM for B2B supports the ecosystem where customers and partners are digitally engaging with your business. The use of federation to support core system capabilities such as authentication, authorization and user onboarding are very common. By far the most popular standard across business systems is SAML, which has existed since 2002, although there is increasing popularity in more modern standards such as OpenID Connect. Whilst OpenID Connect will most likely dominate the federation landscape in the future, SAML will still be around for a while longer.
We will discuss the use cases where SAML can be used as part of your CIAM for B2B implementation but first we will define the different types of SAML flows that CIAM for B2B supports.
Bring Your Own Identity
What is it?
Bring Your Own Identity (BYOI) is a somewhat confusing product name because it implies that you, as an SAP customer, can bring your own identity provider. The main use case for BYOI is to allow you, as an SAP customer, the capability to allow your customers and partners to bring their own identity provider. Perhaps a better name would be 'Bring Their Own Identity', although I'm not sure this has the same ring to it.
What this really means is that your customers and partners can log in to your business systems using their own organization's SSO credentials. In the below example, ACME is an SAP customer, and they host a portal where ACME customer users login to in order to interact with their business.
When the ACME customers user arrives at the portal, they click login and they are presented with a login screen (using Screensets for example). From this login screen they might be presented with different options for authentication, one of which would be to log in with their organizational account, like below:
Selecting this option triggers a SAML flow where Customer Data Cloud is the Service Provider (SP) and the external organization Identity Provider (most commonly Active Directory) is the SAML Identity Provider (IDP). As part of the SAML flow, data is passed back to Customer Data Cloud as part of the assertion, which allows Customer Data Cloud to create a copy of this account. The data provided will typically include:
- Email address
- Unique identifier
Group information allows Customer Data Cloud to automatically assign roles based on a predefined mapping.
Bring Your Own Identity needs to be configured for each customer/partner in order for it to be available as an option. This requires an exchange of SAML metadata files between Customer Data Cloud and the external Identity Provider, in order to establish the trust between them. This configuration is performed at the organization level.
Bring Your Own Identity offers several benefits:
- No additional password for external users to remember
- Allows external organizations to manage their own users through their internal processes
- Access control is handled through group → role mapping
BYOI will not be suitable for all customers and partners, especially when we think of smaller organizations who may not have the time or knowledge to establish the trust between the systems, or have such small volume of users that it doesn't offer meaningful advantages.
However, BYOI will be almost essential for larger organizations who will not want to manage their users manually. BYOI allows these organizations to manage user access completely within their own Active Directory (or other IDP), which also allows them to have a stronger governance over who has access, which is especially important when thinking about employees who leave the organization. It is very likely that an organization already has a well defined leavers process which includes de-provisioning from Active Directory, which in turn revokes access to your business systems.
Just In Time Provisioning
What is it?
Most business systems require a local copy of user data in order for users to access and utilize those systems with the correct permissions. The process for 'copying' the data to systems is known as provisioning and comes in two forms:
- Offline provisioning
- Just In Time Provisioning (JIT)
Offline provisioning requires an upload of user accounts, typically via batch file, at regular intervals such as once a day.. Just In Time Provisioning creates the copy of user data at the point of authentication, so that they are created 'just in time'. The type of provisioning will depend on the type of system; offline provisioning is more common in legacy systems and JIT is not supported in all systems.
Whilst the provisioning approach doesn't really matter in terms of the end result, JIT offers a more efficient mechanism for user provisioning because you don't need to think about integration, except for the frontend login process, which would be required either way.
Customer Data Cloud supports JIT in the context of SAML, where Customer Data Cloud is the Identity Provider (IDP) and an application is the Service Provider (SP). In the below example, ACME is an SAP Customer that hosts a portal which acts as a gateway to other applications in their digital ecosystem. An ACME customer logs in to ACMEs portal (the method of login is irrelevant - the user just needs a Customer Data Cloud session) and they navigate to another application by clicking on a link, which triggers an IDP-initiated SAML flow:
Once an ACME customer user is logged into the portal, they might be presented with a list of different applications they can access:
In this example, the 'Priority Support' application is a separate application which supports SAML for authentication and can also provision users at the point of authentication, so long as the SAML assertion it receives contains both personal and role information. Clicking the tile initiates an IDP-initiated SAML flow and the priority support application receives the following data in the SAML assertion:
JIT allows you to map special assets called 'Claims' into the SAML assertion. In the above example, editorRole and viewerRole are claims representing specific roles in the priority support application. Access to these claims can be determined through the policies that are created as part of Policy Based Access Control.
It won't always be possible to integrate the Customer Data Cloud APIs and SDKs into your business applications which is especially true when using cloud based providers. JIT offers the use of standards based authentication (and authorization) to applications in your landscape. JIT also allows you to centrally manage access to those applications through Customer Data Cloud.
JIT allows you to better integrate with the SAP landscape too as JIT is the perfect integration mechanism between Customer Data Cloud and SAP Business Technology Platform (SAP BTP) cockpit. Group information, which is required by SAP BTP cockpit, can be passed in the SAML Assertion from Customer Data Cloud, so users can be provisioned in SAP BTP cockpit as they authenticate.
BYOI and JIT
BYOI and JIT are completely independent of each other and can be used in conjunction if the requirements meet the functionality. In the below example, BYOI is being used as the authentication method for the ACME customer user, and then that user is navigating to another application from the portal, where a JIT flow is initiated:
In this example, steps 1-4, where the login takes place, could be replaced with any other authentication method (e.g. email/password or phone number login) and the ACME customer user would still be able to access the application using JIT. So whilst BYOI and JIT can work together, they don't always have to.
We have seen the different role that Customer Data Cloud can play as part of a SAML flow by using Bring Your Own Identity and Just In Time Provisioning.
Using these features will improve the experience offered to your customers and partners as they engage with your digitally.