Apache as reverse proxy with authentication passed from back to front - apache

Question

We have an application runing on Weblogic 10.3, with authentication provided on the application itself. We want to put the Weblogic behind an Apache server. The idea is that we will have some public content on the Apache server, and the application will be accessed through the reverse proxy. That's pretty much very standard. The issue comes with the fact that there are some contents on the Apache server that can only be accesssed if the user has logged in the application. So basically the Apache server will server three type of contents, on diferent URIs:
/ -> Will contain the public information, and will be server by the Apache
/myApp - > Will be redirected by the Apache to the weblogic behind
/private - > Will contain the private static information. This should only be accessed if the user has previously logged successfully in myApp.
My question (I'm a total newbie with Apache) is if this possible. My idea is that the application can put a cookie on the responses indicating if the user has logged on the application, and that the Apache will check for that cookie when the user tries to access /private.
Any thoughts?

Answer 1

The / public information is no problem, it's straightforward. Using ProxyPass or ProxyPassMatch to reverse proxy "/myApp" to your internal Weblogic server is also straightforward. You may need to use a couple of other options to make sure proxy hostname and cookie domains are setup correctly. But setting up static protected infrormation in "/private" is going to be a little more tricky.
1) You can check the existence of the cookie set by myApp using mod_rewrite, something like this:
RewriteCond %{HTTP_COOKIE} !the_name_of_the_auth_cookie
RewriteRule ^private - [F,L]
The problem with checking a cookie through something like this is that there's no way to verify that the cookie is actually a valid session. People can arbitrarily create a cookie with that name and be able to access the data in /private.
2) You could set it up so that anything something in "/private" is accessed, the request is rewritten to a php script or something that can check the cookie to ensure that it's a valid session cookie, then serve the requested page. Something like:
RewriteRule ^private/(.*)$ /cookie_check.php?file=$1 [L]
So when someone accesses, for example, "/private/reports.pdf", it gets internally redirected to "/cookie_check.php?file=reports.pdf" and it's up to this php script to access whatever it needs to in order to validate the cookie that /myApp has setup. If the cookie is a valid session, then read the "reports.pdf" file and send it to the browser, otherwise return FORBIDDEN.
I think this is the preferable way of handling this.
3) If you can't run php or any other scripts, or the cookie cannot be verifed (like with a database lookup of session_id or something similar), then you'll have to proxy from within WebLogic. This would be more of less the same basic idea as having access to "/private" through "cookie_check.php" except it's an app on the WebLogic server. Just like /myApp, you'll need to setup a reverse proxy to access it, then this app will get the request (which has been internally rewritten from "/private/some_file") check the cookie's validity, read the "some_file" file ON THE APACHE SERVER, then send it to the browser, or send FORBIDDEN. This is the general idea:
ProxyPass /CheckCookie http://internal_server/check_cookie_app
RewriteCond %{REMOTE_HOST} !internal_server
RewriteRule ^private/(.*)$ /CheckCookie?file=$1 [L]
This condition reroutes all requests for "/private" that didn't originate from "internal_server" through the /CheckCookie app, and since the app is running on "internal_server" it can access the files in "/private" just fine. This is kind of a round-about way of doing this, but if the validity of session cookies issued by /myApp can only be checked on the WebLogic server, you'll have to reroute requests back and forth or something similar.