User Authentication

Ruby Apps Radiant CMS
1

Greetings all,

New to Radiant and the community, but my hope is that my co-worker and
I
can contribute a lot to the project in the years to come.

That being said, our first step is to develop a user extension for
Radiant. We need the ability to add users and group security to our
site
pages.

Has this been proposed, or worked on, yet? Are their any “hooks” in
the
code for doing this that we can leverage in making this extension?

If there is no pre-positioned ability for this we thought about
handling
this through the use of a tag perhaps and then utilizing the inheritance
of
Radiant to pass down the security in the sections required.

In closing, I just have to say that I love the simplicity and power of
how
Radiant is designed. It’s organization allows for a very flexible
system to
be developed.

Thanks for the hard work so far on this great project!

  - Mystic
2

Currently there is no ACL support in Radiant. This has been proposed
and
discussed in this list, search the archives.

I have been brainstorming about this lately and i have some ideas for
working in a “security extension” in the future. I have done some UML
diagrams and pen-on-paper mocks of a possible UI, but nothing tangible
yet.
Maybe in the next wave of energy+motivation…

/AITOR

3

I am planning on putting a few hours into playing with this today - I
will post my outcomes.

On Dec 21, 2007 1:47 AM, Aitor Garay-Romero [email protected] wrote:

Radiant is designed. It’s organization allows for a very flexible system
Site: http://lists.radiantcms.org/mailman/listinfo/radiant

Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant

–
Da Dukk, on the road again!
http://www.NWGamers.org - for a good time!
http://greg.nokes.name Ramblings from the Roost - For a Bad Time!

4

So, here is the jist of the brainstorm, with some almost code… what
do ya’ll think?

Radiant ACL proposal (very rough!)

Step #1 Deal with Caching

Inject a method into show_page to call the authentication system. We
need to know what page is being rendered so that we can pull group
information. I propose passing the page as to the show page module to
facilitate this. At first, I would suggest that this only applies to
the admin pages. It would be pretty easy to allow pluggable user
modules to overwrite the base one, and you could add granular rights
to any page.

In our environment, even with small teams, there are certain pages
that only the leadership portion of the team should be able to view.

def show_page(page)
if authenticator(page.find.groups(:all))
render_page
else
render_login_error_page
end
end

def render_page
response.headers.delete(‘Cache-Control’)
url = params[:url].to_s
if (request.get? || request.head?) and live? and
(@cache.response_cached?(url))
@cache.update_response(url, response, request)
@performed_render = true
else
show_uncached_page(url)
end
end

Step 2 - Validate Access

The authenticator would look something like this:

def authenticator(groups)
unless session[:id].nil?
user = User.find(session[:id])
effective_groups = user.find.groups & groups
for group in effective_groups
case group.rights
when 0 #denied access
redirect_to_login and return false
when 1 #read only
return true
when 2 #read and write
#some action to allow folks to edit
when 3 #read, write and grant
#some action to allow folks to edit, and add people to the ACL
end
else
if groups.include?(anon_group_id)
return true
else
return false
end
end
end

On Dec 21, 2007 7:37 AM, Greg [email protected] wrote:

diagrams and pen-on-paper mocks of a possible UI, but nothing tangible yet.

can contribute a lot to the project in the years to come.
of
- Mystic
Site: http://lists.radiantcms.org/mailman/listinfo/radiant

–
Da Dukk, on the road again!
http://www.NWGamers.org - for a good time!
http://greg.nokes.name Ramblings from the Roost - For a Bad Time!

–
Da Dukk, on the road again!
http://www.NWGamers.org - for a good time!
http://greg.nokes.name Ramblings from the Roost - For a Bad Time!

5

Hi everyone,

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:

http://httpd.apache.org/docs/1.3/howto/auth.html#intro

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 [1] 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.

E.g.

def user_has_role?(role, page)
current_user.send(“#{role}?”, page)
end

Also override #user_has_access_to_action? so that it include the page
param.

So then you just need to monkey-patch User so that messages like
“current_user.uber_admin?(page_doesnt_matter_because_im_uber)” or
“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 [2] 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… :wink:

-Andrew

[1] For more on RubyCAS, see:
http://rubyconf2007.confreaks.com/d3t2p1_security_and_identity.html
http://code.google.com/p/rubycas-server/
http://code.google.com/p/rubycas-client/

[2] writertopia