Hi All,
I am about to release the first version of the Authentication plugin
onto CPAN, and have started work on the Authorization plugin. There
is no code yet, but here is my first attempt at the docs, which should
give an idea of how you can use this plugin. What I would like to
know is how everyone currently does authorization, so that I can make
sure the plugin is flexible enough to handle all edge cases.
This probably isn't the cleanest or clearest documentation ever, but
it is a first draft. Any suggestions on the interface, or the docs
are welcome.
Another thing that I am curious of is whether or not it is sane to
separate these two plugins, or if I should integrate Authorization
directly into the Authentication plugin. My reasons for keeping them
separate are not set in stone, so I would appreciate some positives
and negatives for doing it this way.
Cheers,
Cees
NAME
CGI::Application::Plugin::Authorization - Authorization framework
for CGI::Application
SYNOPSIS
use base qw(CGI::Application);
use CGI::Application::Plugin::Authentication;
use CGI::Application::Plugin::Authorization;
# default config for runmode authorization
__PACKAGE__->authz->config(
DRIVER => [ 'DBI',
DBH => $self->dbh,
TABLES => ['user', 'usergroup', 'group'],
JOIN_ON => 'user.id = usergroup.user_id AND
usergroup.group_id = group.id',
CONSTRAINTS => {
'user.name' => '__USERNAME__',
'group.name' => '__GROUP__',
}
],
);
# protect the following runmodes
__PACKAGE__->authz->runmodes(
qr/^admin_/ => 'admin',
'change_password' => [qw(user admin)],
);
# Using a second named configuration to distinguish it from
# the above configuration
__PACKAGE__->authz('dbaccess')->config(
DRIVER => [ 'DBI',
DBH => $self->dbh,
TABLES => ['user', 'access'],
JOIN_ON => 'user.id = access.user_id',
CONSTRAINTS => {
'user.name' => '__USERNAME__',
'access.table' => '__PARAM_1__',
'access.item_id' => '__PARAM_2__'
}
],
);
sub admin_runmode {
my $self = shift;
# The user should be logged in if we got here
# and they must be part of the admin group
# The checks for this are automatically done for you
my $username = $self->authen->username;
}
sub update_widget {
my $self = shift;
my $widget = $self->query->param('widget_id');
# Can this user edit this widget in the widgets table?
return $self->forbidden unless
$self->authz('dbaccess')->check(widgets => $widget);
# save changes to the widget
...
}
DESCRIPTION
CGI::Application::Plugin::Authorization adds the ability to
authorize users for specific tasks. Once a user has been
authenticated, you can control what that user has access to. It
imports two methods ("authz" and "authorization") into your
CGI::Application module. Both of these methods are interchangeable,
so you should choose one and use it consistently throughout your
code. Through the authz method you can call all the methods of the
CGI::Application::Plugin::Authorization plugin.
Names Configurations
There could be multiple ways that you may want to authorize actions
in different parts of your code. These differences may conflict with
each other. For example you may have runmode level authorization
that requires that the user belongs to a certain group. But
secondly, you may have row level database authorization that
requires that the username column of the table contains the name of
the current user. These configurations would conflict with each
other since they are authorizing using different information. To
solve this you can create multiple named configurations, by
specifying a unique name to the c<authz> method.
__PACKAGE__->authz('dbaccess')->config(
DRIVER => [ 'DBI', ... ],
);
# later
$self->authz('dbaccess')->check(widgets => $widget_id);
EXPORTED METHODS
authz -or- authorization
These methods are interchangeable and provided for users that either
prefer brevity, or clarity. Everything is controlled through this
method call, which will return a
CGI::Application::Plugin::Authorization object, or just the class
name if called as a class method. When using the plugin, you will
always first call $self->authz or __PACKAGE__->authz and then the
method you wish to invoke. You can create multiple named
authorization modules by providing a unique name to the call to
authz. This will allow you to handle different types of
authorization in your modules. For example, you could use the main
configuration to do runmode level authorization, and use a named
configuration to manage database row level authorization. For
example:
__PACKAGE__->authz->runmode_authz(
qr/^admin_/ => 'admin',
'change_password' => { or => [qw(user admin)] },
);
- or -
__PACKAGE__->authz('dbaccess')->config(
DRIVER => [ 'DBI', ... ],
);
METHODS
config
This method is used to configure the
CGI::Application::Plugin::Authorization module. It can be called as
an object method, or as a class method.
The following parameters are accepted:
DRIVER
Here you can choose which authorization module(s) you want to
use to perform the authorization. For simplicity, you can leave
off the CGI::Application::Plugin::Authorization::Driver:: part
when specifying the DRIVER parameter. If this module requires
extra parameters, you can pass an array reference that contains
as the first parameter the name of the module, and the required
parameters as the rest of the array. You can provide multiple
drivers which will be used, in order, to check the permissions
until a valid response is received.
DRIVER => [ 'DBI', dbh => $self->dbh ],
- or -
DRIVER => [
[ 'HTGroup', file => '.htgroup' ],
[ 'LDAP', binddn => '...', host => 'localhost', ... ]
],
FORBIDDEN_RUNMODE
Here you can specify a runmode that the user will be redirected
to if they fail the authorization checks.
FORBIDDEN_RUNMODE => 'forbidden'
FORBIDDEN_DESTINATION
If your forbidden page is external to this module, then you can
use this option to specify a URL that the user will be
redirected to when they fail the authorization checks. If both
FORBIDDEN_DESTINATION and FORBIDDEN_RUNMODE are specified, then
the latter will take precedence.
FORBIDDEN_DESTINATION => 'http://example.com/forbidden.html'
runmode_authz
With this method you can specify the authorization constraints for
the runmodes in our application. If a user tries to load one of
these runmodes, their username will be tested against the
authorization requirements, and these tests fail, the user will be
redirected to a 'forbidden' page. The runmode names can be simple
strings, regular expressions, or special directives that start with
a colon.
:all - All runmodes in this module will require authorization
# match all runmodes
__PACKAGE__->runmode_authz(':all' => 'admin');
# protect only runmodes that start with admin_
__PACKAGE__->protected_runmodes(qr/^admin_/ => 'admin');
# only protect runmodes one two and three
__PACKAGE__->protected_runmodes(
one => 'admin', # member of group 'admin'
two => ['admin, 'user'], # member of group
'admin' or 'user'
three => { -and => ['admin, 'user'] }, # member of group
'admin' and 'user'
);
instance
This method works the same way as 'new', except that it returns the
same Authorization object for the duration of the request. This
method should never be called directly, since the 'auth' method that
is imported into the CGI::Application module will take care of
creating the CGI::Application::Plugin::Authorization object when it
is required.
CGI::Application CALLBACKS
prerun_callback
This method is a CGI::Application prerun callback that will be
automatically registered for you if you are using CGI::Application
4.0 or greater. If you are using an older version of
CGI::Application you will have to create your own cgiapp_prerun
method and make sure you call this method from there.
sub cgiapp_prerun {
my $self = shift;
$self->CGI::Application::Plugin::Authorization::prerun_callback();
}
CGI::Application RUNMODES
authz_forbidden
This runmode is provided if you do not want to create your own
forbidden runmode. It will display a simple error page to the user.
authz_dummy_redirect
This runmode is provided for convenience when an external redirect
needs to be done. It just returns an empty string.
EXAMPLE
In a CGI::Application module:
package MyCGIApp;
use base qw(CGI::Application);
use CGI::Application::Plugin::AutoRunmode;
use CGI::Application::Plugin::Authentication;
use CGI::Application::Plugin::Authorization;
# Configure Authentication
MyCGIApp->authen->config(
DRIVER => 'Dummy',
);
MyCGIApp->authen->protected_runmodes(qr/^admin_/);
# Configure Authorization (manages runmode authorization)
MyCGIApp->authz->config(
DRIVER => [ 'DBI',
DBH => $self->dbh,
TABLES => ['user', 'usergroup', 'group'],
JOIN_ON => 'user.id = usergroup.user_id AND
usergroup.group_id = group.id',
CONSTRAINTS => {
'user.name' => '__USERNAME__',
'group.name' => '__GROUP__',
}
],
);
MyCGIApp->authz->runmode_authz(
qr/^admin_/ => 'admin',
);
# Configure second Authorization module using a named configuration
__PACKAGE__->authz('dbaccess')->config(
DRIVER => [ 'DBI',
DBH => $self->dbh,
TABLES => ['user', 'access'],
JOIN_ON => 'user.id = access.user_id',
CONSTRAINTS => {
'user.name' => '__USERNAME__',
'access.table' => '__PARAM_1__',
'access.item_id' => '__PARAM_2__'
}
],
);
sub start : Runmode {
my $self = shift;
}
sub admin_one : Runmode {
my $self = shift;
# The user will only get here if they are logged in and
# belong to the admin group
}
sub admin_widgets : Runmode {
my $self = shift;
# The user will only get here if they are logged in and
# belong to the admin group
# Can this user edit this widget in the widgets table?
my $widget_id = $self->query->param('widget_id');
return $self->forbidden unless
$self->authz('dbaccess')->check(widgets => $widget_id);
}
TODO
everything :)
BUGS
This is alpha software and as such, the features and interface are
subject to change. So please check the Changes file when upgrading.
SEE ALSO
CGI::Application::Plugin::Authentication, CGI::Application, perl(1)
AUTHOR
Cees Hek <[EMAIL PROTECTED]>
CREDITS
Thanks to SiteSuite (http://www.sitesuite.com.au) for funding the
development of this plugin and for releasing it to the world.
LICENCE AND COPYRIGHT
Copyright (c) 2005, SiteSuite. All rights reserved.
This module is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
DISCLAIMER OF WARRANTY
BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS
AND/OR OTHER PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR,
OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENCE,
BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR
THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER
SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
