Manage Search Requirements in Multi-Tenancy AEM Environment

[#1]

Hi Experts,

Need your advise.

Background:
We have a multi-tenant AEM Assets environment with two brands, where either brand users can't see each others assets including in omni search results (managed through Permissions). We currently have a taxonomy like /content/dam/brand-1/.. and /content/dam/brand-2/.. They both share the same metadata schema and we don't have any cross-brand user use-cases.

Problem statement:
Brand-2 has search requirements that are contradictory to Brand-1. For e.g. Brand-1 should NOT be able to search the keyword against a particular metadata property while Brand-2 should be. Hence, we have a situation where we can't handle both search requirements using one custom search index definition (?) and there's also no way to explicitly define which Index to pick per content path or per User/group (?)

So, I would like to know your views on possible solutions ?

Thanks.

[#2 · Accepted solution]

You are correct, Omnisearch Asset Search Rail is global across all tenants. There are 2 main (custom) ways to "tenantize" it's behavior.

The first is to ACL the search predicate fields nodes for the Omnisearch rail under /conf/global/...  Obviously, this will not satisfy your requirement, since your requirement is to disallow Fulltext terms to be evaluated against specific JCR properties.

I believe the only way to achieve your use case it to permission the properties themselves using Oak's built-in restrictions: https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Built-in_Restrictions

There are a few possible approaches to do this, depending on how flexible you are with your implementation, ill list the in order of preference:

1.  Create 2 JCR property namespaces "brand1:" and "brand2:" ... the brand1: namespace indicates the property is ONLY used by Brand 1 users, and brand2: for brand 2.

Then you can use the "rep:prefixes" restriction to say "only User Group Brand1 can read "brand1:" prefixes properties (and likewise for Brand2).

If you cannot set custom namespaces (ex. the property you want is already namespaced with say, dc:)  ...

2. Use "rep:itemNames" to permissions a specific property name(ex: rep:itemItems = [ brand1Keyword ] )

3. Use "rep:glob" to permissions a property name qualified by a parent node structure (ex. rep:glob = */jcr:content/metadata/brand1Keyword )

Of course, this approach prevents the other brand's users from ever seeing values in these fields as well - so they would not show up on Asset Details, etc.