[RT] Ideas for a multi-tenant and multi-module content model

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

I've been thinking a lot about a content model that would help Sling
applications be naturally friendly to multi-tenancy and to continuous
deployment where multiple versions of modules need to coexist.

I have now written those thoughts down at
https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model

Feedback is welcome but please keep in mind that this is mostly just
thinking outloud at this point.

Credit goes to Dominik Suess for the assemblies idea, it looks like
this intermediate routing layer might help make sense of complex
multi-T and multi-M systems.

-Bertrand

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Feb 2, 2015 at 10:39 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...yes, I think a full example would really help - I think the changes for
> script resolution go in the same direction as a prototype I did long
> time ago (just need to find the code)....

Cool, I'm hoping to have some working code by tomorrow to expose the
ideas more clearly.

So far it looks like the main thing is to make our servlet/script
resolver stateless, to be able to compute a tenant-specific search
path first and then use that path to find scripts and servlets.

-Bertrand

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Feb 2, 2015 at 10:39 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I think a full example would really help...

I now have a reasonably working prototype, details at SLING-4386 in
the "Working proof of concept, February 5th, 2015" section.

It shows how content from different tenants is rendered by scripts
from different versions of a (minimal) module, although the resource
types are the same.

The nice thing is that the changes to Sling are minimal, see there for details.

All just a prototype for now, but I like the way it's going - allowing
old and new-style apps to coexist as this does would certainly help.

In case you're wondering, there's nothing in there as far as
tenant-specific OSGi services are concerned so far, except that a
tenant can define which default servlets are available to render its
resources.

-Bertrand

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Carsten Ziegeler <cz...@apache.org>]

Thanks Bertrand for taking this up,

Am 30.01.15 um 14:19 schrieb Alexander Saar:
> Hi,
> 
> thanks for sharing this. The approach sounds reasonable, but it would
> probably help to have a more concrete example for the content structure
> including the resource type mappings.

yes, I think a full example would really help - I think the changes for
script resolution go in the same direction as a prototype I did long
time ago (just need to find the code).

Carsten

> 
> Will /tenant/T/home only contain groups used define tenant membership? Or
> will it also contain the actual users? There can be scenarios where a user
> could have access to multiple tenants while in other scenarios this may not
> be desirable.
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Alexander Saar <al...@googlemail.com>]

Hi,

thanks for sharing this. The approach sounds reasonable, but it would
probably help to have a more concrete example for the content structure
including the resource type mappings.

Will /tenant/T/home only contain groups used define tenant membership? Or
will it also contain the actual users? There can be scenarios where a user
could have access to multiple tenants while in other scenarios this may not
be desirable.

Regards
Alex


On Thu, Jan 29, 2015 at 4:11 PM, Dominik Süß <do...@gmail.com>
wrote:

> Hi Bertrand,
>
> ok the way how you describe it you'd actually do something "above" the
> existing ResourceResolution. I'm not really sure if we win so much with
> that - a lock in of the resourceType  might be absolutely sufficient and
> wouldn't add further complexity to understand resolution mechanisms.
>
> So we would have something that would define
>
> a) Tenant /content/xyz would be bound to assembly_a (for now skipping the
> question of versioned lookup that could be searchpath sepecific or another
> mechansism)
> b) this binding would force the resourceResolver to resolve resources
> underneath /content/xyz only if they are located underneath
> <searchpath>/assembly_a
> c) the apps folder of assembly_a would contain the rendering resources or
> have the assembly specific servlets mapped to. Every servlet or script used
> within the assembly app would have a representation there which could as
> minimum just have a resourceSuperType that points to the modules
> resourceType and therefore expose the plain feature. Assembly specific
> overlays can be applied to these mapping nodes at any time without impact
> on third assemblies (unless we allow chained assemblies)
>
> The beauty of that would be that it just requires addition of mapping logic
> and the constraints in the resourceResolver but no further addition.
>
> Sidenote:
> - I'm leaving out details like static inclussions with predefined
> resourceTypes within scripts the assembly where we would have to clarify if
> those are ok or if we completely abandon mapping beyond superType
> resolution to enforce a unique way of declaring mapped Types within an
> assembly.
>
> Cheers
> Dominik
>
>
> On Thu, Jan 29, 2015 at 3:03 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > Hi Dominik,
> >
> > On Thu, Jan 29, 2015 at 2:52 PM, Dominik Süß <do...@gmail.com>
> > wrote:
> > > ...I had a chance to look at that model yesterday and absolutely think
> > this is
> > > a great way since it is not too far away from what we have right now...
> >
> > Yeah, we might even be able to run an existing Sling instance with
> > /libs and /apps as a "legacy" tenant on this new model by moving the
> > existing content around a bit, to provide a smooth transition.
> >
> > > ...The detail about the constraint to just use an assembly would
> > therefore be
> > > a constraint on the resourceType Path that would be evaluated by the
> > > resourceResolver and ignores resourceType not being part of the
> > assembly....
> >
> > I was thinking a bit differently, resource types just need to start
> > with the module path like blog/post for the blog module.
> >
> > Then, the script resolver only considers /assemblies/T where T is the
> > tenant ID, looks for a script or servlet reference resolution for
> > blog/post under there, and remaps that to the actual module script
> > based on which modules the assembly points to.
> >
> > All this needs to be proved by some working code if we want to
> > seriously kick the tires of this new model.
> >
> > -Bertrand
> >
>



-- 
Alexander Saar

Mobile: +49.172.8280280
E-Mail: alexander.saar@gmail.com

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Dominik Süß <do...@gmail.com>]

Hi Bertrand,

ok the way how you describe it you'd actually do something "above" the
existing ResourceResolution. I'm not really sure if we win so much with
that - a lock in of the resourceType  might be absolutely sufficient and
wouldn't add further complexity to understand resolution mechanisms.

So we would have something that would define

a) Tenant /content/xyz would be bound to assembly_a (for now skipping the
question of versioned lookup that could be searchpath sepecific or another
mechansism)
b) this binding would force the resourceResolver to resolve resources
underneath /content/xyz only if they are located underneath
<searchpath>/assembly_a
c) the apps folder of assembly_a would contain the rendering resources or
have the assembly specific servlets mapped to. Every servlet or script used
within the assembly app would have a representation there which could as
minimum just have a resourceSuperType that points to the modules
resourceType and therefore expose the plain feature. Assembly specific
overlays can be applied to these mapping nodes at any time without impact
on third assemblies (unless we allow chained assemblies)

The beauty of that would be that it just requires addition of mapping logic
and the constraints in the resourceResolver but no further addition.

Sidenote:
- I'm leaving out details like static inclussions with predefined
resourceTypes within scripts the assembly where we would have to clarify if
those are ok or if we completely abandon mapping beyond superType
resolution to enforce a unique way of declaring mapped Types within an
assembly.

Cheers
Dominik


On Thu, Jan 29, 2015 at 3:03 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:

> Hi Dominik,
>
> On Thu, Jan 29, 2015 at 2:52 PM, Dominik Süß <do...@gmail.com>
> wrote:
> > ...I had a chance to look at that model yesterday and absolutely think
> this is
> > a great way since it is not too far away from what we have right now...
>
> Yeah, we might even be able to run an existing Sling instance with
> /libs and /apps as a "legacy" tenant on this new model by moving the
> existing content around a bit, to provide a smooth transition.
>
> > ...The detail about the constraint to just use an assembly would
> therefore be
> > a constraint on the resourceType Path that would be evaluated by the
> > resourceResolver and ignores resourceType not being part of the
> assembly....
>
> I was thinking a bit differently, resource types just need to start
> with the module path like blog/post for the blog module.
>
> Then, the script resolver only considers /assemblies/T where T is the
> tenant ID, looks for a script or servlet reference resolution for
> blog/post under there, and remaps that to the actual module script
> based on which modules the assembly points to.
>
> All this needs to be proved by some working code if we want to
> seriously kick the tires of this new model.
>
> -Bertrand
>

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Bertrand Delacretaz <bd...@apache.org>]

Hi Dominik,

On Thu, Jan 29, 2015 at 2:52 PM, Dominik Süß <do...@gmail.com> wrote:
> ...I had a chance to look at that model yesterday and absolutely think this is
> a great way since it is not too far away from what we have right now...

Yeah, we might even be able to run an existing Sling instance with
/libs and /apps as a "legacy" tenant on this new model by moving the
existing content around a bit, to provide a smooth transition.

> ...The detail about the constraint to just use an assembly would therefore be
> a constraint on the resourceType Path that would be evaluated by the
> resourceResolver and ignores resourceType not being part of the assembly....

I was thinking a bit differently, resource types just need to start
with the module path like blog/post for the blog module.

Then, the script resolver only considers /assemblies/T where T is the
tenant ID, looks for a script or servlet reference resolution for
blog/post under there, and remaps that to the actual module script
based on which modules the assembly points to.

All this needs to be proved by some working code if we want to
seriously kick the tires of this new model.

-Bertrand

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Dominik Süß <do...@gmail.com>]

Hi Bertrand,

I had a chance to look at that model yesterday and absolutely think this is
a great way since it is not too far away from what we have right now and
what could be seen as best practice for compositing and customizing
applications based on Sling and other propietary "modules".

I think visualizing your blog  example with some boxes and lines would help
others that yet had not a chance to discuss this to understand how this
could work out.

What is a bit hard to read from that model is what kind of changes would
need to be done in Sling to make that work (just the high level changes not
the implementation detail).

The detail about the constraint to just use an assembly would therefore be
a constraint on the resourceType Path that would be evaluated by the
resourceResolver and ignores resourceType not being part of the assembly.
The mapping to functionality/resourceTypes out of the underlying modules
would be realized through those mappin resources with the resourceSuperType
(which then "could" point out of the assembly).

I hope my addition helps a bit to clarify the base idea of the assembly
pattern and does not create more confusion.

Best regards,
Dominik

On Tue, Jan 27, 2015 at 6:55 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:

> Hi,
>
> I've been thinking a lot about a content model that would help Sling
> applications be naturally friendly to multi-tenancy and to continuous
> deployment where multiple versions of modules need to coexist.
>
> I have now written those thoughts down at
>
> https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model
>
> Feedback is welcome but please keep in mind that this is mostly just
> thinking outloud at this point.
>
> Credit goes to Dominik Suess for the assemblies idea, it looks like
> this intermediate routing layer might help make sense of complex
> multi-T and multi-M systems.
>
> -Bertrand
>

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Bertrand Delacretaz <bd...@apache.org>]

Hi Alex,

On Wed, Feb 4, 2015 at 9:00 AM, Alexander Saar
<al...@googlemail.com> wrote:
>...one question I asked myself
> is if it wouldn't make sense to move the actual /content also under the
> respective /tenants/T/content. Then we would have everything in one place
> which may make access control and isolation event easier....

That might be an option - my current SLING-4386 prototype simply uses
a sling:siteRoot=true property to derive the tenant ID from the
content path, so it would work with content in various places.

-Bertrand

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Alexander Saar <al...@googlemail.com>]

Hi Bertrand,

this may be something for the next version, but one question I asked myself
is if it wouldn't make sense to move the actual /content also under the
respective /tenants/T/content. Then we would have everything in one place
which may make access control and isolation event easier.

Alex


On Mon, Feb 2, 2015 at 4:30 PM, Bertrand Delacretaz <bd...@apache.org>
wrote:

> Hi Stefan,
>
> Thanks for your feedback!
>
> On Mon, Feb 2, 2015 at 3:49 PM, Stefan Seifert <ss...@pro-vision.de>
> wrote:
> > ...* multi tenant scenario
> > - what you describe is a solution for the "virtual hosting" multi-tenant
> scenario as described here https://cwiki.apache.org/confluence/x/So2uAg
> > - if this should be usable for the "massive multi site" scenario as well
> additional requirements like nested tenants should be taken into account as
> well....
>
> Sure - as mentioned [1] is only about defining a content model that's
> multi-tenant friendly. There's a number of "details" to figure out ;-)
>
> [1]
> https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model
>
> >
> > * tenant-specific OSGi bundles
> > - you plan for a solution to deploy tenant-specific OSGi bundles (using
> the amdatu solution or something similar)...
>
> That's useful for any multi-tenant setup, yes.
>
> > ...- how do you want to protect against malicious code that may be
> introduced by a tenant-specific bundle?...
>
> I don't know at this point, and if that's not possible running the
> request processing code for all (hostile) tenants in a single OSGi
> framework might not be possible.
>
> > ...- are we sure we find ways to protect against this in reliable
> manner?..
>
> No, not me at least. But a tenant-friendly content model would help
> many scenarios anyway, IMO.
>
> >
> > * tenant identification
> > - you propose that the tenant identifier is always the next level below
> /content.
> > - this is quite inflexible, it should be possible to allow a deeper
> structure to group tenants,...
>
> Yes, I realized that as well, we'll need some kind of marker property
> that says where the top of a tenant content subtree is.
>
> >
> > * modules/X/content/default
> > - i do not fully understand this section, how should this work if
> multiple independent modules are used by a tenant,...
>
> That might for example be CSS styles that a particular version of a
> particular module needs. Not fully defined so far.
>
> For now I'm trying to stick to the "can we mix multiple versions of a
> module and use various combinations for various tenants" problem. I
> fully agree with you that a hostile multi-tenant environment requires
> much more, but I think solving that particular problem is a useful
> small step.
>
> -Bertrand
>



-- 
Alexander Saar

Mobile: +49.172.8280280
E-Mail: alexander.saar@gmail.com

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Bertrand Delacretaz <bd...@apache.org>]

Hi Stefan,

Thanks for your feedback!

On Mon, Feb 2, 2015 at 3:49 PM, Stefan Seifert <ss...@pro-vision.de> wrote:
> ...* multi tenant scenario
> - what you describe is a solution for the "virtual hosting" multi-tenant scenario as described here https://cwiki.apache.org/confluence/x/So2uAg
> - if this should be usable for the "massive multi site" scenario as well additional requirements like nested tenants should be taken into account as well....

Sure - as mentioned [1] is only about defining a content model that's
multi-tenant friendly. There's a number of "details" to figure out ;-)

[1] https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model

>
> * tenant-specific OSGi bundles
> - you plan for a solution to deploy tenant-specific OSGi bundles (using the amdatu solution or something similar)...

That's useful for any multi-tenant setup, yes.

> ...- how do you want to protect against malicious code that may be introduced by a tenant-specific bundle?...

I don't know at this point, and if that's not possible running the
request processing code for all (hostile) tenants in a single OSGi
framework might not be possible.

> ...- are we sure we find ways to protect against this in reliable manner?..

No, not me at least. But a tenant-friendly content model would help
many scenarios anyway, IMO.

>
> * tenant identification
> - you propose that the tenant identifier is always the next level below /content.
> - this is quite inflexible, it should be possible to allow a deeper structure to group tenants,...

Yes, I realized that as well, we'll need some kind of marker property
that says where the top of a tenant content subtree is.

>
> * modules/X/content/default
> - i do not fully understand this section, how should this work if multiple independent modules are used by a tenant,...

That might for example be CSS styles that a particular version of a
particular module needs. Not fully defined so far.

For now I'm trying to stick to the "can we mix multiple versions of a
module and use various combinations for various tenants" problem. I
fully agree with you that a hostile multi-tenant environment requires
much more, but I think solving that particular problem is a useful
small step.

-Bertrand

RE: [RT] Ideas for a multi-tenant and multi-module content model

[Stefan Seifert <ss...@pro-vision.de>]

hello bertrand.

some notes from my side:

* multi tenant scenario
- what you describe is a solution for the "virtual hosting" multi-tenant scenario as described here https://cwiki.apache.org/confluence/x/So2uAg
- if this should be usable for the "massive multi site" scenario as well additional requirements like nested tenants should be taken into account as well.

* tenant-specific OSGi bundles
- you plan for a solution to deploy tenant-specific OSGi bundles (using the amdatu solution or something similar)
- i think this is a very important point, because a tenant concept that only supports tenant-specific scripts but no tenant-specific OSGi bundles will prevent it to be usable for complex real-world applications
- how do you want to protect against malicious code that may be introduced by a tenant-specific bundle? event with a amdatu-like solution you have to grant access to a lot of core bundles e.g. providing resource resolver or JCR API, and it will be easy for the tenant's code to find ways to get system-wide access to all content in the repositories, including that of other tenants.
- are we sure we find ways to protect against this in reliable manner?

* tenant identification
- you propose that the tenant identifier is always the next level below /content.
- this is quite inflexible, it should be possible to allow a deeper structure to group tenants, and define via configuration or content properties where the tenant identification starts
- this is not only useful for a better overview of the tenants, but for sharding scenarios as well where different groups of tenants are stored at different machines or web centers

* modules/X/content/default
- i do not fully understand this section, how should this work if multiple independent modules are used by a tenant, and if the further content structure below the tenant identification node is not known (he may have multiple sites for example)


stefan


>-----Original Message-----
>From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
>Sent: Tuesday, January 27, 2015 6:55 PM
>To: dev
>Subject: [RT] Ideas for a multi-tenant and multi-module content model
>
>Hi,
>
>I've been thinking a lot about a content model that would help Sling
>applications be naturally friendly to multi-tenancy and to continuous
>deployment where multiple versions of modules need to coexist.
>
>I have now written those thoughts down at
>https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-
>tenant+and+multi-module+content+model
>
>Feedback is welcome but please keep in mind that this is mostly just
>thinking outloud at this point.
>
>Credit goes to Dominik Suess for the assemblies idea, it looks like
>this intermediate routing layer might help make sense of complex
>multi-T and multi-M systems.
>
>-Bertrand