rbac confusion

I am a bit confused regarding the documentation of role based access control.

When using the filter "accessControl" in a controller we can specify accessRules with certain context parameters. The documentation reads: "roles: specifies which role that this rule matches." I think this should say "roles: specifies which authorization items (operations, tasks, roles) this rule matches", at least this is what the code seems to do. Maybe this context parameter should be renamed to "authItems" to prevent this confusion.

Or did I understand something wrong?

You are right that it actually can be any auth items. The reason we use the term 'role' in accessControl is that usually only roles will be assigned to users and it is also the common term used elsewhere.

When I specify accessRules in a controller I would usually not require a certain role but rather an operation, example:

A user has the role "admin". The role "admin" has the task "manageBlog". The task "manageBlog" has the operation "deletePost".

In the PostController I would then specify an accessRule for the delete action:

'role' => 'deletePost'.

When really using RBAC then there should be no situation where one would specify 'role' => 'admin'.

I think this should be mentioned in the documentation, currently it reads like you would always have to manually check by doing Yii::app()->user->checkAccess('deletePost').

Agreed with sluderitz. I was confused about it, too.

The manual could be a bit more clear about this.

Thanks for the suggestion. I updated the guide about this.

RBAC description in "The Definitive Guide to Yii"  is still confusing. My co-worker spent about 3 days to understand how RBAC should be used and finished with design of custom RBAC.

I think main confusing factors are:

  1. Code sample from "Defining Authorization Hierarchy" should be finished with $auth->save() and text description should say this authorization rules setup should be performed only once (to auth.php or to database).

  2. For database storage should be used framework\web\auth\schema.sql (there is note about it in the class reference, but no in the Guide).

  3. Should be a code sample of using RBAC operations in accessRules()



public function accessRules()


    {


        return array(


            array('deny',


                'actions'=>array('create', 'edit'),


                'roles'=>array('editPost'),


            ),


            array('allow',


                'actions'=>array('delete'),


                'roles'=>array('deletePost'),


            ),


            array('deny',


                'actions'=>array('delete'),


                'users'=>array('*'),


            ),


        );


    }


 

A reader should clearly understand that in accessRules() can be used operations/tasks names and not only role names.

And I still can not understand what is the difference between tasks and operations?

I now used RBAC for system we are developing now and it is really easy to use and flexible, but I think documentation now prevents Yii users from using RBAC.

Sorry for poor English. And great thanks to Yii developers for great framework.

Thank you for your nice suggestions on improving the RBAC documentation. Will do as you suggested.

Regarding the classification of role -> task -> operation, they are essentially the same thing, as you can see in the code they are of class CAuthItem. We name them differently mainly from user point of view.

  • Operations are only used by developers and they represent the finest level of permission.

  • Tasks are built on top of operations by developers. They represent the basic building units to be used by RBAC administrators.

  • Roles are built on top of tasks by administrators and may be assigned to users or user groups.

The above is a recommendation, not requirement. In general, administrators can only see tasks and roles, while developers only care about operations and tasks.

So, then, is it correct to assert that auth item type does in no way influence any logic in the framework code, that is, all these types are treated absolutely equally everywhere an auth item can be used?

Also, it is not clear from either the Guide or the Reference, how "additional data associated with the item" can be used after supplying it to createAuthItem().

I would also suggest to introduce some parameter that would represent a context of assigning a role to a user, e.g. an object that this role is assigned to this user for. Like this: user="John Doe", role="Moderator", object="this forum branch". As it is now (as far as I understood the docs), if I want to implement such an assignment, I have to write my own AuthManager. Or I can make all roles "default" and put some user-object checking into bizRules.