AEM SAML Integration with Azure Fails on Last Step

[AquilaVasconcelosInfobase]

Hey Guys, 

I'll try to detail the best I can in here.

So, I'm running into a problem with my SAML integration

I configured every one of the steps bellow:

• uploaded the certificate in the truststore AND replicated
• created a keystore in the authentication-service user AND activated the user
• created the OSGI config for the SAML Authenticator
• listed the hosts in the Sling Referrer
• configured the CROSS OSGI config
• listed the path for the reply URL in the allow list of the filters in Apache
• Configured the Sling Authenticator to add authentication to the necessary paths

After all that I'm able to see the integration happening, the azure login displays correctly and I'm able to login with azure, the problem happens only in the last step the one for the POST, the call happens but after that the user keeps logged out. 

Important: the reply URL is configured without the .html extension in Azure side so I had to make a redirect using Apache to add the .html extension.

Important: I'm using SAML Tracer to intercept the requests and I noticed that in the POST the cookie login-token does not come with the Response Headers

[arunpatidar]

Hi,

What is the response url looks like?

make sure you do not change the callback url because AEM has set of rule(whitleist url pattern e.g saml_login) to allow anonymous post request.

Please check https://wttech.blog/blog/2019/how-to-setup-aem-publish-saml-authentication-using-okta/ 

The login-token cookie must be created once you have the valid login in AEM

Form debugging at AEM side, you can enable the custom logger : https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/saml-2-0-authen...

[AquilaVasconcelosInfobase]

Hey @arunpatidar I'm using the same pattern and I have added the following line to the dispatcher filter

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

I've also allowed access to that path through the Sling authenticator.

I've requested the azure team to change the path of reply URL to also include the .html extension, and no It is calling but I'm receiving this
message saying that the payload is invalid, I'm starting to suspect that the enterprise application may not be correctly set on the azure side.

I also have printed the summary in the SAML tracer

[arunpatidar]

It could be, issue is from azure side but i would recommed to remove .html from this path.

This might be added by the apache rewrite rule in your dispatcher rewrite.rule file.

[AquilaVasconcelosInfobase]

@arunpatidar the problem is most likely in the azure, they had created a standard enterprise application instead of a AEM one.

About the rewrite, I don't know if I was making it incorrectly but the way it was it wasent printing this invalid payload, so I'll live the .html in the azure side for now and see how that goes.

I'm waiting on the change from the azure side so I can close this topic.