[javaee-spec users] Re: [jsr342-experts] proposal for Tenant ID

From: Pete Muir <>
Date: Wed, 25 Jan 2012 11:48:23 +0000


It's not clear from the proposal what the *type* of the tenant id would be. I'm going to assume it's of type String for the discussion below.
Assuming that this is cleared up, and the JNDI option was taken, we could update the CDI spec to allow injection of the tenant ID. For example, CDI could define the qualifier @TenantId, allowing the tenant to be injected via @Inject @TenantId String tenantId;. I would suggest specifying this in CDI 3.6 where we allow injection of other Java EE objects which are available in JNDI, using language like:

"a bean with bean type java.lang.String with qualifier @TenantId allowing injection of the current Tenant ID" (I would also need to adjust the surrounding language as the qualifier @Default is specified in the preamble, but that is not hard).


On 24 Jan 2012, at 22:57, Bill Shannon wrote:

> We've been considering how to provide access to the Tenant ID for
> the current tenant of a SaaS application. After discussing this
> issue with our security team, they wrote up the following proposal.
> Let us know if there are any concerns.
> - Context for the Proposal
> We've previously proposed making some sort of "Tenant ID" available
> to multi-tenant applications. While considering how to do this,
> we briefly took a step back and considered the possibility that each
> product could potentially approach the availability of Tenant ID
> through configuration that would be accomplished at the time of
> provisioning and deployment of a SaaS application instance, and thus
> that we would not need to standardize access to the Tenant ID.
> The tenant for which the application is being deployed would be
> represented through a Tenant ID, which would be configured to be made
> available to all interested parties. This would be done through a
> purely proprietary mechanism and exposed to containers through a
> proprietary API or through existing configuration mechanisms.
> While it may be possible to accomplish all of the goals for the EE 7
> limited SaaS definition without making a Tenant ID available through a
> standard runtime mechanism, it has been acknowledged that it may be
> useful to have Tenant ID available for certain things that cannot be
> immediately configured at provisioning time.
> We have therefore accepted the general usefulness of having it
> available through a standard mechanism.
> - Alternatives
> There have been a number of alternative approaches proposed including:
> 1. JNDI
> 2. Java EE Security Context, Java SE Security Platform APIs (Subject, etc)
> 3. New Class/API
> - JNDI
> At first glance, JNDI seems a bit clumsy and awkward to call frequently
> as would be required for a runtime where the tenantID would potentially
> be different per thread of execution.
> At the same time, there are ways to intercept the lookup for
> performance optimization and transformation that could be leveraged to
> meet our needs. Additionally, there is no need to introduce a new JSR
> in order to add a requirement to have a value such as Tenant ID
> available as this may be done through the platform specification
> itself.
> - Security APIs
> The convenience of Subject as a thread-associated object and the
> ability to add Principals and/or Credentials to represent attributes of
> authenticated users made the Security APIs a possible vehicle for
> Tenant ID.
> However, this would require a number of changes that would break both
> explicit and implied contracts that would have the potential of
> breaking applications that are deployed in the field.
> Mainly, we would have to require there to *always* be a Subject
> available. Today Subject.getSubject can return a null value. As can the
> other security APIs that would be considered part of the security
> context. Changing this contract and introducing new semantics in order
> to introduce Tenant ID would involve more risk than is justified by the
> convenience of the Subject.
> - New Class/API
> Technically speaking, a new class/API seems to be the most logical
> approach given the options.
> Unfortunately, it would require a new JSR in order to introduce
> something new that isn't really an enhancement to an existing component
> specification. The addition of this API would likely involve a single
> class and therefore a new JSR would be overkill.
> The Java EE platform specification generally doesn't define new
> interfaces, but it does define things in JNDI and there is an existing
> proposal to use JNDI for Tenant Id.
> - Conclusion
> Therefore, the best vehicle for a piece of information that describes
> something about the environment in which an application instance is
> running that doesn't require a new JSR would probably be JNDI and the
> prescribing specification would be the EE platform spec.
> In addition to the convenience of JNDI, there are measures that a
> platform implementation can take in order to optimize performance of
> retrieving a value from JNDI - as well as ensure that the value
> returned is appropriate given the specifics of a particular platform
> implementation's approach to tenancy.
> While we don't want to guarantee it, it is feasible that the JNDI
> lookup approach could be extended/enhanced through interception in the
> future to accommodate changes in the tenant model such that the
> appropriate id is always returned for the caller's context.
> - Proposal for the EE Platform Specification
> Platform implementations would be told to make the effective TenantID
> available in some well known location in JNDI. They would be free to
> implement a proprietary API to access it and do whatever tenant
> specific activities based on its value. However, consumers should be
> able to count on the value being in JNDI as the standard mechanism.
> The language to describe what this TenantID represents must be
> sufficiently clear in illustrating that it represents the customer for
> which the SaaS application instance has been deployed.
> The name java:comp/tenantId would probably be sufficient for JNDI lookup.
> Any specific alignment with possible future programming models for
> building multi-tenant applications should be avoided. If a separate
> concept of tenant is someday required for a multi-tenant programming
> model then we will make provisions within the programming model itself
> for accessing some representation of the effective tenant for the
> application.
> Efforts within the JDK for adding support for multiple tenants and
> JSR's that are targeted at EE 8 (such as 351) and beyond would probably
> also be leveraged and central to the design of any such programming
> model changes.