Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

Manage Search Requirements in Multi-Tenancy AEM Environment

bsr78033597
Level 2
Level 2

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.

 

AEM Assets search
1 Accepted Solution
davidjgonzalezz
Correct answer by
Employee
Employee

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.

View solution in original post

1 Reply
davidjgonzalezz
Correct answer by
Employee
Employee

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.

View solution in original post