Authorization solution proposal

[auniverseaway]

Context

As of today, DA & Helix do not offer fine-grained authorization. If you can perform an action, you can perform that action across the entire content tree.

DA takes this simplicity to another level: if you have access to a project, you can read, write, edit, destroy, etc.

Existing CMSes (SharePoint, Google Drive, AEM, etc.) provide affordances to prevent certain users from performing certain tasks. This is combined with path-based access control. They also provide "locking" affordances

To work around Helix's lack of path-based preview / publish control, Milo implemented a gating feature. It uses a spreadsheet lookup to determine path, user, group, and time. The gist is: while Milo cannot change AEM Admin API behavior, it can disable preview and publish buttons across the various UIs.

Proposal

I believe a sheet-based approach to ACL is the right approach. Storing this information w/ the resource (AEM-style) creates maintainability problems. From a performance perspective, with a resource-based approach, we would have to traverse up a tree to determine the lowest ACL that applies. This is non-ideal.

With a sheet based approach, we effectively get an index for free while also providing a birds eye view of all access control. When a user initiates an action, we have the sheet in cache (live, admin, collab, content) and can look up the permission quickly.

If we pair this with a timing column we can prevent actions during specific periods of time. This could be during earnings calls or other high profile restricted change periods.

Helix

In doing the above, we are able to provide a path to fine-grained authorization against preview actions. When Helix requests our content (content.da.live) they can provide the same user authorization token back to us, we can get the user, read the sheet, and determine if we should respond with a 401 / 403 or 200.

The publish action would possibly require more work. As of this writing, Helix does not ask / notify the source content provider of this action. In theory, you may have embargoed content that is OK to preview, but not OK to publish. The current proposal is to have Helix supply a X-Intent: preview|publish (credit: @trieloff) header to DA and it can respond with 401 / 403 or 100.

[trieloff]

Discussed this with @karlpauls on Tuesday. I think it's important for the content source to provide a header like X-Require-Intent: publish, so that Helix can remember that the source is capable of validating publish intents.
That enables us to treat sources that don't have an X-Require-Intent differently from those that do, especially in the case of errors.

When no X-Require-Intent is known, Helix MAY send an OPTIONS/X-Intent request prior to publishing, but can treat all responses other than 401 and 403 as a 200. This is especially true for 404, 400, and 5xx responses. The content source simply does not support authorization, so the current default behavior should stay in place.

When an X-Require-Intent behavior is know, and X-Require-Intent is publish, then Helix MUST send an OPTIONS/X-Intent request and MUST treat every response other than a 200 as a rejection, including an unavailability of the content source.

This way an attacker cannot perform a DOS attack against a content source that has previewed, but unpublished content to evade successful authorization.

[tripodsan]

so that Helix can remember that the source is capable of validating publish intents.

this could be stored with the previewed object. i.e. that it needs extra authorization before it can be published.

[trieloff]

We may save the header in the object, so that the format stays the same.

[tripodsan]

The current proposal is to have Helix supply a X-Intent: preview|publish (credit: @trieloff) header to DA and it can respond with 401 / 403 or 100.

this could be configured in the config service, something like:

content {
  source: {
     url: '<da content source>',
     authorizeOperations: ['publish', 'unpublish'],
   }
}

but in general, what you describe is a way to authorize operations via a (preflight) request. similar to https://www.openpolicyagent.org/
afaiu, the AEM security team is also looking into OPA (cc @anchela). maybe we could use a more generic way, or da implements the OPA protocol )(or something)

[trieloff]

I thought of a config option, but decided that I like less config more than more config.

[anchela]

@tripodsan , we did some initial investigation during garage week 23 but didn't have the opportunity to work on a real-world POC. priorities in 2024 shifted towards completing the IMS-service to unblock API-first needs.

[anchela]

on a general note: there have been some ongoing discussions regarding the future of authorization in the AEM-universe. based on past experiences with AEM and incorporating customer feedback, I am rather tending towards an ABAC authorization model not ACL.

[auniverseaway]

I want to follow up on this (cc @trieloff @tripodsan @karlpauls @sukamat @davidnuescheler)

After thinking through the implications, DA does not want to be in the critical path of publishing. At least not today.

This means we will fall back to the original proposal where DA authorizations would only affect DA & Preview. Fine-grained preview permission can still be achieved by the token + the path Helix sends to us.

From an embargoed content perspective, my hope is that we can use other means (Floodgate on adobe.com, Snapshots everywhere else) to achieve the publish protections we require.

To walk through this, but not fully baked:

1. Embargoed event approaching... Black Friday, SUMMIT, MAX, multi-product release, etc.
2. Administrator locks down preview permissions for site / specific paths.
3. Most authors can only push to a snapshot for matched locked paths.
4. Updates for locked content require an administrator to approve (to make sure no embargoed content leaks).
5. Embargoed content reviews happen on aem.reviews.
6. Time of event, snapshot is released to live.
7. Time of event, preview restrictions are lifted.

adobe.com will follow different flows until further notice... using Floodgate or graybox envs, and I think this is fine. My hope is that through DA, versions, and snapshots, we have a path to remove the need for these custom tools, but this is a much larger task.