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.
Geen opmerkingen:
Een reactie posten