[cgiapp] cgiapp Digest, Vol 30, Issue 9
Nicholas Bamber
nicholas at periapt.co.uk
Sun Mar 28 09:47:48 EDT 2010
Mark,
Deepest apologies for not replying earlier.
As I see it what you are asking for stretches into the
authorization area. Cees Hek also wrote an
CGI::Application::Plugin::Authorization module. I suspect that you are
more familiar than I am with that module and that you can tell me why it
does not suit your needs. The second angle of your request seems to be
that the data obtained should be useable in the run modes. There is a
rt bug report (https://rt.cpan.org/Public/Bug/Display.html?id=31133)
that makes a very similar point. Beyond that I don't really have a good
feel as yet whether this would be a good idea.
I am increasingly approaching this from a slightly different angle.
First of all I am trying to get the test coverage of the module upto
100%. (Possibly by actually removing deprecated features rather than
writing test scripts). Secondly I would like to review the code
according to OWASP standards
(http://www.owasp.org/index.php/Top_10_2007). I suspect that a
systematic analysis will sadly reveal a few vulnerabilities and missing
functionality. I would really like to get that right before allowing the
scope to creep.
I would heartily recommend everyone to have a look at the OWASP
site (http://www.owasp.org). It is an open source charitable
organization dedicated to internet security. Shockingly hitherto it has
nothing about perl. So I have dived in at the deep end, started an OWASP
page on perl (http://www.owasp.org/index.php/Perl ) and I am trying to
see how much interest in security/OWASP I can generate in the perl
community on this subject. As far as I can see this can only be good for
perl as a whole.
Nicholas
On 05/03/2010 17:00, cgiapp-request at lists.openlib.org wrote:
> Send cgiapp mailing list submissions to
> cgiapp at lists.openlib.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openlib.org/mailman/listinfo/cgiapp
> or, via email, send a message with subject or body 'help' to
> cgiapp-request at lists.openlib.org
>
> You can reach the person managing the list at
> cgiapp-owner at lists.openlib.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cgiapp digest..."
>
>
> Today's Topics:
>
> 1. Re: Security, Authentication and Authorization for CGI::App
> (Mark Rajcok)
> 2. Re: Security, Authentication and Authorization for CGI::App
> (Mark Rajcok)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 5 Mar 2010 11:43:55 -0500
> From: Mark Rajcok<mrajcok at gmail.com>
> Subject: Re: [cgiapp] Security, Authentication and Authorization for
> CGI::App
> To: CGI Application<cgiapp at lists.openlib.org>
> Message-ID:
> <e4c0aee21003050843j3d23c36di8c5b6771d4a60988 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Nicholas,
>
> I would like to see CAP::Authentication be enhanced to have the ability to
> query additional database fields and make the data available to runmodes.
> These fields need not be related to authentication. For example, the
> ability to specify a user role/privilege field could then avoid the need to
> hit the database a second time for common authorization checks.
>
> In my current app, I have u_state and u_privileges fields. The DB is hit
> once for authen, and then a second time for authz. I've always wanted a way
> to avoid this. I'm thinking of something like this:
>
> DRIVER => [ 'DBI',
> DBH => $self->dbh,
> TABLE => 'user',
> CONSTRAINTS => {
> 'user.name' => '__CREDENTIAL_1__',
> 'MD5:user.password' => '__CREDENTIAL_2__'
> },
> EXTRA_DATA => [ 'u_state', 'u_privileges'] # store this data
> somewhere
> ],
>
> sub a_rm {
> my $self = shift;
> my $authz_data = $self->authen->extra_data; # returns a hash ref: {
> u_state => 'active', u_privileges =>7 }
>
> -- Mark R.
>
> On Thu, Mar 4, 2010 at 5:30 PM, Nicholas Bamber<nicholas at periapt.co.uk>wrote:
>
>
>> Brad,
>> If you have any feedback on
>> CGI::Application::Plugin::Authentication I would appreciate it.
>>
>> My priorities for it are (not in any order):
>> 1.) Getting it to run under taint mode
>> 2.) And making the HTML more configurable
>> 3.) Getting test coverage up.
>> 4.) Keeping test failures down
>> 5.) Working through the bugs in rt.
>>
>> I am also thinking about the big picture on authentication but I have
>> been working on the module for too shorter time to have any definite ideas.
>>
>>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 5 Mar 2010 11:53:37 -0500
> From: Mark Rajcok<mrajcok at gmail.com>
> Subject: Re: [cgiapp] Security, Authentication and Authorization for
> CGI::App
> To: CGI Application<cgiapp at lists.openlib.org>
> Message-ID:
> <e4c0aee21003050853n7394a8by93c127e9ed0d5843 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Mar 4, 2010 at 5:56 PM, Michael Peters<mpeters at plusthree.com>wrote:
>
>
>> On 03/04/2010 10:56 AM, Brad Van Sickle wrote:
>>
>>> 2) Runmode authorization is a little trickier, but still manageable. I
>>> check the user's session in prerun and if they are not authenticated,
>>> redirect to a "not authorized" runmode that redirects them back to the
>>> security app (login page) Any module that needs to set security on
>>> specific runmodes, inherits prerun and does "if" checks against the
>>> runmode/usertype to make sure they are authorized. Anyone trying to go
>>> somewhere they shouldn't is redirected to that same "not authorized"
>>> runmode.
>>>
>> I usually generalize this by putting my prerun checking in my base class
>> and each sub class tells the base class which run modes are restricted
>> to which roles. Sometimes I make this a method that child classes
>> override or sometimes I make it a parameter that's passed to new() in
>> either a startup script or a C::A::Dispatch table.
>>
>>
> Hi Brad, great discussion topic.
>
> I recently wrote an Authorization Plugin (it is on my todo list to get it up
> on CPAN) to handle "runmode authorization". It uses attribute handles to
> specify which runmodes require authorization:
>
> sub subclass_method_x :Authz(administrator) {
> # no authorization logic here
> ...
> }
> sub authz_administrator {
> # authorization logic here
> }
>
>
> The plugin adds a prerun hook such that before subclass_method_x is called,
> method authz_administrator() will now automatically get called ("authz_"
> gets prepended to the attribute handle data to form the authorization method
> name). I normally define authz_administrator() in the same (sub)class as
> subclass_method_x().
> If authz_administrator() determines the user is not authorized, the runmode
> is changed to authz_error() -- which I define in the base class, since I
> normally don't need custom authorization error messages. However, if a
> custom error is needed, the authz_error() method can be overridden in the
> subclass.
>
> I like this approach for a few reasons:
>
> 1. subclass_method_x() is clearly marked that it requires authorization, and
> which type of authorization. I prefer this over something like
> CAP::Authorization's authz_runmodes() concept. If I want to change how
> authorization works for a method, I simply modify the method signature (I
> don't have to scroll up to the setup() method and modify a call to
> authz_runmodes()).
>
> 2. subclass_method_x() doesn't have any authorization checking code --
> that's in another "authorization method", and multiple runmodes can call
> that same "authorization method" when the same authorization logic is needed
>
> 3. I don't have to preconfigure the authorization mechanism in a base class
> (which is the typical CAP::Authorization model). In fact, the base class
> doesn't have to know anything about authorization -- only the subclass where
> the authorization is needed has to know. So for instance, in my
> AdminUserManager subclass, there are authorization methods for checking
> different admin privileges. That's the only subclass that has this logic.
> If I need to change how admin authorization works, the runmodes and the
> authorization logic are all in the same file. I really like that. (But, I
> guess it depends on how you view authorization... if you view it as cutting
> across your application, then the base class might then be preferable.)
>
> 4. I can be more efficient and save the results of database queries
> performed in authz_administrator() for later use in subclass_method_x().
> This was one of the main reasons I decided to write an alternative to
> CAP::Authorization. With CAP::Authorization, database hits were being made
> to authorize, then I would make additional database hits in my runmode to
> obtain more information about the user. For example, in
> authz_administrator() I often grab the user's name out of the database at
> the same time I'm pulling out user role/privilege info. I create and save a
> User object for later use in the runmodes. (I just replied to Nicholas,
> where I requested a similar capability for CAP::Authentication -- then only
> one DB hit would be needed for Auth, Authz, and some other common user
> info.)
>
> As for data authorization (e.g., filtering select queries based on user
> roles), I don't have any good solutions. I dynamically add WHERE clauses
> (or dynamically modify the SQL statement appropriately) like you, or I
> filter the data after getting back query results.
>
> -- Mark R.
>
>
> ------------------------------
>
> _______________________________________________
> cgiapp mailing list
> cgiapp at lists.openlib.org
> http://lists.openlib.org/mailman/listinfo/cgiapp
>
>
> End of cgiapp Digest, Vol 30, Issue 9
> *************************************
>
>
--
*Nicholas Peter Bamber*
*Email:* nicholas at periapt.co.uk <mailto:nicholas at periapt.co.uk>
*Professional Profile
<http://www.linkedin.com/pub/nicholas-peter-bamber/13/998/aa2>
*
* *
*Periapt Technologies Ltd* <http://www.periapt.co.uk>
Want a signature like this? <http://www.linkedin.com/e/sig/47231258/>
More information about the cgiapp
mailing list