• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

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

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,
    Posts: 20120
    Android Eclipse IDE Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.).
    He repaced his skull with glass. So you can see his brain. Kinda like this tiny ad:
    RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!