File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes Tomcat 7.0 configuration w/ multi-tenancy support & realm security & different login.html per tenant Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Tomcat 7.0 configuration w/ multi-tenancy support & realm security & different login.html per tenant" Watch "Tomcat 7.0 configuration w/ multi-tenancy support & realm security & different login.html per tenant" New topic
Author

Tomcat 7.0 configuration w/ multi-tenancy support & realm security & different login.html per tenant

B. Blama
Greenhorn

Joined: Aug 25, 2012
Posts: 1
I'm trying to archive the following:

A Tomcat 7.0 webapp with different login screens per tenant. I want to deploy the WAR only once for all tenants. I came so far:

  • Multi-tenant GWT web-app
  • Multi-tenant Database by "tenant_id" column in every table
  • "users"-table VIEW for each tenant, so that it can be configured as credential source per Context as follows

  • in server.xml.

    I read a few times that people advise against two Contexts sharing the same docBase because of memory consumption.

    So I'd guess what I need to to is the following:
  • Register app as context (one or many needed?)
  • Modify web.xml in order to redirect to different login.html per tenant (which means many "<login-config>"-tags???)

  • Could you advise how this is done? I suppose it involves Apache URL rewrite and/or filters, but I never used these so far and would be happy to handle it with just Tomcat (no Apache).

    Thank you,
    Blama
    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 16141
        
      21

    By "tenant", I presume you mean that you're deploying multiple instances of the webapp for different sets of users.

    You can share a single WAR file (or directory) between as many instances as your hardware can tolerate. Since the WAR is (or at least SHOULD be!) read-only, that's not a problem, although they won't generally share class instances, since each WAR has its own unique classpath. Or in other words, it will require as much memory as "n" separate applications instead of 1 class + n per-user object applications worth of memory. Some experimental JVMs have addressed that issue, but the standard Sun/Oracle JVM doesn't (last I heard, anyway).

    If you're using container-managed (realm) security, the login screen is selected by the contained according to the fixed definition in web.xml. Redirection will probably not work here, since this webpage is managed directly by Tomcat according to minimalistic rigidly-defined rules, but you can do a lot just by "skinning" the page based on deployment options that you set. Since a login screen at heart should only be a form with userID, password and Submit controls, skinning is usually sufficient.

    Along with general deployment options, of course, you can configure a separate Realm at the Context level for each tenant, allowing you to select not only the credentials datasource but even what type of Realm that particular instance runs under (JDBC, LDAP, MemoryRealm, usw.).


    Customer surveys are for companies who didn't pay proper attention to begin with.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Tomcat 7.0 configuration w/ multi-tenancy support & realm security & different login.html per tenant