I will lay the foundation layer for this track. I'm looking at authorization trends in the era of zero trust in web three. And as you can see, this is such a big picture and there are lots of buzzwords in this. So let's wait and see how that actually turns out. So the agenda, I want to take a quick look back, be why and if, and I'm sure they are to change. Authorization models need to change. So what we know and what we've learned might no longer be applicable from use cases to new solutions will be the next steps of why do we have to change. We'll have a look at policy based access and zero trust because in the, in the headline I had to and a look into the future, a future-proof feedback will be then the outlook into the future. And then we kick off these, this session, we have six talks including mine in that track.
And that will be hopefully interesting and it's getting more and more interesting once I left the stage. I look back to enterprise, IM I, all these pictures are of course again generated using the usual suspects when it comes to AI generated pictures. But I wanted to have a, a picture representing enterprise IM and how it feels to me. So way back, so early two thousands, late 1990s. So that's what I wanted to look at. And that was then starting with enterprise, IM, this is where we all come from. So we had a limited number of of identities that were stored in a limited number of IDPs, whether or not they have been called that way back then we had a limited amount of capabilities, web access management, making sure that you can have access to web applications internally, externally, some provisionings or shooting accounts and access rights into connected systems.
Auditing of course important, especially when you're regulated because you were driving the IM implementation way back then forward and access governance. And we were accessing internal apps, internal web apps, a bit of a private cloud, but this is where the trouble begins. And software as a service a bit, this is where the trouble begins. That was then. And how did we manage access? We are talking about authorization concepts. Yeah, we used role-based access controls. So we had users combined in groups. We were assigning roles which covered lots of permissions across different systems and we were assigning roles to users and we had a role concept and we were building role hierarchies and we were building, so D and all this was the management process that was in place and still in place in many organizations. Right now I'm not really making fun of that. It works, it's understood. Auditors understand that. Well, very fine. But the question is, is this the authorization model for the future
New use cases driving change? And I also go very quickly through this because you've heard these presentations before. You know what I'm going to say. So very quickly, what are these use cases that really drive change and that make maybe these traditional authorization concept roles, groups not applicable anymore in the future? We all went to remote work. I don't mention the word covid. Oops. And this had to change. So we need to have new ways of authorizing people, authenticating people, understanding who they are, where they are, if they are who they claim to be. We are moving our applications through the cloud. So we are no longer accessing systems on premise. If you think of the picture before there were on-premise systems and they are no longer there. Maybe this demands for a new way of authorizing identities. We have more complex, more distributed i t environments.
And that is really driving change today as our ways of collaboration changes and that we have large groups and we have supply chains and we are part of a supply chain and we're dealing with lots of partners, that means we have different types of identities interacting with each other and maybe they need to be authenticated and authorized. We are talking about authorization now in a different way as we have done this before. So this is really a use case driving change, having some kind of structured partners with hierarchy in there as well. So lots of hierarchies and combining this maybe role management might be not the case to be the right way. Maybe it works. Surprise me, DevOps and agile development, we are changing the way we are developing applications. And this is also nothing new to you. I know you are experts, you are the experts in the room here.
We have new identities including internet of things. I have a an a watch that is intelligent. I hope my, my my, my telephone is intelligent. We have lots of devices but also everywhere in I O T ot, we have devices that are represented through their own identities, which are related to carbon-based life forms who have ownership, responsibility, liability, do maintenance for that. So changes and big data and analytics, a huge problem for many organizations just right now, you have data in their silos and they're properly maintained. They have access controls, you have governance on that. And then you take that nicely, maintain database and take everything out and pour it into a data lake and create reports. Who maintains access control. This is an issue and let's make sure that we understand that this access is properly maintained. So if you think back to the slide that I had, that was then there's a song by the band ABC called that was then, but this is now, this is now we have more identities to the left.
I don't read them out. You know all of those. We have more IDPs in place which store these identities and make sure that they are available for each individual use case. We need much more capabilities and maybe we have a quick look at that. So we look at provisioning, auditing, we had that before. Inbound federation, outbound federation, fraud detection, constant privacy, federated provisioning. And all of this is really something that is getting more and more important. The question is what is the right authorization model that allows us to achieve proper access control, access management, access governance, maybe even more access analytics, understanding more about what actually is going on in these systems. And of course the services that we are dealing with have exploded. There's no longer the web-based app that was running in your data center plus this old self-built or board application that also runs in the data center. Maybe lift and shift to a cloud infrastructure as a service and that's it. Plus a bit of office 365. We are no longer there. This is now. So we need to have a concept that deals with this properly. So this has really exploded and I've mentioned the term identity fabric over there. I just wanted to have a different picture because I'm bored of this stranded identity fabric picture myself as of now. So I just want to make sure this is complexity and this is what I wanted to show with this picture.
What does that mean if you're, if you're looking at authorization management concepts that are traditional authorization management concepts, they, and this is a statement of mine, maybe it's wrong, contradict me if, if you think I am. These management authorization management concept approaches, they lack lots of dimensions that we require for dealing with this. That is then, or this is now, sorry, that this is now. So we, first of all, we have lack, lack of flexibility. If we have changing access rights, dynamic changes to users, we cannot wait until next night when this actually goes through this role. Management gets provisioned out into the systems. Maybe you need to have more immediate control. So dynamic changes and user roles, entitlements, permissions, complexity. I tone the complexity. When you have more applications, more users, may I more IDPs, more systems, more capabilities. This is not a sum, this is a product of all these dimensions.
And then you end up with more entitlements that you then you most probably will can be dealing with with traditional, with traditional approaches. We are more and more, we are talking about zero trust in a second, more and more contextual information. Is this Matthias? Yes. Is this his device not cup covered in, in access roles groups is the right time? Is he coming from the right network? Is the device jailbroken? Is he behaving strangely, all this context information is just not covered with traditional management approaches. Cross domain access. I want to have access to Salesforce and to Office 365 and to my own clouds. And all of this needs to be maintained with one single approach. Is this doable with traditional role management? Maybe have not seen it. Lack of scalability. I've mentioned the scalability. Lots of identities, lots of services. How to deal with this.
So this is my provocation slide for today. So this, this is just a, it just does not work. Does not work. So what is the way to move forward? We are talking about the trends for authorization and I've asked a representative group of robots and they told me this more context, less risk. Our time is real time. This is where we need to go. So really make sure that we have a dynamic evolution revolution. So we need to have something like dynamic access policies. We need to have real-time decisions made on real-time changes in the environment. We need to protect data, not systems and applications. We need to understand data where it is and it's criticality. This is something that is really of important and fine grained access control to data at runtime, cloud native applications, demand for a different way of authorization. Multi-cloud environments, automation and orchestration. Really pulling that across all these platforms that have just described, I'm just describing a growing world of it. DevOps and C I C D is of course an important part, but in the end still you need to be compliant. You need to be able to prove what you're doing towards the regulator, towards the auditor, towards your ciso and in the end, this shouldn't be the final point, but a improved user experience. People need to be able to use this. This is important.
Policy based access and zero trust. This is what the first, yeah, the first highlight in the, in the headline of this presentation is. So have a look at the p and policy based access control very quickly. This is a standard slide that we always use. What is the policy? A subject and action, a resource in the context. Mathias is allowed to access the word document on SharePoint at usual working times. This is a simple thing that can be easily formulated by everybody. This is nothing that requires highly trained role design. I don't know engineers, everybody can do that. It's understandable. It's a language that can be conveyed to many people. So we use policies to make access control decisions based on attributes on the identities and especially on context. So this is something that really adds this additional dynamic runtime environment information to the equation.
And of course this is particularly well suited for these new modern cloud-based, cloud native multi-cloud environments. So very quickly going through this, I've mentioned P for policies, next up in my headline was zero trust. Yep, zero trust. So let's do this and let's combine this all together afterwards. We usually use that slide to explain to your trust. We have a user represented through a device coming across a network trying to access a system or an app. And that gains access to data. This is what we usually make sure we have zero trust. Don't talk about the term, still don't like it, but it requires a structured approach. So we need to understand the user identity management, access management identity vetting, authentication processes. Need to understand the device device management, device health device fingerprinting, the network. Don't trust system and app. Well maintained through, through access control, access control decisions, wherever they are in the proper way.
Gaining, giving access to data that's behind there. How can we now combine zero trusted policy-based access? Yep. So now this time I've I've, yeah, I've just stroke through the zero trust word better. Not really nice, but never trust always verifies much better than zero trust because it's not implicit trust but always making sure that you understand. So I've rearranged the picture a bit. So we have the user here, the device there, the network here, and we have a verification process. As long as they're here, they're untrusted, we don't understand them, them, we try to learn more about them and use this for this verification process. There's a policy engine, a policy admin, here's a slide. Tiny, tiny policy just as I've described it before. And that is enforced and at that point we verify this is the always verify process and that's the moment where we say, okay, we understand user device and network at runtime.
And then we can say, yeah, yeah, but another factor. Yeah, but no. Okay, giving access to the systems. So this is the system and the app and the data and now that comes together into this overall picture of access management via policy based access. And I've used a few terms and they will come back today I am quite sure in different presentations where we see how that really works out. Technically the good thing is this is somewhere close to the to the application, but we don't know really where it could be an, it could be something that is built into an application. It could be something in the traditional IGA system, but nevertheless it makes decision at runtime based on all this information made available. This is a trends presentation, so I'm fast. Future proof authorization means we get better in brand trust, we enable ourself for this rep three, three thing if it comes apart from NFTs and we will move towards feedback everywhere.
This is really something that I'm quite sure that this will happen, but happy to discuss. First of all, p a and brand trust, the time is not enough to walk through all of this. But the question is if you are able to provide your consumers, your customers, your employees, your systems citizens with the information that you actually have proper control over your access management and you can prove that, that really improves the value of your brand. So you are much more flexible. You can adapt to the change in requirements and make sure that access management is much more agile than it has been before while being able to show that you're still compliant. That's the plan. Of course you can blow up this dramatically, but this is not the plan. You want to do that properly. Ideally this is also more cost effective because you put the decision making processes where they are required with an opa, with something else somewhere where it's required you improve user experience cause you have always the same access management rules being in place there.
You increase the user experience, you improve security and you are able to provide proper maintenance and and security and and stewardship of the data that you have been given and that you need to maintain properly feedback. And web three, we will have to have mechanisms that will be able to deal with the identities of the of web three. And as of now, we are mainly seeing apart from the traditional identities that we have, we will be seeing more decentralized identity and we have that in different tracks here in this, in this, yeah, in this whole conference. And I think this is a really important part and feedback can deal with that and that's the good thing. You need to understand where the identities are and I've just, just given a sign that I need to speed up decentralized authorization. Maybe we need to make sure that it's not only a global your authorization but you need islands of authorization where trust is just very limited and still there.
Feedback can play an important role. And trust verification of course is important. Once you have an identity that is maybe decentralized or centralized, you need to make sure that you understand it at runtime. But this is context data that you can use in a policy policy at runtime. Quickly going across that, finally my thought, my wish for the next time is policy orchestration because this is not yet there. I would love to maintain policies in one place and then pull them out wherever they are needed. But that demands for common languages, common standards, common notations, or at least the common semantic layer where you can communicate at. And this is something where we're not yet at. Nevertheless there are mechanisms like policy as code or policy as data which make these policies available in the more machine readable automatable format. And these are just a few examples how that could look like.
The idea is to transport it from A to B and use it where it's required. Final slide. I made it. Key takeaways, what would I recommend as an Analyst? What can I say? I'm not the practitioners or you are the practitioners, but key takeaways. A implement centralized policy management. I said we are not yet there but aim at going there. This is of course of importance. Once you have this mechanism in place, define clear authorization policies. Make sure this these core policies are understood, well, communicated and understandable. Not only understood, but understandable, readable, strive for a fine grade access control model. Not only this course grain that we had before, web access management, door open, door closed and the rest happens in the application. No. And prepare for the modern authorization patterns and emerging use cases. Things will change. Prepare for web three, prepare for decentralized authorization, prepare for everything that will be around the corner tomorrow. I assume p A is more capable of dealing with that than role-based access or groups are. They will continue to exist. No, ma, no doubt, but I think this is the trend to look at. And authorization might be aac, p a as much more. That's it for my side. Thank you very much. Super.
Thanks Matthias. Thank you. Very quickly, we have one question. You mentioned that there's a level of complexity. Complexity associated with our back. What about P back? Is it not far more complex?
It is complex in a different way, but I think when you deal with it properly, you can create hierarchies of policies and can distribute them much easier than you can deal with roles so that you can more easily deal with that complexity. As I said, you can completely do screw it up, you can really do it wrong, but feedback most probably offers a much better approach to much
Better. Provided is centrally managed as you mentioned. Right, exactly. Okay, thanks Matas. Thanks.
