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.
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.
One of the common requests I see in the forum is how to implement RBAC. While you can implement Yii 2's built-in RBAC, that might be too much for developers who are just starting with Yii 2 or have simpler needs. Sometimes you are looking for a fast solution and just want two flavors, user and admin. And even if you will eventually need more, you can use these methods as a starting point for developing your own features or move on to Yii 2's RBAC.
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.