Access Control
Fine-grained access control for content, folders, and API endpoints.
DA has its own access-control layer, separate from whatever permissions exist in AEM. It's built around access control lists (ACLs) declared once per organization, and it governs who can read or write content, folders, sheets, and media in DA.
Declaring ACLs
ACLs live in a permissions configuration sheet with three columns: path (the resource being governed), groups (who the rule applies to), and actions (what they're allowed to do).
Actions
read— can view the resourcewrite— can modify the resource; write always includes read- empty — explicitly no access
Specifying groups
The groups column accepts a comma-separated list of identifiers, mixed and matched as needed:
- A plain email address, e.g.
joe@bloggs.com - An IMS Organization ID, e.g.
FEDCBA987654321 - An IMS Organization ID plus a group name, e.g.
FEDCBA987654321/My Group 1 - An IMS Organization ID plus an email, e.g.
FEDCBA987654321/joe@bloggs.com
Path syntax
DA doesn't distinguish folders from documents when matching paths — the same pattern language covers both, and a trailing .html can be used to disambiguate a document from a folder of the same name.
/project/dir/document1— a specific document/project/dir/sheet1.json— a specific sheet/project/dir/img1.jpeg— a specific image, PDF, or other media asset/project/dir/subdir1/— a specific folder/project/dir/**— everything under a directory, excluding the directory itself/project/dir/+**— everything under a directory, including the directory itselfCONFIG— access to the organization's own configurationACLTRACE— a temporary, debugging-only path for tracing how permissions were resolved
How permissions resolve
For each group a user belongs to, DA finds the longest matching path in the permissions sheet and takes the actions listed there. Row order in the sheet doesn't matter — everything is sorted by path length at evaluation time. Once every matching group has contributed its actions, the results are merged into a single, unioned permission set for that user on that resource.
Bootstrapping a configuration
The first row you add to any permissions sheet should grant yourself write on CONFIG, otherwise it's easy to lock every admin — including yourself — out of the site's own configuration.
path groups actions
CONFIG myuser@email.com writeReading permissions from the API
- 401 — an anonymous request has no access to the resource
- 403 — an authenticated request was denied
x-da-actionsheader — hints at the resolved actions for the request, e.g.path=readorpath=read,writex-da-child-actionsheader — on list responses, hints at the actions available on child items of a folder