The thing I often find confusing about security is the different concepts of security.
Sometimes I feel this strange desire to add security information to the data layer - my thoughts go along the lines of "this information should only be seen by X, so I should only return it from the database if X is the user." Besides... filesystems sort of work like this don't they?
Then I think about a real world example, like a forum. In a forum there are many different "security concepts" (I know I'm butchering this term, there's likely an agreed upon term and model I don't know about) at work. There are some things you can see but not change (other people's posts), other things you can know about but not see (private forums), and yet other things you don't know about entirely (hidden forums). Then there are the more complicated concepts like "tamper-evident" systems, for example when I edit a post that
already has a reply there's text appended to my post making the edit
evident. This type of security is certainly not possible at the data (model) layer.
The view, or presentation, layer is also a bad candidate for a couple of reasons: transformations (as amazing and flexible as some of them are) are not ideal places to evaluate security, and sometimes (ideally) we want the client to perform those transformations, which happens outside out control. Bad idea.
That leaves the controller, which is where I do most of my authentication. It has access to all the data, it exists in a flexible programming environment, and it's where all the business logic is (which likely determines who can see what).
If you're still dreaming about modeling your application security after filesystem security (I still do from time to time) do some reading about Novell's 589 file and folder permission attributes - it's the coldest shower I've ever needed to take
As an aside, I've always found every different type of data required it's own security concept in order to be really secure. Not every piece of information in the world can just be "read-only" or "writable". Some need permissions like "can change colour" or "is visible on Tuesdays". To keep your code simple (and your sanity) try to design your security with that in mind. Often defining a default permission for each object and then merging roles and individual permissions (in that order) is a good plan. I think I already covered that in another thread though, so I won't abuse the deceased equine.
Cheers,
Kieran