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
