Hi Nicholas, No need to apologize, I only visit this list a few times a month (but not for lack of interest).
I'm not looking for CAP::Authorization functionality to be added to CAP::Authen, I just used that as an example. I would "simply" like CAP::Authen to have the ability to pull additional fields/data from the DB when it is checking credentials. (The bug report you reference does not appear to be related.) I like your approach of getting test coverage up first, then tackling new features. I stumbled upon OWASP sometime in the past year (when looking at CSRF), and was also disappointed to see the lack of Perl presence. Thank you for stepping up. -- Mark R. On Sun, Mar 28, 2010 at 9:47 AM, Nicholas Bamber <[email protected]>wrote: > 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, [email protected] wrote: > > Send cgiapp mailing list submissions to > > [email protected] > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.erlbaum.net/mailman/listinfo/cgiapp > > or, via email, send a message with subject or body 'help' to > > [email protected] > > > > You can reach the person managing the list at > > [email protected] > > > > 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<[email protected]> > > Subject: Re: [cgiapp] Security, Authentication and Authorization for > > CGI::App > > To: CGI Application<[email protected]> > > Message-ID: > > <[email protected]> > > 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<[email protected] > >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<[email protected]> > > Subject: Re: [cgiapp] Security, Authentication and Authorization for > > CGI::App > > To: CGI Application<[email protected]> > > Message-ID: > > <[email protected]> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Thu, Mar 4, 2010 at 5:56 PM, Michael Peters<[email protected] > >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 > > [email protected] > > http://www.erlbaum.net/mailman/listinfo/cgiapp > > > > > > End of cgiapp Digest, Vol 30, Issue 9 > > ************************************* > > > > > > -- > *Nicholas Peter Bamber* > > > > *Email:* [email protected] <mailto:[email protected]> > *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/> > > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > > ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
