2 of 2 people found this helpful
In most cases your Identity Provider (IdP) will generate a crt/key for you.
If you are using a local system, like SimpleSaml, you will need to generate this for that system and match them to the ones installed on Tableau Server (OpenSSL can be used for this)
The IdP usually is on SSL, so your server would need to match; but if you have one that has a non-ssl option (or if you have a local system), you could do it on port 80.
If SAML is used in other locations, it can indeed support Single Sign On - saving your users a step of logging in. In the background, the user is forwarded to the IdP and back; but they would never notice.
SAML can indeed be used with trusted tickets.
Hope this helps!
I am the Systems Admin Helping Jeff out. I was able to create the certs but now I can not find /wg/saml/SSO/index.html for the endpoint in AD FS.
If the endpoint requires this try adding it to the end of the entity ID. SimpleSAML doesn't require this, but AD FS might require some settings tweaks.
Here are the settings I use: https://www.interworks.com/blog/daustin/2013/11/27/saml-integration-tableau-81
are there any better options for enabling seamless SSO from multiple domains? We have SAML configured, however our AD FDS deployment currently doesn't capture the logged in windows authentication and therefore users are prompted. And we're wondering if we're barking up the right tree.
Are you talking about in an embedded iframe, or in general?
A common annoyance is the orange "login box" in the iframe. If this is what you are referring to, you may be able to bypass it by disabling clickjacking (See SAML portion at the bottom: http://kb.tableau.com/articles/knowledgebase/clickjacking-protection )
If the latter, you should be able to setup SAML to auto-login your users (assuming the user's browser supports passing through the AD credentials), but this setup would be on the SAML IDP side - so it might take some tweaking in AD FDS.
I think in general. Later this year, our external users (that come into their distinct site via custom portal / load balancer / trusted auth) are being moved to a different AD domain. As far as we know, Tableau Server is constrained to point / authenticate to only one domain which hasn't been an issue to date.
I believe I have the same question. We are looking to authenticate via SAML; however, we would like to leverage multiple ADs. We are multiple institutions under a single system. Each institution has their own AD domain. Using SAML, will we be forced into checking "local authentication" in the user auth config option? If so, how do we go about managing users and authorization?
yes, I believe that AD can still be in the picture. To boil it down to the very basics, Tableau is delegating the authentication to your SAML component and SAML somehow needs to know what AD domain to refer, I'm not sure if Tableau talks at all directly to AD in this configuration and what occurs when adding / maintaining new users. In our case the SAML component deployed is AD Federation services (FDS) and we're still very much in testing. Oh, one more point is that "enable auto logon" needs to be turned off which tells Tableau to not leverage Microsoft SSPI, but rather go via another method, in this case SAML.
we had an interesting finding last week that I'd like to validate here.
- FACT or MYTH: Trusted authentication does not reference AD credentials. Rather, it verifies that the user is defined within Tableau Server
If it is fact, then we may get away with not having to configure SAML at all. We are thinking that the only time that our external client will need to be in the AD domain (that our TS points at) is during user provisioning. So we may have a back door slick option:
1. Add external client to both internal AD domain and external client AD domain
2. REST API - add client to Tableau (validates against internal AD)
3. Delete client from internal AD (because our windows team wants the external clients to be 100% segmented from a security perspective)
This is correct, SAML is really a local user in terms of implementation in 9.x, but trusts the authentication of the iDP (SAML provider) … So passwords are not used for web logons (only for tabadmin and REST calls). The Tableau Server, by default, will look for a claim called “username”, which needs to be a string match for the user id. If that matches, then tableau logs in the user and uses the local user definition to determine groups and permissions.
This changes somewhat in 10.x, with the introduction of site-level SAML (current, 9.x only supports server side configuratios).
wow, site level configs will be fabulous. Something to look forward to with Tableau 10.
In current state, is there any back door for adding local users to TS when we have AD integration? This would solve our problem of enabling trusted auth for users in a different AD domain. And I know guest can be added, how can we add other local accounts?
Any advanced info on how Tableau will implement site-level SAML in 10.x and what admins should do to plan for this?
can SAML be used to authenticate against multiple AD domains? We are observing that Tableau can login to one AD FDS.