I don't remember seeing this specific error before, but haven't explicitly tried with Azure AD SAML2 myself.   You could take a look at the basic steps described in https://www.sagecity.com/gb/sage-x3/b/sage-x3-uk-support-insights/posts/test-system-build-diary-big-build-part-4-saml from page 17 onwards would potentially be relevant to your situation.

You may also find the blog https://www.sagecity.com/us/sage_x3/b/sageerp_x3_product_support_blog/posts/how-do-i-setup-saml2-authentication-with-microsoft-azure useful

Hope this helps

Hi Victor,

when you have downloaded the metadata from X3 at SAML2 part: did you use the external URL or the local Server URL?

Step in Mike Shaws Link:

Looks like that makes a difference e.g. for the callback URL which is written to the file.
When you use the local server URL during the download of the file the local server name will be placed there.
This name can then not be resolved when trying the login via SAML2 and the external URL.
Would mean: you have to use the external server URL when you donwload these data.

Thanks mate for your reply, External URL

A quick update, had a meeting with Amir Shahi from Sage AU and he helped us rectifying the issue which was removing the entire setup and redoing all from scratch. So at this point not sure where exactly the issue resided, but one of the key thing we changed along the way was to make sure in Host setup for port 8124 which needs to use SSL connection > it is also using the self-signed certificate generated by Syracuse itself (where as I was using a separate self signed certificate generated by OpenSSL which was used between Syracuse and proxy server on this port). So really can't tell if this was the ultimate resolution or the fact that we have redone the entire setup in both Sage X3 and also Azure which might have fixed/updated some discrepancies between the two systems (the best IT solution, just restart it!

I have done a lot of SAML2 setup in X3 (mostly Azure) but was dealing with this issue for quiet some times now, hence just sharing my experience if your client's IT team does this, another issue will emerge. Some government agencies may force the Azure authentication to happen before even any Enterprise application (like Sage X3) page can be loaded. So in DNS setting or somehow (I am not sure how) of published website for Sage X3 they set it to go through Azure AD first time user puts in https://publicdomain:port , then after authentication it loads Sage X3 login page. It is understandable which helps them to avoid any risk of hacking issues with Sage X3 basic Authentications method till now (which strongly has been advised by Sage not to be used in published environment). But now that we are changing the method to only SAML2, it causes another issue (double dipping). 

So in this instance, after activating SAML2 and deactivating basic authentication, when we are calling the published URL for first time on a new browser (not in incognito mode and not having Sage X3 URL cached in its history before) > it goes to Azure authentication process as part of the IT policy > then loads Sage X3 login page > then user clicks on Azure Single Sign on button from Sage X3 login page > which then refreshes the page in a split second and goes to X3 successfully, but actually behind the scene it went to another Azure AD authentication request, this time triggered by X3 and because it has been authenticated once (before loading Sage X3 page), it won't bother the user for second time (we can see it in the logs of both Syracuse and also Azure enterprise application). Interesting case, Huh? 

It works fine, until the user closes the Browser entirely and opens the same Browser again > calls the published URL of Sage X3, this time it loads the log in page immediately (because the first Azure Authentication has been already done and Cached by the browser before) > then if they click on Azure single sign on button from Sage X3 login page > we get the error message "Empty" again > KO!

The only way around it:

1. Ask user to clear cache every time > which is not ideal 

2. I am also chasing the IT team to see if they can change their policy and let Sage X3 login page to load first, then we go through Azure for authentication as any other project (thanks to Amir's suggestion)

I will leave a feedback here once the issue is permanently resolved and how we did it finally. 

Final update, the IT team of my client checked the proxy server setup and changed some setup in something called wrapper which then allowed the Sage X3 URL to load X3 log in page first and everything is working as expected. Thanks Mike and Markus for taking your time to leave a reply for my post.