Strictly speaking, I believe it's best the controller deal with a single model interface and all business logic, data access logic, etc be encapsulated by that interface.
If this is the case, then what do you use your controller for? In my experience, I've used the controller to kind of tie it all together. i.e. instantiate the mapper, call a find() from it which returns a domain object, send the domain object to the view, etc. So, the Data, Domain, and View are all separate from one another, and are all tied together with the controller. When you say "Thin controller," how thin are you talking about?
Consider the question: Where should my access control logic go?
In the controller or in the model?
Common knowledge would suggest that go in the model, and yet, in some instances it's equally well suited in the controller. I recently entered into a discussion about the subject of thin controllers heavy models and vis-versa but suffice to say, in my experience sometimes what is theorteically best is not always realistically best.
Maybe I'm misunderstanding the question--or perhaps I haven't encountered the more advanced access control you are referring to. But in a web app I just did, you have to log in to access any part of the site. I have a Singleton pattern that wraps my Session, and I have a static method to check the login. This is called in the Front Controller, and if it returns false, we're sent to the login.
This seemed logical, as at every page I want to check if I'm logged in or not. In this case, I'm calling the static function in the controller, but the actual logic is in the Session Singleton. Now that I think about it, that would probably be considered the model.
Would this be considered access control in the model?