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 ##### 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/ ## ## ## ################################################################
