Use a dedicated service user/subservice for Redirects Package creation and replication

[koha26]

Type

Improvement

Referenced issue

#3701

Background

The new replication approach is a good optimization because it avoids replicating each redirect rule individually.
However, it is not appropriate to grant authors/content admins broad access to all packages. In practice, this caused issues because editor/content-admin responsibilities are intentionally limited, and they typically do not have access to /etc/packages.

Problem

Current implementation can require UI users (authors/content admins) to have package-related permissions, which violates least-privilege and role separation.

Temporary workaround
Grant limited permissions for package creation/replication to unblock operations.
Proposed long-term solution
Implement package management via a dedicated system user + Sling subservice that performs package creation and replication on behalf of users:

• UI users trigger replication without direct /etc/packages access.
• Backend service performs package operations using service credentials.
• Keep user permissions scoped to redirect configuration only.

Acceptance Criteria

1. Authors/content admins can replicate redirect maps without direct permissions to /etc/packages.
2. Package creation/assembly/replication runs through a dedicated subservice and system user.
3. Service user permissions are minimal and documented (least privilege).
4. Existing redirect replication functionality remains unchanged from a user perspective.
5. Audit/logging clearly shows actions executed by the service user.
6. Tests cover success and failure paths for service resolver acquisition and replication flow.

[YegorKozlov]

@koha26 Thanks or the PR. The service user makes sense, although it makes it harder to control who can publish redirects.
What if we add a condition to ReplicateRedirectMapServlet to check the replication permissions? Something like.

// user needs the crx:replicate role on the redirect node
if(!replicator.checkPermission(session, ACTIVATE, path){
  throw new AccessDeniedException("Access denied. User <userid> does not have permissions to replicate <path>");
}

this way you can only publish redirects if you have crx:replicate on /conf/mysite/settings/redirects

Also, I'd like to narrow the scope the service user to the redirects packages only. Adding a rep:subtrees restriction should do the trick, although I'm not 100% sure it'll work in AEM 6.5. So far the tool is fully compatible with the older versions of AEM.

set ACL for acs-commons-redirects-package-replicator-service
    allow jcr:read,jcr:versionManagement,rep:write,crx:replicate on /etc/packages restriction(rep:subtrees, '/com.adobe.acs.commons.redirects')
    allow jcr:read on /
end

[koha26]

@YegorKozlov, I agree with using a dedicated service user and with narrowing its permissions to redirect packages only.

I would avoid adding a hard permission check (and exception) in ReplicateRedirectMapServlet for end users. That would block valid operational workflows for users who are intentionally limited to redirect management and do not have replication rights. If a user has read/write access to the redirect configuration, they should still be able to trigger redirect publication, while package creation and replication are executed by the service user.

So my preference is:

1. Keep user permissions focused on redirect content (/conf/.../settings/redirects).
2. Execute package creation/replication via subservice.
3. Restrict the service user as tightly as possible (including subtree scoping to redirects package path, if supported across target AEM versions).

If you are good with my approach, I can quickly fix the PR to reflect changes to service user permissions.

[YegorKozlov]

@koha26 I'm good with the approach. Please update the PR.

[koha26]

@YegorKozlov, I have pushed a change that includes a service user declaration. I applied rep:glob, because it's available since Oak 1.0, rep:substrees - only since Oak 1.44.0.

[vhochstein]

Any plans to merge the Pull Request related to this ?