dinsdag 30 september 2008

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.

3 opmerkingen:

Frank zei

Much of what you mention hit me when I tried to figure out what realy implementing RBAC would mean.

"You still have to manage user accounts". Certainly, but that is not the problem that RBAC supposedly addresses. Hopefully, it will make things easier, but that has yet to be proven.

Being able to do something with RBAC in situations where you don't own the accounts, is a certainly an issue, but again not really tied to RBAC. Furthermore, it is not unsolvable. The issue here is access to the role(s) that a user has. As you already point out, SAML (or Cardspace if you like) are ways to address this.

Context is most definitely something that the RBAC standard is not too clear about. The "session" concept is probably closest to what you refer to as context. "Session" is only defined in terms of "an activated subset of roles".
Whether a session is a time-based thing, a channel-based thing, or some other kind of animal, is not specified. From an RBAC standard point of view, you could interpret this as: it's up to you. Unfortunately, this sort of freedom seems a guarantee for non-interoperable implementations.

RBAC-only or also rules (or something else)? Yes and yes, I think I should say. In the RBAC model, objects are protected from roles by two layers: operations and permissions to use operations. Ownership of objects seems to be factored out of this equation. I.e. the RBAC standard doesn't tell us how to deal with this. Take the following example: users on a PC get a role that allows them to read (=RBAC operation) files (=RBAC object). However, the intent is to limit this to files owned by the users. So the set of objects that you are allowed to read is more limited than can be specified with the operation. Even if the operation is more specific, say "Read owned files". There is still the issue that it is not the operation that determines this ownership.

Conclusion, in many cases you will need something in addition to RBAC. The difficulty is in finding a trade-off between creating a few additional roles or adding other mechanisms.

On role mining there is ample literature to support your claims. Indeed, this is a daunting task.

Because RBAC doesn't (seem to) deliver on its promise, many people step away for it and hope for the best with new initiatives. The mostly philosphical and somewhat sceptical remark that I would like to make on this one is: "nothing will do the trick". Different mechanisms tend to solve different ends of the problem space, so it highly depends on your particular problem whether something new will help you. The claims-based approach (OASIS-SAML, Cardspace) certainly seems promising, but .... These approaches concentrate on the transport of "things" (called Claims) that you can use to base your authorization decision on, or at the very extreme, delegation of those decisions. As such, these mechanisms are te be viewed as complementary to RBAC, rather than as a replacement. They don't solve the authorization problem.

The bottom-line is that RBAC is not a panacea, that it doesn't and cannot solve all our authorization problems, and that there a no alternatives besides "older" mechanisms.

André Koot zei

Thanks for the comment, good to see that most observations are shared. RBAC is often seen as the de facto standard solution, but without taking into account the limitations, especially in a SOA environment.

My observation about managing accounts is that you still have to have a managed account to bind to a role. If you don't know the account (which is the case in a SOA back-end system), you can't bind it to a role, unless you bind it to a default role. Identity management indeed is not an RBAC issue in itself.

The context part is made difficult in this situation:
two users beloning to two different legal entities have the same role. But user 1 cannot have access to objectes belonging to legel enity 2 and vice versa. Same role, different context, different authorizations.
'Roles' give authorizations, 'context' limits authorizations.
Your comment about object ownership adresses a kind of context as well. So we share this point of view :)

Frank zei

Another take on RBAC's "limitations" is the following. The purpose of RBAC is to avoid having to assign individual permissions to users. As such, ownership can only exist at the role-level. The implications of this are that RBAC can only be used in domains in which all users share the ownership of all RBAC-protected objects in that domain.

In domains where there is such a thing as group ownership of objects, some way has to be found to get around this. If the amount of groups is large and volatile, then trying to solve this with roles will not work.

I just had an E-mail exchange with Rick Kuhn (one of the authors of the RBAC standard) and he informed me that the CS1.1 RBAC implementation standards committee had just met and that one of the outcomes of that meeting was that they will be revising the standard. They expect this revision to take a couple of years because there is a lot of interest and many ideas for enhancements.