Great. So, welcome for this wonderful afternoon to talk about something that's probably been plaguing pretty much everybody who has been part of any IAM program, right? Irrespective of what solution you have and irrespective of what approaches you've taken, you've ran into this issue of how do I on-board an application seamlessly, right? And why is this so important? Why should we care about it? Because as you start thinking about what are the things that you run into, it's almost like peeling an onion, right?
So, there is a business side of things that you should be aware of. There is a technical integration that happens. And there are some interesting synchronizations that happen between systems that you should be aware of. And then you run into these completely undocumented behavior and exceptions that these systems get involved with.
So, why do we think these on-boarding activities kind of fail? First and foremost, you see that applications evolve, right? Over a period of time, you would have built certain use cases. You would have had people come and do a bunch of changes. And then the documentation isn't keeping track with those changes because you're so wound up with actually making those changes, you're not spending enough cycles about the future of the system and everybody else who needs to know what's happening with it, right? Then you're stuck with with these changes that happen.
If you really want to know something, what has happened, somebody will say, go talk to Fred Smith or go talk to Jane Marshall. They know about it. They were part of the changes that were incorporated a while ago.
You know, you should go, talk to them about it. And then the thing about IAM is, as you think about how it is built and thought about, there is a structure to it. But when you think about how businesses run, how processes run, it doesn't really map exactly into what the IAM structure would mean. So there's kind of a chaos that comes into this, right, when you start thinking about it. And then you end up looking at a problem where you feel that, oh, I got this platform.
You know, it's probably one of the most commonly used things. I got this platform for any application for it to come and fit into.
And, you know, you start functioning and you start running your processes and so on. But the truth is, every application is different, whether it's operating system, directory, database, your CRM, ERP app, homegrown application, your identity stores. It doesn't matter what it is. Every system is different. And it's really difficult to just take that representation and bolt it into something that we call it as. It's a platform that can consume whatever these systems represent. So at the end of the day, what this means is you end up with a lot of, you know, impedance mismatch sort of things.
And then these gaps that come in, which invariably mean that there is something that people will end up doing to push the process or your activities and say, okay, we'll just take this forward, right? You know, we need to get to the next level. That's what you're focused on. So invariably, you end up having a lot of these blind spots. And those blind spots, you know, is the outcome of this. So how do we deal with a situation, you know, as you dig deeper into this? What happens here is the reality is there are certain things that IT knows about your application, right? How is it configured?
How are the integrations done? You know, what is the synchronization that happens?
And how, you know, some of the things are, you know, set up for maintenance and upgrades and so on. And then there is business, which really knows, you know, the why part, right?
You know, how a process is set up. Why is, you know, somebody getting access here? What does this role mean? And why is this given to only people in, you know, engineering or only in finance? That's something business, IT wouldn't know about some of those things, right? But for a true integration, what we really need is we need to find a way that the IT intelligence and the business side of intelligence should converge. And you build something that, you know, can fully understand and manage, you know, what this is all about.
So the kind of knowledge that comes, you know, has to be consolidated, collated, and that's when, you know, together you'll be able to do a better, you know, integration. So as you look at, you know, the IT and business and you start going down, this is what I call a peeling of the onion. So next you start thinking about the access model.
And again, the reality is that, you know, some are group-based, some have a role base, some have their own proprietary things, and some have native permissions. And, you know, there is no standardized structure, you know, across all the application, you know, landscape. And then you also have, you know, certain logic that is built in, you know, explicitly for modeling something, right?
You know, it's not easy to get that set up into one of these access models. So you end up writing some custom logic that will be bolted on. And then comes the problem where you're trying to take, you know, an application environment and again bolting on to an IM structure, which is, you know, almost like, you know, square peg in a round hole kind of a situation, right? You really get into that, you know, kind of a problem. This is where AI agents can come in and what they can do for you is they can actually understand your application access model, right?
You have the ability where you can present, you know, the information that's available to you about the application. And they can provide a mechanism where you can leverage that information to define your processes in terms of how you want to onboard the application itself. And then the problem that arises is when you think about the various tasks that you perform, you know, as part of the onboarding, you know, the line of business will come and it comes up with its own use cases. You will take the use case and say, okay, now I got the IM solution, I'll start configuring it.
And then you'll suddenly find that, oh, the UI is not completely set up to, you know, actually describe what I want to do, right? Because now you're saying the business requirement is not mapping to the user interface of the application.
Whereas, you know, the AI agent is something that can interpret that and do some things for you there. And then you have entitlements.
So, most applications don't really have entitlements. What they have is permissions, right, that correspond to what changes you can do in that application. They don't really map it to really something that is more consumable for, you know, somebody who is managing a process, you know, in terms of entitlements.
So, this is where agents can come in. They can look at your permission set and come up with actually meaningful set of entitlements, you know, that you want. And over a period of time, you can see that the applications evolve, you know, things change and a whole bunch of things happen there. And you find that for you to be able to reason and find a mechanism for your systems to adapt to your business needs, you know, you really need an AI agent that can take all of this information and actually present certain context for you, you know, in terms of your execution itself.
So, digging a little bit deeper, you know, you just see that, imagine a situation where all that the business user is going to do is describe your application in natural language, literally natural language, what your application looks like, right? And then you have the AI agent, which will start understanding what you're saying about this application. It could be anything.
It could be describing your identity story, it could be describing a directory, it could be describing your homegrown application, you could be describing your own ticketing system that you built over a period of time, doesn't matter what it is, right? And then it'll take those and it'll start bringing in relevant pieces, you know, in terms of contextualizing, you know, your need and what your intent is, because what you're describing is your intent, right? You're not getting into the nuts and bolts of how some things are necessarily, you know, functioning underneath, right?
So, the net result, you are helping business to come and talk to a system in a way that the system will understand your needs, right? You're not trying to describe an application based on what the vendor expects you to do. Every vendor you see have their own terminology, have their own process of doing some things, and they have their own user interface, right?
So, think of a model where you don't have to worry about any of those elements, right? The user interface or the jargon as you're describing, you know, your application. Okay.
So, again, you know, I won't spend time on this. You know, it's really what it is really telling you is moving from permissions to entitlements, you know, like I said, you can go from something that's deemed as raw into something that's bringing your business context and giving you more, you know, meaningful information. Okay.
So, with that said, how do you actually take this, you know, agentic approach and build something in terms of, you know, onboarding, right? So, for you, conceptually, what I described is, you know, here are all the challenges.
So, then you'll say, okay, let's get into the nuts and bolts. How do you actually address various aspects of onboarding? First and foremost, you know, people want to find out how is this application going to be connected to the IAM? How am I going to connect to this, right?
So, you will need to, you know, present that information. Again, a lot of things become harder and harder, right, as you dig deeper into, you know, how you will build the connections and, you know, I have to write a connector, I have to buy a third-party connector, oh, connectors are expensive. You get into all these kinds of situations. And then here is where you can bring in your data in different forms, right? You can bring in, you know, just sample CSV data. You can bring in schemas of the data. You can bring in textual description. You can bring in a JSON description of your data.
You can even have an XML representation of it. It doesn't matter what it is. You can bring some of these, you know, forms of data for you to, you know, represent what it is.
Again, the same kinds of things, you know, apply once you start saying, okay, I look at this application. Is it group-based? Is it role-based? Is it this?
So, how am I going to do the mapping? So, how does this vendor solution handle role-based stuff? What if it is a combination? How do I do that mapping?
So, you are not going to be burdened with any of those things. This is where, based on how things are being used, you know, sometimes you use mostly group-based. Sometimes you use only role-based. Sometimes you use just, you know, a combination of these things.
So, you can let the system come back and tell you what is a good way to define your, you know, processes, you know, in terms of access model itself. So, this kind of enables you to do quick, you know, governance.
Again, we talked about this earlier. You know, essentially what it means is that there is so much of, you know, difference between a business application and your normal structure.
So, every platform has this normal structure. So, they don't, you know, negatively fit in. It's not a natural fit into the system.
So, how do you, you know, handle, you know, those kinds of, you know, serials? So, best way to manage some of that is to be able to, you know, represent that, you know, in a natural language.
And then, of course, is the relationship, right? So, I have identity stores, multiple identity stores. How does this relate with the identity stores? What is the, you know, point at which we say that, okay, it is this user who has that particular account or set of accounts, or he's an owner of, you know, some non-human identity somewhere, and he's responsible. How do you build all this correlation, you know, in the process?
Again, same set of challenges come in, and then for people to figure out themselves, it becomes harder, right? So, best is to come and say, describe what you know about the environment, and let the system tell you, you know, here are the possible linking rules, here are the possible things that you can do, and how it gives a certain kind of confidence score, you know, in terms of how you manage this, right?
Then, the next challenge would be to figure out the operations. So, you have all these entities you are managing, and then you are required to figure out what are the operations.
So, how do I go about describing each resource out there? How am I going to manipulate that? How am I going to change the relationship between those, and how am I going to actually handle those easily?
So, this, again, can be something that you don't have to configure or, you know, bring in third-party tools for you to, you know, develop this, but do this through a natural, you know, language, you know, description. And then, of course, a couple other things, you know, before we get into a quick demo here. One is around, so far we talked about the onboarding side of things itself, and then once you do the onboarding, then you take it to other processes, right?
Whether it's your request process, whether it's your review process, you know, how do you use an agent that will help you define, you know, what's the frequency of my review, right? What are the things that I want to support in terms of request? What makes sense for people to request?
You know, is it descent of entitlements, or is it, you know, based on, you know, certain roles, or should I seek membership in a group? You know, things like that.
So, you don't have to worry about determining a lot of those things, but the system will actually help you, you know, in that guidance. And then, again, every application, like we discussed, is managed differently, and it's got different set of attributes. It plays a different role. It could have some role in terms of the overall compliance needs, and the auditor might have a different set of expectations, you know, in this particular application, and you might be also interested in certain metrics. Metrics could be around usage.
Metrics could be around, you know, what are the things that people are, you know, not using. A whole bunch of things come into play, and that is something that the system can also tell you, and you don't have to sit and, you know, manually go through the configuration set of things. Okay.
So, here is an example. So, this is a textual description of some homegrown application that we have, right? This is what, you know, we are wanting to onboard. I'm just giving you an example.
So, you could bring in SQL file. You could bring in JSON file, whatever you know about it, right? You can bring in sample data, anything that you know about it, or a combination thereof, right? You don't have to, it's not limited to just something like this. Anything that you know about the application can be something you can present.
So, let's say you had somebody come in and say, this is what I know about the application. I don't know anything else. This is what I know. Can you please onboard this application for me, right? This is literally the content that they will bring in, right? They could bring in, like I said, exported data from those systems as well.
So, if you did this, okay, let's show, okay. All right.
So, this is a recorded script. I wanted to make sure it's easy to understand. What you're seeing is, here are the set of applications that are there already in the system.
And then, here is an interface that will do a chat-like interaction in terms of how you want to manage. So, these are all sample interactions that you can do with the application. You can ask questions about users, reports, people, what access they have, everything surrounding them.
So, you can ask how-tos as well. Hey, tell me how to onboard an application. Tell me how I can do this, how to generate a report, how to trigger a campaign.
So, a bunch of these things can be handled through this system. And what it does now is, it's actually uploading a file. The video didn't capture the file upload part of it. But what it will show you is, whatever file I showed you in terms of text, that's the file that is called a sample homegrown application. And I'm just going to ask it, hey, onboard this application for me. I just gave a piece of text and said, onboard this application for me.
And then, what the system is doing at this point is, it's using a bunch of technologies underneath, you know, a bunch of LLMs and other pieces out there. And it was able to interpret. And this is what it provided as summary in terms of what it understood from that, right?
So, this is a quick summary. And you can start asking more questions about, okay, so now that you onboarded this, tell me a little bit more about what you...
So, the same thing could have been, you know, through an exported data as well. But that's what it figured out. And you can ask more questions.
You know, you can, you know, if anything here is not accurate in terms of its interpretation, you can go back and fix it and say, hey, I really want to add another linking rule. I want to change the owner. Or I want you to add an additional resource for, you know, managing this.
So, you can start, you know, interacting with it so that, you know, it's able to answer, you know, a lot of these, you know, questions, you know, for you. Again, so everything about this system, you can, you know, query and it'll tell you what this is.
So, the whole thought process here is that this whole thing is done in a way that, you know, we are able to take this piece of data and we will do through a process, you know, RHLF, as many of you are aware, make sure that at every step of the way, we get user feedback and sign off on it. We just don't go and push this integration and take it into production, right?
So, how do we do that? So, you have a concept called as drafts.
So, anything you do, you know, that is going to be, you know, manipulative in nature, you can go back and look at what you've configured, right? And then say, yeah, this looks fine and I'm going to sign off on it.
So, it created a draft for this particular, you know, application and you can actually see what it looks like. So, the top layer is a textual summary that system generated and then it's organized data, you know, in a form that you typically see when you've configured an application, right? This is what you will see once you configure that.
So, imagine this sort of templatized, it doesn't matter what you have underneath, you can take a representation like this and you can, you know, push it to, you know, irrespective of the solution that's underneath. So, it's just giving you an idea that it figured out here is the properties of the user group role, here are the operations and so on, okay?
So, I'm going to skip, you know, all of this and just going to go to the last slide. Hopefully, you got an idea of how you can take a textual description, bring it in and it actually is generating a SCIM interface to the environment, by the way.
So, if you're really wondering, so how is it actually going to talk to something, it's not going to talk natively in SQL or LDAP or anything. It is actually going to build a SCIM interface for you as underneath for you to operate.
So, what does this actually mean, right? So, you really need a platform and a mechanism where you start thinking something that is more adaptive and explainable, right? Everything that it is doing needs to be explainable and, you know, it should not be rigid, you know, the environment you're operating and onboarding an application. And then think of this as an assistant. It's like an ongoing assistant for you.
You know, people typically hire a bunch of SMEs to do this, spend so much money on doing this application onboarding. Instead, you can leverage, you know, these assistants for your onboarding process. And then the line of business can come and describe. And what we have not shown you is, you know, you can describe your campaign requirements there. You can say, you know, run this campaign, you know, for this application twice a quarter, you know. Do privilege access review. Do org front account review in this application.
Everything can be described through this and that can actually create a corresponding campaign for you. And most important thing is the context is maintained, right? Everything about what's happening with this application is available in a consumer form, human consumer form for people to, you know, deal and take it forward.
Again, last couple of notes is, you know, you really need to know what you're governing and you need a system that really understands you. You know, it shouldn't be any other way, you know, given where we are with all the things that are out there. Thank you very much.
Thank you, Sanjay.