• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

request chaining between multiple tomcat clusters

 
Greenhorn
Posts: 10
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We are planning to setup a cluster of tomcat containers to handle authentication as an API separate from a tomcat cluster that handles the actual APIs.

Traditional setup is to have a Gateway, Apache or Load Balancer to authenticate the request, acting as a proxy, to the actual containers handling the request:
Load Balancer -> Apache (authentication module) -> Tomcat cluster
Load Balancer -> Software/Hardware Gateway appliance (authentication module) -> Tomcat cluster

However, we have more logic in these authentication modules that is not written in Java and so it made sense to write Java APIs handled by a dedicated authentication tomcat cluster.

So, now you have these options
1. Load Balancer -> (Apache -> Authentication tomcat cluster) -> API tomcat cluster
2. Load Balancer -> Authentication tomcat cluster -> API tomcat cluster
3. Load Balancer -> API tomcat cluster + with Authentication

We chose Option 2 following separation of concerns and to avoid Apache hop. Is "servlet forward" from authentication cluster to API cluster the best practice or make a regular HTTP call from the authentication cluster and act as a pass through or Proxy to the API tomcat response so you can handle the response?

What is the best way to chain different tomcat clusters where one tomcat cluster is acting as a pass through or (forward, reverse) proxy to another tomcat cluster, so it can also snoop/modify the final response?

 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would recommend that rather than kludge together some sort of one-of-a-kind security manager that you use the J2EE standard container security system, instead. If you like, I can even provide an enumeration of all the reasons why this would be preferable; it's currently about 11 items long.

One of the biggest reasons for avoiding DIY security is that in all the years I've worked with J2EE, almost never have a I seen a DIY security system that actuall was secure . Most of them can be cracked in under 15 minutes bu non-technical personnel, in fact.

So on the whole, it's better to use a system that was designed and proofed by full-time security professionals, is well-documented, debugged, has around 15 years of reliable history, is part of the J2EE API and requires minimal code support.

Tomcat's implementation of this system is via a security Realm. The Realm is defined by wiring in plug-in security module appropriate for your authentication and authorization needs into Tomcat itself (since it's container managed). Tomcat comes with a set of stock Realm modules that use everything from XML text files, to JDBC to LDAP and beyond.

It is also quite easy to create custom Realms. One of the ones I did several years back invoked a web services server to validate credentials and security roles.

By offloading the security function onto a Realm module, you not only relieve the web applications from having to contain a lot of fragile security-related code, you also relieve them of having to worry about the low-level architecture of the seurity system itself. This, in turn allows more freedom to tune the load-balancing and clustering features without having a massive impact on the application code.

 
rad kri
Greenhorn
Posts: 10
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Note that we will still use the Load Balancer -> Apache (where SSL ends) and these take care of the DOS attacks and white listing.

New approach:
1. Load Balancer -> (Apache -> Authentication tomcat cluster) -> API tomcat cluster

What we are trying to do is simply remove the perl and complex policy file modules in our Gateway and Apache that handle validation of oauth signatures, make cache/DB lookups to modify headers and modify final response from API cluster. The reason for switch is to use open source alternatives to save money and also provide connection pooling, caching and optimization that is becoming quite complex using perl modules and gateway appliance policy files!

The only option then was to have a tomcat cluster just for authentication and authorization that then makes a HttpClient kind of a request to the tomcat cluster handling actual APIs. I was making sure if there is a better approach to this problem avoiding the overhead and extra latencies with such setup. We did not want the tomcat filter route to include both in the same war/app due to lack of separation of concerns.

In the REALM approach added to our tomcat API cluster to call the authorization tomcat cluster, we don't have a provision to modify the response, it is only meant for authentication. What we wanted was the tomcat authentication cluster to act as a proxy.

Basically how can we use Java APIs in our Apache/Gateway instead of those perl modules or gateway policy files?
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you want separation of concerns when it comes to security, I definitely recommend using the J2EE standard. It doesn't merely separate the authentication and authorization, it takes it completely out of the application code entirely.

A typical load-balanced Apache/Tomcat setup might use Apache httpd as the public proxy, forwarding via mod_jk or mod_proxy to a Tomcat cluster. If the Tomcat cluster is using container A&A, and the app is fully load-balanced (as opposed to "sticky" sessions, that are tied to a single server in the cluster), then a cluster-friendly Realm would be required. This is essentially a Single Signon type of Realm, since signing on to any Tomcat in the cluster authenticates you to all the Tomcats in the cluster. If you have a master security server, then each Tomcat's Realm would talk to it. Requests wouldn't be forwarded, they'd stay on the receiving Tomcat, and any Realm-to-security server traffic would be inside the Realm subsystem itself. That's going to be a lot less overhead than bouncing HTTP requests from one Tomcat to another.

And, as I said, it doesn't require warty application programming that the maintenance people are going to screw up because they're using a one-of-the-kind security manager.
 
rad kri
Greenhorn
Posts: 10
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Our APIs are restful and there is no need for container session management, all of the authorization is done by looking up a database entry for the limited set of users and matching against the url pattern being accessed unlike other public facing apps that have millions of users. Authentication of the requests is also similar but follows the oauth 2.0 paradigm.

So basically we don't use tomcat sessions and don't worry about sharing the sessions among the tomcat cluster. The other problem is that we want the proxy to parse the response before returning it which is not possible using Realm.

"Wonder why there is no mention of tomcat being used as a proxy like Apache?", what's wrong with this, especially in our case where there is a lot of authentication, authorization code that we want to re use.

Now that you mentioned, I need to verify if our tomcat creates a separate session for each request from a unique IP rest call although the APIs are restful. What I mean is, does tomcat create those sessions with session context that get timedout in a tomcat container?
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah! ReST makes all the difference.

Although I am a major proponent of the container security system, it's not a good fit for sessionless ReST, since it's based on sessions and ReST isn't supposed to have sessions. Plus the overhead of requesting and processing security credentials interferes with the efficiency of ReST. On the other hand, a Tomcat Valve might be a good place to screen out unauthorized requests. Or, keeping it simpler, a ServletFilter. The main difference is in whether you want bad URLs to be able to even approach application logic at all or get rejected by the server immediately.

There are probably 2 reasons why Tomcat isn't used as a proxy.

1. J2EE is a high-powered processor in its own right. Anything sent to it would generally be expected to be using that power, rather than having Tomcat pass it on. Most true proxying is low-overhead/minimal logic and handled by simpler systems.

2. Tomcat doesn't have the ability to natively work down amoung the privileged ports (80, 443) without exposing a lot of high-powered capabilities as security risks. Meaning Tomcat would have to be running as a root/admin user.

Since you are apparently looking to work with the response side of the process, typically that would mean that the webapp had made an internal request to another webapp or maybe some non-web service such as JMS. In that case, the outer app would be creating the response based on what the secondary app returned. The secondary app could be within the same Tomcat, a different Tomcat, or a non-Tomcat/non-Java webapp server.

If, on the other hand, you're looking for basic characteristics in the outgoing response itself, the outbound side of a ServletFilter is a good option.

The important thing to consider is that if a client makes a request to server "X", then server "X" must be where the response appears to return from. Whether server "X" is a simple server, a proxy server, or the entry point to something really complex, the HTTP protocols demand that. So you can't literally chain a request from server X to server Y and have server Y return the response directly back to the client.
 
rad kri
Greenhorn
Posts: 10
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I discussed how we can use HTTP client make it a proxy in previous reply.

"The only option then was to have a tomcat cluster just for authentication and authorization that then makes a HttpClient kind of a request to the tomcat cluster handling actual APIs. I was making sure if there is a better approach to this problem avoiding the overhead and extra latencies with such setup. We did not want the tomcat filter route to include both in the same war/app due to lack of separation of concerns."
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Separation of concerns doesn't mean physically breaking functions into separate apps. At least unless there's good reason.

Separation of concerns means that you don't intermingle logic to the point where changes in one function interferes with how another function works. A filter is actually one very good way to enhance separation of concerns, providing that that filter only performs one function. Such as acting as the security gateway.

One of the most famous examples of Separation of Concerns in operation is the Model/View/Controller (MVC) architecture. Typically one app contains all 3 component types: Models, Views and Controllers, but Models hold data, Views provide presentation and Controllers keep the 2 in sync without the need for Models to know what the Views are doing or vice versa.
 
reply
    Bookmark Topic Watch Topic
  • New Topic