Page History

In this scenario Sling is used for "virtual hosting", that means hosting multiple tenants that should be fully isolated.

The main goal according to the wikipedia definition is cost saving, that means instead of a single sling instance and the corresponding infrastructure for each tenant all tenants are hosted in a shared instance. There is no need for content sharing.

Usually the users of each tenant are distinct from each other.

In this scenario the whole instance is used by one corporation which has the need to host a huge number of sites (e.g. 100 or 1,000 or more sites) in a single instance.

Besides cost saving of having a single instance, additional goals are the support of content sharing. Although there are some users that have only access to a single site, there are plenty of users that can have access to multiple sites (read/

write or only read).

To structure the huge number of sites a hierarchy of regions and subregions is used.

• Tenants are defined centrally and up-front
• Tenants are completely isolated from each other
• A flat list of tenants is acceptable

• Tenants are defined implicitly by the content structuring in regions and sites
• It is required to have "nested tenants" with some sort of inheritance

• A user can access only the content of his tenant, he is not able to see any content of other tenants. Inside his tenant, ACLs may prevent him from reading or writing some of the tenants content.

• A user can read and write all content of the sites/regions he has access to (he can have more read access than write access).

• Tenants must be able to overlay the Internationalization so that they can provide and use their own translations

• It has to be possible to overlay translations per region or site.
• Sometimes translations to a foreign language can be shared between regions/sites, although this is limited due to different variants of the same language in different countries

• Developers of the tenant can upload their own scripts with custom code to the instance. Inside the tenant only the custom scripts and the global ones can be used, no scripts of other tenants.
• It is possible to overlay scripts provided globally with tenant-specific ones. It is possible to overlay both scripts at /libs and at /apps.

• The global scripts provided by applications can be used in all sites and regions. Although it is possible that some custom scripts are developed specific for a region or site, it is not important to hide this extensions from other sites/regions - they may wish to use them as well.
• Overlaying scripts is only used to overlay OOTB components from /libs with specific ones at /apps.

• Bundles are deployed globally, all tenants can use them
• The tenant has the need to adapt certain configuration settings for his tenant - this configuration is used only for his content and scripts.

• Bundles are deployed globally, all regions and sites can use them
• It may be required to adapt certain configuration settings per region and/or site

• Usage of admin session in code is problematic, because it gives access to all custom scripts and all content of other tenants
• All code uploaded by tenants has to be considered potentially malicious, the tenants do not trust each other
• A "Tenant Admin" user concept is required

• Usage of admin session is not problematic, because all code is maintained and governed centrally

• It is required to be able to adapt certain configuration settings on a tenant level
• It may be required to to define separate configuration for different sites of a tenant as well

• It is required to support configurations on multiple levels - globally, regions, sub-regions, sites
• Configuration inheritance between the levels is required
• Access to the different configuration levels can be controlled by ACLs