The IAM Hyperscaler: Orchestrating B2B Compliance

So, thank you. I was going to say good morning, but I think I'm a bit late for that.

So, let's say, just get started. My job description is Lead Solution Architect Identity. That's not entirely true. I'm also responsible for cyber defense, so I guess you could say trust architect. I should maybe apply for that job title.

Okay, so the talk is totally different. We have like the high dollar and high production value presentation from a vendor and this is just a regular customer in the field showing a little bit how we addressed the concrete need.

So, at least somebody knew the company and I know a couple of other guys know the company because they actually used to work together with me. All my emotional support today in this presentation. We are a fairly successful insurance company in the European market.

Now, the new merge company is about 22,000 employees. We have like 1.1 billion earnings tax.

So, it's a sizable operation. We do pretty much everything. You can insure your bike, you can insure your satellite, or you can insure your mega project. But we also have retirement homes, pet clinics, and it's a wide range of things to be dealing with.

So, this is, I hope, enough about the company. I do admit that I did a little bit of a marketing ploy with giving the title of the talk. It's not going to contain AI.

So, if you're looking forward to this, I'm very sorry, this is very traditional. My point of view is that identity and access management really has to not be in the way of what the business wants to do. It has to enable orchestration, it has to be very quick and expeditive and it needs to also delegate some competence. And I think my colleague, Alfrandro, might agree with me.

So, in that sense, we should work a little bit similar to what a hyperscaler is doing. Now, we had a requirement that took us all in all like one year to really come up with all of this. And this is the only thing you see. It's quite boring. It's pretty much just in the end when you're done with taking all the information from the customer and you have a proposal for insurance policy. You need to actually assign a person to this policy that is legit.

So, it is a person that is registered personally with a financial market regulator. He needs to work for a company that is also actively registered with a financial market regulator. And it needs to be a person for this portfolio that is also actually certified for this field of insurance policies.

So, what you see in the application is just this picker. You get it pre-filtered and all of the magic that's happening in the background to be always up to date. We will delve a little bit more into it if you all care for this.

Okay, thank you. I did a couple of infographics. I used Gemini.

So, yeah, the watermark, I removed it. Just so you don't see it, but okay. The very high-level construction from the first degree of detail is really just we have like this fairly tried-and-true pattern of having a metadirectory. It is based on LDAP, so you can directly query it. There's a lot of applications that stay working with this. We have the layer where we actually provide all the possibilities for orchestration and so on with APIs for something that needs to be in real time. And we also have the possibility to have something that is eventually correct.

So, we have an orchestration tool, which we'll be going into a little bit more on the next slide. The company has actually had some experience with IBM IIB. Didn't work out so well, so we defaulted back to Kafka, which is really giving out the responsibility for transforming the information to the customer. And I think this is also maybe generally a good pattern going forward in not always having to create a connector with your IBM system if they can actually work with that.

So, it's a little bit of we don't have to do everything ourselves all the time. So, this is like the high-level construction. If we want to go a little bit more in detail, and this might be hard to read down there, I'm not quite sure. It might be small. Okay. For the concrete use case where we have to gather all this information, always provide the up-to-date and correct information with all the user accounts that can actually work with the company, we have a couple of issues. We have maybe the biggest issue that the financial market regulator didn't think of providing an API.

Makes it a bit tricky to daily verify things. But we have to be at least once a week we have to do full recertification of all the accounts.

So, we have the issue that the APIs might be inexistent or rate-limited. The second API that we need to consume is by the Vocational Training Association.

So, there we know if they have the training for a certain type of product. They have a totally different rate limit. We can call them once a day.

Okay, good. But what do you want to do? What you want to do is if we get via, for instance, with a little bit more competent partners that we have, via scheme, new user accounts, we need to event-driven enrich these user accounts and have them fully operational within like 20 seconds if possible. Usually it's more like one second, so it's quite nice. And we have to come up with a way to decouple of these things.

So, what we do is we just have a buffering mechanism for rate-limited APIs. We have a component that is exposing all the changes into central metro directory via Kafka topics.

And so, we have a microservice that is listening to things happening via Kafka and is then able to enrich all these objects with the information. So, this will enable us to be usually correct within, yeah, I think within less than one second. This is fully automated and scales quite well. All right. This might not be so super exciting. This is really just how the company works.

As I said, we have opted to usually go on Kafka as a means to decouple technical domains, right? So, as soon as you go from one technical domain to a different technical domain, the idea is to just push things into a Kafka topic. The other guy is responsible for reading, acting on it, and transforming to their own representation that they need. The way we work there is a bit different than in the classic identity and access management. It's more like a GitOps thing. These toolings are built by the internal developers, and they work totally different.

So, what we have to do is we have to gather all the information for providing the Kafka topic. That is, we have on one side the definition, the business data model, how these information should be labeled, and what is the syntax for the information. And we have to talk with the customer which information actually needs to be in the topic. And then we need to have a data owner, right?

So, once this is done, we are out of the loop. This is fully automatic. The customer just goes to the YAML, adds himself to the definition. And if the data owner is actually approving the pull request, a couple of seconds later, this is all configured and deployed, and it's fairly nice. It is a little bit of a conceptual gap to the classic identity and access management, where we do the utmost to limit what you can see, and so on.

But, yeah, the company wants to move this way. They want to be fast. And we have to somehow fit into the solution space that we are given. Okay. What I've been talking about is actually in production. I'm really just talking about the B2B slice, and only in the market unit Switzerland, which is a big, important market unit, but it's very far from the whole picture, of course.

So, we are talking about 45,000 user accounts that we have to manage in this way. We have now that things have settled down, and that we had this quite painful transition from having 17 different ways how we manage brokers into one fully automated concept. Now we are down to 5,000 changes on a user object per day that we need to handle, and then potentially maybe enrich or do something. And all this information is published into, I was going to say 18, but it's not anymore true, into 36 Kafka topics. Why 36?

It's technically more like 18, but we have on one hand the compact data topics without retention, but it's always reflecting after, yeah, maybe a second or so, the current state of every user object with all the information that this population needs. And it's just one bracket, always updated. And the second amount of topics is just the data topic.

So, what we do there is we publish the individual changes. I did not go too much into detail there, but what we have is a small microservice that is getting all the information that is changing in the central metro directory and has a definition.

Again, it's a YAML. If you change it, it gets a micro-deployment. It is then slicing and dicing and populating all the Kafka topics that are relevant with all this information. In the case of a compact data topic, what we do is we quickly read the source object in the directory to have the full state and to be able to provide the data information and the full topic information.

Usually, this takes way less than one second for an object. We have 20 consumers. It doesn't sound like much, but one consumer might be the whole B2B landscape for all the products.

And so, it's maybe not so small. And the side benefit of all of this is we can do a complete reload of all the topics in less than 10 seconds.

So, if there's a mistake, if we need to do something, it's very quickly fixed. It's no big deal. All right.

So, that is what we have. Actually, I don't know how much time I have left because this timer is pretty much standing still all the time. Really? Crazy. We have time for questions. Okay. I'm going to slow down. All right.

So, you have seen what we have in production. We're quite happy with it. It's also something that is complementing the more traditional IGA quite well that we have in place for the B2E where there's much more complexity. But we want to move forward. And maybe that is the moment where I should mention how did we come up with all of this command pattern topic that we're using for this.

That is, we had, like two years ago, also a regulatory requirement that is the right to forgetting data. So, what we had to do is we had to react to a Kafka topic, of course, where the information is published that somebody is no longer a customer.

So, what do we have to do? Our technical domain, which we, as you might have imagined, we have to decouple and nobody should know what exactly we do and don't use our private APIs.

So, we had to react to this and we had to delete, for instance, the user accounts for the B2C domain. So, that's the initial thing that we had to do. We came up with a small microservice that knows how to serialize this for this exact environment that it needs to work on. And it has a pipeline of things to do that automatically also serves as a high-level audit trail. Because somebody had a request, we did something, it had an outcome, and this is persistent.

So, it's quite convenient. This was working and we had to extend it a little bit. The multiplexer, I think I mentioned already, is working. It's quite nice. This is very convenient. A super small connector is doing all these things. But we have new requirements, of course. The good thing is we can usually convince the internal customer to actually front the cost and to argue for the need for this implementation.

So, the new thing that we have to do, and we've been discussing this actually this week, how to move forward with this, is we have, from the modern application landscape side, the request to automate more the provisioning of two clients. So, they, as you might have already noticed, are very happy with Kafka topics.

So, their idea is that they write into a Kafka topic their demand. So, this is just a classic CRUD operations, a couple of parameters. And we check then and say, okay, look, this seems to be okay. The syntax is in order and you guys are actually entitled to do this. And we put it into the command pattern topic and proceed. The side benefit that we seem to be possible to realize with all of this is what we have in this topic is just the high-level information, what they want.

Currently, we do serialize this to the private API of, I think, yeah, maybe I should not say Foreshark. There was a guy from Ping, right?

So, Foreshark, there we do it and we just create in all stages these OAuth 2 clients and we provide the information into result topic. But we are most likely going to change to Keycloak, right?

So, what can we do? We can just reset the step where we have been and replay this information because it's some high-level information and create it in Keycloak and create it in EntroID. The customer has no impact. It just gets updated information.

So, this would be convenient. We can just rerun configuration changes and it's totally decoupled from the customer. And they never use private APIs. They don't know how exactly we work within the technical domain. It is just transparent. And with this, I think I'm through and we have time. We do. For one or two questions.

Also, I might say, actually, I'm just like the high-level guy doing PowerPoint, talking a lot, sitting in meetings and replying to emails. And the guy who did all of this maybe scanned the code. He's really cool. He's unfortunately not here. He was supposed to give the presentation.

I'm just, you know, the cheap stand-in. Sorry. Please scan the code. Go to him. He is really cool. Thank you. Questions about his identity practices? One question I have is what happens when an AI agent shows up to this environment and wants to get privileged? Is that something you've considered, thought about? Could it happen? Relevant? I don't know. I don't know. Maybe.

Yeah, maybe. We do a couple of things. And actually, we're going live in production with the MCP gateway that is also fully integrated with identity and access management, with all these self-service things. So we do build a lot of tools. In this concrete case, I'm not quite sure if we are going to rely on artificial intelligence. We more use it in gathering the configuration of the stuff we build and doing human-readable documentation automatically. So the engineers are not really required to write documentation. They don't do it. They don't do it well. They don't like to do it.

So we just use AI to come up with all these. So basically, it documents the code for them and documents the architecture. Yeah. You're MCPing what? What are you expecting the agents to try to get? That's a good question. I think we have, like, dozens of use cases already. But I hate to say I'm really just for the identity and access management and a little bit cyber defense. So I just do the plumbing, and I try to understand what the customer wants and try to fit it somehow into a workable solution.

So you front-ended it with an MCP server, but whatever the applications are is up to somebody else, essentially. Kind of, kind of. So I hope we managed to convince, I think they did it that way, that usually the flow should be on behalf of. So if we say, for instance, a conference, and at the moment that you work with the LLM and you want to know something that is in conference, the gateway should then do it on behalf of. And we are provisioning new entitlements into the solution.

And when you talk with the LLM, you have exactly the same entitlements and data that you can actually access as if you would directly work with it. So this, again, is I try to convince people to do same scalable solutions. Yeah.

Well, thank you very much. We're in about, is Alan in the room?

Oh, there he is in the back. You can slowly walk up. You have a couple minutes. That was too fast. I'm sorry.

No, no. On time is good. Early is always good.