I have a webapp deployed in Tomcat server with Apache in front of it. One of the requirements, is that the webapp has to be accessible using two different paths. For example:
http://domain.com/aa/bb/v1/*
and
http://domain.com/cc/v1/*
My webapp is configured with the first URL, so any request to /aa/bb/v1/* is handled correctly by Tomcat.
Then, to be able to "forward" the calls to the second URL to the first one, I've used mod_rewrite in apache, like this:
RewriteEngine on
RewriteRule /aa/bb/v1/(.+) cc/v1/$1 [NC,L,P]
This works fine! Except when I activate the digest authentication in Tomcat. In digest, the password sent by the browser is some more or less complex hash value calculated including the username, the realm and among other things, the URI. The URI of the browser, is not the URI of the webapp (I've modified it with mod_rewrite) so the authentication fails.
Any ideas in how to solve this?
Finally I've found one easy solution. One of the configurable values of the Tomcat's Digest valve is to do not validate URIs. This can be done by adding the digest valve configuration in the context.xml file:
<Context>
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Valve className="org.apache.catalina.authenticator.DigestAuthenticator" validateUri="false" />
......
I'm not sure if somebody will say that this is insecure... however, for my case is enough.
Related
Hoping someone can give me some advice if possible.
We have a Linux box in our DMZ with the WebSphere plugin. This points to a Windows box running WebSphere Application Server.
httpd config only contains the default virtualhost with no ServerAlias specified. There is a redirect set up in the virtualhost in httpd.conf to forward any requests to service.domain.com to service.domain.com/wascontext1. Plugin-cfg.xml is set up with two uri groups, wascontext1 and wascontext2, but only 1 is actively used.
I want to use the Linux box as a reverse proxy for another application totally separate to WAS. It would have a different domain (i.e. dimsim.domain.com) but point to the same IP.
I was going to add another virtualhost for this but am unsure exactly how the WebSphere plugin will behave with it. From what I understand if I set this up and went to dimsim.domain.com/wascontext1 it would serve the WebSphere content as httpd forwards all requests to the plugin.
Is there a way to tell httpd to not send requests to the WebSphere plugin based on domain name or virtualhost? Or would doing a rewrite on any requests to dimsim.domain.com/wascontext be considered ok?
thanks
jc
EDIT: Thanks for the responses! I'll test changing the virtualhost name in plugin-cfg.xml on our second unused context and let you know how it goes.
A solution that doesn't require plugin-cfg.xml changes: If you use an Apache-based HTTP server, you can conditionally set the per-request variable "skipwas" to short-circuit the WAS Plugin processing.
e.g.
SetEnvIf Host ^dimsim\.domain\.com$ skipwas=1
If you look at the plugin-cfg.xml file, in the first part of the file you will find virtualhostgroup section similar to this:
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:9080"/>
<VirtualHost Name="*:9443"/>
<VirtualHost Name="*:443"/>
<VirtualHost Name="*:80"/>
</VirtualHostGroup>
just change the Name from * to the required domain name e.g. service.domain.com and then plugin will forward only requests for the service.domain.com hostname.
So something like:
<VirtualHost Name="service.domain.com:80"/>
should work for you.
When a request comes into the web server, it is passed to the WebSphere plugin and then plugin examines the request based on its configuration to determine if it should forward to WebSphere or pass back to the web server for further processing.
The "route" clauses in the plugin-cfg.xml are key to determining what will be forwarded and what will not. A request must match all the values in the route to be forwarded. A route contains virtual hosts, uris and clusters. The request must match one a virtual host from the VirtualHostGroup in the route, a URI from the UriGroup in the route and there must be an available server in the ServerCluster value of the route for the request to be sent to WebSphere.
Note-If you manipulate your plugin-cfg.xml for your setup, be aware that plugin is very sensitive about the format of this configuration and incorrect or invalid entries could cause a crash of the webserver. Be sure to backup the file and test before using in production. Also, if you modify your WebSphere configuration, it could overwrite this file and wipe out your changes.
Sorry for the late response.
covener's answer of setting the following does what I need.
SetEnvIf Host ^dimsim\.domain\.com$ skipwas=1
I've successfully configured Apache to listen over SSL/443 and proxy Tomcat listening on HTTP/8080. I have also set up basic authentication in Apache.
Once the user connects to my Tomcat servlet, will the HttpServletRequest.getRemoteUser() be populated or null. If null, how might I get the remote user?
The simplest solution may be to use mod_proxy_ajp, which in addition to proxying requests also transfers a variety of metadata to Tomcat, including authentication information such as REMOTE_USER.
These docs for Alfresco discuss this configuration, which includes changes on both the Tomcat side (so that it knows to trust the forwarded authentication) and the Apache side.
If you're using a generic http proxy like mod_proxy, you would need to arrange for Apache to add the value of REMOTE_USER to the request (possibly as an X- header), and then arrange for your Tomcat application to recognize and trust that header (and you would obviously need to arrange for your front-end proxy to strip that header from any incoming requests).
I don't know how you would do this on the tomcat side, but this post seems to have some suggestions.
I needed to add
<Location />
Order allow,deny
Allow from all
RequestHeader unset Authorization
</Location>
to the wrapping location, the RequestHeader being the specialty that fixed it.
I found this (again) via http://codeblow.com/questions/remove-fundamental-authentication-header-with-apache-mod-proxy/ - don't know where I originally found it last year, it was a last measure for some security issue.
Tomcat in our application is considered back-and side and additionaly we have apache that fronting tomcat server as a reverse proxy and redirect requests to appropriate tomcat instance.
Now we need to set up HTTPS connection between apache proxy and tomcat for specific urls(Login, etc..). Tomcat documentation says that it's possible to achieve this with additional <Connector> within server.xml config.
In order to set up https over login page existing configuration with AJP protocol was replaced with the following:
ProxyPass /app/login/ https://127.0.0.1:6666/app/login/
All other urls specified like below:
ProxyPass /app/anyotherurl/ ajp://127.0.0.1:5555/app/anyotherurl/
With configuration below we expect that secure data (login/password) for login page will be encrypted and all other page will remain unchanged.
After the login apache should use normal ajp protocol because there is no sensetive information any more to protect. But it's not what actually happen in our case because for some reason apache is redirecting us to host specified in ProxyPass, namely to localhost.
This could happen due to the fact that our application while executing login logic on tomcat has two consecutive redirects.
We've tried to set ProxyPreserveHost on within virtual host to fix situation mentioned above, but we are not sure whether it is secure option and this one won't break another pages as well as we are not sure how it will work if tomcat will be located on other machine.
It would be good to know any other solution how such stuff can be applied internally for specific pages.
I'm a bit out of my depth here and nothing I have found quite addresses my problem. Si any and all suggestions are most welcome.
I've got tomcat6 running on CentOS 6.5 hidden behind an apache server (v2.2.15) and I am using Apache's mod_proxy to expose the tomcat webapps, which are running on port 8080. The tomcat hosts one production application and several development applications. On the apache side, both a Drupal site and the aforementioned tomcat production application are on the same domain and, thanks to rewrite rules, all requests to this domain are changed to https. The development sites are reached via subdomains and do not get re-written as https requests.
For the most part, this arrangement works fine. But parts of the tomcat apps are AJAX (calling a Java Struts 1.2 backend). Most of those requests are handled OK. But a few AJAX requests result in redirects (i.e., forward.setRedirect(true)) and that redirect is http (I guess because the container itself is not secure). As a result, I run into cross site scripting issues. I imagine I can use CORS headers to avoid the problem. But that seems like a hack. Is there a relatively painless way I can use to have tomcat send redirects back as https without making tomcat handle ssl directly?
Cris
You could configure the RemoteIpValve in Tomcat:
Another feature of this valve is to replace the apparent scheme
(http/https) and server port with the scheme presented by a proxy or a
load balancer via a request header (e.g. "X-Forwarded-Proto").
To configure Apache to forward the original protocol in the X-Forwarded-Proto header, add a RequestHeader directive in your Apache config, e.g.:
<VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
...
Note that in Tomcat 7, there is also a RemoteIpFilter.
You don't need to do anything special. It already works. Make sure you set the "redirectPort" in server.xml to Apache's HTTPS port, usually 443, and add the following to your <security-constraint> sections for resources you want secured by HTTPS:
<user-data-constraint>
<description>HTTPS</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
Late to the game here but others may find this-- we had a similar setup and issue where everything worked fine until the application started using ajax posts which did redirects for the response. The fix was to use mod_header in apache to rewrite redirects using "Header edit Location"
http://httpd.apache.org/docs/current/mod/mod_headers.html
Header edit Location ^http://www.example.com/ https://www.example.com/
This went unnoticed prior to the ajax redirects because the browser has no problem doing page level redirects to http (which apache would then redirect back to https). But the ajax cross-site prevention halts at the initial http missing out on that would then be redirected to https by a subsequent request.
I use apache as a proxy to my application web server and would like to on the fly, change the domain name associated with a sessionid cookie.
The cookie has a .company.com domain associated with it, and I would like using apache mod rewrite (or some similar module), transparently change the domain to app.company.com. Is this possible ? and if so, how would one go about it ?
You can only change the domain of a cookie on the client, or when it's being set on the server. Once a cookie has been set, the path and domain information for it only exists on the client. So existing cookies can't have their domain changed on the server, because that information isn't sent from the client to the server.
For example, if you have a cookie that looks like this on your local machine:
MYCOOKIE:123, domain:www.test.com, path:/
Your server will only receive:
MYCOOKIE:123
on the server. Why isn't the path and domain sent? Because the browser keeps that information on the client, and doesnt bother sending it along, since it only sends this cookie to your server if the page is at www.test.com and at the path /.
Since it's your server, you should be able to change your code that creates new cookies. If you felt you needed to do it outside of your code for some reason, you could do so with something like the following, but you'd have to look exactly at how your cookie is being written in the header to match it exactly. The following is an untested guess at a workable solution for this, using Apache's mod_headers:
<IfModule mod_headers.c>
Header edit Set-Cookie (.*)(domain=.company.com;)(.*) $1 domain=app.company.com; $2
</IfModule>
You can also use mod_headers to change the cookie received from the client, like so, if need be:
<IfModule mod_headers.c>
RequestHeader edit Cookie "OLD_COOKIE=([0-9a-zA-Z\-]*);" "NEW_COOKIE_NAME=$1;"
</IfModule>
This would only rename cookies you receive in the request.
ProxyPassReverseCookieDomain company.com app.company.com
or interchanging domains (as you are not clearly defining which is internal/external).
ref: https://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html#ProxyPassReverseCookieDomain
I don’t know any module that provides such feature. So I guess you will need to write your own output filter using mod_ext_filter that does this for you.
But if you have control over the other server, it might suffice to just omit the cookie’s domain value so that the client will automatically choose the requested domain as the cookie’s domain.
I ended up just creating an intermediate page that via javascript changed the cookie domain to the proxy server (by omitting the domain value) and then re-directed user to the target page. That seemed to resolve the issue. Thanks for your answers.
If your web-app is capturing the Host: header and using that to determine the domain= portion of the cookie, you might also consider the Apache directive
ProxyPreserveHost On
which relays the Host: header from the client.
This only works if your app is designed to assume that its domain name is whatever the client suggests with the Host header. If your app is one of these, this will not only fix your cookies, but also any absolute URLs that the application generates, which can save you the overhead of otherwise needing to enable mod_substitute
ProxyPass "/" "http://company.com/"
ProxyPassReverse "/" "http://company.com/"
ProxyPassReverseCookieDomain "company.com" "app.company.com"
Note: If it comes second in ProxyPass it should be first in ProxyPassReverseCookieDomain... I spent half a day or more figuring this out :-/
Also see: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreversecookiedomain