Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

AEM SAML issue - 403 Forbidden

Avatar

Level 2

Hi All,

 

We are trying to integrate Ivanti SAML into AEM publisher. We are getting a 403 error in the saml_login path. (AEM 6.5.20, on-premise)

SibiMa_2-1717533622989.png

 

Added dispatcher rule also as per the below

https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-16873#:~:text=SAML%20A....

I'm still getting the same response. 

 

In dispatcher, we are getting below logs: Assuming the issue is something from publisher based on the below red colored.

SibiMa_1-1717533273848.png

 

The POC from localhost to Okta is successful.

Kindly help to get through this issue. I even tried enabling logs as per the Adobe docs, https://experienceleague.adobe.com/en/docs/experience-manager-65/content/security/saml-2-0-authentic... not getting any clues from here as well about the issue.

 

Thanks in advance!

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 2

Hi All,

 

Thanks for all your responses. We have successfully configured the SAML in a fresh publish instance and it is working fine.

I have followed

https://experienceleague.adobe.com/en/docs/experience-manager-65/content/security/saml-2-0-authentic...

https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-16873#:~:text=Issue%2F.... (Only if using dispatcher) change in the format of rule as below

/0091 { /type "allow" /method "POST" /url "*/saml_login" }

Configuring Apache Sling Authentication Service in config manager

Additionally, Adobe Granite Cross-Origin Resource Sharing Policy configuration.

 

Thanks

View solution in original post

6 Replies

Avatar

Community Advisor

Hi @SibiMa ,

A 403 Forbidden error during SAML authentication typically indicates that the request is being blocked, either by the dispatcher or the AEM publisher itself. Since you've mentioned that you have configured the dispatcher rules according to Adobe's guidelines and are still encountering the issue, it's essential to troubleshoot both the dispatcher and the AEM publisher configurations.

Here are some steps to diagnose and potentially resolve the issue:

Dispatcher Configuration

  1. Check Dispatcher Filters:

    • Ensure that your dispatcher filters allow the saml_login path. In your dispatcher configuration, this would be in the filter section. You should have an entry that explicitly allows this path:

 

/filter
{
    ...
    /0004 { /type "allow" /url "/saml_login" }
    ...
}
​

 

  1. Review Dispatcher Logs:

    • The logs you shared indicate a possible blocking by the dispatcher. Double-check the dispatcher logs to see if any other rules might be inadvertently blocking the request. Look for any DENY entries related to the saml_login path.

AEM Publisher Configuration

  1. Check User Permissions:

    • Ensure that the user account configured for SAML has the necessary permissions to access the AEM resources. Sometimes, a 403 error can result from insufficient permissions for the user being authenticated.
  2. Review SAML Configuration:

    • Double-check your SAML configuration in AEM, especially the Service Provider (SP) and Identity Provider (IdP) configurations. Ensure that the metadata is correctly configured and that the certificate used is valid and properly uploaded.
  3. Enable Detailed Logging:

    • You mentioned enabling logs as per the Adobe docs. Ensure that detailed logging for SAML is enabled:

 

com.adobe.granite.auth.saml.SamlAuthenticationHandler
org.apache.sling.auth.core.impl.SlingAuthenticator
org.apache.jackrabbit.oak.security.authentication.token.TokenAuthentication
org.apache.jackrabbit.oak.spi.security.authentication.external.impl.ExternalLoginModule
​

 

    • Check the logs for any detailed error messages that might give more context about the 403 error.

Additional Steps

  1. Dispatcher Cache:

    • Clear the dispatcher cache to ensure that any old rules are not interfering with the new configuration.
  2. Network Configuration:

    • Ensure that there are no network-level blocks or firewall rules preventing access to the saml_login path.
  3. Validate Dispatcher Configuration Syntax:

    • Sometimes, a small syntax error in the dispatcher configuration file can cause unexpected behavior. Validate the configuration file for any such issues.

Troubleshooting Workflow

  1. Test Direct Access:

    • Try accessing the saml_login path directly on the AEM publisher without going through the dispatcher. If this works, the issue is likely with the dispatcher configuration.
  2. Temporary Disable Dispatcher:

    • Temporarily disable the dispatcher to see if the SAML integration works. If it does, incrementally re-enable the dispatcher rules to identify the problematic rule.

Example Dispatcher Configuration

Here's an example dispatcher configuration snippet that includes a rule to allow SAML login:

 

/cache
{
    /rules
    {
        /0000
        {
            /glob "*"
            /type "allow"
        }
    }
    /invalidate
    {
        /0000
        {
            /glob "*"
        }
    }
    /statfileslevel "0"
    /allowAuthorized "0"
    /rules
    {
        /0000
        {
            /glob "*"
            /type "allow"
        }
    }
    /headers
    {
        "CQ-Action-Scope"
    }
    /filter
    {
        /0000
        {
            /type "allow"
            /url "/saml_login"
        }
        /0001
        {
            /type "deny"
            /glob "*"
        }
    }
}

 

Ensure you replace this snippet appropriately into your existing configuration, respecting the overall structure.

If after following these steps, you still encounter the issue, consider providing additional logs or configuration snippets for a more detailed analysis.

Avatar

Level 3

In order to troubleshoot SAML request, prefer to use SAML-tracer chrome plug in.

Avatar

Level 2

I am already using this plugin and the response from SAML seems fine.

Avatar

Community Advisor

Have you also whitelisted the URL which will be making the SAML post request in Sling Referrer Filter ? From the logs I see there is no referer entry for the POST request, which seems a bit strange. 
You could cross check if the referer header is being denied somewhere in your configuration.

 

Avatar

Level 2

Hi @h_kataria We have configured the SAML on a fresh server, and it is working fine. The server from which I captured logs and posted has been there for 7+ years, and I think there are some rules that need to be revisited.

BTW, the Sling Referrer Filter was also configured, but still it didn't work.

Avatar

Correct answer by
Level 2

Hi All,

 

Thanks for all your responses. We have successfully configured the SAML in a fresh publish instance and it is working fine.

I have followed

https://experienceleague.adobe.com/en/docs/experience-manager-65/content/security/saml-2-0-authentic...

https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-16873#:~:text=Issue%2F.... (Only if using dispatcher) change in the format of rule as below

/0091 { /type "allow" /method "POST" /url "*/saml_login" }

Configuring Apache Sling Authentication Service in config manager

Additionally, Adobe Granite Cross-Origin Resource Sharing Policy configuration.

 

Thanks