B2B and External Identity Governance

Well, I guess we may as well get going. Welcome, everybody. My name is Allan Foster, my colleague Guy Pensa. When we started looking at the B2B space, we got thrown into the topic late and the question we sort of came up with is, hey, we've done these. So I was one of the founders of ForgeRock, and during an extended period of time, I was heading up our technical side out of Singapore. And so we worked with a lot of big customers who were looking at various kinds of B2B problems.

And so I thought it probably would be worthwhile for us to share some of the learnings and some of the things we ran into. Specifically, nothing that we're going to say here is going to be revolutionary or something we haven't seen before. But every single one of them came from a customer deployment where there is surprise as we start talking about some of these things.

And so it may just be interesting for us to sort of go through, let me set up the, there we go, a little bit of context and stuff in this as to what kinds of B2B things, starting from some very simple ones through to some fairly complex kinds of issues, right, and setting up this context. So the sort of first thing that we have whenever you have any kind of B2B relationship is every other paragraph and probably every paragraph of things that you read contains the words either delegation or on behalf of.

And it breaks a lot of the thinking that we have as we start thinking around identity because, and we'll have a look at this in a few more slides later on, what it ends up doing is it brings multiple identities into things that we normally assume is one person. It's a simple use case. There is you, the creator of a document. There is the enterprise that is who you're creating that document for. And then there is what happens when you are no longer around. And so now there's what happens to the ownership of that. And those end up being pretty ugly kinds of discussions.

And so wherever we look at it, this idea of delegation and on behalf of, doing something on behalf of someone else. And we'll dive into some pretty heavy use cases on that. The level of integration with business processes can be across the board. And I'll sort of look and draw a couple of sort of tiers, starting from the simple ones, which probably most of us have done, to some really complex ones that we dive into them. So if we start off at the simplest of all, right? The simplest of all, just the enterprise wanting to go out and consume some resources or consume some services.

Not really a complex B2B case, but there's a couple of interesting things here. Me as the end user, I do not have control over the underlying connection and the relationships. Already we've got this separation of admin and the end user.

Example, something like Slack or Dropbox. It's easy. Any of us have implemented Slack to join into our conversation. What do we do? We throw in a URL that points to some kind of federation authentication service. And we're finished by Friday afternoon. It's all done. We've got everything in place. It seems really simple. The problem that comes up into this is just below the surface there's a whole lot of rocks sort of just waiting to get us later on when we don't think that they're going to come into this, right?

Federation, we can authenticate, OpenID Connect, we can use SAML, we can do any number of these things to do the initial authentication problem. And we ignore the problem of lifecycle. I think probably every other slide up here has the discussion of lifecycle. How do we – and even in the previous presentation there was the discussion of how do we determine when things change? When access rights should or should not change. The most important one is when that person is no longer there. What do we do with that?

Oh, it's easy. We just delete their account.

Yeah, what about the artifacts? And that simple discussion that we start going in and saying, well, what about the content they created? Let's say it's Dropbox. And they've put a whole lot of content up on Dropbox. If we delete the account, we delete the content. So now somebody, because it was done on behalf of, somebody has to take ownership of that. And it needs to be a process in order to get into that. And so once you open these up, these extended the pre-implementation discussion phase by weeks.

And as we try to decide what's going to happen with those, well, we can get a little bit more complicated. Slack, Dropbox, these are not that interesting to be able to go in and do. The authentication is easy. When are we going to provision? First time the user goes in or something along that line. Maybe it's just in time. Maybe we're going to do everything in a batch. There is no right answer here. There's just different answers.

But again, the life cycle comes into it. When do we deprovision? When do we know that we need to deprovision? In many of the organizations, it's never deprovisioned. The user's account stays there because it's easier to just leave it there in case we need it one day than to actually go in and clean up. So there's all of these kinds of things waiting to trip us up. Let's get a bit more complex in it. Let's start looking at things that start engaging us with business processes. In a little while, we look and the whole thing gets more complex as we add in the next ones.

So things like Workday, ServiceNow, using Google for your email and calendar. Again, they're basically just consuming services. They interact with the business, but fairly nice sort of silos in terms of what they're going to apply. They do bring a little bit of a complexity, though. And the complexity in them is that they all seem to feel that they should be authoritative about users. If you're using Google to manage your email and your calendars, as far as Google's concerned, the list of users that it has is the authoritative ones.

Likewise, you're using Workday. It seems it's authoritative. And so part of the process we have to go through now in implementing that, how do we keep these looking like it's a single authoritative source, but keeping them all in sync? Where are the triggers? How do we keep all of these things in place? Does it tell us when the user is deleted? Can we manage those triggers and tie into them and try and keep that synchronization work? One of the customers we dealt with, their solution to that, they will simply reprovision every Monday morning.

They just get rid of everything and reprovision it in. For their use case, it worked. For many use cases, that's not going to work. Further up, we take things that now tie into core business processes inside of our organizations, SAP, Oracle Financials. We're interacting with multiple organizations. Fine-grained authorization becomes important because we have to think about things like separation of roles. We've got who's going to do what inside of that. We've got to think about the authorization problem. We also have the sort of unintended problem of the artifacts again.

Because when you're working in those systems, there's generally this idea of an owner of the underlying data. We have to consider that the lifecycle of the data is very different than the lifecycle of the user who may come and go at whatever point they come into it. The different roles are no longer tied to the same person. It's easy to do things when you say, oh, well, the creator's no longer there. Delete everything they touched. And as we start bringing in the B2B pieces, that breaks. You can take the next one. Thanks very much.

What's interesting to me is all too often the focus is on integration. People are always talking about, oh, the scope of this integration project is. And they seem to miss the point. And what I mean by that is that really the problem or the situation in the business-to-business conversation is one of identity. And if I consider, then, that I have these different houses, if you will, of identity data, how do I work with that in those B2B configurations? It becomes a big problem.

How do you deal with a situation of in this federated identity model, are we having the users remain siloed in those individual silos? Or are we going to attempt some type of integration or amalgamation of identity data across these different places with what we might consider to be the chief identity provider? But it really does become a problem. I have to consider all kinds of aspects here. I have to consider the case of delegated administration.

Well, by someone's mind, due to lack of communication or a lack of an explicit statement, one might argue or assume that they have delegated administrative capabilities perhaps spread throughout the business-to-business relationship. And others, of course, might have a different opinion altogether. It's really important to articulate clearly what are the guardrails that you wish to implement in these integrations. Delegated authentication.

Well, that's fun. And if you've heard me speak in certain circles, I'm a little annoyed. I'm a little annoyed at times when very clearly there should be a delegation pattern in place. It's not defined, it's assumed. But often what I find in place is an impersonation pattern where, in fact, a delegation pattern should be the construct. And that turns into a larger conversation which involves all kinds of effort that maybe was not initially scoped.

Oh, think of the delegated triggers. Think of the case where I have, as you say, initiating work on behalf of. And then in the case of initiating work on behalf of, and now doubly compounded with the notion of agentic AI agents, I need to have clear confines, clear descriptions are what are the, well, the authority that I wish to expose to these client requests. Is there a next button?

Yes, the green one. And so in that business-to-business relationship then, and in dealing with identity governance in that business-to-business relationship, take a step back and have a look at the lie of the land. And as I'm looking at the lie of the land, be very clear about how can I cookie cutter an approach to user provisioning? I want to get rid of all of the assumptions and I want every rule articulated very clearly in my plan.

Often, unfortunately, there's the case of miscommunications. Not only from the business-to-business level, but right down to the user-to-user level. How do you deal with that? It might be something, a tangible example, it might be something as simple as I'm a visitor in a, my organization is a visitor to another organization and needs to access the messaging platform and let the messaging platform be Slack.

Well, there might be processes in place that weren't considered during that finite relationship. For example, it could be something as simple as that the entities that have Slack access are all entities that I would find in the HR system, which may not be applicable if I'm from the outside, the arena.

Now, lucky for me, every technology provider I've provided services for has included me, has provided to me a badge. But there are many cases where that's just not the case. Everyone focuses on onboarding, right? Be sure to get the user population as quickly as you can access to the services they need to get the job done. That's what we all think about. The problem is, that's the easy part. It really is the easy part. Authentication, we've got that covered. Authorization, we've got that covered. Synchronizing data, for the most part, we have that covered.

It's the cleanup after the fact that's the problem. And it's a really big problem. How do you deal with, not only just initiate, but how do you deal with the full life cycle of, well, the identity from beginning to end? And I can think of many cases where artifacts still exist.

In fact, I had one customer who took this position in their Confluence data source, right? They took the position of, well, we will just allow for all access to that data across the company, after all, it's company data. What happens if that data was scoped to a particular audience within the organization that maybe required executive level access only? That's a problem.

Now, I have to agree, I particularly like the value of that, not just search agents, but AI enabled search capabilities extend to me today, especially on these points. Anybody here use Rovo? Only two of us use Rovo? In the whole room? Hmm. Rovo is exceptionally talented for me in parsing JIRA, parsing Confluence, and building out for useful reports from that distributed set of data. Go ahead. I'm just aware that we are between everybody and lunch.

Oh, dear. Oh, dear. One of the things, and a lot of things that Guy is talking about in here, when we start dealing with these things, it is messy. It's going to stay messy, it's going to be, in many cases, it's ugly, and we have to try and get things together. There are tools that help, but it's ugly, right? We've got these different kinds of users, and the things that I ran into every single time, there is no right way to do something. There's only many, many, many different ways.

And the challenge that we've got is to work out which one of those different ways involves the appropriate compromises, because every single one of them is a compromise. If we do this, then we can't get this to happen, so on down the path. It is a big, messy piece that we go in. But there are some bright spots as to getting it to work.

The tech, as Guy said, and as we've had the other presentations today, the tech is actually the easy part. It's protocols, it's standards, it's getting the tech working. We kind of know how to do that. The really hard part is understanding the business processes and knowing what we are trying to achieve.

So almost without fail, every project that we went into that involved, and it didn't matter if it was building a partner portal, bringing partners into play, however they wanted to tie them in, sitting down and spending way more time than you think you're going to spend on defining those business processes is where we end up spending all of that time, right? Defining where the trust is, do we trust them logging in? Maybe you've got people from organizations you don't control. What are you going to give them access to? Or do we just copy them locally?

Both of them work, they have different challenges with them, but understanding what that trust relationship is and tying that into it. And every single time, this takes days, weeks, working out what to do with it, and then how we're going to do with things. Because the problem is if you've got data stuck in Dropbox, you've got to take care of it before you lose the account, and you've got to have a process in place to be able to take care of it, whatever that means. Maybe it just means putting it up in a zip file and dropping it up in an archive folder somewhere.

Maybe it's assigning it to some other user. It's all part of that process in thinking about those users, which I think takes us to the slide before lunch. Don't reinvent the wheel if you're doing it for multiple partners. Solve the general case. Have a look and say, how do we want this to work? You can always be specialized for a particular partnership that, I don't know, there was some kind of special case.

Fine, you can specialize on that. Solve the general case.

Otherwise, every single one that you do ends up being different, has its own requirements, has its own problems, and nothing ever really works right. The documentation side of things, and I see I've just hit the zero, so we're going to stop soon. Sounds good. The documentation, when the problems happen, it's not going to be you that have to deal with them. It's going to be the guy who opens up that documentation to say, what on earth did we actually do here?

And so having a consistent, defined, documented process means that we can get the tech relatively easy to solve that, which I think, oh yeah, this was just my favorite one. Don't take the pilot end. And so when the B2B agent arrives, if it hasn't already, does that break this model, or how can you extend it? I don't think it does. I think it does mean you sit down and you now think about what does that agent mean in the model of how they fit in with the data, the resources, the access, et cetera, et cetera. But fundamentally, it's an identity problem. Correct. Not an integration problem.

It's an identity problem. And client-server. Sounds good. Any questions from the audience? Or lunchtime calls, which is definitely my thing. I vote lunch. Lunch it is. Thank you very much. Thank you very much.