I have moved this thread to the Server Administration. SAML authentication is supported by Tableau. It sounds like there is a configuration issue with your setup. Have you reviewed the setup instructions to verify your setup?
You may want to open a Tableau Support ticket to engage a member of the Tableau Support team to assist with your configuration setup. http://support.tableau.com
2 of 2 people found this helpful
We contacted Tableau Support on this issue almost 2 years ago.....hopefully this is still relevant.
Below is copied from my support case with Tableau....good luck!
I have done some further research on this issue to provide a more complete answer on why this change was implemented with SAML in Tableau Server 9.0, and how that compares to other authentication methods. Thank you for your patience, as I wanted to make sure this information was as complete and accurate as possible.
The way embedded SAML views were accessed in Tableau Server 8.x was:
1. If a user has not already logged in to the IdP, an IdP sign in dialog loads within the iFrame.
2. After sign-in, a user proceeds to see the view load within the iFrame.
3. On subsequent sessions, the user can still be signed in to the IdP, and the view will load without sign in.
This was a security risk, as any web page could have a Tableau Server view embedded that contains hidden elements that capture credentials on initial sign in to the IdP without the user's knowledge.
In Tableau Server 9.0, the underlying process is the same, but a pop-up is used for sign in to the IdP to break the frame and prevent an overlay on the webpage from hijacking credentials entered into a fixed area of the embedded view.
SAML sign in is still automatic when already signed in to the IdP (when the 'Sign In' button is pressed, a popup briefly flashes, but does not require credentials). The issue of course, is that orange sign in button which requires an extra user interaction when accessing the view.
Our tier 4 engineers, who work closely with product development, have provided this response about that button and pop-up:
"To address your question about opening the popup automatically: we require the user to push a button because browsers will block popups if they are not opened from certain user-initiated interactions. You’ll see the “this page tried to open a popup and we blocked it” message."
Automatically opening the pop-up on page load is one of the options under consideration for streamlining this process, but would require users to whitelist the pop-up in many browser environments. Other possible options are being considered as well for future versions.
As for why this affects SAML, but not Kerberos or AD with automatic login: those two authentication methods to not require users to enter credentials through a web browser, as both check credentials when the user logs in to their computers with an Active Directory account instead.
Note that as far as AD authentication is concerned, 'enable automatic login' has to be checked for this single sign on behavior. If not checked, a user will still get the orange button that loads a pop-up to take their AD credentials. The pop-up was not implemented just for SAML, but is there to prevent clickjacking for all authentication that takes user credentials when embedding.
I understand the frustration about lack of documentation on this issue, and will look into getting information on this added to external facing sources. I do appreciate the feedback on this, as we are always working to improve documentation and provide a better experience accessing information about our products.