[Dbix-class] AuthN/AuthZ at the ORM Level?

[Jeff Albert]

Hey Bill,
Thanks for the response! Practically speaking, this is a DBIx::Class questi=
on, although I thought I=92d start off by asking it at the application arch=
itecture level, and drill down from there into the DBIC specifics. I defini=
tely need to be as granular as =93user x has permission to do action y on o=
bject z=94; my initial thought was to override the existing DBIC methods (s=
earch, find, update, create, et al), but that feels awfully hack-y, especia=
lly when my application layer provides such rich authN/authZ tools already =
=96 so lately I=92m leaning fairly strongly toward, as you suggest, just en=
forcing that all access to the application will be through a web-service in=
terface which enforces all the rules in a manner that is functionally opaqu=
e to all clients =96 that way, cron jobs don=92t get any special considerat=
ion by loading the model classes directly, and as you say , then can be run=
 from anywhere. Your post has helped me confirm my decision to go that rout=
e, so it probably qualifies as insightful =96 thanks!

Cheers,
Jeff


From: Bill Moseley [mailto:moseley at hank.org]
Sent: Sunday, April 11, 2010 8:33 AM
To: DBIx::Class user and developer list
Subject: Re: [Dbix-class] AuthN/AuthZ at the ORM Level?


On Fri, Apr 9, 2010 at 10:08 AM, Jeff Albert <jralbert at uvic.ca<mailto:jralb=
ert at uvic.ca>> wrote:
So, like many folks, I=92m writing an application that relies on DBIx::Clas=
s as its ORM, which will be accessible through a web application but also f=
rom other clients (a command line client, for example). As a matter of best=
 practice, should I attempt to implement authentication and authorization i=
n DBIC, so that all my clients are automatically made to endure  authN/auth=
Z, no matter their implementation; or should I force all interaction with t=
he application to go through the web app (ie, command-line client just make=
s HTTP calls) and centralize my authN/authZ there?

Is this a DBIx::Class question or a more general application design questio=
n?

I'm not sure there's a "right" approach -- the layers of the app often get =
a bit fuzzy.   Depends a lot on the structure of the application -- i.e. do=
 you only care that someone is "logged in" or does every object in the mode=
l have an "owner" so that, say, every SQL query must be joined with a user-=
rights table?

I used to add much of the access control to the model.  That meant the mode=
l often had methods where I passed in a user.  So, from within a Catalyst a=
pp:

    $foo =3D $c->model( 'App::Foo' )->get_foo( $id, $current_actor );

And in one case an app was really user-centric so the User class had an exp=
losion of delegation methods:

   $foo =3D $current_actor->get_foo( $id );  # Get specified foo if use has=
 read access to $id

So, cron jobs would load up the model, get a user object and then do its wo=
rk.

(I also have used ACCEPT_CONTEXT as a way to provide the current use to the=
 model.)

More recently, though, I've been using more of a web-services type approach=
.  The model code is still very separate from web app (e.g. Catalyst), but =
it simplifies things a bit by demanding that all interaction with the appli=
cation is via the web.  The cron jobs don't have to run on a server where t=
he application is installed, there's an existing auth framework, there's co=
nsistent logging, standardized request and response format, etc.   Basicall=
y, scripts use the application's API to do all their work.


I appreciate any and all insight you can provide!
Well Jeff, I'm not sure how insightful my response is, but I suppose it loo=
ks more insightful than not receiving any response at all.



--
Bill Moseley
moseley at hank.org<mailto:moseley at hank.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100412/59d=
ca9e0/attachment.htm