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.