Re: [cgiapp] RFC - C:A:P:RMAuth

[Michael Graham <suppressed>]

Hi Steve,

I think it's great that you're tackling this one!

We had a discussion about this about a month ago.  It was hidden under
the CGI::Application::Framework announcement.  I think the discussion of
permissions started around here:

    http://www.mail-archive.com/suppressed/msg03540.html

I've included some of the bits from that discussion in my comments
below.


>     * List possibilities to do authorization/login and to limit runmode
>       access to specific users. And how to dynamically build
>       menu/navigation so that a particular user only sees what he's
>       allowed to do.
>
> Well, the first part isn't always easy, so I skipped it. Plus I think
> Michael Graham & Richard Dice have spent way more time contemplating it
> then I would have. The second part however, "Limit runmode access to
> specific users and dynamically build menu/navigation, etc, etc" I found
> particularly interesting because I've done it, rather easily.

Splitting authorization and authentication into two separate modules
does seem like a good idea to me.  For one thing, it would allow people
to use plain HTTP Basic Authentication (e.g. .htaccess files) but still
use a cgiapp based authorization scheme (e.g. by telling the
authorization module to use $ENV{'REMOTE_USER'} for the username).

Besides, all the cool kids are doing it.

However, if we are going to split the two, then we should probably name
the modules appropriately:

    CAP::Authentication (or Authent or Authen?)
    CAP::Authorization  (or Authz?)

On the Authz side (which is what you're doing), we had previously talked
about doing role-based authorization, e.g:

    $self->require_authorization({
       mode1 => 'admin',
       mode2 => ['admin', 'manager'],
    });

Looking at your RMAuth plugin, I'm not exactly sure how you're handling
mapping users to permissions.  The sample xml file is just for a
specific user, right?

You may be interested in the unfinished CAP::Auth module (by Cees Hek
with help from Jason Yates) which implements role-based authorization. 
It's referenced here:

    http://www.mail-archive.com/suppressed/msg02928.html

(CAP::Auth does both Authen and Authz, but you'd only be interested in
the Authz part.)

We also discussed different ways of specifying the authz requirements,
including using attributes to tie roles to specific run modes:

    sub my_runmode : RequireAuth('manager') {
        ...
    }

Note though that even in this situation, you still need some
configuration data that tells you what users have the role 'managers'.

Finally, I believe that there should be hooks available to the app
writer so that they can customize the authorization rules for a
particular situation.  For instance, the Authz plugin's default
$self->check_permissions() method might look something like this:

    sub check_permissions {
        my $self  = shift;
        my $user  = $self->get_current_user;
        my @roles = $self->get_runmode_roles;

        return $self->user_has_roles($user, @roles);
    }

But it would be useful if the app could override that somehow, e.g.

    sub check_permissions {
        my $self  = shift;
        my $user  = $self->get_current_user;
        return $user->is_the_boss;
    }


Michael


-----------------------------------------------------------------------
Michael Graham <suppressed>

YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - suppressed
-----------------------------------------------------------------------



---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed