Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
B. Blama
Greenhorn
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,
    Blama
     
    Tim Holloway
    Saloon Keeper
    Pie
    Posts: 18156
    53
    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.).
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic