[RT] Multi Tenancy

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[RT] Multi Tenancy

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [RT] Multi Tenancy

Stefan Seifert
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:[hidden email]]
>Sent: Monday, August 11, 2014 1:18 PM
>To: [hidden email]
>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
>[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Bertrand Delacretaz
Hi,

On Mon, Aug 11, 2014 at 3:13 PM, Stefan Seifert <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Bertrand Delacretaz
On Mon, Aug 11, 2014 at 3:29 PM, Bertrand Delacretaz
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Carsten Ziegeler
In reply to this post by Stefan Seifert
Hi Stefan,

thanks for sharing your thoughts,

2014-08-11 15:13 GMT+02:00 Stefan Seifert <[hidden email]>:

>
> 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:[hidden email]]
> >Sent: Monday, August 11, 2014 1:18 PM
> >To: [hidden email]
> >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
> >[hidden email]
>



--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Ruben Reusser
In reply to this post by Bertrand Delacretaz
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

RE: [RT] Multi Tenancy

Stefan Seifert
In reply to this post by Bertrand Delacretaz
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:[hidden email]]
>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
><[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Alexander Klimetschek-2
In reply to this post by Stefan Seifert
On 11.08.2014, at 06:13, Stefan Seifert <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Carsten Ziegeler
2014-08-12 1:47 GMT+02:00 Alexander Klimetschek <[hidden email]>:

>
> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [RT] Multi Tenancy

Stefan Seifert
In reply to this post by Alexander Klimetschek-2


>-----Original Message-----
>From: Alexander Klimetschek [mailto:[hidden email]]
>Sent: Tuesday, August 12, 2014 1:47 AM
>To: [hidden email]
>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

Reply | Threaded
Open this post in threaded view
|

RE: [RT] Multi Tenancy

Stefan Seifert
In reply to this post by Carsten Ziegeler
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
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Dominik Süß
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 <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Carsten Ziegeler
In reply to this post by Stefan Seifert
2014-08-12 10:36 GMT+02:00 Stefan Seifert <[hidden email]>:

> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Alexander Saar
In reply to this post by Stefan Seifert
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 <[hidden email]>
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: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [RT] Multi Tenancy

Stefan Seifert

>-----Original Message-----
>From: Alexander Saar [mailto:[hidden email]]
>Sent: Tuesday, August 12, 2014 8:34 PM
>To: [hidden email]
>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
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Alexander Klimetschek-2
In reply to this post by Carsten Ziegeler
Carsten Ziegeler <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Alexander Klimetschek-2
In reply to this post by Dominik Süß
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üß <[hidden email]> 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 <[hidden email]>
> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: [RT] Multi Tenancy

Carsten Ziegeler
In reply to this post by Alexander Klimetschek-2
Am 12.08.2014 23:19 schrieb "Alexander Klimetschek" <[hidden email]>:
>
> Carsten Ziegeler <[hidden email]> 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