[Phase 2] - Gated Content Experiences

[kunwarsaluja]

[Phase 2] - Gated Content Experiences

reference : https://github.com/nawaz-adobe/aem-protection-worker/blob/main/README.md

[mhaack]

Dirk's team is working on a core product solution for this, that should be considered.

[kunwarsaluja]

@mhaack I heard from Jean Kautzman earlier that they are working on a similar feature but thats only xwalk ? SITES-37804 and very limited in capability as a first step.

I think we would want to showcase this usecase from DA first solution but happy to connect incase we have a better solution than the above CDN solution as in the one-pager at https://github.com/nawaz-adobe/aem-protection-worker/blob/main/README.md

We have a live customer (CME group) using this in production with DA level authoring support too

@amol-anand @gilliankrause

[mhaack]

The part JC is working one consists out of two parts:

• authoring for xwalk
• edge worker for CDN

The first part can be ignored for DA. And we need a replacement for that. Little app to manage the cug headers etc.

The worker part IMHO should be reusable and work with any content source, does not matter if DA or XWalk or sharepoint. If that is part of the product it should be reused.

[kunwarsaluja]

@mhaack Last discussion I had with JC, the solution in the initial stages was only for usecases where the whole sub content tree are protected/gated (managed by sheet and response headers) but doesnt go into usecases where we have gated content on block/section/page level driven by metadata or classes (sample page here)

I think this might need some extra discussion later on and decide what we want to put in the demo coz both usecases make sense

[mhaack]

I understand, the solution by JC is on page level only and no use cases for block/section level. However these maybe should fragments on its own, of course protected and fetched client side.

In any case instead of building something specific for demo, I recommend doing it together. Also the DA App part to manage the permissions should be part of the product and we should build this together. cc: @jckautzmann

[jckautzmann]

Hey — thanks for looping me in. Here's where we are on the CUG / gated content front:

1. Product solution for AEM authoring (xwalk)

On the AEM side, we've built a product-level CUG authoring experience for xwalk sites. Authors define access rules in a closed-user-groups spreadsheet (path patterns, authentication requirements, and allowed groups), and when they publish it, the rules are pushed as response headers to the Config Service — no code changes needed.

Protecting Content with Closed User Groups (CUG)

2. Summit portal — edge worker for DA (WIP)

We're building a summit portal demo using DA for authoring and a Cloudflare edge worker for CDN enforcement. The worker proxies requests to the EDS origin, reads the x-aem-cug-required / x-aem-cug-groups response headers from the Config Service, and enforces access control at the edge — redirecting to OAuth login (Adobe IMS, configurable) when needed, checking group membership, and managing sessions via Cloudflare KV.

It also includes a portal redirect (/auth/portal) that routes each user to a group-specific landing page based on a DA-authored mapping spreadsheet, and an admin endpoint (/auth/cug-headers) that pushes the CUG rules from the DA sheet to the Config Service.

The worker is live at summit-portal.franklin-prod.workers.dev and is content-source-agnostic — it reads standard x-aem-cug-* headers regardless of whether the content was authored in DA, AEM Author, or SharePoint.

[jckautzmann]

@kunwarsaluja FYI: I added some support (POC) for block-level authorization/personalization to the summit portal. I implemented a user-group-teaser block and added it to the home page (https://act.aem.now/):

• If the user is not signed in, the block is not shown
• If the user is signed in, it renders the teaser fragment defined for their customer, e.g. /customers/0-9/000-demo/teaser. The teaser is automatically protected by the CUG headers defined at /closed-user-groups, as it sits below the customer portal path.
• source code: https://github.com/aemsites/summit-portal/tree/main/blocks/user-group-teaser

The only caveat is that /closed-user-groups-mapping.json, which maps groups to customer portal paths, is accessible to all signed-in users (though it doesn't grant access to the portals themselves).

cc: @mhaack