No Browser Pop-up when clicking Verify IDP

[Treyson]

Hello Team,

I am having an issue where we are installing Alteryx Server 24.2 and are unable to verify our IDP when setting up SAML with OKTA.

I have followed all of the instructions here: https://knowledge.alteryx.com/index/s/article/Configuring-SAML-on-Alteryx-Server-for-Okta-1583461082...

When I am verifying my IDP, we aren't getting a pop-up to authenticate with OKTA. I went through the steps in this documentation (below) and am still unable to get the pop-up window to launch. We added all the OKTA wildecards and he Gallery URLs (webapi, gallery, etc.).

https://community.alteryx.com/t5/forums/postpage/board-id/server-discussions

Some other things we tried:

• All the ports are open and connecting. We were able to navigate in the browser to OKTA and we leveraged PowerShell to do Invoke-WebRequest and those came back fine.
• Switched the authentication type to built-in so that we could add an email to the default gallery user section, and then switched back. 
• downloaded Chrome
• switched the default browser to EDGE
• switched the default browser to Chrome

Anything I am missing?

[gawa · Accepted solution]

@Treyson Recently I got stuck for SAML setting for 2023.2 with Azure(sorry it's not OKTA). I configured everything according to online manual, but failed. Actually ACS Base URL that is automatically populated had unnecessary suffix, and it caused error at Azure.

If you see pop-up error message like 'not verified' when configuring SAML during system setting, some parameters in SP and/or IDP might be wrong. (I know it's difficult to identify it though)

As a side note, when I switch auth type of Alteryx Server, I always delete all program files/program data associated with Alteryx Server, and newly set up Alteryx Server from scratch. Even if Alteryx Server is uninstalled from control panel, program data still persist in ProgramData directory, and remember previously set parameters that can cause unwanted issue when newly setting up.

[Treyson]

@gawa Sorry for the late response on this. We had a similar problem with OKTA. One of the URLs that is setup on the OKTA setup side is case sensitive, and it took someone at Alteryx to make us aware of that. It was a painful exercise, but totally worth all of the learning.