As you can see the title of Mike, you know, is relatively long. That is because I put all four major theme. I'll discuss today into the title. It's about rethinking IGA. So rethinking the way we do this core element of identity and access management. And I look at deployment models. I look at role models. I look at re-certification and customization because I have the strong belief that, and that's also what we get as a feedback from the market. There's a need for identity management modernization.
We need to, to really shift to a new level and, and look at things which don't work as good as we like them to do. And, and I think there's a huge potential to also utilize some parts of our, you know, what you have to modernize and to, to really get way better in how we do identity governance, identity administrations are, how do we deal with these core elements?
As I said, like use life cycle management, identity provisioning, including all the connectors to systems and access governance. And this is what I'll, I'll touch on in the next few minutes. And as I've said, I have four topics.
And the first of these topics that is deployment. So over the past two or three years, we have seen a lot of conversations about, should I continue running my IGA on premises, or should I shift to a cloud first approach or say more? Because when I look at many of the discussions specifically in the broader IM perspective than it is that some parts of IM tend to be commonly shifted towards as a service model while others are seeing more as something that can run on premises.
And it may be that, that a lot of customers and that our experience as well are better served with something which allows them to decide some flexibly about a deployment model, maybe even having instances and different models.
And so when we talk about flexible deployments, it's about cloud first remain on premises, what else to do?
And so at the right side, you see this identity fabrics picture I've talked about in a couple of talks over the last 12 to 15 months, and there's a ton of material available at our KC plus where you can read through what, what we see behind this concept of at the end, it's a paradigm for sort of a unified perspective on all identity management, including the IHA pieces. And I don't want to go into detail of that, but I just wanna highlight within that identity fabric, one area, one section, which is this more sort of right hand section, which is the technical architecture.
And I believe that that we need to do two things. And the one thing is we need to ensure that we have a certain level of flexibility in deployment.
We might op opt for something which is purely SA based. There are some options and there might be reasons to do so, but otherwise we should have the flexibility to shift sort of traditional on premise, maybe with a managed service provider model to something which is really a SA model and which may also operate in different cloud. So to do that one thing, we need to do a diff a second thing.
We need to have an identity management and IGA, which is an architecture that is built for that flexibility. And so modern are architectures from my perspective are really the foundation for, for getting that flexibility. And I'll touch this architecture piece by the end of my talk again, but it's really having these architectures that give us the flexibility. What do I mean by that?
I mean, we need to have solutions that are constructed in microservices.
What we usually see from the outer side is that we see APIs that we see a consistent API layer or modern API layers rest based commonly. And we can use these APIs later on for customization. What you also should see from the outside is that there are several containers and that the deployment of these solutions is based on container based deployments. And with that ability, we then can use a lot of different deployment models. There might be rights on it, and there might be reasons for going for pure SA.
And there are some really good pure SA solutions, but for, for many use cases specifically around IGA, what I see is that many organizations feel today are not a hundred percent ready for sort of going all in into a pure SaaS model, having the right architecture in place. And this is a piece of the modernization to look at, helps you in having the flexibility you need.
So with these architectures, you prepare for the flexible deployment. This is a very logical thing.
And if you look at the picture and the upper part, and there's the architecture, and this is what that provides the option for the flexible deployment of our overall IGA solution. So that was part one part, two roles. If you're honest, there are way more road projects, stalling, or really failing than succeeding.
And, and I know so many customers I've talked with and they said, oh, we already did three, three tries with Royal projects. We don't really want to do another one. So if something is, is really complex and, and cumbersome, the question is, are there better ways to do it, but I believe there's a time for change. And I thought a lot about roles and I'm talking about roles for, I don't know how long the problem is.
Roles is what I would call an artifact problem. What is the problem?
The roles are artifacts as in artificial, they are something which, which aren't sort of totally simple to see, and logically we need to construct them artificially. And why shouldn't we start with something real? And that real thing that is policies. Everyone can easily describe a policy, but I've never seen a role project, which said, oh, let's start with the policies. Let's talk about subjects that can perform actions on certain objects, under certain constraints. That's the structure of all of these policies, regardless of, at which level they assign.
So Martin can print on printer one to three from his desks, but only from his desk only when he's in the office, that is a policy, everyone in the business, everyone in it can easily describe policies. If we then cluster the subjects that have similar entitlements, and that is something we even could do with some supportive technology.
That's not really rocket science, that's trust clustering that we can figure out who are the, the uses that are relatively similar. It's a little bit like role mining, but we don't start with the roles. We start with newly described policies.
So we don't start by, by sort of concerning the legacy and the mistakes we've made. But we start with newly freshly described policies. We cluster it, and then we have the entitlements and promotions because they are already described in the policies. Martin needs access to the printer under certain constraints. Okay. That's a very simplified example, but someone can do certain things and SAP under certain constraints, etcetera, all these things are in the policies. Everyone can describe them and everything is in there.
So the role management challenge from my perspective is at the end, we are starting at the wrong place. We don't, we must not start with creating complex artificial roads.
We must start with something everyone can easily describe, and that our policies and the good thing is in these policies. We have the roles, we have the entitlements and permissions, but we also can derive lower level policies or policies at, at other levels. Like we can derive the access management policies. We theoretically could even derive the firewall policies.
And if the, we invested that we may even be able to derive a lot of that automatically. But even if you have a standard role project as of today, if you say we need to, at the end to set a role project, this is a project of defining entitlements correctly, defining who needs access to what then the question is who needs access to what, who to subject access the, to what the object that is nothing else in the policy. The main question of identity management is who is access to what is, is, is not which roles do we need, but from the policies we can do everything else.
And if you do a project that way, and maybe sooner or later supported by clever new technology, your role projects have a far higher chance to succeed than they have today. Tightly related to that role problem. That's the review problem. And so I tend to, to, to start when talking about this topic was a very simple question. Do you know a single organization that that really loves doing access reviews that says, oh, this is one of the real great things in our daily work, in our regular work. I'm really looking forward to my next access reviews by the end of the quarter.
I don't know a single one worldwide that I know a lot. So something's going wrong. Something is not good here. How can we do it better?
And again, it's, it's about policies. It is about something we, we get from the other policy part, I've talked about.
It's about policies, automate automation. What we need to do is we need to automate to have lesser reviews. And when we look at how access is granted, then we have basically two ways. So the one way is we have manual requests and that menu request Martin says, I need access to that. That should be an exception. That must not be the norm. It should be automated based on policy. That should be our standard based on the organizational data.
Like every employee has access to certain areas of team SharePoint, whatever. Every departmental manager has certain entitlements people at that location, people in this project, cetera, EV all these things we can derive a lot from attributes. There are a lot of attributes we usually have.
And, and if we are good in our China processes, working with HR cetera, and there's an area, we usually have some room for improvement.
Then, then we can get more and we can define what is granted automatically. And if you're a little bit pragmatic here, then this is even this works even better, because that means if you're pragmatic, we can go and, and say, okay, we maybe don't care about, oh, but, or everyone is allowed to that. But Martin has a little bit different entitlements.
If there are trust a little bit different, and that little bit is not the high risk part, then be pragmatic and say, okay, everyone has the same. There are exceptions on that, but we can do a lot automated. And if we automate it, that means we once approve the policy. We ensure that the execution of the policy. So the translation of the policy in concrete entitlements is correct. And that we can drag the entitlements based on manual or automated. That tracking is super important because that helps us in reviewing.
If we know what has been granted automatically, then we on the one hand need still to, to review the single entitlements for manual requests. Yes. But for the policies we need just to review, are these policies, correct? We need process for approving the policies before they become active. We need for retiring policies. So we need all these. So to speak standard processes, we have around access as well around policies. But the clear question is, do we need to do manual reviews when the policies are well managed, well approved and correctly working, I had conversations with auditors.
And so far, every auditor said, yes, this is fully okay from his perspective, but I don't guarantee disclaimer here, big one. I don't guarantee that every auditor thinks the same way, but basically it is a, a process where you get a structuring very simplified way even reduced. And that's, I think a very important argument, the quality of what you do will be way higher if you do it right with policies than with single entitlements and single reviews, because you then have far less to concentrate on to do it. Right.
And when we look at this entire thing, we, we want to reduce ideally, or we, we struggle with access requests, the number of that. So it's, and, and people struggle with finding where to request. We struggle with the access approvals.
So, so for, for managers, it is always some extra work and we struggle most with access review.
And I think you should really ask your question, where do you wanna be on that equation? Do you wanna be here on the left hand side in red, or do you wanna be on the right hand side in green with a low number, with a of access request, a lower number of approvals, and though number of access reviews, there are a lot of things you can simp do around simplifying access reviews, beyond what I've talked about.
Think about time, restricted, entitlements and other stuff, but policies and automation definitely help you in making this part of your drop and the, this part of the use of drop way simpler. So number four, last but least customization, probably the one. Other of you listening to this talk already had issues where there was the next speak release of his IGA tool of choice. And then a lot of customizations didn't work as expected anymore.
Scared about it. There are solutions and the solution at the end today is customized outside. That requires a modern architecture.
We are back to this identity fabric picture I have here where to the lower, right, the technical check, right on, on a previous slide. So customized and customized outside, because what you have is there are APIs exposed and for, for customizing as ENCO. So it's about these APIs, which we expose as an API layer and which we then can use to create microservices for customization, which build on these APIs, which even may expose their own APIs.
So if we want to, to move to a, sort of a higher level standard capability for whatever the registration or old school password reset, we could create something which more sort of a witched or however it, we like to call this microservice. We customize. So we can extend, we can use these APIs from our system, as well as the own created APIs to extend.
And we can use this to orchestrate, to other applications like our it service management should be its not ITMs here. And if the APIs are stable by the vendor or by an wrapping layer, we put it on top of that.
The segregated code, our customization lifts in well defined microservices. So even if I changed the platform below the microservice remains stable and we see this, this happening in, in, in a couple of IHA solutions, which are coming more from, from companies that derive from a system integr area, which in fact put such layers on top of other IGA tools. And so we can do a lot here. We can do a lot around customization and that is something which definitely helps us in doing our identity management better than before. So there's a solution.
And what really is important is you should starting rethinking your IGA. Don't take it as it is. There are a lot of good things in what you have today, but there are also a lot of things we commonly struggle with sync beyond that sync towards identity fabrics. And we had a couple of events on that and you have a ton of videos and texts you can get from us, but simply beyond it, you need IGA, but do it right and modernize it think beyond, and also be skeptical regarding sort of the established approaches you have. That's it from my end. Thank you.
