[cgiapp] app authorization patterns, best practices?
Jerry Kaidor
jerry at tr2.com
Wed Mar 28 12:26:14 EDT 2012
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/ ##
> ## ##
> ################################################################
>
More information about the cgiapp
mailing list