Migrating from RBAC to ABAC, part 2: Access control fundamentals

Down with the role! That's actually been my motto for quite a while. But getting rid of the role cannot be done overnight. Especially since we are rolling out roles in great numbers. And that, by itself, is not all wrong. Just the pursuit of greater control of authorizations is good. However, as explained in my previous blog, a role is not the most logical, most efficient or most flexible way of managing authorizations. A role is basically just a concept developed to make a translation of business functions to technical permissions. And that requires some quantum leaps.

One of the leaps is that we look at what a person must do and not what authorizations a person needs: When someone has the position of an ‘accounts receivable administrator’, he or she gets the authorization to manage debtors. But that's really a huge mental leap. Actually you should argue just in the opposite way: what tasks have to be done, and then evaluate what access is needed: both for a person and an authorization. That seems trivial, but it is a fundamental reversal of the authorization model.

Access Control in Reverse

Access should really work out this way:

Records of Accounts Receivable should be managed within the finances process. The process owner of this process is accountable for managing this process. The requirements for performing a certain task in that process, as defined by the process owner, are: relevant education, experience, organization (department), location, time of day, device. And perhaps even some extra quality requirements defined by the process owner to ensure that the processing is carried out correctly. For example: that the person executing a task cannot manage his own customer records and that no two critical consecutive tasks in the same process may be performed by the same person. And the process owner defines these rules to prevent fraude and misuse of controls. Yes, this is Separation of Duties. This is where SoD comes from!

If a process owner already captures such a lot of quality criteria, for the process owner it is completely irrelevant to define who may perform the task, provided that the person performing the task meets all criteria. A process owner doesn’t have to define who should receive the authorization, he just needs to be able to verify that someone who performs the job meets all the criteria defined.

Fundamentally different

This in fact is a fundamentally different way of thinking about authorizations. We no longer assume that the user of an information system has the correct role, but that he has to meet the defined criteria, competences and context. And those are the attributes of a person's identity or context. If those attributes correspond to the required quality standard that have been defined in the form of measurable criteria, then there is a match and only then this person may perform the task. And as a bonus… the calculated access permissions can even differ per session, or moment, based on context or whatever dynamic criteria were defined…

So, yes, it looks very logical to adopt such a model. But then other questions emerge:

Where do these attributes come from? And how do we know if these attributes are correct? We will discuss this matter in a future post. And it will imply some serious changes to migrate from RBAC to ABAC. But based on the old Role Model we can imagine a migration scenario from RBAC to ABAC.

As I wrote in the first blog, RBAC is aimed at providing authorizations to people to perform certain tasks. If we can assume that the person who has to perform the tasks effectively meets the quality criteria as defined by the process owner, then we *could* say that this person’s role *implicitly* has the right attributes. That means that we could consider this role as all required attributes… And if so, migration of RBAC to ABAC only is a technical migration:

Instead of logging into the application with a username and password, the user now just connects to a business function through a federated protocol, using a SAML message containing an indication of the identity and the role in the form of attributes. One does, of course, need to adapt the application to allow for access using a federative SAML protocol…

The migration of an application from traditional RBAC (=through provisioning of account and authorizations) means that we just need to change the login facility, because the authorization model in itself does not change. The application needs an interface to be able to parse the SAML message and to map the attributes to the RBAC model of the application. That’s all: Since we still use the Role metaphor, the authorization model and the permissions don’t change.

And of course we need to add an 'Identity Provider', because such specific component must generate the SAML message that contains the ‘traditional’ user identity (account) and role (as an attribute). In a future blog I will expand on this, since this may be the most important migration aspect.

Hybrid ABAC model

The new access control model, using a traditional Role in the form of an Attribute, can be regarded as a hybrid ABAC model. Hybrid in the sense that authorizations are still linked to roles, but that modern federation technology is applied. Hybrid means that an RBAC authorization model is used, but that the underlying technology for ABAC, ie federation, is deployed. We no longer provide accounts and authorizations to target applications, we use federation techniques. Real ABAC would mean that we no longer use Roles but just rely on attributes. But this full (dynamic) ABAC model requires some more fundamental changes to access management and ICT infrastructure, ABAC requires a new architecture.

The hybrid model is a pragmatic solution to switch from the traditional IAM technology to the modern technology.

In the next part in this series I will explore more about attributes and information security.

An unexpected ABAC challenge

Currently three of my assignments have an interesting similarity: attribute based access control, all at the same time. And for all customers the choice for ABAC is related to rebuilding the internal application landscape. These customers are not implementing ABAC to facilitate federation of external identities, they're implementing ABAC for internal users of internal systems. There are multiple drivers for this change. There is, of course, the desire to publish internal services to external parties, some day. But there's also the concept of service orientation and the use of service buses and web services. But the concept of separation of identity provisioning and service provisioning is gaining ground as well. Explaining the pro's and con's of ABAC for both business and ICT is no longer a mission impossible.

But at the same time I experienced that there is an interesting and unexpected blocking factor: the application developer. It seems that where both the business user and ICT operator like the added value of federation and ABAC, the application developer has some trouble to get a grasp of the new paradigm:
There is no login page for an app anymore, no users table, no account name or password to manage. How do you implement access control without  a user database and an authorization table with roles? And if users don't log on to your app, how do you know who they are?

An unexpected problem for sure. We need to educate developers as well, to ease the paradigm shift.

"Authentication versus authorization" - Axiomatics blog

If you're interested in modern acccess management techniques, using, SAML, OAUTH and XACML based access, you should really read the three part blog by Andrew Hindle on the Axiomatics website:

Part 1: Federated Authentication

Part 2: SAML and OAuth

Part 3: Bringing it all together

Enjoy!

Attribute management

In my previous post I said that I need a facility to manage attributes issued by third parties. I have plenty digital identities, but most of them can only be used for a specific purpose. A limited number can be used in a multi-purpose fashion.
There's DigiD, the Dutch digital identity that was provided to me by the Dutch government and that can be used in my relation with a number of national and local government transactions and for a few transactions beyond that, like for my health insurance business. But these services can use only one specific attribute of my DigiD identity, the 'BSN', a unique identifier, like the American SSN.
Another multi-purpose identity is my Twitter account. But it also only has some predefined attributes, but if a service provider needs extra attributes, he needs to capture those through other channels. But there are no attribute providers beside the identity providers we know and love...

But, a few weeks ago I received an invitation from ISACA to download digital Badges that can be used to indicate that I am a Certified  Information Systems Auditor (CISA) and a Certified Information Security Manager (CISM). These badges can then be imported in an 'Acclaim' account, that I can use to present my badges to others. And ISACA mentioned that presenting these badges in my LinkedIn profile is a preferred way to show my certifications.

How about that? ISACA issues a badge that proves my qualification. It is an attribute of my profile, it belongs to me. Not to one of my identities, but it is an attribute of me as a professional. And ISACA is qualified to issue these attributes, ISACA created these attributes, ISACA is the owner of the CISA and CISM titles.

ISACA issues badges in the form of an Open Badge, an open standard, created by Mozilla. And Mozilla created it's own backpack facility in the Mozilla Persona digital identity. The backpack can be seen as a wallet that contains the badges. Acclaim is another form of a digital badge wallet. Here is the acclaim page with my ISACA badges.

I really liked this idea, so I created my own badge issuing process. As you may recall I started the #ditchcyber campaign and this campaign is supported by the @CyberXpert account. I decided to offer CyberXpert badges to followers of this Twitter account. Any follower who uses the RCX or CCX title can get a digital badge and import that badge in a Persona Backpack. Here's my backpack, showing a CyberXpert badge.

Next thing we need to find out is if an Open Badge attribute can be collected by a digital identity and combined to a SAML message.

Let's kill the IAM acronym!

In the information security industry, the IAM acronym is well known, it's the acronym for Identity and Access Management. IAM is used in blogs and tweets, consultants manage IAM projects and vendors sell IAM tools and suites. But I am feeling less and less at home with this acronym: it feels like a false acronym.
Identity Management (IDM) and Access Management do not exist together. These terms point to different processes and responsibilities. Let me explore and explain this some more.

Identity Management is a process for managing the lifecycle of identities within a trusted domain, be it a real or virtual organisation or an Internet resource like a mailserver. Identity Management is responsible for managing digital identities and user accounts. It is about 'who', it's a process for managing 'subjects'.

Access Control is a whole different ballgame. It's got nothing to do with 'who'. It's all about defining 'what' and 'why' for accessing 'objects'. Access Control is about defining the access policy for managed objects and resources. And it's about the person responsible for defining these policies. Access Control is a shared responsibility for a process owner, who in turn should define access rules for realising Seggregation of Duties, and a Data Owner, who is responsible for data governance and who should define access rules based on all kinds of laws and regulations.
The process owner and the data owner have to decide what kind of permissions should be available under what conditions. A process owner should not be interested in managing the accounts accessing his resources, but he should be interested in why accounts might be able to access his resources. And he must be interested in the audit trail: who did what.

Of course there is a link between the two processes. And that's simple because Who can do What and because of Why. The link is the digital identity, in most cases addressed as a Role of User Group.

Identity Management can largely be supported by tools. IDM is responsible for synchronising user accounts, roles/groups and passwords between systems and for provisioning attributes towards all kinds of related systems. The business case for IDM is in lowering costs. A single point of administration lowers operational costs and results in better data quality because of it. IDM can be implemented in an IT project.

Access Control is a business process. There's not a lot of technique in this process. Of course the rules have to be implemented in systems, but it's not an IT responsibility. The business case is not in lowering operational costs, but in delivering better transparancy and governance.

IAM projects tend to result in either an IDM implementation or in nothing at all. So why call it IAM after all? We better start calling it Identity Management and Access Control, or, as I tend to do, IDM/AC.

With the growing acceptance of Identity Management services in the cloud, separating IDM from AC is a logical consequence. The next step will probably be delivering Access Control in the cloud, in the form of Policy decision engines using SAML and XACML. And this process is better of by not managing Identities at the same time, so that it can be re-used regardles of the process that requires this kind of functionality.

myOneLogin ad

I just read one big ad (dressed as an article) for the myOneLogin service. It is some kind of identity broker, directed at enterprises and SMB's, facilitating single sign-on for cloud applications. It's a $3/month per user service that might replace the use of OpenID for enterprises users. It also addresses strong authentication needs and can cope with SAML.

Anyway: this has got nothing to do with identity 2.0. It's not the end user that is in control of his identity. This may be fine for enterprise use, but why would a company pay fot sso in the cloud? Enterprise sso (esso) may be considered a security measure (it makes sharing accounts by end users difficult). And if you employed esso, cloud apps should be handled as well.

I'm a little bit concerned about such developments. The problem with services like this (as wel as with OpenID) is that a central authority gets to know my whereabouts. Can these authorities be trusted? How about international regulations? Any clue? How do they handle logging and log analysis? Or log retention (I hope Not).

I'm happy with this kind of development, because it propagates the use of open standards like SAML.

Still, not for me, though. I prefer an internal esso and besides, the password store in firefox and ie is capable enough. It is great, however, that using sso you are into green computing, in pandemic planning and fuel conservation and thus protecting the environment. I don't know how, but it's in their About statement (at least in today's version) :)