Re: [RT] Multi Tenancy
Am 12.08.2014 23:19 schrieb Alexander Klimetschek aklim...@adobe.com: Carsten Ziegeler cziege...@apache.org wrote: Yes, right - now the replacement for loginAdministrative can prevent this if loginAdministrative is not working anymore (throws an exception). No! With JAAS Subject.doAs() you can still login as admin [1]. Right and i can do reflection etc. Carsten Disabling loginAdministrative() is just preventing the all too convenient and already well-known way in the prominent SlingRepository API. It does NOT prevent code including JSPs to login as admin if it really wants to! The thing is that there are still Sling authentication handlers that need to define the user (incl. admin). Otherwise the code would have had to be moved down below the JCR API or some Java Security style privilege would have to be done to trust certain auth handlers running in Sling. [1] http://sling.markmail.org/thread/itfmayeef6lyz3tg Cheers, Alex
Re: [RT] Multi Tenancy
2014-08-12 1:47 GMT+02:00 Alexander Klimetschek aklim...@adobe.com: And then use the resource types in the content: /content/tenant1/site/@sling:resourceType = tenant1/components/foo I think this is not feasible in the general case. For example, imagine having ootb components with a resource type components/foo. Each time such a component is added to content, the resource type would be needed to be adapted - which is doable but adds on top of it. And how do you want to distinguish between using the default rendering and a specialized one easily? Then, if you have shared content between tenants like some common stuff which you want to render differently, this doesn't work. I agree that having a tenant specific resource type is one way of doing it, but it's definitely not the only way. In essence, I would be very careful in adding a new complexity such as tenant based resolution. This doesn't realy add complexity, it just adds another search path to the resolution. Unfortunately, we have to cache script resolution as otherwise request processing is way to slow and thats the only place where we have to be careful about the current tenant. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: [RT] Multi Tenancy
-Original Message- From: Alexander Klimetschek [mailto:aklim...@adobe.com] Sent: Tuesday, August 12, 2014 1:47 AM To: dev@sling.apache.org Subject: Re: [RT] Multi Tenancy ... And here it becomes tricky. Because if you are allowed to write arbitrary code (e.g. in JSPs), you can get an admin session, and thus do what you want anyway. So enforcing to set the right resource types in the first place (e.g. UIs not allowing you to choose templates / components from another tenant) have the same level of security then a complex tenant script resolution mechanism. if the tenant-specific scripts are allowed to get an admin session, they cannot only access scripts of other tenants, but all their content as well, which is i suppose much more problematic than accessing the custom scripts. you can effectively steal all content of all other tenants of the same instance. so, it's difficult to use the current architecture for a tenant model where the deployed scripts have to be considered unsafe and the tenants cannot not trust each other. i think it would be possible to extend the sling API with ways to prevent getting an admin session via configuration, but is this still save when accessing JCR API directly, or other services running in the OSGi context which may expose administrative access to other parts as well. so this really depends on the usecases (i will start creating a wiki page for them today) that the tenant support has to fulfill. stefan
RE: [RT] Multi Tenancy
i created a first draft of a wiki page where i tried to collect the different views of and requirements for multitenancy of the recent discussions: https://cwiki.apache.org/confluence/x/So2uAg i coined new names for the two scenarios Virtual Hosting and Massive Multi Site we should decide first which of the requirements we can target in a first phase, and which are more complex or even not solvable within the current architecture. and - of course - what is already fulfilled by the current sling tenant implementation. my interest is currently primary in the massive multi site scenario, and especially the configuration part in it. stefan
Re: [RT] Multi Tenancy
Hey Stefan, just to add my 2 cents on constraints for a tenant: * In both cases the tenant could be identfied by one or more branches in the repo that can be linked to exactly one tenant. * In cases of Tenant Inheritance (as described in the Massive Multi Site Scenario) the returned Tenant would be the most concrete Tenant but could be identified as subtenant (e.g. /content/maintenant/subtenant maps to subtenant which can be identified to be anchestor of maintenant) * Contentsharing could happen on two levels ** Inheritance (Subtenant can always access resources from anchestors or in last resort the platform - but is most probably not allowed to write there) ** Synching/Sharing (Master-Slave or bidirectional syncing of Resources, so content virtually lives within the tenants content) I don't think it is a good idea to bind Resource Resolution and therefore scripts to a tenant since I can see the issue comming that a second tenant needs to be set up with exact the same scripts. I would define a mapping where Applicationpaths can be mapped to a tenant and the Searchpath lookup adds those paths dynamically to a tenant. This has the advantage that it is possible to define tenant by tenant which applicationextension will be made available to them. Best regards Dominik On Tue, Aug 12, 2014 at 12:43 PM, Stefan Seifert sseif...@pro-vision.de wrote: i created a first draft of a wiki page where i tried to collect the different views of and requirements for multitenancy of the recent discussions: https://cwiki.apache.org/confluence/x/So2uAg i coined new names for the two scenarios Virtual Hosting and Massive Multi Site we should decide first which of the requirements we can target in a first phase, and which are more complex or even not solvable within the current architecture. and - of course - what is already fulfilled by the current sling tenant implementation. my interest is currently primary in the massive multi site scenario, and especially the configuration part in it. stefan
Re: [RT] Multi Tenancy
2014-08-12 10:36 GMT+02:00 Stefan Seifert sseif...@pro-vision.de: if the tenant-specific scripts are allowed to get an admin session, they cannot only access scripts of other tenants, but all their content as well, which is i suppose much more problematic than accessing the custom scripts. you can effectively steal all content of all other tenants of the same instance. so, it's difficult to use the current architecture for a tenant model where the deployed scripts have to be considered unsafe and the tenants cannot not trust each other. i think it would be possible to extend the sling API with ways to prevent getting an admin session via configuration, but is this still save when accessing JCR API directly, or other services running in the OSGi context which may expose administrative access to other parts as well. Yes, right - now the replacement for loginAdministrative can prevent this if loginAdministrative is not working anymore (throws an exception). And as you note this also depends on the use case, if you can trust the per tenant scripts than this is fine. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [RT] Multi Tenancy
Hi Stefan, thanks for putting this together. While I agree that the requirements are different for the 2 scenarios, I'd rather see the multi-site scenario as a subset of virtual hosting. Tenants in virtual hosting could be structured internally as a multi-site as well. I also think that in the virtual hosting scenario there are requirements for users to access multiple tenants. Think of agencies working on behalf of multiple customers. I'm not sure I understand the definition that tenants are defined upfront in virtual hosting. They can be created dynamically at run time. Alex On Tue, Aug 12, 2014 at 12:43 PM, Stefan Seifert sseif...@pro-vision.de wrote: i created a first draft of a wiki page where i tried to collect the different views of and requirements for multitenancy of the recent discussions: https://cwiki.apache.org/confluence/x/So2uAg i coined new names for the two scenarios Virtual Hosting and Massive Multi Site we should decide first which of the requirements we can target in a first phase, and which are more complex or even not solvable within the current architecture. and - of course - what is already fulfilled by the current sling tenant implementation. my interest is currently primary in the massive multi site scenario, and especially the configuration part in it. stefan -- Alexander Saar Mobile: +49.172.8280280 E-Mail: alexander.s...@gmail.com
RE: [RT] Multi Tenancy
-Original Message- From: Alexander Saar [mailto:alexander.s...@googlemail.com] Sent: Tuesday, August 12, 2014 8:34 PM To: dev@sling.apache.org Subject: Re: [RT] Multi Tenancy ... thanks for putting this together. While I agree that the requirements are different for the 2 scenarios, I'd rather see the multi-site scenario as a subset of virtual hosting. Tenants in virtual hosting could be structured internally as a multi-site as well. yes, i hope as well we can find a solution which fits both needs. just wanted to make sure all aspects of both scenarios are covered. I'm not sure I understand the definition that tenants are defined upfront in virtual hosting. They can be created dynamically at run time. my thought was that in a virtual hosting scenario you start creating a tenant, and automatically a content subtree is created assigned for this tenant, e.g. using a tenant creation wizard. in the multi site scenario this is different - a user just creates a new site, and if it matches a specific pattern/structure (which is configurable), automatically a new tenant or configuration scope is created. this is the usecase view, from a technical point of view this should not be much a difference. stefan
Re: [RT] Multi Tenancy
Carsten Ziegeler cziege...@apache.org wrote: Yes, right - now the replacement for loginAdministrative can prevent this if loginAdministrative is not working anymore (throws an exception). No! With JAAS Subject.doAs() you can still login as admin [1]. Disabling loginAdministrative() is just preventing the all too convenient and already well-known way in the prominent SlingRepository API. It does NOT prevent code including JSPs to login as admin if it really wants to! The thing is that there are still Sling authentication handlers that need to define the user (incl. admin). Otherwise the code would have had to be moved down below the JCR API or some Java Security style privilege would have to be done to trust certain auth handlers running in Sling. [1] http://sling.markmail.org/thread/itfmayeef6lyz3tg Cheers, Alex
Re: [RT] Multi Tenancy
Ack. As Dominique mentioned, there are cases where you want to share scripts between tenants. For example a partner hosting multiple customers with a set of common components/resource types. If you want to model that with a custom resource resolution, you will build the same system that's already there: Who says that tenant configuration that you'll need (defining /content/acme is tenant acme and is only allowed to execute stuff from /apps/acme, /libs/* and maybe /apps/common etc.) is safer than setting up resource types as now? Cheers, Alex On 12.08.2014, at 04:38, Dominik Süß dominik.su...@gmail.com wrote: Hey Stefan, just to add my 2 cents on constraints for a tenant: * In both cases the tenant could be identfied by one or more branches in the repo that can be linked to exactly one tenant. * In cases of Tenant Inheritance (as described in the Massive Multi Site Scenario) the returned Tenant would be the most concrete Tenant but could be identified as subtenant (e.g. /content/maintenant/subtenant maps to subtenant which can be identified to be anchestor of maintenant) * Contentsharing could happen on two levels ** Inheritance (Subtenant can always access resources from anchestors or in last resort the platform - but is most probably not allowed to write there) ** Synching/Sharing (Master-Slave or bidirectional syncing of Resources, so content virtually lives within the tenants content) I don't think it is a good idea to bind Resource Resolution and therefore scripts to a tenant since I can see the issue comming that a second tenant needs to be set up with exact the same scripts. I would define a mapping where Applicationpaths can be mapped to a tenant and the Searchpath lookup adds those paths dynamically to a tenant. This has the advantage that it is possible to define tenant by tenant which applicationextension will be made available to them. Best regards Dominik On Tue, Aug 12, 2014 at 12:43 PM, Stefan Seifert sseif...@pro-vision.de wrote: i created a first draft of a wiki page where i tried to collect the different views of and requirements for multitenancy of the recent discussions: https://cwiki.apache.org/confluence/x/So2uAg i coined new names for the two scenarios Virtual Hosting and Massive Multi Site we should decide first which of the requirements we can target in a first phase, and which are more complex or even not solvable within the current architecture. and - of course - what is already fulfilled by the current sling tenant implementation. my interest is currently primary in the massive multi site scenario, and especially the configuration part in it. stefan
[RT] Multi Tenancy
Hi,
we've seen a lot of different dicsussions over time wrt multi tenancy in
this list. In addition, there is the age old proposal at [1] and the tenant
module in [2] which superceeds parts of the proposal on the wiki
The current tenant module detects the tenant of a request either based on
the requested content path or the user home and provides this information
via an adapter factory for both, the resource resolver and a resource.
While this mechanism might not be sufficient, I think the key point here is
that you get the tenant by adapting the resource resolver - which actually
allows to do any detection being it path based, or based on the url, a
cookie whatever. In that sense, it seems that this design is sufficient.
When it comes to content, structuring content by tenant and using ACLs to
protect this seems to be sufficient as well.
Now, the tricky and yet unsolved part is resource and script resolution.
The idea outlined in [1] is imho obsolete because we now already have
tenant support.
I think we can add tenant support to resource resolving and script
resolution without any further api changes: both implementation can try to
adapt the resource resolver to a Tenant and then the resource resolver
implementation can use this extra information for lookups. The script
resolver uses the resource resolver anyway, the only thing needed to be
added there is that caching of script resolution should take the tenant
into account.
My suggestion is that, if the Tenant information is availabe, resource
resolving looks at three places. For example if foo/bar should be
resolved:
1. /tenants/{tenandId}/foo/bar
2. /apps/foo/bar
3. /libs/foo/bar
The first available will be used.
I think there is no need for several search paths per tenant or to make
this further configurable
WDYT?
Regards
Carsten
[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
[2] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/tenant
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
RE: [RT] Multi Tenancy
hello carsten.
thanks for bringing this up. multi-tenancy is very important for our projects.
but to be honest, until now i did not see that any of the current tenant api
implementation [2] is of much use for user usecases.
let's start with the detecting of a tenant:
* if adapting from a resource resolver, detection by user is done. but this
implies that every user is exactly assigned to one tenant, which is - at least
in our projects - not always the case. there are always users that have access
to multiple tenants, controlled via ACLs. so this is not a 1:1 relation, but a
1-to-many relation.
* if adapting from a resource a path-based detection is used. here i do not
fully understand which path is meant - the path to the content of the tenant
(e.g. /content/*), or the path to custom scripts used in script resolution
(comparable to /apps/*). i do not get the distinction from your RT as well -
you refer only to the script resolution part. but if adapting from a resource,
this is usually a content resource, not a resource pointing to a script.
in my opinion both is relevant - to be able to connect one or multiple subtrees
in the content resource hierarchy with a specific tenant, and to allow to
provide tenant-specific script overlays.
in a 1:1 releation user-tenant the content dependency could be modeled via
ACLs, but if you have one user that can access multiple tenants this does not
work.
besides this for our usecases the option to provide tenant-specific script
resources has no high prio. much more importance is the possibility to create
tenant-specific configuration. this may apply OSGi services, which currently
support only one global configuration (ore one per runmode combination). on the
other side this applies to other application-specific business logic which
should behave differently from site to site or from tenant to tenant.
btw. we should perhaps first start to define what we mean with the term
tenant. this much-used and overloaded term might be a source of confusion as
well. in my view a tenant is in its smallest form e.g. one site (homepage and
all content pages below), perhaps plus a separate area for media assets. but a
tenant can also be a huge entity consisting of a lot of sites and other
content. because even for a huge tenant there might be the need for different
configuration for different sites/areas of the content we are currently
thinking if we even need support for nested tenants, which allow a
configuration parameter inheritance between the inner and outer tenants, up to
the global level of OSGi configurations.
for the configuration topic perhaps a separate RT should be started, but it's
closely related to a tenant concept.
stefan
-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org]
Sent: Monday, August 11, 2014 1:18 PM
To: dev@sling.apache.org
Subject: [RT] Multi Tenancy
Hi,
we've seen a lot of different dicsussions over time wrt multi tenancy in
this list. In addition, there is the age old proposal at [1] and the tenant
module in [2] which superceeds parts of the proposal on the wiki
The current tenant module detects the tenant of a request either based on
the requested content path or the user home and provides this information
via an adapter factory for both, the resource resolver and a resource.
While this mechanism might not be sufficient, I think the key point here is
that you get the tenant by adapting the resource resolver - which actually
allows to do any detection being it path based, or based on the url, a
cookie whatever. In that sense, it seems that this design is sufficient.
When it comes to content, structuring content by tenant and using ACLs to
protect this seems to be sufficient as well.
Now, the tricky and yet unsolved part is resource and script resolution.
The idea outlined in [1] is imho obsolete because we now already have
tenant support.
I think we can add tenant support to resource resolving and script
resolution without any further api changes: both implementation can try to
adapt the resource resolver to a Tenant and then the resource resolver
implementation can use this extra information for lookups. The script
resolver uses the resource resolver anyway, the only thing needed to be
added there is that caching of script resolution should take the tenant
into account.
My suggestion is that, if the Tenant information is availabe, resource
resolving looks at three places. For example if foo/bar should be
resolved:
1. /tenants/{tenandId}/foo/bar
2. /apps/foo/bar
3. /libs/foo/bar
The first available will be used.
I think there is no need for several search paths per tenant or to make
this further configurable
WDYT?
Regards
Carsten
[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
[2] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/tenant
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Re: [RT] Multi Tenancy
Hi, On Mon, Aug 11, 2014 at 3:13 PM, Stefan Seifert sseif...@pro-vision.de wrote: ...btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well... Definitely - I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions. -Bertrand
Re: [RT] Multi Tenancy
On Mon, Aug 11, 2014 at 3:29 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions... There's already https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support but as Carsten says we do have a tenant API now. Like Stefan I'm just suspecting people have different ideas about what multi-tenancy means, so having use cases would help. -Bertrand
Re: [RT] Multi Tenancy
Hi Stefan, thanks for sharing your thoughts, 2014-08-11 15:13 GMT+02:00 Stefan Seifert sseif...@pro-vision.de: let's start with the detecting of a tenant: * if adapting from a resource resolver, detection by user is done. but this implies that every user is exactly assigned to one tenant, which is - at least in our projects - not always the case. there are always users that have access to multiple tenants, controlled via ACLs. so this is not a 1:1 relation, but a 1-to-many relation. Right, this is how the implementation currently works - the nice thing is that this is abstracted behind the adaptTo call, so it can easily be replaced with something totally different. * if adapting from a resource a path-based detection is used. here i do not fully understand which path is meant - the path to the content of the tenant (e.g. /content/*), or the path to custom scripts used in script resolution (comparable to /apps/*). i do not get the distinction from your RT as well - you refer only to the script resolution part. but if adapting from a resource, this is usually a content resource, not a resource pointing to a script. I think in this case, adapting from a content resource is meant. To be honest, I'm not sure if this is a good idea anyway - but the good thing is - as above - it's abstracted. Personally I would skip this adaption and just go with resource resolver. in my opinion both is relevant - to be able to connect one or multiple subtrees in the content resource hierarchy with a specific tenant, and to allow to provide tenant-specific script overlays. in a 1:1 releation user-tenant the content dependency could be modeled via ACLs, but if you have one user that can access multiple tenants this does not work. I think, the way I wanted it actually to describe is, that there is a 1:1 relation between a request and a tenant. All tenant aware components simply adapt the resource resolver to Tenant and get the tenant. Regardless of how the mapping is done. besides this for our usecases the option to provide tenant-specific script resources has no high prio. much more importance is the possibility to create tenant-specific configuration. this may apply OSGi services, which currently support only one global configuration (ore one per runmode combination). on the other side this applies to other application-specific business logic which should behave differently from site to site or from tenant to tenant. Right, the use cases we have are per tenant scripts right now :) But I totally agree that per tenant OSGi configuration/bundles etc would be nice. A broad answer to this would be subsystems - although I'm not sure if it would help in all cases. btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well. in my view a tenant is in its smallest form e.g. one site (homepage and all content pages below), perhaps plus a separate area for media assets. but a tenant can also be a huge entity consisting of a lot of sites and other content. because even for a huge tenant there might be the need for different configuration for different sites/areas of the content we are currently thinking if we even need support for nested tenants, which allow a configuration parameter inheritance between the inner and outer tenants, up to the global level of OSGi configurations. for the configuration topic perhaps a separate RT should be started, but it's closely related to a tenant concept. Right, it's overloaded. I think the wikipedia definition at [1] is what we mean. Although this needs to be mapped to Sling powered application. In our case we need partitioning of content, resource resolving and script resolution. With fully multi tenant support this would include OSGi configs and bundles. So, this would fit your site definition even for large sites. [1] http://en.wikipedia.org/wiki/Multitenancy Regards Carsten stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Monday, August 11, 2014 1:18 PM To: dev@sling.apache.org Subject: [RT] Multi Tenancy Hi, we've seen a lot of different dicsussions over time wrt multi tenancy in this list. In addition, there is the age old proposal at [1] and the tenant module in [2] which superceeds parts of the proposal on the wiki The current tenant module detects the tenant of a request either based on the requested content path or the user home and provides this information via an adapter factory for both, the resource resolver and a resource. While this mechanism might not be sufficient, I think the key point here is that you get the tenant by adapting the resource resolver - which actually allows to do any detection being it path based, or based on the url, a cookie whatever. In that sense, it seems that this design is sufficient. When it comes to content, structuring content
Re: [RT] Multi Tenancy
for us the goal would be to run multiple customers in one sling instance without the ability to touch the code/content of any other tenant. It would be nice if a) restricting users from one tennat to another would be simple b) allow a good search path override for each tenant c) split out the admin account into tenants (an admin session should not have access to all tenants) d) osgi properties per tenant (probably needs to be handled in felix?) Ruben On 8/11/2014 6:29 AM, Bertrand Delacretaz wrote: Hi, On Mon, Aug 11, 2014 at 3:13 PM, Stefan Seifert sseif...@pro-vision.de wrote: ...btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well... Definitely - I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions. -Bertrand
RE: [RT] Multi Tenancy
when looking in the wiki i found another page [1] with some thoughts on multi tenancy from a mailing list discussion from february [2] from this i get we have two quite different scenarios although they have a shared part: * the fully isolated tenant scenario - tenants are fully isolated and have their own script (overlay) path, own users, own i18n etc. - as described in [1] - the existing tenant implementation targets on this scenario as well, but does currently fulfill only part of the requirements from [1] * the manage multiple tenants scenario - a set of users (editors, admins etc.) manages a set of tenants with n-to-m relation between users and tenants - providing script overlays and admin separation is not that important, but configuration and content separation it think both scenarios can be handled with a single (flexible/customizable) implementation, but both have their own complexities not relevant for the other. so when starting a wiki page we have to respect both scenarios. stefan [1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support+Integration [2] http://apache-sling.73963.n3.nabble.com/Tenant-Implementation-in-Sling-td4031217.html#none -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Monday, August 11, 2014 3:32 PM To: Bertrand Delacretaz Cc: dev Subject: Re: [RT] Multi Tenancy On Mon, Aug 11, 2014 at 3:29 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions... There's already https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support but as Carsten says we do have a tenant API now. Like Stefan I'm just suspecting people have different ideas about what multi-tenancy means, so having use cases would help. -Bertrand
Re: [RT] Multi Tenancy
On 11.08.2014, at 06:13, Stefan Seifert sseif...@pro-vision.de wrote: btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well. in my view a tenant is in its smallest form e.g. one site (homepage and all content pages below), perhaps plus a separate area for media assets. Yes. Already today you can have multiple sites/projects/tenants by using different resource types: /apps/project1/components/foo /apps/project2/components/foo and this is really the same as /apps/tenant1/components/foo /apps/tenant2/components/foo And then use the resource types in the content: /content/tenant1/site/@sling:resourceType = tenant1/components/foo The next question is then probably how to avoid tenant1 can use code of tenant2? And here it becomes tricky. Because if you are allowed to write arbitrary code (e.g. in JSPs), you can get an admin session, and thus do what you want anyway. So enforcing to set the right resource types in the first place (e.g. UIs not allowing you to choose templates / components from another tenant) have the same level of security then a complex tenant script resolution mechanism. Shielding custom code from different tenants essentially will require a JVM that can do that properly, of which only an IBM one can do it AFAIK. OSGi itself won't really offer a safe shielding - even subsystems are just there for simpler deployment configuration of groups that belong together, not for security. Also, in general you want to minimize the parts that have to know about the actual tenants. Most code should just read content / resources, look up configurations which are absolute or relative paths (such as the resource types pointing from /content/tenant1 to /apps/tenant1 or a configuration reference from /content/tenant1 to /etc/tenant1) and handle them transparently. ACLs enforce access to it, e.g. all tenant1 users have access to /content/tenant1, /apps/tenant1 (although this is special since servlet resolution is done using a special user) and /etc/tenant1. This leaves the part that needs to know about actual tenants to a minimum - the management of creating a new tenant (which can be just a template of content + ACLs + users/groups), deleting it etc. And it decouples specific application code from knowing the exact tenant structure, which could be different in different scenarios, and most importantly, it avoids being constrained to a single level such as /apps/tenant1 and allows nested project hiearchies such as /apps/tenant1/subtenant/project1. IMHO servlet resolution is one such application code part that shouldn't know about it. In essence, I would be very careful in adding a new complexity such as tenant based resolution. Cheers, Alex
