Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 3 down vote accepted

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

share|improve this answer
Ahhhh interesting. Thanks AviD! – Mike B May 3 '11 at 15:06
@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 '11 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 '11 at 0:09
@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 '11 at 0:24
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 '11 at 0:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.