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.

Migrating from RBAC to ABAC (Part 1)

A long time ago I wrote the following statement on my LinkedIn profile: "RBAC is EOL". And in my not so youthful overconfidence I mentioned this during an intake with a potential customer, who asked me how they could introduce Role Based Access Control (RBAC) as conveniently as possible. That talk never materialized into an assignment…

‘RBAC is EOL’ clearly was a premature statement. I must admit Role Based Access Control is far from End-Of-Life. Rather, in practice, we see RBAC becoming more popular and we see more and more organizations starting RBAC projects. Following on the heels of financials and government, other industries are becoming aware of the need to address authorization management. IAM projects and RBAC solutions are increasingly embraced and most of the major information systems, such as SAP, Oracle EBS, CODA, EPIC, Salesforce, Chipsoft, have been built in such a way that RBAC is the de facto authorization model. RBAC is a well-known, but not well understood, way to think about authorizations and access control. Surely I can help customers with that, of course ;)

Why on earth do we use RBAC?

RBAC promises to be a simple access control model, but it’s very difficult in theory, here’s a link to the original NIST publication: http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

But also in real life RBAC is very complex. Let me explain why RBAC should be EOL.

First let me explain why we use RBAC: Ease of operation.

Yes, really, that's really the only reason that we use RBAC. It is an easy understandable method to grant access to read a file, a record or to allow access to a location for a person. It’s also easy to control access: you can find out if a person has access, you may well be able to explain why that is the case and whether the granted access is correct.

Because of use of the concept of a 'role', we can disconnect an 'authorization' from a 'someone'. That saves a lot of administration. If two employees have to perform the same tasks, they need to have the same authorizations. If we give both persons the same ‘role’, then they have the same permissions, at least if the permissions that are required for execution of those tasks are bound to that same role. If someone else is assigned the same role, that person will also get the same permissions. So it's really a lot easier to grant permission by assigning roles than to provide the individual authorizations to everyone separately. We start having problems when there are roles within roles, nested roles: In that case it’s getting foggy what authorizations a person effectively has. The best thing about direct assignment of authorizations is that it’s much easier to show what permissions someone has effectively. You can tell right away after all. Not that we gain much insight because after all, we still have to interpret all these granted permissions once again for every individual assignment of authorizations. Role management does make life easier.

But by just managing roles we’re not done yet. On the contrary. There is not one single type of role, there are different kinds of roles and different levels of roles and of course there are nested roles. There are roles in an organization and there are roles in applications. No, these are not the same!

There are lots of roles in an organization. And there are also positions in an organization. Positions in an organization result in a view of an organization for providing a wage to employees and it a position is created in the hierarchy of an organization. But roles are a view on combined activities within an organization, our way of organizing authorizations. It may look like a position, but it is not.

And here the difficulties start. Is there a relation between a position and a role. Is there a hierarchy? Can people have more than one position and more than one role? Can roles be shared between departments? And do all identical positions result in the identical roles? So, as you can see, the easy concept is getting a bit less easy.

In RBAC, roles are assigned in order to grant authorizations to perform certain tasks. Roles are in fact a set of tasks carried out by a person. A credit manager uses the financial system (the debt management part of course), Office365 (the share of his or her department perhaps?), the intranet, perhaps a module in a CRM system. In addition, a credit manager must have access to the sales administration, e-banking environment, the general ledger. But there are other roles with overlapping authorizations, roles for people that have an almost similar set of applications, but with different access within. That means that an authorization cannot be related to a single person. Here the perceived advantage of RBAC disappears.

Tasks

Now, who decides which tasks our staff with the role credit management has to execute? The hierarchical manager of our employee. And perhaps there’s also a process owner. But these managers have a different focus… the line manager obviously wants optimal performance within his department, but the process owner has different requirements, such as competent, capable and high-quality staff and separation of duties within the process. This can result in conflicting interests. A line manager wants to perform as many operations with a full occupancy, but the process owner wants a high-quality high governance process.

However, there is still another important player: the system owner. The line manager may well want an employee to perform various tasks, but that collection of tasks should be supported in the information system in the same way. What if the role model developed in an information system conflicts with the organization roles and process roles? This is not a theoretical issue, this happens every day in every organization.

Authorizations

Last but not least: what effective authorizations are there in a role? Employees in AGSAPAX-IAM-DEB-Linux-WS seems to get access to GRXACZP-LEDG02Q-File Transfer-RW. Is this? Who knows if this access rule (the kind you see in a lot of Excel sheets) is permitted? And is this authorization granted explicitly or implicitly? Who's in that group? Is that correct? Is that authorization still accurate and up to date? Is the authorization not too broad? How much do these rights cost? Who granted such access rights? Who linked these authorizations to the role? Has this been approved?

In my experience there are dozens more of these question. And they all lead to the same conclusion: the RBAC model may look like a practical access management method, but it is not. There are so many complications that have to be managed, that it’s hard to be in control.

Done with complaining. What are we going to do about it?

In part 2 in this series we start migrating from roles to attributes, my holy grail and I’ll introduce a hybrid ABAC model.

(this blog first appeared in Dutch at https://www.cqure.nl/kennisplatform/van-rbac-naar-abac-deel-1)

European Identity & Cloud Conference 2016

This year  I managed to plan my trip to the European Identity & Cloud Conference 2016 in Munich, again hosted by KuppingerCole. I have visited this event before (had a talk about some ABAC developments), This time I'm just a conference consumer. But I will try to post some news now and then. For real-time notifications, follow my Twitter account @meneer, but you get a lot more information by following the conference hashtag, that should be #EIC16 :)

Hot topics: #blockchain, #CIAM (Consumer Identity and Access Management), Privileged Account Management (#PAM), #Cloud and #Governance

You can find out about the program here.

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.

Using Passbook for Attribute Management

By now we know all there is to know about managing digital identities so the next level of access control is to further investigate managing (defining, granting and revoking) authorizations. And the ideas about granting access to resources, based on certain (user owned) attributes are gaining ground. In the future I will get access to documents, files, databases and locations based on attributes, more than because of who I am (one of my many identities).

A while back I wrote some posts ("I need a Pall or Pass" and "Attribute management") about managing attributes and about the lack of information about this issue. And I found one interesting entity providing attributes: ISACA issues attributes in the form of OpenBadges, an open standard to manage whatever attributes in a digital wallet, like Mozilla Persona.

Only recently did I come across another digital wallet system, Passbook by Apple. According to Wikipedia "Passbook is an application in iOS that allows users to store coupons, boarding passes, event tickets, store cards, credit cards as well as debit cards via Apple Pay." That's interesting. I didn't know about Passbook, because I don't own or use any iThings, but someone crafted an app for the Sailfish OS on my Jolla smartphone. So, thank you :)

A little about the purpose of Passbook: it is there to manage coupons, tickets and all. And those items are valuable items, they have to be protected. So inherently passes are secured to a certain level and Passbook must facilitate that. These items give access to certain features that were defined by the coupon or ticket provider, these permissions were defined by the owner of the resource that the ticket holder wants to have access to.

This look a lot like the owner's responsibilities that we see in regular IAM environments. Someone, an owner of a resource, a file, a database, a room, defines access rules and decides what identities can have access. Yes, not unlike any theater ticket. And yes, I did write that I need a Personal Attribute Storage System, a Pass. It could well be a Passbook...

Can we use some app like Passbook for attribute management. Yes of course, by all means. But I am curious to know if Apple created an open standard to make it feasible to use the platform elsewhere too.

AD is EOL

Recently I had this discussion, about managing identities in a company and what strategy to follow towards future developments like Attribute Based Access Control. A very interesting discussion, because this company was quite big and employs several tens of thousands of personnel. And only a few thousand of those have a Windows account. These people need an account because they have an email address and need access to folders and shares. The others don't have a Windows account, because they don't use any information systems.

AD is a silly tool: it's a user directory, a domain controller, an authentication service, an authorization server, a federation server. Too big too fail, but no focus.

During the discussion the IT manager of the company stated thet he wants every employee to get an Active Directory account, because he feels that in the near future everyone need to access some information resources on a Windows server or Sharepoint. Everyone needs an AD account (no, licensing costs is not yet a problem, as long as they don't use the account actively).

In my opinion this is not the right strategy. In the near future we don't access data on Windows of Sharepoint servers anymore. We will use web services on web servers that we access with a digital identity that can come from any (trusted) source. Active Directory will become Passive Directory.

It already happened: my company doesn't even have an AD anymore. I think it will be end-of-life before it's end-of-support...



Yes, I know, I must be wrong, everyone is expanding AD and so growing their legacy base. And we all move to Azure AD. But just think about this mind experiment...

OpenBadge Based Access Control

A while ago I posted a few entries about using attributes instead of roles to grant access to resources. At the same time I wrote that the current way of providing attributes is limited. So far attributes are provided by identity providers, hence only parties that trust an identity provider know what attributes can be used and may decide to trust the attributes provided by the identity provider. But as I stated, there are many cases that you do not want to get an attribute from your identity provider. You may have passed an exam, received a compliment or endorsement, or you may be part of another community than the one you work for and the one who provides your (digital) identity. Your digital identity provider may not even know all these attributes. And rightly so, an identity provider needs to provide trustworthy (within the trust framework) identities.

So I came up with the idea to make it possible to receive and collect attributes, much in the same way that we are used to receive and collect badges for gaming, or scouting...?.

And I showed that such a mechanism is in use at this very moment, although not yet in the way that I want: Isaca provides digital badges to certified members. And you can collect these badges in a digital wallet, that you can also use to present youor badges.

It's a pity that there is no use other for these Isaca attributes yet. I would like to use my CISA and CISM badges to be elegible as a candidate for a security consultancy project with prospective customers. How easy it would be to just so show my Isaca badge, instead of writing a resume or pointing to my LinkedIn profile. If you need an IT Auditor, here's my Isaca CISA badge... Or if you need a CISM, just search LinkedIn for CISM badges...


Today I learned that there is a another organisation contemplating to provide badges. LibreOffice volunteers may get badges in the OpenBadge format, the same format that Isaca is using. This wil most certainly mean that we will see OpenBadge become a default adopted open standard.

We probably have to come up with use cases for access control based on OpenBadges. Currently these badges are just that, they just show that you are member of a community, but there are no permissions connected to badges. Yet...

"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.

I need a PAL or a PASS

There are two IAM concepts that I really like:

• Identity 2.0, where I can login to a service provider using an identity that was provided to me by an identity provider, who proofs that it is really me.
• Attribute Based Access Control (link to the NIST ABAC standard): you get authorizations not based on your identity, but on your capabilities that some authority feels you have.

The first development makes it possible to separate responsibilities for objects on the internet. A service provider only needs to take care of services and data, an Identity Provider (IdP) only has to take care of digital identities and authenticating it's users. A service provider only needs to trust the digital identities provided by an Identity Provider, and that creates an enormous scalability of web services.

Attribute Based Access Control enables the authorizing of persons as requested by a process owner or data owner. This owner has to define the quality requirements for executing tasks within a process of towards a data element. The process owner or data owner doesn't need to have any knowledge about the identities or roles or groups that are defined within an organization. But this is a new concept and a very tough responsibility: these owners never before had to think about these requirements. Nevertheless, this is an exciting concept: someone doesn't get permissions because of his function or role within an organization, but because of his capabilities. And these capabilities are called 'attributes' of the identity.

The interesting thought is that an identity provider also provides some attributes. Such as address, phone number, gender, date of birth, expiration date and a lot of other variables. The IdP concept of ABAC is implemented in the SAML message format, where the term Claim component is used as the attribute component.

One of these attributes could well be the Role of an identity. An internal identity provider in an organization may well know the function type or role of an employee, who gets a business identity. In such a case an attribute can be used to allow Role Based Access Control capabilities to the access control mechanism.

But... what if a process owner requires an attribute outside of the scope of the identity provider? Where does the extra attribute come from? In the ABAC concepts attributes are bound to identities, that means that in order for an employee to prove that he has the extra required attribute, he in fact needs to provide another identity that does contain the required attribute. But... in all reality, that's just not feasible. What might be possible is that the identity provider forwards the attributes provided to an identity on behalf of another identity provider. For instance: an internal IdP could add attributes, like results from a course that the user attended. But that creates new trust issues (did the user follow the course successfully, is the attribute really provided by the school, in what context can the attribute be used and some more).

I am not aware of any implementation. And perhaps we should not want such an implementation and we should think of another way.

As a user I would not like this hassle of using different identities or of 'IdP-in-the-Middle' constructs. I want a convenient place to store my attributes, some kind of a wallet. Not a wallet with different identities (although I really loved the Information Cardmetaphor promoted by Kim Cameron), but a wallet with different attributes. And the attributes within this store could be used with any of my identities that I want to use for a specific purpose.

I need a PAL, a Personal Attribute Locker, or a PASS, a Personal Attribute Storage System (I'm great with acronyms :) ). Identity Providers could post digital identities and/or attributes to my locker and I could mix and match whatever combinations of identities and attributes I would want to use. Provided that the context and scope of identity and attribute is a valid combination, but we'll have to think about this in another post. What would the implication be? Suppose I am an employee who needs access to the CRM system. But in order to execute some CRM task, I would have to provide an attribute that I am an experienced blog poster. This attribute cannot be provided by the company I work for, but it can be provided by Google because of this blog. Google could post this attribute to my PAL and I could use this 'external' attribute with my company Identity to execute the CRM task.

What do you think? Is this a feasible idea?

In a future post I will expand on this idea, because recently I found out about an interesting standard that could perhaps be used as the mechanism that I want...