Hi, thank you all for being here. I'm Jos Groenewegen. I'm a tribe architect responsible for identity and access management at Rabobank. It's a large bank in the Netherlands. We do a lot under IAM, so most of my day-to-day work is about strategy and vision and deciding how we can tackle the problems towards the future. But I also dabble a little bit in technology as a hobby outside of my work, so we will be talking about that and what we can do with AI connectors, how we can make them better. And I'm going to give the word to Angelika first.
Yeah, thank you very much, Jos. So, Angelika Steinacker, I'm a consultant and I work closely together with Jos at Rabobank for various topics. And for that one, we had looked into the things which are exciting at the moment, which is AI for something. But nevertheless, we have to do all the classical ones also, and we wanted to see if AI can really accelerate that.
So, let's start with the identity fabric, which is also a very important topic at that conference. There have been several workshops on that one. And what are we looking here into it? This is a very, very simplified version of a picture of the identity fabric, just for the ones what we need for the moment. And you have this, this is the architecture of the identity fabric, and the IAM orchestration layer is, of course, how it is managed and operated. And the connectors are then the integration points. We will get a little bit deeper into that one.
But what I wanted to say at the moment is that identity fabric, which brings the silos together, and the orchestration layer is exactly what connects the dots. It is only as good as how many systems are connected to that, because an unconnected system is an ungoverned system.
So, let's look into the orchestration layer a little bit further into that one. And this is what makes the fabric, the identity fabric operational, as I said before. And it receives signal, for example, from HR systems, it applies policies to that one, it triggers provisioning workflows, it manages lifecycle events, and it does the synchronization between the systems. And this is something which brings the identity fabric to life. And of course, it can only work with the systems which are connected, and we have here in grey the not-connected systems.
So, the quality, the coverage, everything, and reliable of connectors, which you have, is then whether it is reachable in the identity fabric or not. So, and you have a little analogy, which we had been looking into as the GPS navigation, you can say the IAM orchestration layer is like the GPS navigation system, through which the identity fabric is then, which is going through the identity fabric.
And just as a navigation system guides the driver to their destination, then through a complex roadwork, but also the GPS navigation systems has to respect the traffic laws, it has to adapt to real-time conditions, if there is a blocking in the road, and re-routing around obstacles then. And this means, similar to that, the IAM orchestration layer does the same in the identity fabric. And of course, if a road ends, the connector is missing. And with that said, then, we look a little bit into deeper from the identity fabric to connectors.
We have seen connectors are very important to get the systems in the identity fabric, or that the identity fabric really can work properly. And so, this means, if you want to govern applications, you need to connect them. As I said before, a non-connected application is a non-governed application. And this means it is outside policy enforcement, outside lifecycle management, and outside access reviews. And this means also, and this gives us the bottleneck in this system. And if you have built connectors to IGA solutions, of course, you know what I'm talking about.
In a typical enterprise, you have around hundreds of applications. This is the standard.
And then, building and maintaining all these connectors in the traditional development lifecycle takes weeks and sometimes months. I know that from my own experience in these projects, an SAP connector can take six months time and a lot of person days to get ready and to work with it. And nowadays, when the business has demands on new application and the volatility in application is so large, this is not feasible anymore. You have also then a growing tail of a backlog of applications and systems to be connected. And this all means your coverage of governance is not there.
And for us, the question was, can AI really support and accelerate the building of connectors? And Jules has dived into that topic. So that's the question, right? The theoretical framework is clear. Why we need these connectors, you can say it's an age-old problem. It's clear. At this conference, we've been talking a lot about AI and agentic AI. But we actually thought, yeah, okay, talking about AI, that's nice. And we could have held a beautiful presentation about agentic AI and concepts as well.
But we posed a different question before we had the theoretical framework, which is, can we actually already practically do something with the AI? So we thought, well, for these connectors, maybe we can. They actually fit quite well what an AI can do into what we want to do.
First off, a connector, in the end, is quite static code, right? We don't need a scary agent autonomously acting all throughout the system. All we need to do is very cleverly generate code. We can connect the system. And it's actually quite strictly formative. We know the input. We know the output. We know the way it goes in. That actually fits quite well. We think we can do that. It's also quite easy to see whether it works or not, right? You can say, oh, AI, large language model, it's going to hallucinate.
Well, if I provision a user, it's either going to be there or it's not going to be there. It might get a slightly strange name. But by and large, I'm not too scared of hallucinations. It works or it doesn't. It's active or it's inactive. Then AI always needs some kind of good input.
Well, actually, all those systems you're trying to connect to, they have very good documentation. And they have standard-ish, right? If they were all following a perfect standard, I would be happy. We would not have had to stalk all the vendors out there. We'd just say, this is a standard plug-and-play connector. It works for everyone.
However, we all know that's not how it works. All those systems we're connecting that we need to govern are slightly different. But they're documented well enough that we thought, yeah, let's give this a shot.
Now, a slight disclaimer. This was a, well, I'm going to say hobby project. So we wanted to prove whether this would work or not. We did not go about covering all the edge cases. So do I know if it will work with similar characters? We really didn't bother about that. You might probably get some errors there. I'm not sure if you've ever critically tested what your human developers make. Some edge cases will break as well. So we thought, can we do this? Let's start small. For the AI nerds, we used Cloud Code 4.6 SONNET with a standard 20 euros a month subscription.
Nothing fancy, no giant amount of tokens. And we actually found we did need to do quite a bit of pre-work, thinking about it, writing down what are the actual join and move reliever scenarios. What do we actually want in terms of provisioning, reconciling, describing that? So we did require domain expertise. We couldn't just say, build me a connector. We did have to explain what that connector needed to do.
We also, I'm not sure how many of you have worked with AI, but basically we use the AI with good instructions to build better prompts. That's how you can generally develop quite well with AI if you're working with it.
You say, this is what I need, which is 10, 20 lines of prompt. And then you say, build me a prompt to prompt yourself to build this. And then you get 10, 20 pages, which you can have it working on quite nicely. And we said, well, let's actually see if we can get an AI to build a connector. And we thought, let's start small. Let's start with seeing if we can start provisioning EnterID, our favorite IDP. That's where the initial pain started, and it had nothing to do with AI.
Yeah, suddenly you need to configure a test tenant, so you need to get a developer subscription, you need to set that up. You need to grant permissions, and that's actually where the AI was already quite handy. Because we said, well, generate your code, and actually said, oh yeah, I generated a connector for you, it should work. And these are all the things you should configure in your EnterID tenant for it to work, right? There and there you can generate a secret, so I can connect. You could also use a certificate. These are the permissions I need. So we had some things to configure.
But lo and behold, it worked. We were able to provision users. Then we said, well, we're a bit tired of using Postman for this, so make us a nice little UI, which it did. But we were able to provision users. So we thought, that's good. First experiment is successful. Let's see if we can expand this a bit. So we prompted and prompted and prompted and prompted and prompted. So first we expanded the EnterID connector. Can you disable users? Can you add groups? Can you remove groups? And then we thought, well, Entro works. What about Salesforce?
And what about, and what about, and we started tinkering a bit and tinkering a bit. And in the end, we settled for four systems.
Entro, we thought, it uses a graph API. Salesforce uses a REST API. Slack using SCIM. Workday using their proprietary SOAP interface, we thought. Four different systems for which we could easily get developer tenants.
Otherwise, we might have picked other ones, but setting up an SAP system is not as easy because I didn't get a developer license. So four different systems, four different kind of proprietary interfaces. And in about, after the initial set of six hours, we were able to build four connectors for four different systems, which could do all the provisioning, deprovisioning, reconciliation, group management that we wanted.
Now, I'm not sure how many of you have ever built connectors, but being able to do that for four systems in six hours was a lot better than our initial expectations. Yeah. And this brings us where we are standing now. So it sounded really good, but I think there are some obstacles into it.
So, for example, not falling into the rabbit hole of prompting. This is one of the things I have experienced. But anyway, what we are, three things to take away.
So it can, AI can accelerate connector development. And we have shown it that it can, and that you can really use that to do that.
But, of course, this is not the entire story. Because the human steering remained essential. We had to tell the AI what we wanted. We had to tell the AI what are the actions we want, what's the format we wanted. So we did still require quite a bit of domain expertise. So it's like a typical construction worker. It can greatly accelerate how quickly you can do things if you know what you're doing. If you don't know what you're doing, you can. It also won't help. And it is not only the speed.
Of course, it can accelerate. But we wanted to achieve is to have more and more applications connected. So to expand the coverage. And so with speed, we wanted to expand the coverage to have more and more applications connected. To the systems in the identity fabric in the orchestration layer. And this is the real opportunity. Especially for this fluffy applications. Which you have, where you don't have really standard connectors or whatsoever.
I mean, an EnterID has a standard connector usually. But it was just for it. Just for an experimentation. But that is the takeaway we want to give you. Try this if you haven't tried in your organization. You can. It's not that scary because you don't get an agent which does everything. And as we see, it does really give you the opportunity to actually grow your IAM landscape. To actually cover far more of your landscape than you previously could. And a lot of the applications where in the past you would say it's not feasible to connect those. Might actually be feasible now. And with that said.
Any questions from the audience? I think we have a couple of minutes left.
Yes, I would agree. So I think there are two minutes left. If my iPad is correct. So we can take a question from the audience. Either through the application. Also then from the people in the online stream. If you have a question. Go ahead and ask them in our application. So we can see it here. So are there any questions in the room here maybe? Who wants to ask something? Okay. Can we get a microphone over there?
Yeah, thanks. That's really cool. What do you see as the shareable artifact? Is it the prompts? Is it the code? Or is it both? Seems to me there's value in the prompts as well. Since you've been through that already. I can't say there can be some value in the prompt. But I think generally the far more shareable artifact. Is the code which you can just plug into your IGA. In our case we use an IGA solution I know fairly well. To basically say hey. This is how a custom connector should look like. For this IGA tool. Just have the code. And you have a working connecting for that.
So and yes the prompts can be useful. But I would say the. What you produce is basically just connectors. Just in a far faster format. What is probably the most valuable is. The strict standard of. This is how I want to define the connector to look like. We already do that with our orchestration layer. A standard of. This is what every connector should look like. So that you actually know that the output. Your AI gives you is good. And meets those criteria you have. Okay. So then thank you very much. So as we already have the next panelist in the room.
I would say thank you very much to Rabobank. And to Dr. Angela Melker. Thank you very much.
