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,?
(see
http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html)
Werner
On Tue, Jan 24, 2012 at 11:57 PM, Bill Shannon <bill.shannon_at_oracle.com>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"