How to cope with digital identities - Migrating from RBAC to ABAC, part 4

Show me a role and I’ll show you an attribute - In the previous blogs, I showed that the concept of Roles is not the most obvious and that we should contemplate about different paradigms for access control. I suggested using the principles of Attribute Based Access Control (ABAC, some might say Claims Based, or Context Based, but the main idea is the same). Implementing ABAC in an effective and efficient manner requires rebuilding the application landscape. Migrating towards this goal takes a lot of time, so using a ‘Hybrid ABAC’ model is a pragmatic migration strategy. You can use the current Role model and use the modern federation technology that underlies the ABAC philosophy. We can use the Roles as Attributes and grant access based on these Role-Attributes.

Active Directory as an attribute source

But if we migrate from RBAC to ABAC, where do we get the attributes from? We need an Attribute Provider. In the Hybrid ABAC model we need attributes, but the starting point is an RBAC situation, where access to resources is granted based on Roles. And these Roles are already managed in most organizations and in many information systems. And besides, in most organizations Roles are managed in Active Directory: people are made member of Groups, managed in Active Directory.

Active Directory is an interesting component. AD fulfills a lot of tasks in an ICT infrastructure. Of course it is a directory, a register of all users with many properties (‘attributes’) of these users. The main purpose of a directory is to provide user information. The main protocol used is LDAP (lightweight directory access protocol).

AD is not only an address book. It’s also an authentication service: if a user logs into Windows, the credentials are verified in AD, the user ID and the password hash, and personal PKI certificates are in stored in the AD.
AD also manages access to lots of IT resources connected to the Windows platform, like printers, modems and other components. For all these objects, AD is the managing component. It’s a busy beast and it gets busier every year: https://social.technet.microsoft.com/wiki/contents/articles/19037.active-directory-features-in-different-versions-of-windows-server.aspx

For our RBAC to ABAC migration we don’t need all that stuff. But we can use some parts of this infrastructure to create the content in the SAML messages that we need to access an information system, the Service Provider (SP in short). We can use the content that’s managed in AD to generate the attributes that are required to access the SP. AD can in fact act as an Attribute Provider, an AP. And that is possible because in many RBAC enabled organizations, a person’s role can be added to AD. This mostly happens by making this person a ‘group’ member in AD. The Group is a subdivision of the AD directory structure. There can be different kinds of group memberships in AD. Making people in the finance department member of a group ‘AG_Finance_share’ would mean that they can have access to uspecific finance oriented resources, like a share on the network. AD supports plenty different ways of differentiating users and authorizations. The group is just one of those, but we can use it effectively to manage attributes.

Building an identity provider

Our migration strategy is to transform the Roles into Attributes. A role is an attribute of a person, in the context of being an employee. And there are other attributes that can be managed in AD.

In order to effectively make use of federation style of access, we have to be able to generate SAML messages based on the requested access. We need an Identity Provider to generate these messages.

An Identity Provider (IdP) is an ICT component, and a responsibility for generating SAML messages that can be used by Service providers. The IdP will find the attributes for a user in a directory, like AD, and create a SAML message. The message will have to be created in conformance with an agreement between the IdP and the SP. A SAML message is an XML type of text message, that is generated according to certain open standards and that can be used to transfer security related data. SAML means Security Assertion Markup Language, and that implies that the IdP states that the claims (attributes) in that message can be relied on, provided that the SP trusts the IdP.

Practice case

Let’s work this out in a practice case:
The ERP system of an organization is a traditional information system, with its own user repository and an authorization model based on RBAC. The ERP system supports different business functions like pay-rolling, views on customers and projects and lots more.

And for the sake of this exercise, let’s assume that it is possible to add a ‘service provider’ layer on top of this system, so we can access the system using a SAML message instead of using the traditional login facility. And the functionality can be made accessible through this service provider layer.

User Alice wants to have a look at the pay-rolling functionality. She tries to access the application via a URL in her intranet portal. When she accesses the URL of the SP, the service provider will try to determine if she is authorized to access the function based on the precondition that Alice has the role of an HR employee.

The IdP generated the SAML message and added the attribute “HR-employee” based on the fact that in AD Alice is member of the role “AG_HR_employees”,  where AG means Application Group. The content of the role name in the SAML message will have to be determined based on the agreement between the SP and the IdP. Where the IdP can read “AG_HR_employees” in the AD, the role name in the SAML message may need to be written as “HR employee”, or whatever the SP can recognize as a valid role name. Next the SP will map the role name to the authorization matrix in the ERP system, thus granting Alice access based on the RBAC role model in the authorization matrix.

The IdP therefore has to trust that Alice is a member of “AG_HR_employees”. Alice has to be member of that group in AD. Luckily that’s not the biggest problem: we already know how to make Alice a member of that group: we use the regular Provisioning facility, for instance the provisioning performed by an IAM solution. In the IAM role management solution Alice must be given the RBAC role ‘HR employee’ and then the IAM tool will make Alice a member of “AG_HR_employees” in AD.

The migration strategies

This migration strategy can be used when rebuilding the application landscape, or purchasing a new system is not feasible. In the image below different migration strategies and access methods can be seen. The simplest access method is using SAML to facilitate Single Sign-on. The IdP generates a message with just the user-id that the SP can parse. This is a very simple access method and it only results in bypassing the login screen and the password management features of the system.

The second method is the hybrid ABAC strategy. The IdP generates a message with the user-id and RBAC role, that can be parsed by the SP and the underlying information system. The authorization doesn’t change one bit, but accessing the system is much easier and can be done from other identity providers too.

The most advanced method is real ABAC, but that requires building a different access strategy, by externalizing the access rules. This is no small challenge…

Next time we will analyze the IdP and SP technologies and try to draw a roadmap.

Read also the previous parts in the series on the Migration of Role Based Access Control to Attribute Based Access Control: