I agree, but you can create your own abstract interface as a replacement and go from there. If you find yourself in a position where you need to support all of the NIST (http://csrc.nist.gov/groups/SNS/rbac/) flavors of RBAC from the simpler solutions to the more complex solutions with extremely fine-grained hierarchial control, you have no choice.
That’s my question as well.
IMO, none of it should be in core.
All user auth/management extensions worth their salt is kept up-to-date, so that’s not an issue.
I prefer flexibility.
However, if any of you have some adjustments/fixes to the current system, please forward them here.
I would not call it bad. NIST loosely defines the features in RBAC and sort of categorizes the various possible implementations based on RBAC solution complexity. The existing interface probably needs to be handled in a manner similar renderers with the ability to add abstract classes for lighter to heavier implementations.
I didn’t understand a word of what you wrote, mmx - care to be precise? 
Just my two cents, this is the first time I am reading this thread.
I have applications that require user management. Some are very simple requirements, login and update a page, logout. But other apps have so much overlap with user roles I don’t see how the current offerings could provide a more flexible approach.
I think we must keep in mind that Yii is framework, not an application. In it’s current form Yii is extremely flexible and configurable. Some of the user/auth extensions are better than others, if we don’t like any of the offerings we can write our own. In my case I have hacked existing extensions until they work just the way I want them to.
That said the Yii team constantly impresses me with innovation and often provides solutions for problems I didn’t know I had!
To sum up if it ain’t broke … you know the rest.
I don’t think this feature is broken or lacking at all!
doodle
What I am missing is a "superuser" functionality, many rights (auth) modules implement this, so you can have a user, which always passes checkAccess()-calls, not only for debug mode as mentioned above.
Hardcoded superusers have downside - if application gets compromised, it is known for what to target.
Besides - it’s really easy to make a role with all the rights and assign that to a user. Well, I see most of the people go for Yii-Rights extension - and although it looks nice, it’s crap at handling massive assignment or go through tens and hundreds of tasks and actions. I stick with SRBAC and creating a superrole and assignin it to a user is like 4 or 5 clicks. So from my experience it’s an imaginary issue, just picked the wrong instrument
What’s wrong with the concept of “root”?
The problem in my case is more about interoperability of extensions.
E.g. I have an extension (behavior) which implements checkAccess() on a per-record basis, if something gets messed up I just want to be able to have a user which can access all records, without adding broken rules to my auth-db.