Parts 3 and 4 of the blog series from RBAC to ABAC

This year I joined the new Dutch subsidiary of Nixu Oyj, the Finnish cybersecurity company, as a security and IAM consultant. Nixu employs over 50 IAM consultants, so it feels like a great place to have conversations about digital identity, access control and to share knowledge. What better place to post my blogs?

Parts 3 and 4 of my blog series about migrating from RBAC to ABAC have been published at the nixu site:

Part 3 About the need for dynamic access rules

Part 4 Using roles as attributes

Enjoy these reads and feel free to contribute to the discussions!

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)

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

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.

RBAC limitations in SOA

For a few years we have been working within a SOA environment and we implemented some form of the RBAC security paradigm. But since a few iterations of our SOA we feel that we arrive at the limits of RBAC. RBAC is fine within a single security domain, like an application, but as soon as you cross your security borders, like you will do in a SOA, you run against problems.

Some RBAC limitations in SOA

• In RBAC you still have to manage every user account and bind these accounts to roles. Unknown accounts can only be linked to a default role, like guest or customer. But users coming in through the Internet channel are not only guests or customers, but they can also be employees, partners, external service providers, you name it. There may be plenty accounts you don't want to manage, because they don’t belong to your security domain. Unless you manage different portals for different roles and have some form of identity management within the portal environment in place, RBAC is of no use.
  Federation could be a solution, but that only limits interaction possibilities to trusted partners you federate with. Besides, most federeation solutions use shadow accounts within the security domains, thereby creating a new identity management problem because all duiplication. Silly, but if you want RBAC, you pay for it…


• RBAC has a problem with the concept of context. If someone has a role, then he will get the permissions associated with that role. Automatically. There is no restriction in place based on the concept of context. A context could be the channel used (internet, lan), time of day, legal entity etc. An account using a wireless home PC might not deserve the same permissions as the same account in an office using a centrally managed workplace. But such a concept does not exist in RBAC terms (unless you define lots of extra roles). RBAC must always be complemented with a rule-based access control function.


• Another big objection (but that is not specifically SOA) is that there is no possibility for user profiling. Meaning authorisation based on the skills of an employees instead of the single fact that the user is connected to a role. RBAC doesn’t know the difference between junior or senior employees within the same role. Unless you define separate roles. And creating duplicate roles is not why you implement RBAC.


• Another problem (also not specifically SOA): role mining. Have you ever tried mining roles? How many roles have you identified? How many unique roles are absolutely necessary? Often mining is an useless excercise. But without mining roles it is hardly possible to define the necessary authorizations. Or is the role the object that you want to manage?

There are more issues, probably, but for us this was sufficient to declare RBAC ‘Old School’. We will continue to apply RBAC for some specific uses, but we will not implement RBAC as a dogma and certainly not within our SOA. We are studying new authorization paradigms, probably using the SAML Claims mechanism.
Identity management will be replaced by identity Provisioning and identity management will no longer be core business for most organizations. Access Control will stay core business, but no longer based on the user part and will also no longer be based on roles.