Level 2

Solved

AEM Saml authentication returning a 204 after POSTing SAML response to saml_login on publish instance

Forum|Forum|3 years ago
December 14, 2022
6 replies
4396 views

Hello guys,

I am trying to set up SAML authentication on my publish instance, but am having no luck.
Currently have SMAL authentication working for my local author instance.
When setting up the SAML authentication handler everything seems fine.
Get redirected to my preferred external IDP correctly and can login fine.
Then the IDP sends the SAML response to my URL: http://HOST:PORT/content/wknd/saml_login.
In stead of receiving the normal 200 response code, it gives a 204 response code.

Added logs after, which resulted in this error:
14.12.2022 13:49:21.421 *DEBUG* [qtp1242332285-2068] com.adobe.granite.auth.saml.SamlAuthenticationHandler Private key of SP not provided: Cannot sign Authn request.

Steps followed were based on this:
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/adobeexperiencemanager-tutorial

Any feedback/input would be appreciated!

Best answer by JOosterwijkT

I have resolved the issue after debugging. After deleting the OSGi configuration for the Adobe Granite SAML 2.0 Authentication Handler on the config manager, I put down some breakpoints in the package by adding it to the external libraries in intellij.
It still hit those breakpoints after the config was deleted, which should not be possible.
After I deleted the configuration files from the codebase and setting up the saml handler again, it worked. It seems that the configurations of the code were being hit, despite not showing up in the configuration manager of AEM.

arunpatidar

Community Advisor

Have you also followed the https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/saml-2-0-authenticationhandler.html ?

Arun Patidar

J

JOosterwijkTAuthor

Level 2

Yes have also followed these steps, except for the decryption and signing of messages which were optional

Saravanan_Dharmaraj

Community Advisor

Please check the below post which discussed 204 response for SAML postback
https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-postback-gives-http-204-instead-of-http-200/td-p/384108

Check Adobe Granite Cross-Origin Resource Sharing Policy OSGi config entries on publishers to make sure that the IdP's origin is an explicitly allowed origin or use .* regexp as allowed origins regexp.

J

JOosterwijkTAuthor

Level 2

Below the configuration I gave the Adobe Granite Cross-Origin Resource Sharing Policy you referenced:

milind_bachani

Adobe Employee

Hi @joosterwijkt ,

Please refer following link :

https://experienceleague.adobe.com/docs/experience-cloud-kcs/kbarticles/KA-17476.html?lang=en

For com.adobe.granite.auth.saml.SamlAuthenticationHandler Private key of SP not provided: Cannot sign Authn request, it suggests to re-upload the new IDP certificate.

J

JOosterwijkTAuthor

Level 2

@milind_bachani According to your source:

If you are not encypting the SAML response, you can ignore “Private key of SP not provided: Cannot sign Authn request” error.
I am currently not encrypting the response, so it seems the error can be ignored in some way...
Currently does not work and is the only error recorded in the saml log though

W

WasilZee

Adobe Employee

Check whether the returned subject/user in the SAML response has appropriate permissions to access the original page path requested(or root path /). If you have selected Autocreate CRX Users, validate the Add to Groups/Auto Group Membership [1].

Thanks,

Wasil

[1] https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/saml-2-0-authenticationhandler.html

J

JOosterwijkTAuthor

Level 2

Hi @wasilzee ,
I think i forgot to mention this in my question, but I have autocreate CRX on, but users do not get created. It feels like the SMAL response does not land correctly when sent back to AEM...

J

JOosterwijkTAuthorAccepted solution

Level 2

I have resolved the issue after debugging. After deleting the OSGi configuration for the Adobe Granite SAML 2.0 Authentication Handler on the config manager, I put down some breakpoints in the package by adding it to the external libraries in intellij.
It still hit those breakpoints after the config was deleted, which should not be possible.
After I deleted the configuration files from the codebase and setting up the saml handler again, it worked. It seems that the configurations of the code were being hit, despite not showing up in the configuration manager of AEM.

M

martin_knyazyan

Level 2

Hello @joosterwijkt .
I faced the same issue a couple of days ago, and I tried your solution, but it didn't help me to solve the problem. Therefore I'll put the steps I have done to fix the same issue, when testing locally without dispatcher.
I was checking the integration on local publish instance without a dispatcher. There are key steps that should be followed.

Create new config com.adobe.granite.cors.impl.CORSPolicyImpl~<identifier>.cfg.json. If you are testing on local, add "null" in alloworigin property list, because sometimes IdP sends POST binding back with 'Origin' header set to 'null'.
Create/Update org.apache.sling.security.impl.ReferrerFilter to allow IdP host.
If you are using dispatcher make sure to allow request to */saml_login in your farm config file and make sure, that you are not rewriting URI ending with saml_login.

For more info see: https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/authentication/saml-2-0

Hope this helps others.
Regards

N

Niels Van Vliet

Level 2

Adding to this thread:

I found out that there is another scenario in which the SAMLAuthenticationHandler returns a 204.

If you're passing the origin Passing the Origin header to the author (via the dispatcher’s /clientheaders setting), this causes the /saml_login endpoint to return a 204 No Content instead of performing the expected 30x redirection for SAML login.

The recommended workaround I received from support is to configure your dispatcher to exclude the Origin header for SAML login requests (i.e. for the /saml_login endpoint) by adding a specific farm with a more specific virtualhost configuration for /saml_login

/authorsamlfarm
        {
        # client headers which should be passed through to the render instances
        # (feature supported since dispatcher build 2.6.3.5222)
        /clientheaders
          {
               $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_author_clientheaders.any"
               $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_common_clientheaders.any"
          }
        # hostname globbing for farm selection (virtual domain addressing)
        /virtualhosts
          {
                "aem-author.prd.company.com/saml_login"
                "aem-author.acc.company.com/saml_login"
                "aem-author.tst.company.com/saml_login"
          }

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded