[cgiapp] app authorization patterns, best practices?

B. Estrade estrabd at gmail.com
Tue Apr 24 14:22:03 EDT 2012


I am finally at the point where I am writing a driver, so I have a
stupid question.

Do I need to place this into the main module's parent directory in
order to have Authen/z use them?

Thanks,
Brett

On Wed, Mar 28, 2012 at 09:26:14AM -0700, Jerry Kaidor wrote:
> Hello,
> 
>    I just emailed you the source of the MULTI_DBI driver.  I do not
> pretend that this is the best way to do it, or even that it is very
> good;  I am far from expert at object oriented Perl, and sweated blood
> to get it to work at all.  And a month or two ago it stopped working
> suddenly, and I haven't had time to troubleshoot it.
> 
>    It authenticates against multiple "user" databases, all with the same
> format.  One is designated as "global", and the others are sub-business
> specific.   The driver authenticates by username and password, and
> records which database it authenticated against in the session->param
> structure.
> 
>                   - Jerry Kaidor
> 
> 
> 
> 
> 
> 
> 
> > On Fri, Mar 23, 2012 at 8:05 PM, Jerry Kaidor <jerry at tr2.com> wrote:
> >>
> >>> I have some questions regarding best practices when implementing
> >>> role based access control (RBAC). I have been playing with
> >>> CApp::Authentication and Authorization, and they both do basically
> >>> what I need.
> >>
> >> *** Me too.  I have three sub-businesses.  Let's call them A, B, C.  I
> >> want to have access to all of it, but I want my managers to only have
> >> access to
> >> their particular piece.
> >>
> >>    Here's more or less how I did it.  BTW, it recently broke for unknown
> >> reason, and I havent' gotten around to troubleshooting.
> >>
> >>   CApp:Authentication has a notion of "drivers".  I wrote a multi-DB
> >> driver that can look in a set of authentication databases.  I have a
> >> "users"
> >> mysql database at my global level, and another "users" database in each
> >> subbusiness.  When somebody attempts to log in, the multi-auth driver
> >> tries each database in turn.  If it successfully authenticates against
> >> the
> >> "global" database, that user has privs for all the sub-businesses.
> >>
> >>   Each line in the "users" database has a set of "permissions" flags,
> >> which correspond to things seeming to permission as I coded.  In line
> >> with the code are statements in the form if( getpriv( user, business
> >> )){}.  That way, I have a permissions system with much finer
> >> granularity than Capp::Authorization, which I do not use at all.
> >>
> >>                               - Jerry Kaidor ( jerry at tr2.com )
> >>
> >>
> >
> > Jerry,
> >
> > I didn't think about using the driver in this way - thank you for the
> > idea.
> >
> > Another thing I am looking at doing is setting up contexts. What this
> > does is that it allows the user to  assume a particular set of roles
> > given what they are doing if they are assigned mutually exclusive
> > roles globally. Basically, each context is a set of compatible roles
> > that are active at any given time. The user is permitted to switch
> > among contexts as they wish, activating and deactivating roles as
> > needed.  I know it's another level of complexity, but still part of
> > the RBAC thing - I'll look more at the drivers aspect. Thanks, again.
> >
> > Brett
> >
> >>
> >>
> >>
> >>>
> >>> Here's the skeleton I came up with -
> >>>
> >>>       https://gist.github.com/33d23edf8fa2c0f48dc0
> >>>
> >>> My question is really, what's the best way to go about separating
> >>> functionality in a CApp based application?
> >>>
> >>> A practical case I am looking at right now is that I have form that
> >>> is used to manage user data. There are 3 roles - User, Manager, and
> >>> Admin. Each one has the types of permissions you'd expect (User can
> >>> manage himself, Manager can manage his Users, Admin can do anything).
> >>>
> >>> I was thinking of the best way to build this form and control actions
> >>> cleanly and compose this form using 3 different runmodes that are
> >>> increasingly restrictive.
> >>>
> >>> For example, the User form calls the "user" runmode, and returns the
> >>> form content. The "manager" runmode takes the output of "user" and
> >>> adds some stuff to it. The "admin" runmode might take the result of
> >>> the "manager" runmode - which would also include what the "user"
> >>> runmode provides...and so on.
> >>>
> >>> Ultimately, my goal is to get away from nasty frog boiling "if" blocks
> >>> controlling authorization and rely on composable functions (i.e.,
> >>> runmodes or modules) that will cleanly give me what I would like using
> >>> the runmode level protection that CApp::Authorization provides you.
> >>>
> >>> I've searched around and banged my head against this pretty hard, so
> >>> any thoughts or resources would be appreciated. For all I know, this
> >>> might be a bad idea. But I am really just looking for the best way to
> >>> create an access controlled system as cleanly as possible.
> >>>
> >>> Thank you,
> >>> Brett
> >>>
> >>> ps: I noticed that even if POST_LOGIN_RUNMODE is protected via
> >>> CApp::Authentication, the check seems to be ignored immediately after
> >>> login. I am not sure if this is a known issue or that there are some
> >>> callbacks happening in the wrong order. This will happen in the gist I
> >>> linked above.
> >>>
> >>> #####  CGI::Application community mailing list  ################
> >>> ##                                                            ##
> >>> ##  To unsubscribe, or change your message delivery options,  ##
> >>> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> >>> ##                                                            ##
> >>> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> >>> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> >>> ##                                                            ##
> >>> ################################################################
> >>>
> >>
> >>
> >>
> >> #####  CGI::Application community mailing list  ################
> >> ##                                                            ##
> >> ##  To unsubscribe, or change your message delivery options,  ##
> >> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> >> ##                                                            ##
> >> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> >> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> >> ##                                                            ##
> >> ################################################################
> >>
> >
> > #####  CGI::Application community mailing list  ################
> > ##                                                            ##
> > ##  To unsubscribe, or change your message delivery options,  ##
> > ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> > ##                                                            ##
> > ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > ##                                                            ##
> > ################################################################
> >
> 
> 
> 
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
> 
> 


More information about the cgiapp mailing list