User Switch in Multitenancy environment on SAP Cloud Platform

[priyanka_sadana2]

In this blog, you will learn a way to switch the user credentials while accessing the backend in a multitenancy environment on SAP Cloud Platform. I’ll start with explaining multitenancy followed by provider and tenant sub accounts, tenant on-boarding and off-boarding and then we will move to User switch.

Please pay attention to the fact that this is one of possible solution to achieve user switch and readers are free to come up with their suggestions.

I would like to thank Naresh Pidugu and Vaibhav Agarwal for their ideas while implementing the concept of User Switch.

What is User Switch?

Let’s consider a scenario where more than one customer/ company needs the same application with company specific data and each customer has multiple end users who need to access this application. Each user in each company is provided its own credentials to access the application. But the same user credential does not exist in the backend system because the customer does not want to do user management in it. Customer is ready to take one company’s credential for backend and wants to internally switch the user credential to company’s credential without providing these credentials to the user. We will come back to the details after covering the basic concepts.

Multi tenant environment on SAP Cloud Platform

• Develop and run a multi-tenant application in SAP Cloud Platform


• Share the application with multiple consumers/ tenants simultaneously


• Each consumer accesses the application by a dedicated URL which identifies their tenant. This URL gets generated when the tenant subscribes the application.

Where to host the application?

Approach 1:

An application provider has a global account. It contains

• Provider Sub account (where the multi-tenant business application is hosted)


• Customer Sub accounts (dedicated to each consumer or tenant)


• Once the multitenant application is developed, the developer must register it as a SaaS registry. This will enable the tenants to subscribe the application.

Approach 2:

Each customer and the application provider have a separate Global account.

• Once the multi tenant application is developed, it should be commercialized in CIS.

Tenant onboarding and offboarding:

Subscription is initiated from the customer subaccount.

The SaaS Provisioning service requires to define the following API end points:

PUT – callback/v1.0/tenants/*

DELETE – callback/v1.0/tenants/*

PUT is used to onboard a tenant when a customer subscribes to the application

DELETE is used to offboard a tenant when a customer unsubscribes to the application.

Click on subscribe and you will see a subscribed application which you can open via a click on “Go to Application”



Once the link gets generated, map it in the routes on provider account.

Let’s take an example to understand user switch (below details are based on Approach 1 in this blog)

We have a multi-tenant application App1 available as a SaaS registry. Two customers C1 and C2 need this application. C1 and C2 will have their respective tenant sub-accounts via which they will subscribe App1 and a unique URL will get generated.

Each user of C1 will use URL1 and each user of C2 will use URL2 and their credentials will get authenticated using respective customer IDP.

The users of C1 and C2 can now access the application but they do no have individual backend credentials that can allow App1 to interact with the backend.

Each company has its own backend credentials let’s call it as P1 and P2 for C1 and C2, respectively.

We need to switch the credentials of each user of Company C1 to P1 and the credentials of each user of Company C2 to P2 while they are accessing the application APP1.

How to achieve this?

• Th URL for each tenant is unique and contains tenant information and can be used to detect the tenant of the user.


• Maintain a destination per company. A destination consists of the system information and credentials. The system information for each company would be same but the credentials are different i.e. the room is same but the door to enter the room is different. Therefore, we require a separate destination for each company. Let’s call them as MTAppDest1 and MTAppDest2.


• Maintain user-provided variable which contains a mapping of tenant versus destination as you can see below.


• So, once the application needs to interact with the backend it will
  
  
  
  1. read the URL and detect the tenant id
  
  
  2. then will read the user provided variable present in provider sub-account which consists of the mapping of tenant id and destination.
  
  
  3. Once it knows the destination then it will read the destination configuration and access the backend system.
  
  
  
  

What is required when a new customer is to be onboarded?

1. Provide a new tenant account (sub-account in this case)


2. Subscribe the application


3. Create a destination in the Provider sub-account


4. Add a mapping in the user-provided variable


5. Add the new route to the routes

Note: When you have to follow  Approach 2 as per your requirement and in case commercialization process is taking time then in the mean time you can deploy the application using approach 1 and temporarily register it as a SaaS registry to test the onboarding, offboarding and the application behavior from another subaccount within the same global account. This will help you to be ready with a tested application.

 

[former_member189718]

Hi Priyanka,

thanks for this article.

Some ideas:

• if the consumer account is part of the same global account as the provider account, how should the destinations be maintained by the customer? The customers would not have access to this account.


• maybe a tenant -> destination mapping can be avoided, if there is a naming convention that every customer specifies the same name for the relevant destination


• the application doesn't need to read the URL to identify the tenant, the tenant is provided with the JWT token.

Best regards,

Jan

[priyanka_sadana2]

Hi Jan,

 

Thanks for the ideas.

• The destinations will be maintained in the provider sub account when a new customer has to be onboarded. This will be done by the provider and not the customer.


• Do you mean that destinations should follow a naming convention that represent the customer and using that convention (Regular Expression) we can identify the destination? I am trying to understand this. So, if a user accesses the application then we can identify the company via the tenant id and then for that tenant we navigate to the destination that follows a naming convention which is somehow related to the tenant id?


• Yes, you are right. The tenant can be accessed via the JWT token.

There is so much to learn from you Jan.

Thanks and regards,

Priyanka Sadana

[former_member189718]

Hi Priyanka,

yes, I agree it then has to be done by the provider. But the provider doesn't have all the details for this destination. So there needs to be communication between consumer and provider. That's why option 1 having a consumer subaccount within the provider's global account would not be an option for me at all.

I meant the following: if the application expects a destination for connecting to the back end, the application provides guidance that every consumer has to name the application "myCRMsystem". AS a consequence, the application always only reads "myCRMsystem" which is there for all the customers and gets the correct destination details.

Best regards,

Jan