Mitigating authentication bypass risk in Adobe Experience Manager Assets using Dispatcher filter rules
This article explains how to review Dispatcher filter rules for the AEM Assets login endpoint excluded from SAML authentication. Dispatcher filters restrict requests by URL and method; they do not authenticate users or replace AEM repository permissions. To address the risk, verify the endpoint and SAML callback paths, review the effective filter order and repository permissions, and test the changes in a non-production environment before production deployment.
Description description
Environment
Adobe Experience Manager as a Cloud Service environments using AEM Assets, SAML authentication, and Dispatcher
Issue/Symptoms
- A security review identifies an AEM Assets login endpoint that is excluded from SAML authentication.
- The Dispatcher configuration does not restrict requests to that endpoint as intended.
- The security team needs to verify whether the endpoint exposes functionality or data to unauthenticated requests.
Cause
A SAML-excluded endpoint does not invoke the SAML challenge for requests to that path. Dispatcher filters match request attributes such as URL and method; they do not authenticate the caller. A filter allow rule does not grant authentication or replace repository permissions. Protect sensitive functionality and data with the applicable AEM authentication and repository permissions, and use Dispatcher as an additional access-filtering layer.
Resolution resolution
Follow the steps below to resolve the issue.
-
Review the Dispatcher filter rules and identify any entries that apply to the login endpoint, such as
/libs/granite/core/content/login*). -
Update your Dispatcher configuration to add the following rules:
- Deny all requests to the login node by default:
/0100 { /type "deny" /url "/libs/granite/core/content/login*" }- Allow only legitimate GET requests to the login page.
/0101 { /type "allow" /method "GET" /url "/libs/granite/core/content/login.html" }- Allow only the form POST target used by the login flow.
/0102 { /type "allow" /method "POST" /url "/libs/granite/core/content/login.html/j_security_check" } -
Verify that the rules are ordered correctly. Because Dispatcher filter rules use a last-match-wins evaluation model, place the broader deny rule before the more specific allow rules.
-
Deploy the updated Dispatcher configuration in a non-production environment.
-
Validate that only legitimate login requests are allowed and that all other requests to the login endpoint are denied.
-
Verify that the login process continues to function as expected.
-
After validating the configuration, deploy the changes to the production environment.
-
Monitor logs and access attempts to verify that the vulnerability is mitigated and that unauthorized access attempts are blocked.