I'm studying for CISSP certification and one of the video lectures I viewed (CBT Nuggets) really confused me. Here are some excerpts from the lecture:

"Role Based Access Control doesn't always use the role for the basis for how it's going to divide information and access the information"

"Now let's get into, I guess the easiest way to define it is the 'types of RBAC' that you might see out there. The first one is role based and that one is the one that's naturally the idea here because we're talking about role based access control. But what I'm also going to say is that there's also what's known as Task Based Access Control, also called RBAC. In other words, the way we're going to divide our groups or our containers is either going to be by role or by task.

Is it correct to consider Task Based Access Control as a type of RBAC? That doesn't seem right and other resources seem to discuss it as an entirely separate access control framework (e.g. http://books.google.com/books?id=qf_h9ixAx70C&lpg=PA61&dq=RBAC%20TBAC&pg=PA61#v=onepage&q=RBAC%20TBAC&f=false)

1 Answer 1


There are some non-canonical (or non-"standard") access control models (besides the well-known MAC, DAC, RBAC...), that are simply not well defined.
As in, anyone can define or redefine them as they want, as long as the model makes sense.

E.g. this post was the first time I heard that model called "Task based access control", though I use/employ/review it a lot. Strangely, that book you linked to was the second time, in a different meaning...

I will point out that in many/most cases that use the model you called TBAC, it is aggregated back up into roles.
That is, the access is granted based on a task, but the access check then compares this task to roles that contain that task, and users that are part of one of those roles.
In other words, tasks can be seen as "sub-roles" - or if its easier, roles become role-containers, and the tasks are the real roles...
See e.g. Microsoft's AzMan tool.

Clearly, this is a huge improvement on straight RBAC, since it gives you some granularity and dynamics to play with, but it's still a form of (extended) RBAC.
Btw, I've also seen this called "Hierarchical RBAC", so...

  • @Mikey, also note some of the quote - part of it is a logical way of partitioning roles. Do you do this by organizational "role" (title), or by technical tasks? This disconnect is what makes role management so tricky. There is usually not one correct answer...
    – AviD
    May 3, 2011 at 15:12
  • I was afraid you'd say that ;-) It makes since but I'm concerned that ambiguous areas like this will become troublesome during the exam since I won't have an essay field to explain why I chose the answer.
    – Mike B
    May 4, 2011 at 0:09
  • 1
    @Mikey sorry to say but (unless they changed it in the last few years) the CISSP exam is unlikely to require that level of analysis and role modeling, just to be familiar with the terms (and what they mean, what they're used for, etc). To be clear, until proven otherwise, I doubt that "Task Based AC" is going to be one of the terms, it will just be "RBAC".
    – AviD
    May 4, 2011 at 0:24
  • 1
    But getting past the test, these considerations - like most other issues - are a tradeoff. What makes sense in your context? What is more "natural" for the users / administrators? What type of application is it, and what is the org's culture? Who are the users - IT folk, or "business" types? And so on...
    – AviD
    May 4, 2011 at 0:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .