André Koot - From RBAC to ABAC in a Pragmatic Way

Topic of today is migrating from ARRB to AAC in a pragmatic way. First question will be, do you have to migrate from ARRB to AAC and second pragmatic? What does it mean?

Well, first, last question, first pragmatic doesn't mean it's feasible for every organization, every instance. So we have to find some architectures in British to make it possible to migrate, but I've got some customer case here I'd like to discuss with you and show you why to migrate from Arabic to Abe. Everybody aware of ARRB B you all know the, the ideas behind Rob base access control, you know, about Abe based exit control. Are there any fans, a Arabic in the house? One fell. Okay. The not fans of Arabic?

No, I don't. I don't like it from 10 years ago on my LinkedIn profile. I wrote ARBs end of life. Not yet.

Sorry, but who got the first? Who am I? I am a security consultant with NSU. NSU is a finish cyber security company. And I'm the one of the consultants in Netherlands. I'm most fond of my registration here, registered cyber expert.

You know, don't know it, but it's my fear. I'm, I'm convinced that most security incidents are not from outside 98%, in my opinion are inside security incidents. So why bother with managing cyber instance, if we can first have to clean up our internal organization.

So, and this identity X management about the internal side, NSU, anyone familiar with NSU, apart from the colleagues here, we are all in security company based in Finland stock listed federal independent or independent. And we got over 200 consultants in Finland, Sweden, and in Netherlands and a few in America. So you'll be able to find us role based access control, who doesn't use it.

Well, any company I come in say they're using role based access control. And if you dive into it, it's in most of the case it's used. Partly it's not. It's the ideas to use role based access control in most security policies that say we have every authorization must be handled using rules.

Well, lots of authorizations are still directly attributed. So we've got some challenge ahead.

And, and in my opinion, it's end of life. Why?

Well this, you know, this is, and our back matrix. This is from a customer and it's just one in, well, I show you a few slides, few images of the role-based access control matrix. It's about components, roles, resources, authorizations, access, you name it. It's in there. And there's really someone, an asset owner who says this is okay. Someone who says, but this is the, this is the authorization matrix for organization. This is how we use it. I bet he doesn't know what's in it. I bet most asset owners don't know what's in it.

Do you think the roles should be manage, but the asset owner and if system, owner, or someone else who should manage roles, any idea, Business Unit, business unit, can you dive into a bit more business unit? The people that are doing a business process, they should determine who Has access. Okay. Business system. That's in my opinion of completely, right? We rollbacks asset control, especially something like separation duties should be handled by a process owner. And every customer I met, I see that OD is responsibility of an asset owner or system owner.

I'll show you why that's wrong. And that's why one of the reasons we should, why should we should migrate? Great. And we got some Arabic, other Arabic challenges. First of course's OD, but we got another challenge. Cloud knows no rules. There are no rules in the cloud. So if you're connected to the cloud, have your customers come into the cloud or you accepting accessing system in the cloud. There are no rules. You don't speak the same language as your relationships. In other side of line, there are no rules in the cloud.

So how can we do rule waste access control when you're cloud oriented, second Rach doesn't know about context. In fact, the more rules you have, the more authorizations you have, and there's not a negative rule. There are no rules that limit authorizations. So you should add rules on top of roles in order to be able to, to limit the access. Our doesn't know about context. So if you're accessing, sitting, accessing your system from outside, using mobile other device from other country, other time zone, there are no rules that make it possible to exercise. It.

Attributes that authorization Businesses, they don't use roles, businesses, the org, the teams and organization, the business units, organization units. They don't use roles.

They, they talk about mandates tasks, permissions. They don't speak in rules. That's that's funny, we doing our back and we say, it's a business thing, but business doesn't know about roles. And the other side we got it. It doesn't think about roles. It does think about efficiency, grouping authorizations, but it thinks that business runs roles and business wants, thinks that it runs roles. So we got a debt situation here. And some of the challenges, as I said, In a role model, do you give access to an application or do you give access within an application? And of course we saw the slides.

Most roles are more content of rules are comprehensible for the business. So if some manager gives you a role, he doesn't understand what's in it. Some quite big challenges. How about this one OD separation of duties. If you just learned it should be handled within a process. Process owner should be responsible for separation duties, not someone who's by accident and system owner, or a line manager or someone from a team manager. It should be someone in the business process. I know the situation from a customer and we, he said that the system owner is responsible for separation of duties.

Well, that's okay. If the business process we're talking about, step one to five is managed completed within the system.

If the, if the process is handled within one system, that's okay, the system owner could be responsible for defining separation of duties. That means if step three should not be handled by someone in step two or step four, plus you could define a role that's responsible for managing task three and the others cannot be handled by the other role. So we can define suppress duties within this system. And the system only could do it. We find that this is happening a lot of organizations, but suppose we got the same, the same process it's handled by more than one system.

We've got a big problem here. For instance, if we look at system one, the system owner, or system one doesn't have any OD problem, because he's only got these two steps and there's no OD within this process. If we look at system owner two, he's got one done authorization and no OD problem. Look at system three, the system owner doesn't have any OD problem because he just has some tasks. They're not conflicting. But if you look at the process as a whole, we got a big problem. There's no OD defined. One person could have all these roles in different systems.

And so have one all conflicting roles within one organization within the wrong role. So we should migrate to something else, make the process owner responsible for OD why I'm saying this because most of the time we say we use our back. And then we are in control of OD. We use roles to manage OD which organization doesn't. I bet every organization is using roles to manage OD so far. I haven't found any customer who doesn't. So In future, what should we do first? We should define process and process quality. First.

That means that the process zone process owner is responsible OD and is responsible for implementing OD in business rules. It's not a rule type rule thing. It's a business. It's a rule thing. If you do step one, you can do step two it's role thing. It's rule thing. So it's not rural it's rule. So we should add rules to rules, of course, but that's very difficult. And the second is process only should define quality criteria within this process. You can actually good part task two.

If you got the following criteria, the following attributes, the following mandates, or whatever you call it, to be able to, if someone's competent to execute the task, it shouldn't be based on role. It should be based on competence within for the task needed. So if some let's get back to this process model, if in step three, someone has to have a driver's license to execute the task to expert D that would be driver's license, not a role chauffer or driver. It should be their attribute driver's license. That should be the one criteria to give access to this task.

And it's the process owner who responsible for doing that? The process owner do not only define OD. He's also has to define the quality criteria to get access to the task. If we do this current information landscape, the application landscape doesn't fit applications that don't build to make, to facilitate based asset control. We do have every application we use, whether it's SAP or whatever system we use, it's based about a role based access control model. It doesn't, isn't based to give access based on attributes. So how can we migrate? Can we migrate?

Yes, we can. For instance, this is a traditional R system.

This is, you can see it very good. It's a gray blocks, this whole area, and traditionally log in using the username password. You are user, you get an account, you get a role based on the user role matrix. And based on this role, you get access to application functions, authorization in this information system, this traditionally how we build applications. So we got user table, a roll table, authorization table that gives access to application functions.

What if you migrate to something like Abe, Abe, we could try to open up the application using Federation technology semi or, or whatever, whatever. And we got several steps to take. It must be possible of course, to build a layer on top of this application that we have to make it possible to intercept messages, whether it's OS of whatever. So we have to add upon the application, the service provider layer, The first step would be to move, to add the account that we use into the message.

That means we get single sign on the user access, the application, the user, we, when the user gets to the application, we add the message we give. This is user, but the RD. And so the user doesn't have to log in the application. It gets access based on the message based on the sum token. And we use, we know which account it is so we can access the application without logging in second phase would be to migrate the role to the message. We got a semi token, and we kept the role of the user in this message. That means that we can say to the application, this is Andre and his role is driver.

And it means the application doesn't have to find out who I am or what my authorization are. The application knows this is his role, so we can access to this role. And the final step would be sorry to migrate the authorization part in semi token, That would be killing the application logic, moving all, migrating, all application logic out of the application, into the service layer to make it possible, to use attributes, which you see three steps here. The first steps will be as single sign on. So just logging and use the user ID, no logging in anymore. Second step, I call it hybrid aback.

It's not real aback. Abe would be using real attributes. This is a pragmatic way to, to migrate towards Federation type access. That will mean we use, we give the, we use role-based access control as built in the application. As the application is being used for decades, we don't change that. We just change the way to execute, to enter the application. So it's hybrid, it's traditional AR using Abbe facility feature technology. And last one would be real Abbe. We just use real attributes coming from an Abu store or whatever. What would that mean for a migration?

First, we need to add a layer on top of the application. We need to add an API layer on top of the application to make it possible, to intercept, to receive some messages from our tokens or open ID connect tokens. We don't mind that should be possible. Not every application would support this, but it should be the way to go. We should implement an identity provider. We do have extra directory. Of course we do. We could add an identity provider to create some messages or the tokens to connect to the application. We need to implement adequate management.

Because if we give, say that someone's got a role, this role is used in attribute form. So we need to manage those attributes. We need to manage those so-called roles in our identity provider layer. By the way, in this customer case, we use the regular active directory as the attribute store. It's not clean. It's not neat. It's pragmatic. So we can use roles and transmit, transmit them as attributes to the application. And of course we, he's not real AAC.

It's R B, you've got a small picture, this, a traditional IM business. We all know and love this, this regular provisioning. We got a HR system, identity management access management control system. We got an ad being provisioned by the exit management solution. And we got a traditional application, but the service provider layer on top of it, any role managed in this situation will have to be provisioned using the excess management solution and provision to the ID environment.

And in fact, in fact, if someone wants to access the application, the identity provider will create a same message using the identity and the role attributes with the trajectory. Well, the event as you're doing this is you don't have to migrate everything in one steps.

No, no big bank scenario. You could use this pragmatic way to migrate additional legacy systems to a modern Federation style technology, no loss just gains. You can step by step enhance the number of attributes that you could use in the same manner we can.

Of course, open up the current legacy applications from outside organizations. This was done for a customer who needed our legacy applications to be opened up for external organizations. So we could use the same facility for external organizations that we use internally. And of course you can do have some experience using Federation tile style technology, but now, well, if you use RBK keep going on, keep using ARRB B any form of control is better than no control at all.

So you just, if you using our B you're in control, if you use, if you don't forget to add the process owners, one of the stakeholders in the rule management process And think about authorizations from a business process perspective. So no longer from a system application owner, asset owner, or line manager, whatever it should be done by a process owner who's responsible for authorization.

Well, that's about it. Thanks a lot on the round of applause for right. Please.