Skip to main content

[jsr342-experts] Re: proposal for Tenant ID

  • From: Werner Keil <werner.keil@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: proposal for Tenant ID
  • Date: Wed, 25 Jan 2012 00:45:46 +0100

Bill/all,

Thanks a lot for the update. It came a few minutes late for the most recent JSR 351 conf call, but some essence, especially the proposed schedule towards EE8 is something I wanted the EG to know. 
We did discuss things like annotations vs. other means to highlight attributes that are immutable or not, and something like Type Annotations from JSR 308 (also not before SE/EE8 as of now) could be one option for that.

Any JSR and (EE) Platform beyond a finished 351 would clearly benefit from attributes usable for a Tenant, Customer or Account ID, and JSRs like the soon launched Social API Antoine, I and others are just finalizing before proposal also expect to benefit from such IDs. As it aims to reuse JSRs like 351 or JSON among others (already in EE) where appropriate, it'll also be more likely part or some "Profile" (whatever a set of modules in a EE8 like world may look like) within EE8, but should otherwise stand independently with parts of it equally targeting at least SE and the Desktop, or let's say JavaFX as a client.

What about effects on other JSRs, e.g. Portlets or things like the recent developments in JSF?

I assume, "Tenant" may be added as probably the highest level of Scope, too.
Maybe for some of the other JSRs (CDI especially) this could mean something like @TenantScoped, too,?

Werner

On Tue, Jan 24, 2012 at 11:57 PM, Bill Shannon <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.



--

Werner Keil | JCP Executive Committee Member (ME) | Eclipse UOMo Lead

Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR

Skype werner.keil | Google+ gplus.to/wernerkeil

* M-Day: February 1 2012, Frankfurt, Germany. Werner Keil, JCP EC Member, OpenDDR Evangelist will discuss "Mobile Web Development"

* Social Media Week: February 13-17 2012, Hamburg, Germany. Werner Keil, JCP EC Member, designated Social JSR Spec Lead will discuss "Java Social"

* Mobile Developer Conference: February 14 2012, Hamburg, Germany. Werner Keil, JCP EC (ME) Member, OpenDDR Evangelist will present "OpenDDR"



[jsr342-experts] proposal for Tenant ID

Bill Shannon 01/24/2012

[jsr342-experts] Re: proposal for Tenant ID

Werner Keil 01/24/2012
 
 
Close
loading
Please Confirm
Close