Expand my Community achievements bar.

SOLVED

Role based header menu's

Avatar

Level 5

Hi All,

Using AEM as an intranet portal  - following are my thoughts on enabling role based menu navigation for end user - some links hidden for certain roles / some links disabled

option 1 - client context would be my recommendation any view on this or any other better?

1) use the client context with custom role trait and deliver teaser (pre authored with multiple menus for the different roles) - gives the content author to realize the experience and extensible for additional roles

2) use JavaScript based function checks along with css hide/show - needs a code change every time

3) try it using server side - like role based checks on jsp/jstl. but if these pages are cached then big issue

4) create menu links as content fragments and tag with separate role based etc/tags and use a servlet json to fetch the links (on ajax) and do a client side layout

can we still cache the pages with dynamic menu ?

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi,

The question is: Does the header need to show "personalized" information or only "targeted" information? Personalized means, that this kind of information must be reachable by other unauthorized roles. Targeted means, that it doesn't matter if other people, which normally don't see this information, get access to it.

In the second case you can use the simple selector-based approach as described by Sham HC. In the first case you need to combine it with permission sensitive caching (or just have it dynamically created on AEM side, if you have too many combinations of groups, which will cause problems when you create that many files...)

kind regards,
Jörg

View solution in original post

8 Replies

Avatar

Correct answer by
Employee Advisor

Hi,

The question is: Does the header need to show "personalized" information or only "targeted" information? Personalized means, that this kind of information must be reachable by other unauthorized roles. Targeted means, that it doesn't matter if other people, which normally don't see this information, get access to it.

In the second case you can use the simple selector-based approach as described by Sham HC. In the first case you need to combine it with permission sensitive caching (or just have it dynamically created on AEM side, if you have too many combinations of groups, which will cause problems when you create that many files...)

kind regards,
Jörg

Avatar

Level 10
  • You are making things too complicated to use client context ....
  • Designing nice structure & assigning out of the box acl with custom simple navigation component can solve this issue.
  • use selector for navigation component. So that selector equals role & there by you can cache it.

Avatar

Level 5
       yes these 200k users will be mapped to multiple roles in identity and would like to use that information via client context custom data store for authorization can white list the URLs for roles with regex patterns as custom config acl like we white list selectors or use saml to authorize the URL and maintain content structure based to roles aligned to a common blueprint Or Would it be better to have 200k users maintained and mapped to groups in crx and use cug? But as I have stated earlier managing these end users /group in crx could be cumbersome with arm ui and even if use psc for caching all the pages would required to be authorized as this is a menu component which is available on all pages

Avatar

Level 5

Hi,

Thanks for the info, I did not specify this earlier , In my case i do not want to store end user profile in AEM so after external authentication(SAML) want to drive restricted menus on headers having a teaser and different menu campaigns attached created by authors .This gives authors to preview the different menus based on client context UI as custom data store would have loaded the traits to support 2,00,000 users(different user roles).

But if go with ACL based approach I am thinking of user / groups/acl management within AEM UI being more cumbersome to support 2,00,000 users 

Also the links in menu can also be external links so it might not fit a direct navigation component within a content structure.

And for internal links when content grows ACL check for content will be a challenges at it will be applied for each resource request practically and author have to modify ACL if any updates to menu listing.

Now please tell me if client context works well or i have to go by ACL with users maintained in AEM.

Also it will be on AEM TarMK with multiple publish instance to drive the user load.

Also these menus will be part all the pages and is it possible to cache the page which has a client context target - I feel yes as it is going to an Ajax call to load the role based menus - Please let me know other wise

Overall this menu should be visible for the user role and has to be support without any future code change as well.

as in below and the teasers to have different menu expereinces

https://docs.adobe.com/content/docs/en/aem/6-0/develop/personalization/client-context/_jcr_content/p...

Avatar

Level 5

Hi,

Thanks for the info, I did not specify this earlier , In my case i do not want to store end user profile in AEM so after external authentication(SAML) want to drive restricted menus on headers having a teaser and different menu campaigns attached created by authors .This gives authors to preview the different menus based on client context UI as custom data store would have loaded the traits to support 2,00,000 users(different user roles).

But if go with ACL based approach I am thinking of user / groups/acl management within AEM UI being more cumbersome to support 2,00,000 users 

Also the links in menu can also be external links so it might not fit a direct navigation component within a content structure.

And for internal links when content grows ACL check for content will be a challenges at it will be applied for each resource request practically and author have to modify ACL if any updates to menu listing.

Now please tell me if client context works well or i have to go by ACL with users maintained in AEM.

Also it will be on AEM TarMK with multiple publish instance to drive the user load.

Also these menus will be part all the pages and is it possible to cache the page which has a client context target - I feel yes as it is going to an Ajax call to load the role based menus - Please let me know other wise

Overall this menu should be visible for the user role and has to be support without any future code change as well.

as in below and the teasers to have different menu expereinces

https://docs.adobe.com/content/docs/en/aem/6-0/develop/personalization/client-context/_jcr_content/p...

+ sharing similar thread where CUG is not recommended - please share your thoughts on client context vs cug ?

http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

Avatar

Employee Advisor

Hi,

With the 200k users you have a number of problems, with the biggest being the number of individual groups. At one point all these groups are used to restrict access on the content. If you don't plan well, the management of the ACLs will become very hard.

If you implement the navigation using the client context, that's fine. Then you let the client (browser) decide what is displayed as menu. That might be ok... But in the end you end up with the menu being rendered on the server side, based on the provided information. Or do you plan do load all possible menu items and then decide on the client side which one to display?

kind regards,
Jörg

Avatar

Level 5

Thanks Jörg.

Approach Still it is not yet decided we might use both CUG for authorization and Client Context for cache safe personalization of menu header as it is via ajax and also give author control over different experience.And still the menu fragments can be cached.

Avatar

Level 10

Are you trynig to support 200 K user roles?