Sending SAML response to a different URL

Question

Hello,

We are trying to establish SSO from Azure AD to an application, with a proxy in the middle. Assume the application URL is: example.app.com and the proxy URL is example.proxy.com. We would like Azure AD to send the SAML Response to example.proxy.net instead of sending it to example.app.com.

We were able to make this setup work in Okta, by setting the following values on our SAML 2.0 application:
Single sign on URL: https://example.proxy.net/login
Recipient URL: https://example.app.com/login
Destination URL: https://example.app.com/login
Audience URI (SP Entity ID): https://example.app.com/login

As you can see, we override the Single sign on URL with the proxy URL and then have to explicitly set the rest of the URL in order for the SAML assertion to be accepted by the application. In Okta, the description of the Single sign-on field says: The location where the SAML assertion is sent with a HTTP POST. This is often referred to as the SAML Assertion Consumer Service (ACS) URL for your application.

We are trying to recreate the same setup in Azure AD using an Enterprise Application but we can't find the equivalent field in Azure to Okta's Single sign-on in order for Azure to send the HTTP POST to our proxy. Can you help us find that field?

Thank you,
Yoav.

Answer 1

Hey - is there an answer to this question?
I am having the same issue here as well.

Answer 2

Hi James,

Regarding the "Single Sign-On with SAML" settings, the problem we have is that if we change the Reply URL from https://example.app.com/login to https://example.proxy.net/login, the following happens:

1. Azure AD sends the HTTP POST request to the proxy - this is what we wanted
2. The SAMLResponse XML in the HTTP POST is incorrect - the Audience, Recipient, and Destination URLs point to https://example.proxy.net/login instead of https://example.app.com/login and the application rightfully rejects that.

What we are looking to do is find a way to change the URL Azure AD sends the HTTP POST to without affecting the content of the SAMLResponse XML. In Okta, this is supported by changing the "Single sign on URL" field to point to the proxy and setting the Audience, Destination, and Recipient fields to point to the application.

I will look into more details on how the Application Proxy might assist here.

Is there anyway to replicate what we have in Okta to Azure AD?

Thank you,
Yoav.

Answer 3

Thank you, James. If needed, I can provide all the technical details, test environments, etc.

Yoav.

Answer 4

While we have an open ticket with Microsoft on this, we ended up implementing a SAML proxy feature in our product. It works by presenting itself as the service provider to the IdP, and as the IdP to the application (in our case, Snowflake). The setup is more complex, as it requires another key pair to be generated and to change the application to trust the SAML proxy as an IdP, but it works well.

Answer 5

Hi,

We have the same problem with a QRadar instance behind Application Gateway and Azure AD single sign-on.

Any solution to fix the problem?