So, what is the duty that we have today? So, the title of the panel says Mastering Authorization xBAC et al.
So, and all the BACs you can find out there. And we wanted to kind of provide a service here of understanding it, because I think you hear in the IAM space a lot of strong opinions, what you need to do now and so on, but we all come from the reality, I hope at least, and need to combine what is there already with what would be the best, what the analysts recommend, for example. And that is the reason why I have my colleagues here. Maybe a very quick introduction, who you are, and then we kick off the discussion.
Hi everyone, I'm Heiko, CEO of Nexis, identity guy by heart, more than 20 years in IAM, and have most likely been in touch first time with x, some authorization control models, back in time during my PhD thesis around 2005-2006, where RBAC and ABAC and all this kind was still a thing, and still it is today as well. I'm CEO of Umbrella Associates, a boutique consultancy in Frankfurt, and we are doing identity and access management in depth. I have been doing authorization projects since over 10 years, mostly in scale, so that's what I'm here for.
Yeah, Philipp Messerschmidt, lead advisor and deputy chief of advisory for Köppinger Coal. I think you know what Köppinger Coal is doing, but as lead advisor, I'm also working with the customers, so I'm not just doing the research part, but also I'm seeing a lot of projects and customer sites, so that's where I can add my experience on authorization from the field, but also from the research.
So, with the different backs in place, maybe we start with one thing first. So, besides RBAC role-based access control, what is there else?
So, maybe to have a very quick understanding of what is there. Maybe one or two things that come to your mind first, Heiko, and then we go over. I take the easy one, leave him the harder one.
ABAC, PBAC, TBAC. Hybrid models. Sorry? Hybrid models. There is RBAC, there is ABAC, there is PBAC. They all are beautiful, but they have their characteristics. Yeah. I have one more in mind. I don't know if I heard it, you or?
I mean, Heiko basically covers all of that. Okay, you said already.
RBAC, you said already. Ah, okay, RBAC. We can say RBAC, but it is part of ABAC somehow.
I mean, there are discussions out there, but I would consider that part of ABAC. So, there is not really much more. We have the older ones, MAC and so on, but this is nothing that we probably should use anymore. You could have just created another one.
YBAC, WBAC. I can do everything, right? Yeah. We just make it a new model right now, live on stage.
IBAC, I had intent-based access control somehow, was someone saying, yeah. So, there are new things coming already and rising again.
So, yeah, somehow the question is how to keep up with all of this. When we are talking before, and I think that is, yeah, the topic that is all around, RBAC is dead, yeah.
So, as I have worked in the insurance space, and I know the mainframe is dead, and he is quite long dead, but I still see him from time to time at some organizations. So, maybe, Roland, you might want to elaborate a bit on this. Why RBAC is dead?
Well, from the management perspective, it is absolute horror, because when you scale up, you will see the limitations of RBAC, and this is a role sprawl, and it is a well-known phenomenon. And in the end, it is because you have underfit of your model. The model does not fit your requirements anymore, and you will see this when you scale up in numbers with your models. And all those models have different characteristics, and they will stand out when you scale up.
But, Philipp, when we look at the practice, we still see it a lot in the reality. So, it is dead. It is not working. Why is it still there?
Yeah, I would say I know why. Because the dead RBAC is simply what we have done for years now, for decades, probably. And most of the use cases that we see out there, you can still solve them with RBAC. And if you have an IGA in place, you are used to RBAC, what will you do?
I mean, you are using these use cases by RBAC. If that makes sense, it is a different story. But we can certainly say that RBAC is still the most popular access control model out there. Absolutely. And thinking about dynamic roles, so infused by attributes, so a mixture of roles and attribute-based access control, it gets a little bit more flexible and helping you to get a bit rid of complexity.
So, I would say, despite its limitations and its challenges, it has a couple of nice advantages. On the one hand, like Philipp said, it is just there. It is working very wide. It covers a lot of cases, probably not all. But then you can combine things, different authorization models to really leverage it. And it is in part, not every time, it is super understandable for business departments.
So, when you have kind of roles that are somehow aligned to job functions, to tasks or something like that, a manager in an HR department, in the finance department gets it. If you present an OSINT policy, it is a bit challenging. That's true.
So, the thing is, I think Martin Kuping has said something in one webinar. He said, yeah, the role-based access control is something, because we as humans are bad in scaling.
Yeah, it helps us to somehow understand what is there and happening in our systems. So, maybe then Roland, to you again, the question.
So, I'm now there with 2,000, I don't know, I'm from the insurance industry before. So, I have now 2,000 applications which have static access control, yeah, role-based, yeah. And I'm now there and you say, yeah, our work is that, do something else. What should I do? This really depends on your use case, on your architecture. The beauty of authorization models, like all expects, is that you can combine them and you can try to eliminate shortcomings from one level with the advantages of another model.
So, it really depends on your architecture, on your use case, on your administrators and how you can integrate this into your whole architecture stack. So, it really depends.
As I said, all authorization models are beautiful and this is also true for Orbeck, but it depends really on your case. So, then maybe can you give us a practical example, maybe from your experience around one use case, where you say the combination worked or was a good idea and really, as you said, like the advantage or the disadvantage of the one, the other one could cover and then make it work like charm as you want to sell it usually.
So, for example, Rebeck is a wonderful system because you can add a lot of complexity into your model and you can really model deep hierarchies with Rebeck and this is beautiful, but you will have a central state and you have to maintain that state. And from the infrastructure, it's hard to maintain a state in really big infrastructure.
So, that's a shortcoming of Rebeck and you can cope with this with a good implementation, but you have to choose between availability and consistency and really big structures and really big environments. And on the other hand, P-back and A-back are beautiful because you can decentralize the whole model. You can completely decentralize attributes on the subject side and on the resource side and just bring them together in the evaluation situation at runtime.
So, this is a really distinction between both models. Adding on that, a good example with P-back.
So, with R-back, you basically allow someone to have access to something. With P-back, you can also create denial policies, which gives you advantages thinking, for example, on agents or on more complex use cases.
For example, to combine IAM with GRC information from the governance risk and control space and you can say, okay, my external contractor, who is not based in the European Union or who has no managed hardware or no ISO 2701 certification, which is normally kind of data that's stored in third-party management systems, GRC systems, this kind of stuff, you can bake this into a policy and say, okay, those folks are not allowed to create, to access any systems that contain PII data that might cause conflicts with GDPR and this kind of stuff. You can do this with agents.
So, an agent hosted in the US is not allowed to kind of process European citizens' PII data and you have to kind of have certifications in place that the model is not biased and so on. And then you can create allow and deny policies, which gives you an additional power to guard things like agents, for example. That's what I call the expressiveness of your authorization model.
So, in R-back, you are limited to R-back, but it's hard to define a deny policy. It's also hard to define deny policies in pure A-back, but with P-back, you can do that.
So, you have a different expressiveness in each model. And P-back, of course, has the most advanced expressiveness because you can literally do what you want. But what you get there, what you get in this is a policy sprawl.
So, what we know from R-back with role sprawl is also true in A-back and in P-back. So, when you start to see an explosion in your attributes and your policies, you may experience an underfit of your model or you're holding it wrong. Okay.
So, the thing is, the bad things of the one model can still happen with the other one. Philipp, maybe towards your direction. The thing is, Roland said, yeah, I have the 2000 applications and he says, okay, it depends on the use case. Then I say, okay, it would be good for all my use cases. How do I start?
I mean, it really depends on the use case. I'm not denying that. But what in addition?
Yeah, I mean, what we just learned is, to summarize a little bit what you just said, every model, every access control model has strengths and weaknesses. So, you need to really understand your use case and combine the models so that you get the best out of it. We are all talking about role explosion in R-back. Guess what? Roland said it. Our P-back is not changing much. It is transforming a role explosion in a rule explosion if you are doing it the wrong way.
So, you need to find the level where the other models, so, Re-back, A-back, P-back, you name it, can help you with your use cases covering the heavy lifting, the scaling part. And then, when it comes to the individual, very specific access rights, this is something that might better be handled by an R-back, so, where you can define the roles very specific to that person or to that intention even.
And then, you can still do the heavy lifting if that scales for some reason and can use another model. So, combining these models and applying the right model at the right time is definitely a key to success. And that is how you also prevent role or rule explosion in the end. The thing is what I also want to know that in addition is, so, I know now the use cases where I want to change, where I want to go, and I see, okay, I need to change a lot in my organization and my applications. I need to make them ready, for example, to do P-back and so on.
So, now I have all the applications, I cannot do everything at once. So, how do I get into the transition?
So, I have now defined I need to change, but how do I get there? I think that is what most people need to know. The target picture is beautiful, but how do I get to the target picture?
So, again, it really depends on your organization and your requirements and how your organization works. But we have building blocks for that.
We have, for example, also then we have the PDP-PEP pattern that really helps you to cut in your architecture, in your business processes, hook in, and start to implement a new authorization model for that. Practically speaking, I would say start with new applications.
So, nowadays, when you start to write a new application, you don't want to implement authentication, right? From the beginning, you start with externalized authentication. Do the same with authorization. Don't bother around with implementing authorization yourself. Use the PDP and OSINT pattern for that.
So, this is a really, really easy one. If you have an already existing architecture, then, well, it depends. Start not with SAP because it has one of the most complex authorization requirements and implementation you can get.
So, you won't do yourself a favor if you start with SAP authorization and try to externalize that. So, find an easy target. Find something that is small, comprehensible, and you can start with implementing your new authorization model and architecture into that. Absolutely. Absolutely.
Then, you have the base of existing legacy application. Figure out whether it makes sense to refactor.
Sometimes, probably not. Sometimes, probably yet.
However, you can apply PBX still there with kind of attributes coming from the outer world bound to the identities or to other systems. That's the one thing. Think about proper governance processes for your authorization models, whether it's roles, attributes, policies, or so on.
Because, basically, you need always to govern things in place. So, whilst it's clearly for roles, if you don't have a proper attribute governance, who's the leading system for what, and what does the value evaluate to, then you will have problems with PBX as well and other standards. And if you are, like probably most of you, are not just one big company, but a company with different legal entities in different countries, with legacy and so on, then not every attribute follows the same rules.
So, your French colleagues might have a different understanding of job IDs and using a different name pattern while your UK colleagues using another system and having kind of other things. So, it's not that easy to say. And you might have even conflicting information, because when things have been separated in the past and now kind of baked in into the central policies, then you have a non-uniqueness about attributes, values, and so on.
So, having proper governance processes in place is important and kind of divide and conquer. So, you have to involve your wider organization. That's nothing an IM team of 5, 10, 15, 20 persons can completely cover. You finally have to involve your business folks, because a lot of authorization is just a business decision on who's allowed to do what, independent of how you express it.
I think there is a thing that resonates very well with me, but the thing is so that you have your organization who's delivering the attributes, and now they have another responsibility, because real-time authorization decisions are taken based on these attributes. You need to really make your organization aware what is the impact that is now created by these attributes. And this is just organizational awareness.
So, everything comes to the center. Maybe, Philipp, in your direction with the experience in terms of governance and programs that are resulting out of findings and similar things, do you foresee any issues with the auditors who are now like attached to somehow role models and so on, and you're taking away their babies like excess review and so on? And I see already the first findings which say no role model, but the other things are not there.
So, any opinion or idea how to solve it? Well, I think I have to be a little bit careful with my statements here.
Last year, I was approached after my panel by an auditor telling me his perspective. And so, what we can see from the past is that auditors are also used to our back.
So, changing that is putting them into a different position, having a different perspective. So, the challenge with rules and policies is it's not 100% clear at all times who has access right at this moment in the target systems. And this is something that RBAC is doing really good. And we have these snapshots and they are easy to understand. And this is somehow a challenge that we have with the auditors that this is changing as well for them.
So, now they need to understand the rules that we have, the policies that we have and how they work. So, we are adding, if we want to go for snapshots, more snapshots to the whole picture because we need the snapshots of the rules, the policies. We need the snapshots of the attributes because otherwise the policies and rules are not telling me anything. For the graphs, we probably have graphs in there.
So, we need the graphs as well snapshot. So, then we probably still have RBAC.
So, we need the snapshots of the IGA as well. So, that makes like at least five more snapshots areas that we need to add for the auditor. And then he needs to bring all of that together.
So, that is certainly not decreasing complexity for them. Okay.
So, a lot of educational work ahead of us. Yeah, absolutely.
Again, again, yeah. Educate organization and now even the auditors. I think that was a very good closing.
Yeah, so we have covered the whole area. Thanks a lot for joining me here in the panel.
And yeah, applause for our attendance. Thank you. Back to you, Charlie. Thank you so much. Thank you so much. I would have one question because I'm interested. Okay. What do you think about ownership for these more advanced policies?
So, who will own a complex authorization policy? Who's the one in the organization who can take care of them? The business. The business. Do you think they will do that? They have to. They have to. We have to educate them and to get them there as well.
Exactly, that's true. It also depends.
So, if you have an AI model and you are giving it some policies for his next task to do, then of course, the owner of that task will be the owner of that policy. But in a business, yes, in a business perspective, the business owners will be the owners of those policies or the attributes. Thank you so much. Thanks again. Thank you.
