AEM SAML sign-in shows the login page when the SAML handler path is not mapped correctly
When SAML SSO is enabled in AEM, you can still see the default login page instead of being redirected to the identity provider if the SAML authentication handler is not mapped to the correct paths. This happens when the handler does not listen on the required protected path or on / when SSO should apply site-wide. In that state, AEM does not invoke the SAML flow for the requested resource and falls back to the standard login page. Review the SAML handler path configuration, map it to the required protected paths or /, and test access again.
Description description
Environment:
- Adobe Experience Manager 6.5
- Adobe Experience Manager as a Cloud Service
- AEM Publish with SAML authentication
Issue/Symptoms:
- Users see the AEM login page instead of being redirected to the identity provider.
- SAML SSO is enabled, but protected pages do not trigger the SAML flow.
- Authentication works only for some paths and not for others.
- SSO does not start when users access pages that should be protected.
Cause:
The SAML authentication handler is not mapped to the correct repository paths. When the configured path does not include the requested protected content, or when / is not configured for site-wide SSO, AEM does not invoke the SAML handler and instead shows the standard login page.
Resolution resolution
To resolve SAML sign-in issues caused by incorrect SAML path mapping, follow these steps:
- Open AEM Web Console
>OSGi and locate the Adobe Granite SAML 2.0 Authentication Handler configuration. - Review the configured Bind paths value and compare it with the path of the protected content.
- Set Bind paths to the required protected path. If SSO must apply to all pages, set the value to
/. - Save or deploy the updated SAML configuration in the appropriate environment.
- Access a protected page again and confirm that the browser redirects to the identity provider instead of showing the AEM login page.
- If the login page still appears, confirm that the requested resource falls under the configured Bind paths value and that
/is used when SSO should apply site-wide.