I don’t to sound pedantic here, but can we be sure to distinguish
between Authentication (auth), Authorization (authz), and Access
Control? See the intro of this section of the Apache manual:
Just to be clear, this looks to be a problem entirely of authorization
and not authentication or access control.
Take a look at Radiant’s login system in lib/login_system.rb: Auth is
provided by the before_filter #authenticate (which unfortunately also
authorizes to some extent), which calls #current_user. I’d recommend
using this method instead of calling User.find(session[:id]) manually.
This way your extension will work with other extensions that may
overload the authentication mechanism (e.g. I’m working on an
extension that uses RubyCAS-Client  to allow centralized
authentication over multiple applications – and I’m going to do this
by overriding #current_user).
Ok, so let’s consider an authz system: let’s say a user has roles.
Roles grant them permission. Roles can either be global
“Uber-administrator” or granular to a page “Editor of the lunch menu
web page”. Right now Radiant determines if the user is authorized
using the #user_has_role?(action). If you overrode this to call to
include a page parameter, it would probably do what you need.
def user_has_role?(role, page)
Also override #user_has_access_to_action? so that it include the page
So then you just need to monkey-patch User so that messages like
“current_user.lunch_menu_editor?(lunch_menu_page)” make sense.
I flirted with added an authz system to Radiant awhile back, and while
this project  seems to be dormant and permissions are in funky
little strings, the data model is solid and is what I’d recommend for
the storing users and roles.
Well, I hope this helps. Auth and authz can be tricky, so I wish you
the best of luck. I think the hardest part really, is putting
together a role admin interface that makes sense. That’s why I’m
leaving that as an exercise to you…
 For more on RubyCAS, see: