Hi @annette2​ ,

SAML and reverse proxies are supported, however, I see that IIS with ARR is causing this issue on the redirect to the IDP login. I'm confident there will be a way to configure IIS differently as other reverse proxies do not have this issue, but I don't have a solution at the moment. I can update this thread when I have a suggested IIS configuration change.

Thanks Richard for investigating. Yes if there is an alternative to ARR that would then support Azure AD SAML authentication we would be keen to try it. Annette

Hi @annette2​ ,

I did some playing around and I found that on IIS in the AAR configuration article (Step 5/6) if I unchecked Reverse rewrite host in response headers SAML would authenticate okay. Please test this change thoroughly though.

Update: It looks like this might effect non-SAML login. This might not be an option.

Thanks Richard. When I was on leave my colleagues tried this and we are now a step further. The account we are logging in with needs to have access granted to the application but it does look like it should work now. Thanks for investigating this for us.

Hi @richardatsafe​,

I am a colleague of Annette and have an update on this ticket. Unchecking the 'reverse rewrite host' in IIS made it possible to login with SAML from within the machine FME Server is installed on, but from outside the machine we have a timeout. The reason for this is that port 8443 is included in the rewrite url and is not accessible: https://<fme server url>:8443/fmesaml/login/saml2/sso/fmeserver. We tried removing the port from the rewrite url in Azure, but this results in an error message stating there is a mismatch.

Do you have any further advice for us? We have also been trying to change parameter SINGLE_SIGN_ON_AUTH_URL mentioned in step 13 of this document Configuring FME Server for HTTPS: Using a PFX or P12 Certificate (safe.com) , but without result.

Thanks in advance.

Stefan

Ah, can I confirm that IIS is on a different machine than FME Server? I'm not sure I have another IIS workaround. It should be noted that other reverse proxies or gateways don't seem to have this trouble so I hope there is still a configuration change we can make on the IIS ARR side. Unfortunately, the SINGLE_SIGN_ON_AUTH_URL is only applicable for LDAP single-sign-on not SAML, and I don't have configuration suggestions for this, but I can make a ticket to investigate.

Hi @richardatsafe​. Thanks for your reply. The IIS is running on the same machine as FME Server. Is it normal behaviour that the rewrite url includes the port (in our case 8443) and isn't that the reason it is not working? If so, I think we have to postpone our saml configuration for now.

Hi @stefan.vdberg​ 

I, unfortunately, do not have a lot of experience with IIS, but I presume a port rewrite would include the port as IIS and FME Server can't bind to the same port on the same machine. I have scheduled time to look into this scenario, but if you want to make a ticket and discuss the configuration in more detail that might help us get on the same page.

Hello ,

Please see the document Failure to Connect to Azure AD Through IIS Proxy for additional configuration nresolution] steps for FME Flow using Microsoft IIS as reverse proxy and configuring Azure AD as identity provider. This can also be found on the article FME Flow Troubleshooting: Azure Active Directory.