Tenancy or B2B ? — which to pick ?

WSO2 Identity Server was released with B2B capabilities in built recently. There are people with doubts about what exactly Organization management is. On top of that, there’s confusion about what exactly the difference between B2B and Tenancy in the context of CIAM.

You must keep one thing in your mind while you try to understand this! Always try to understand the business cases and business nature to figure out whether it’s B2B or Tenancy. Also, there is no exact right answer in certain cases. What we discuss here is always arguable in both ways depending on the use case and the type of use case (workforce, CIAM, and so on). Well, another important point is we are only concentrating on Identity and Access Management here. What I am trying to do is to give you some guidance toward modeling your answer.

Let’s take an example to understand it better. Let’s take a typical SaaS solution which we are already familiar with. Zoom. Well if you are not familiar with Zoom it’s a cloud-based platform that allows users to connect for video and audio conferencing.

Let’s first talk about the nature of the business. They have one solution which is a video conferencing application that is being used by multiple types of users.

1. Individual users (direct consumer users: We call them B2C users) — You can consume Zoom as an individual by buying a subscription and registering with your email address.
2. Corporate account — This is when your employer decides to buy a Zoom subscription so you will be entitled to use it with your corporate email account. We call it B2B (Business to business) users. You will understand why it’s called Business to Business later.

The first case is trivial. Let’s talk more about the second case, which is B2B. Here the SaaS solution is Zoom and they have a single application used by multiple enterprises (organizations) like your organization. Your company pays them so that all your company users are entitled to use Zoom.

If you take a look at this from Zooms’ angel. For them, there can be multiple businesses that consume their service. Your organization is one of them. Different companies come and register to consume their service which is video conferencing.

For Zoom they have to manage these users coming from different organizations. More importantly in the context of organizations. When users try to access the application, you need to figure out which organization the user belongs to, and what kind of features/applications (In case they serve multiple applications) the organization has subscribed to before letting them access the application.

This is what we are trying to solve through B2B CIAM. Let’s dig deep and see what else the requirements are in terms of these organizations’ management.

• User profiles have to be maintained under different organizations. Each organization needs to have its admins to do user management/subscription management and so on. Eg: Your company’s DigiOps team members should be able to log in to Zoom as an admin and do some administration tasks under your organization. We call this delegated administrators.
• Admins at the Zoom level (Parent organization) should also have visibility to different organizations. (for user management and other level of administration tasks) as an example, if your organization admin needs some help configuring something or if an end user reaches Zoom through a support channel, the Zoom admins/support personnel should have insights/rights to do certain things under different organizations.
• Users need to be treated in the context of organizations. So when you authenticate a user, the proper organization has to be figured out.
• The application roles are decided and governed by Zoom, which is the parent organization. For example, the “zoom-admin”/”conference-organizer” roles are more application-related and those should be defined by the business-owning organization and then shared with other consumer organizations so that they can assign relevant users from their respective organizations. Likewise, there can be several other roles.
• What about permissions/scopes? Do you need to define permissions under every organization? Well, I would say No. The permissions/scopes that are related to the business/application have to be decided by the governing organization.
• Groups are a bit different. You may need to have your groupings for users. They are not associated with any permissions.
• Choosing MFA. MFA is a requirement for such SaaS applications. For certain organizations, there may be requirements to have certain levels of assurance when you authenticate to an application. Eg: You need to have a second-factor authentication mechanism configured to access any business application. In such cases, you need to give that flexibility to the respective application-consuming organizations.
• In case your company is a large organization, probably you may have your enterprise IDP which acts as the single source of user identities. In such a case, the company may need to plug this IDP into Zoom so that the company users can log in / Single Sign On using the same IDP without duplicating user credentials.
• Each organization may need its branding in terms of user experience. Even if Zoom doesn’t provide it, that can be a standard requirement when it comes to SaaS systems. URL branding is also a part of this branding where you need to access your organization-specific instance through a dedicated URL. eg: https://wso2.zoom.com

We’ve been discussing what to expect in a typical B2B scenario. Let’s discuss more.

You typically only have a single application that is implemented tenant-aware manner (SaaS). This application is shared between all companies. If you think this in the Identity Server context, you only need to create an application in the parent organization that can be shared across sub-organizations. There is no need to create applications (register client IDs and Secrets) in child organizations. (You may need to create applications if you have a requirement to expose APIs to sub-organizations so that they can consume those APIs from their Applications)

Do you expect any governing policies to be aligned with your company when you consume such a SaaS application? for example the user password strength, password expiration, login session duration, etc. Typically as an organization that consumes a SaaS application, you don’t have control over them. These are controlled and governed by the parent business-providing organization. If you need to align them to your organization’s policies, probably the solution is to plug in your enterprise IDP to SaaS application. This way, all your governing policies can also be effective as it’s your company’s enterprise IDP.

We discussed a lot about Organization management or B2B capabilities. Now let’s spend some time figuring out when we would consider Tenancy,

Tenancy is a more isolated concept. There can be requirements that each organization has to be completely isolated. There is no sharing. You don’t share a SaaS application that is provided by a parent organization. Instead, what you need is an isolated Identity Provider which can act as an IDPs for different companies/organizations to cater to their Identity and Access management requirements.

Each of these isolated groupings (can be organizations/ departments) may have their own applications developed and needs user authentication independently. These applications may be independent and self-governing. These isolations may have their governing policies such as password policies, session expiration, token validities, and so on. They do not want anything to be inherited from anywhere as they are independent bodies.

You can think of this as an IDaaS solution as well. Similarly, Asgardeo is an IDaaS solution. You get your tenant when you sign up with it. Different organizations come and create organizations as they need IAM solutions for their organizations or companies which are totally isolated from each other. Contrastively if you are a SaaS business provider, you are not looking for an IDaaS platform. Instead, you look for an IAM platform that can cater to B2B capabilities including organization management.

The things we discussed may slightly be different when it comes to certain workforce requirements which we model using B2B capabilities. Again, it’s hard to defend which one is the right answer. You always have to explore and understand both the business requirements as well as use cases to decide which one suits you best. I hope you got some direction toward modeling towards the right answer for your question which to pick. Please comment on this if you would like to discuss anything further on this topic.