Authentication handlers in a proxy setting

[Dan Axtell <da...@snet.net>]

Hi,

I wrote some mod_perl handlers for authentication and authorization, basically 
to set cookies and check user roles.  I use them for both static and dynamic 
content from Perl scripts.

I'm looking into splitting Apache into two servers, one optimized for static 
content and acting as a reverse proxy for the dynamic content Apache server.  
I understand that in the static httpd.conf, I can do things like:
        ProxyPass               /perl/ http://dynamic.server:8080/perl/
        ProxyPassReverse        /perl/ http://dynamic.server:8080/perl/
and in the dynamic server's httpd.conf, I can add ScriptAlias and Location 
directives to call my authentication handlers.

What I don't understand is what to do about static directories that want to 
use the handlers via Directory directive, or via a local .htdocs file.  Does 
any such directory need to be forwarded to the dynamic server in order to then 
call the handlers?

Thanks, 

Dan

Re: Authentication handlers in a proxy setting

[Fred Moyer <fr...@redhotpenguin.com>]

On Mon, Mar 29, 2010 at 4:24 AM, Dan Axtell <da...@snet.net> wrote:
> server on the back end.  It seems like a lot of overhead to have mod_perl on
> the front end purely for authentication; I might as well keep the monolithic
> configuration I have now.  Thanks for the input, though, it helps clarify
> things.

It depends on the size of your httpd processes with mod_perl enabled.
If you have handlers that don't load a lot of third party modules, you
can get away with 10-20 meg mod_perl httpds.  And a fair amount of
that memory will be shared.

Re: Authentication handlers in a proxy setting

[Dan Axtell <da...@snet.net>]

>
> It would be more logical to do the authentication on the front-end
> server. Then, if the back-end server needs the result of the
> authentication, you could add an appropriate HTTP header (with the
> user-id and maybe more stuff) to the request, before proxying it to the
> back-end.
> The idea is that (supposedly) the communication between the front-end
> and the back-end happens on a secure or private channel, so if the
> back-end gets this header, it knows it comes from the front-end.
> Getting the content of a request header is pretty light-weigth, so the
> work to do on the back-end for AAA could be minimal, since it can
> "believe" what the front-end tells it.
>
That makes sense, but the Apache documentation on server configuration 
suggests a very light-weight front end server with the heavy-weight perl 
server on the back end.  It seems like a lot of overhead to have mod_perl on 
the front end purely for authentication; I might as well keep the monolithic 
configuration I have now.  Thanks for the input, though, it helps clarify 
things.

Dan

Re: Authentication handlers in a proxy setting

[André Warnier <aw...@ice-sa.com>]

Dan Axtell wrote:
> Hi,
> 
> I wrote some mod_perl handlers for authentication and authorization, basically 
> to set cookies and check user roles.  I use them for both static and dynamic 
> content from Perl scripts.
> 
> I'm looking into splitting Apache into two servers, one optimized for static 
> content and acting as a reverse proxy for the dynamic content Apache server.  
> I understand that in the static httpd.conf, I can do things like:
>         ProxyPass               /perl/ http://dynamic.server:8080/perl/
>         ProxyPassReverse        /perl/ http://dynamic.server:8080/perl/
> and in the dynamic server's httpd.conf, I can add ScriptAlias and Location 
> directives to call my authentication handlers.
> 
> What I don't understand is what to do about static directories that want to 
> use the handlers via Directory directive, or via a local .htdocs file.  Does 
> any such directory need to be forwarded to the dynamic server in order to then 
> call the handlers?
> 
If I understand correctly, and if your front-end server does not have 
mod_perl, then I'm afraid that the answer would be yes.

It would be more logical to do the authentication on the front-end 
server. Then, if the back-end server needs the result of the 
authentication, you could add an appropriate HTTP header (with the 
user-id and maybe more stuff) to the request, before proxying it to the 
back-end.
The idea is that (supposedly) the communication between the front-end 
and the back-end happens on a secure or private channel, so if the 
back-end gets this header, it knows it comes from the front-end.
Getting the content of a request header is pretty light-weigth, so the 
work to do on the back-end for AAA could be minimal, since it can 
"believe" what the front-end tells it.

Now this all depends quite a bit on what you need to do to authenticate 
a user, how heavy it is, how you check that a user is already 
authenticated and so on.

I am using a variety of schemes which work more less that way, so if you 
have a more precise description of what you are trying to do, I may be 
able to give you some additional ideas.

Re: Authentication handlers in a proxy setting

[Dan Axtell <da...@snet.net>]

>
> To do access control for static files while still using your mod_perl
> auth handler, take a look at mod_auth_tkt or perlbal.
>
Thanks!

Re: Authentication handlers in a proxy setting

[Perrin Harkins <ph...@gmail.com>]

On Sun, Mar 28, 2010 at 3:41 PM, Dan Axtell <da...@snet.net> wrote:
> What I don't understand is what to do about static directories that want to
> use the handlers via Directory directive, or via a local .htdocs file.  Does
> any such directory need to be forwarded to the dynamic server in order to then
> call the handlers?

To do access control for static files while still using your mod_perl
auth handler, take a look at mod_auth_tkt or perlbal.

- Perrin