Handling authentication with Apache reverse proxy for plack/PSGI app

Question

This is my scenario:

So,

1. Requests via encrypted HTTPS go to Apache like: https://server1/MyPerlApp
2. If the user is not logged in, they get a redirect to some login page (in the server1), and Apache doesn't proxy the request to Server2
3. When the user logged in - IS authenticated - then Apache forwards all requests that are coming to https://server1/MyPerlApp to http://server2:5000

Question1: Is this possible? (Asking, because I don't know Apache enough deeply, and this is not an simple:

ProxyPass /MyPerlApp http://server2:5000/

because I need need authenticate the user at server1 and set ProxyPass Only if authenticated. Since Apache is quite flexible I assume the answer is yes for the above (but confirmation and details is very welcomed) - so here are my main specific questions:

• How will my Plack application know what user is authenticated at the Apache level (i.e. on the 1st server)?
• what is an easy way to deliver some of the user info to the perl app on the server2? e.g. with Apache's mod_rewrite what appends an user=username parameter to each query,
• can Apache can set some HTTP headers that my perl app should read?
• is there an easy and recommenced way?

I'm looking for how to avoid authentication routines in my starman/perl app, maily because:

• the user need to log into server1 anyway (for other tasks in his workflow)
• if he is already logged in, authentication in my app is not needed (avoid unnecessary double login)
• but I still need to know which users are logged in (via Apache at server1)

There is already similar questions, but:

• https://stackoverflow.com/q/12561830/734304 (no answer)
• https://stackoverflow.com/q/11907797/734304 (no answer)
• Apache reverse proxy with basic authentication (similar, but the backend is in the same server and same apache)

Answer 1

[I think you asked four questions here. Some of them overlap. I will try to answer as many as I can, then edit your question to make it a bit clearer. It might be helpful to post your current Apache httpd.conf so people can see how you are handling access and authentication currently. That way you might get better suggestions on how to integrate the proxied application(s) with your Apache instance.]

Setting up a front-end that can handle "Web Site Single Sign On" requires some planning and configuration but it is worth the effort. To make this easier, you'll want to use Apache-2.4. You probably are using this version, but Apache has become something of a workhorse, such that some sites update it much less frequently than in the past. Apache 2.4 includes mod_session and mod_auth_form which make it possible to set up form-based "web portal Single Sign On" sorts of tools with Apache for sites with multiple back-end application servers (often running on separate machine ports or sockets) combined under one outward facing set of URL/URIs. This pattern of use was so widespread with Apache that the 2.4 release added features to make it easier to do.

You asked about an "easy recommended" way to do what you have described. Well, you are on the right track. Apache's httpd is really useful for this kind of authentication/authorization and "user login" sort of application - so much so that it's become a staple tool for what you are trying to do.

You asked how to "deliver the user information" to the back-end server. You do that in the same way you handle state in any web application: with sessions and cookies. Session information contains key/value pairs encoded as an application/x-www-form-urlencodedstring. You can also create an HTTP_SESSION environment value that you back-end application can read from. Your Plack/Starman application has to be able to handle sessions and cookies (i.e. it has to be "session aware") if you want to use them there of course. Look at Plack::Middleware::Session for ideas on how to approach this.

For sure, setting up authentication with mod_auth_form is more complicated than Basic authentication. But with form based logins javascript can be used (judiciously), client applications can store form information locally for quick logins; as well, forms are flexible and can gather more data and pass more information to the user and some of the complexity (redirection after authentication) can be handled by Apache. Since they are just an HTML <form>, you can start simply and make them more elaborate as your site grows. That said you can have an Apache Reverse Proxy simply provide Basic Auth for your back-end.

Without seeing more details about your installation I can't say how/why you might need mod_rewrite per se, but Rewrite directives can play nicely with ProxyPass. Of course throughout your site you'd want to check for authentication and session information and redirect users to a login form where/when necessary. Using mod_auth_form makes this easier to implement at the cost of a somewhat more complicated configuration. As for the reverse prosy itself, you'd use ProxyPass in the normal way to pass requests to your back end:

ProxyPass /app http://[starmanhost]:3000/

Then you need configure or tweak your current Apache system to have Session On and require authentication for the URLs in question (unless the entire / requires authentication) in the standard Apache way:

<Location /app>
 AuthType Basic
 Session On
 SessionCookieName session path=/
 ...
 require valid-user
</Location>

etc. As the Apache docs point out (and you'll want to read mod_session, mod_proxy among others), you can pass session information around for use by back-end applications.

If the SessionHeader directive is used to define an HTTP request header, the session, encoded as a application/x-www-form-urlencoded string, will be made available to the application.

• From mod_session documentation Integrating Sessions with External Applications.

For privacy/security you'll want to use mod_session_crypto and SSL if that's possible. As you note you will not need encryption to be "end to end" (i.e. HTTPS from client to outward facing front-end and between the reverse proxy and back-end applications) but if outside connections are https:// and you keep session information on the server (using mod_session_dbd as another response noted) using encrypted storage, you can avoid obvious threats inherent in sharing user session information across servers. The best part of this is you can add these layers one by one without having to modify your back-end applications extensively. This is the advantage of creating a solid "WebSSO server" front-end to handle logins.

Note that I've been using the term WebSSO here a bit loosely. Strictly speaking, WebSSO (and SSO) are much broader and more encompassing concepts with their own standards tracks and technologies (there are a couple Apache projects focused on this). This is why I tend to call the approach you are trying "Web Site SSO". Support for a wide range of authentication, programming language modules, proxying, and rewriting makes Apache's httpd the "swiss army knife/duct tape" of choice for handling logins and sessions in this way.

Your rational for doing this is sound, since you can avoid extra logins and confusing users (and their browsers). As well, by decoupling the authentication steps from your application and dedicating that task to Apache, you make it easier for developers to write back-end applications. Your question is very general though. I think you can start to try out some of the suggestions that begin to appear here and if you run into problems you can follow up with more specific questions focused on your implementation.

Get the Apache bits working correctly first (Session On; ProxyPass, <Location /app>) and make sure the right information is getting created, stored and passed on by the front-end. This will be very useful for lots of things going forward. Apache gurus can help here. Once you have the proper session information being passed to your back-end you can ask questions about how to access and use it in in your perl code with starman and plack. There may be missing or rough bits in tools and documentation but lots of sites want to do what you have described so these things will appear and continue to improve. Good luck.

References

• A Gentle Introduction to Plack Sessions
• Deploy Catalyst Applications with Starman and Apache
• Using Apache mod_auth_form
• Authentication in Apache2.4 using mod_auth_form and mod_dbd
• Reverse proxying behind Apache

Answer 2

Apache's mod_session looks to be the component you are missing. Since the proxy is the gateway to the applications in the back-end, it can handle the authentication on the HTTP layer and pass back sessions as needed to the Perl script using the proxy entry.
Exposing the user information to the Perl application can happen in a few ways.

mod_session_dbd - is a module to store session information in a database. This could then be shared with the back-end server hosting the Perl application.

mod_session_cookie - is a module to store session information in a cookie on the browser of the client. Session variables would be stored in the cookie and the Perl application would retrieve them.

But, cookies or putting session variables in the URL open up security concerns. Cookies and headers can be modified.

mod_proxy should pass the session variables back to the applications in the form html.

http://httpd.apache.org/docs/trunk/mod/mod_session.html