[cgiapp] Security, Authentication and Authorization for CGI::App

[Nicholas Bamber]

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.

> Today's Topics:
>
>     1. Security, Authentication and Authorization for CGI::App
>        (Brad Van Sickle)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 04 Mar 2010 10:56:17 -0500
> From: Brad Van Sickle<bvansickle3 at gmail.com>
> Subject: [cgiapp] Security, Authentication and Authorization for
> 	CGI::App
> To: CGI Application<cgiapp at lists.openlib.org>
> Message-ID:<4B8FD821.5050706 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I'd like to get the list's opinion on some security practices for
> CGI::Application.
>
> In a lot of my applications I'm noticing that I need to "secure" things
> at many different levels and this is resulting in me having a security
> infrastructure that is very spread out and hard to manage/change.
>
> Specifically, I need to be aware of the following things when
> implementing security:
> 1) Authentication - figuring out who the user is and if they have access
> to app at all
> 2) Runmode Authorization - figuring out of the user has access to
> perform the specific function they are requesting
> 3) Data authorization.  - In quite a few apps I'm noticing the need to
> allow multiple users or user types to have access to the same runmode,
> but I need to show them a specific set of information based on who they
> are.  Example, I may have a end user role tied to an organization and a
> management user role, who has permission to see and manage data for a
> group of those organizations so I need to adjust the data output
> accordingly.
>
> The way I handle that today is:
> 1) Authentication is pretty simple, I have a "Security" application that
> provides the login form, processes the login, hands out the session and
> then redirects the user to the actual app.
> 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.
> 3) Data authorization is the part I'm least happy with.  I often find
> myself pulling keys (groupID, organizationID, etc..) out of the user
> profile, doing an "if" check on user type, and then dynamically setting
> WHERE clauses on my DB queries according to what user type I'm dealing
> with and what information they are allowed to see.  It's cumbersome and
> hard to manage.
>
> My problems with my current approach:
> 1) This seems to work ok.
> 2) My authorization scheme works, but doing things like adding new user
> roles, changing permissions, etc... can get messy and I feel there is
> probably a better way.  I'd love to be able to "ask" my security
> application who this person is and if they are allowed where they want
> to go.  I think there are modules that do this to at least some extent,
> but I still have to keep that list somewhere and not sure just moving
> it's location makes things easier.
> 3) As I mentioned, my data authorization scheme is very hard to manage
> and I'd love to find a better way.  I just don't have any ideas about
> what that "better way" is.  Obviously it's easier to do some query
> alteration to display different data than to write entirely new
> applications or modules to cater to different user types/access levels,
> but when requirements change, new user types are added, etc... it can be
> a considerable amount of work to alter all the "if" checks on the
> queries accordingly.  This is also notoriously difficult to test for,
> because of the sheer volume of test cases.
>
> I apologize for the extreme length of this, but I wanted to give a good
> overview of what I'm doing today and see if any of the smarter, more
> experienced members of the list might be able to give me any suggestions
> about how to make my security more modular/portable and easier to manage.
>
> Thanks
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> cgiapp mailing list
> cgiapp at lists.openlib.org
> http://lists.openlib.org/mailman/listinfo/cgiapp
>
>
> End of cgiapp Digest, Vol 30, Issue 7
> *************************************
>
>
>