What I've done in the past for a highly scalable (across many teams of users) is employed a resource-requester model. Where you have a generic accessor wrapper that behaves like a transaction, but when you construct the transaction you pass in the userId.  Every resource record will reference a table of who is allowed to access it and with which access level. So the queried tables inside of the authTransaction will implicitly join across that permission table.

This approach is great because its hard to screw up. The interface simply won't let you request a resource without supplying who is requesting it. The downside is that its an extra join for every query.
Though I employed this technique with mongoDB and had no speed problems because I put the access list directly into each table.  :)

Apologies if this hard to follow, I'm sitting at a camp fire tapping on my phone.

On Apr 23, 2011 1:24 PM, "Michael Snoyman" <michael@snoyman.com> wrote:

So far for my uses, isAuthorized has been sufficient, together with
some simple helper functions applied as necessary. However, I'd be
happy to try to flesh out a more complete system. Can you point out
specific issues that you're running into that seem like they could be
solved better?

Michael

On Sat, Apr 23, 2011 at 1:47 PM, Max Cantor <mxcantor@gmail.com> wrote:

> We have what is becoming a rather large webapp using yesod/persistent but have been doing authoriz...