Level 2

Solved

AEM SAML issue - 403 Forbidden

Forum|Forum|1 year ago
June 4, 2024
3 replies
3424 views

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)

Added dispatcher rule also as per the below

https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-16873#:~:text=SAML%20Authentication%20is%20configured%20in,via%20the%20dispatcher%20enabled%20URL.

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.

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-authenticationhandler not getting any clues from here as well about the issue.

Thanks in advance!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by SibiMa1

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-authenticationhandler

https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-16873#:~:text=Issue%2FSymptoms,via%20the%20dispatcher%20enabled%20URL. (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

HrishikeshKagne

Community Advisor

Hi @sibima1 ,

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

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" }
    ...
}

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

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.
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.
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

Dispatcher Cache:
- Clear the dispatcher cache to ensure that any old rules are not interfering with the new configuration.
Network Configuration:
- Ensure that there are no network-level blocks or firewall rules preventing access to the saml_login path.
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

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.
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.

Hrishikesh Kagane

sukumard

Level 3

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

S

SibiMa1Author

Level 2

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

h_kataria

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.

S

SibiMa1Author

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.

S

SibiMa1AuthorAccepted solution

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-authenticationhandler

https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-16873#:~:text=Issue%2FSymptoms,via%20the%20dispatcher%20enabled%20URL. (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

Dispatcher Configuration

AEM Publisher Configuration

Additional Steps

Troubleshooting Workflow

Example Dispatcher Configuration

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded