Authentication and Authorization is a good tutorial. Among other topics, it describes basic aspects of Yii's RBAC implementation. But however hard I read the tutorial, I couldn't understand how exactly the hierarchy works. I found how to define authorization hierarchy, how business rules are evaluated, how to configure authManager, but almost nothing about how I should build my hierarchy, in what sequence its nodes are checked, when the checking process stops and what would be the checking result.
I assume you are familiar with accessControl standard filter. It allows you to separate privileges to run some action from action code itself. There is however one problem with most common usage - you cannot use bizRules, at least based on some parameters passed to 'checkAccess' just because it is hard to pass them in accessRules() result.
In this wiki, I try to implement a simple authorization schema without putting much logic inside a file
or into database table. We are constructing authorization hierarchy inside the controller. We are getting
roles for the current user from database table and assigning only roles to user that are declared in the
particular controller. We have brought down the work of loading of auth data at main
application level to controller level. This way we have pulverised auth data for entire site into smaller
units. Finally we are going to look at couple of examples.
This article shows a quick and easy way to implement flat user access control system. Flat means, that user access is controlled by level only, which is solution exactly opposite to complex RBAC access systems.
This HowTo assumes that you have a smattering of ACL in general and of how the acl-extension works basically. It will introduce you into the abstract and give you a hint on how to use Business-Rules. If you have in-depth questions, please refer to the extension documentation.
Using ACL in an RBAC-manner cannot and should never obscure the fact that the underlying system is still ACL-based. In fact, the Business-Rules are just another layer in the permission-check plan.