[cgiapp] app authorization patterns, best practices?

[B. Estrade]

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