B2B Identity: More flavours than your local Ice Cream shop [Intermediate]

Good afternoon everyone. My name is Mithun. Welcome to this session. I work within the IAM Business Acceleration team at Thales.

So, let's start with something serious, very serious. A question. Who here loves ice cream? Let us do that with a show of hands. And if you don't raise your hand, that's fine. Don't worry. This is a safe space. We will accept you. We might judge you a bit, but quietly. Now you might wonder, it seems a bit odd. Why are we talking about ice creams in the context of B2B? But be with me and hopefully this will make some sense by the end.

So, let the ice cream be our spirit guide for the next 15 minutes. Moving on to the next question. When you are in an ice cream store, how many of you cannot resist picking more than one flavour?

Again, with a show of hands. Indeed, that's pretty much all of us, right? It's impossible. There are so many options to choose from. You have vanilla, chocolate, caramel, pistachio, mango, some of the most common ones. And then you have really exotic ones, which are quite difficult to pronounce as well.

So, think of thyme rosemary with the Amalfi lemon zest. But you still want to try them.

Now, as you are in that store, you're not trying to work, trying to make that choice. It is very overwhelming, but still there is a sense of joy attached to it.

So, when you walk out with a cup or a cone in your hand, of course you are overwhelmed with all the thoughts that you had to put in to make the choice, but there is still a lot of positivity and joy around it. So, please hold on to that feeling, that feeling of choice paralysis with joy, right, for a minute or a moment. And now contrast that to this feeling, when you're trying to figure out how to take care of your external business identities.

In this case, you are not overwhelmed with the ice cream flavours, but you are bombarded with the whole IM domain and subdomains of workforce, consumer, all the different acronyms you can think of, like SIAM, PAM, ZP, IDV, SCA, and probably an acronym that somebody must have made up five minutes ago. So, it's not that straightforward. It's not that easy. You start thinking, okay, what should I do? Should I use my workforce solution to take care of my external business users? But these are not really my employees, and these are not consumers either.

So, should I build a new portal? Should I try to search for a different portal? Or perhaps maybe I should just go to a corner and shed some tears and hope that magically the solution appears. But that's not the case. It's not that straightforward.

So, let's try to make it a bit more simple. Let's try to go to the basics, the Identity 101. Let's try to look at what are the core capabilities you can think of when you are talking about managing your B2B identity users.

So, well, you can have onboarding, authentication, authorization, self-service, which are kind of, you know, if you compare them to the rest of the IAM solutions, those are kind of similar. And then the fifth one, delegation management, which is a bit unique to the B2B proposition.

The rationale being that the reason why you're looking for such a solution is so that you can make sure that you reduce your IT cost, you reduce your help desk cost, so that you don't have to manage these thousands of external users, but rather you can delegate it to these third-party companies that you're dealing with. But is it really that straightforward?

Well, I wish it was, but that's not the case. As you start digging a bit deeper, let's say onboarding, you end up with questions like, what kind of onboarding are we talking about? Sorry for the technical delay. It's a difficult choice. I would say pistachio and mango, but I would choose the same flavors also in fruits and every possible option. Thank you. So when we go for onboarding, you will have questions like, okay, what kind of onboarding are we talking about? Are you talking about users or are you talking about organization?

Because unlike workforce or managing your employees and individual consumers, where there is no concept of an organization, there is only a concept of an individual user. In B2B, you can also have to deal with onboarding of organizations externally.

Similarly, when you go to authentication, and again, these are not exhaustive questions, but just to give you a flavor, what kind of authentication will you choose? Will you go for local credentials? So think of the fact that a central company issues a pair of credentials, a username and a password, that these external users can use to log in to access your business applications, or you are willing to have federated login, which technically is just a topic, but what it implies is that you are willing to trust the IAM solution of a third party, a third company that you don't control.

So this is purely based on trust. This would depend on factors like how mature their IAM practice is, how good are their policies with the security setup, and so on and so forth. So it's not just about the technicalities, but the repercussions it brings. Moving on to authorization, you can think, okay, is this going to be admin time or runtime?

Meaning, are you fine with the setup where somebody assigns a set of roles or entitlements and that's all, and the external user can log into any business application based on the roles and entitlements? Or you think, no, this is not enough. I need to go a bit more dynamic. I need to evaluate at runtime when the user is logging in and performing some action, whether he or she is allowed to do that. Then self-service.

Again, this is not so much self-service in the context of user, but self-service in the context of third party organization. What can they really do? Can they really set up their own federation, if you allow them to? Can they set up their own role catalog? So you can define the boundaries of what actions and entitlements could be, and then each third party organization can pick and choose and convert them into roles which are more suited for their company, depending on their size, how they are set up, so on and so forth.

And finally, the last bit, which is the delegated piece, which is, you don't want to manage these thousands of external users on your own, because you are going to incur cost, both in terms of infrastructure, in terms of people, so having a team in place to on-board them, off-board them, give them access, so on and so forth. So what you really want is to delegate this user and access management responsibility, what we call closer to the chain of command, which is where these users lie, which is in their own company to their respective managers.

But again, you can have questions like, yes, I do want to have a delegated manager, but what are the boundaries of it? What should this delegated manager be able to do? Should they be able to, let's say, on-board, off-board, delete users, give them access? Can they sub-delegate, meaning, can they appoint more delegated managers in their company?

Or, for example, can they change some data on the user? So you need to still define the boundaries of what that delegation really looks like.

So again, it's not very straightforward and simple. So let's try to, you know, put ourselves in the shoes of a few scenarios on what kind of flavors we would have chosen had we been in that situation. Before that, before we look at the scenario, let me bring up, you know, the personas. And this is, I can tell you, this is coming from our insights in having assisted select customers in the past and pretty much, you know, given the industry, the size, all those customers have more or less the same setup with, of course, different naming terminologies.

So think of yourselves as the central organization, right? The one that is really looking for a solution to manage these external identities. Now within that organization, you can have personas like Isaac, who's a technical guy. His responsibility is to basically set up the product, right? Configure it, make sure it works end-to-end. Another one could be George, who is a partner manager. Now this terminology, partner manager, can be different for different industries.

Again, it is also depending upon which side of the spectrum you're looking at. So are you looking at your suppliers? So the companies that provide you anywhere from raw materials to technology? Or are you looking at the other side, which could be your distributors? So your resellers, your distributing channel, your business customers. So that partner manager terminology can be different based on who you're looking at, but the crux remains the same. It is a person in your organization whose responsibility is to manage that relationship, whether it's with a business customer or with a supplier.

Now on the third-party organization side, right, think of whether a supplier, again a distributor, or a business customer, there could be different personas. Now for the simplicity, let's look at two different personas. You can have a lady like Jane, who is the manager, right? So she heads a team, and she is responsible for making sure that people that are joining her team get the right access in the right moment, quickly. And then in the end, you have a person like William, who's a business user.

Now this business user can be a seller, can be a broker agent, can be an office personnel, depending upon the situation. But he's a business user, right? So he doesn't care about what roles are and what IT infrastructure is. He wants to go about his daily job in the most frictionless manner. Now if you look at the persona ecosystem, you'll realize that these three are very business profile personas. They don't come with any kind of IT background, right?

So the solution you provide to them must be intuitive in nature, because otherwise you are going to end up with the same problem, that is a lot of help desk calls. Also, if you look at the capabilities, then what a George and a Jane can do is actually the key here. Because George should be able to manage multiple partners, which means that he should be able to set up multiple partners, assign delegated managers, control what they can do within the boundaries.

Similarly, Jane being the delegated manager will be the person responsible for managing her user population and her team. And there could be one or many Janes, right? Depending upon the size. So as I said, this is a summary of pretty much what we have assisted with most of our customers in the past. Now let's go to those three scenarios. So put yourselves in the shoes of an insurance company. They work with brokers, right? Third-party brokers that are reselling their insurance policies.

Now in this case, you can see that the volatility is not so much on the broker organization level, meaning insurance company don't sign up new broker firms every other month. Typically that happens, you know, maybe once every three to four months. Where the volatility lies is on the user level, because given the nature of the industry, there are a lot of people working in a freelancing manner as broker agents. Sometimes they work for two different broker firms, you know. So you're looking at managing volatility of users, but not so much organization.

And in this case, your crux is that you want to empower delegated managers. So think of Jane and alike, so that they can basically onboard users and manage their discretionary access. So you're looking at, you know, volatility of users, delegation of user, and delegation of access management. If you tie this back to those five flavors and scoops you saw, perhaps looking at the onboarding scoop, you might not choose the full portion, because yes, onboarding is for both users and organization, but in this case you're only dealing with the user onboarding.

You don't care about organizational onboarding, because it is not a problem at scale. So when you start picking those capabilities, you'll not choose each one of them in the same portion, and you might not pick all of those. So for example, self-service as well, that would be pretty limited here, because you don't want to allow them to set up their own role catalog, you don't want to allow them to have their own federation, so on and so forth.

Again, those two flavors being just an example. If you go ahead to a second scenario, so think of a manufacturing company that makes furniture. Now their market strategy is that they don't want to get into selling, so their selling is purely channel-based. So they only sell through their resellers and distribution network. They don't have direct sales, which means that they are working heavily with all different kinds of resellers across the globe. And as you can see, what would happen in this case is volatility on the organizational level. So you can have new resellers joining and leaving.

So big resellers can stick around for a longer time, but smaller resellers might join and try selling the furniture for a month, but if it doesn't go through, they might just off-board. So in this case, you are dealing with volatility of organizations as well, not just users. So the key here is that you want to enable these third-party organizations to be able to onboard themselves autonomously, manage their users, and also off-board themselves in the same manner if required.

So in this case, going back to the flavors again, if it was for onboarding, you will choose the full scoop, because you want both organizational onboarding. At the same time, you also want user onboarding. In this case, the authentication can also come with mixed flavors. You could decide that for business relationships with some of your trusted resellers who have been resellers for years, you might trust their federated authentication, but for all these local ones that come and go, you don't want to take that chance, and you want to issue them local credentials.

So again, it differs on what kind of flavor you choose given the scenario. Now let's look at the last scenario for today. Put yourselves in the shoes of a bank. Now in this case, the bank is dealing with their suppliers. So what they're looking at is being able to manage their technology providers. Now pretty much all of us would have a banking account, and it doesn't take a lot of thinking to understand that banks don't change their core platforms every year.

Typically, a bank would choose a core banking platform, and the chances are that it sticks around for decades. The same is the case with the debits and the credit cards. Usually banks don't do that in-house. They always tie up with the company that will personalize that card for you, dispatch it, courier it, and handle all of the lifecycle around it. So in this case, it's not so much about volatility of organizations, actually.

It's also not about volatility of users, because these are very handful of selected technology partners which are highly trusted, and the partnership runs across decades. And well, maybe you can have anywhere between a few hundreds to maybe lower ends of thousands of these kind of external users. So if you tie it back, the core crux here is that you want to grant these third-party organizations more autonomy. So the crux here again is autonomy. What can they do on their own?

Because they're highly trusted, they should be able to manage their own role catalog, they should be able to manage their own users, of course, the access, the federation, the policies, you name it. So the more autonomy you give them, the easier the collaboration and the working becomes. So if you had to tie it back to those five scopes, in this case perhaps you might choose a bit of user onboarding, not so much organization, but you will choose the full scoop of self-service. So what they can do autonomously, you know, without you having to come into picture.

So those were the three scenarios that we spoke about. Now it's Friday afternoon. We all have hit our data limits. You would have been part of, I guess, more sessions than there are categories in Netflix. So let's keep it a bit more simple, right? The only message I want you to take away from here is, next time, you know, when you head into the weekend and when you walk into a proper gelato shop to get some ice cream, think of the fact that, just like ice cream, within B2B IAM, the right scoop in the right portion makes all the difference.

So you have too much of authentication and it becomes a friction. You have too less of an authentication and it feels like you're handing out free samples on the street. It's no longer secure. So you have to get that right balance and that is the main message over here.

You can, before you start to make a proper solution, you try to look at what solution you want. You must look at what the setup is. How are these interactions happening, whether they are your suppliers or business customers, distributors, what kind of engagements do you have, where does the volatility sits, so on and so forth. Once you have that in mind, then you can look at what kind of core capabilities or flavors you're looking at and in what kind of scoop, right. At the same time, do feel free to grab some ice creams on the way out. We have them as handouts as you walk into the weekend.

So thanks a lot for making it to this session and I hope you have a nice weekend and hopefully next time or every time you get an ice cream cone or a cup, it's in the perfectly right proportion for you and every time you have an ice cream, you think of B2B IM. Thank you.