Getting to Understand Hierarchical RBAC Scheme

Tutorials

hierarchy, RBAC, security, understanding

```

First of all I'd like to convert this to a more human-readable form:

<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://i55.tinypic.com/2yk0wzk.png.stack.imgur.com/VeAHh.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://i55.tinypic.com/2yk0wzk.png.stack.imgur.com/VeAHh.gif" /></a></td></tr> <tr><td class="tr-caption" style="text-align: center;">Sample blog system authorization hierarchy</td></tr> </tbody></table> The <span style="background-color: #9fc5e86ccffe;">turquoise</span> boxes represent roles, the <span style="background-color: #ffd966efc6e;">yellow</span> box is a task, and the most fine-grained level of the authorization hierarchy - operations - are <span style="background-color: #f9cb9cfd06f;">tan</span>. Collectively roles, tasks and operations are called <b>authorization items</b>. You should keep in mind that functionally all auth item types are equal. It's completely up to you to make some auth item a role or a task - still it would do the same thing. Different types of auth items are introduced solely for the purpose of naming convenience. You are not limited to the three authorization levels: there can be multiple levels of roles, tasks and operations. (Getting back to our diagram, you can see this point illustrated by multiple levels of roles.) Also you may skip any of these levels (the role <b>author</b> has immediate child operation <b>create</b>). The only restriction is that in the auth hierarchy roles should stay higher than tasks and tasks should stay higher than operations.

Now let's take a quick look at what was on blog system creator's mind. Everything seems to be quite logical. The weakest role is <b>reader</b>: the only thing he is allowed to do is to <b>read</b>. An <b>author</b> has a bit more power: he also can <b>create</b> posts and <b>update his own</b> posts. <b>Editors</b> can read posts and <b>update</b> (edit) <i>all</i> posts, not own ones (in fact, according to the hierarchy, editors can't create posts and that's why editors haven't got any <i>own posts</i> at all). And of course, the most powerful role is <b>admin</b> which can do anything.This leads to the two possible parameter passing strategies. The first one is to remember for every auth item what other auth items can be reached from it in the hierarchy and provide each call to <b>checkAccess</b> with the exact number of parameters. The advantage of this strategy is code brevity and probably efficiency. The other strategy is to always pass all parameters to every auth item, no matter if they would actually be used for business rule evaluation. This is a "fire-and-forget" method which can help to avoid much of trial and error while implementing you app's security. Its downside is possible code clutter and maybe drop in script performance.

This is only basic information about the RBAC authorization model in Yii; much more advanced security models can be built using it. Please refer to <a href="http://www.yiiframework.com/doc/guide/">The Definitive Guide to Yii</a> and <a href="http://www.yiiframework.com/doc/api/">Class Reference</a> for more details. Also there's a number of web interfaces implemented as <a href="http://www.yiiframework.com/extensions/?category=1">extensions</a> which can help you do the Yii RBAC administration.
 
 
Links
 
-----
 
Russian version: [Как разобраться в иерархической системе RBAC](http://phptime.ru/blog/yii/29.html)