Recipe: Azure AD and Tableau
1kg of Azure AD, 500g of SAML, and 100g of TCL and 50g of TS
Last updated
1kg of Azure AD, 500g of SAML, and 100g of TCL and 50g of TS
Last updated
Microsoft provides Azure AD apps that can be used to simplify the integration between Tableau Online and Azure AD. The goal is to create a good onboarding and user experience to the Tableau services. It explains the attributes required by the service to authenticate and plays around with the configuration to demonstrate how it works.
Update - 22nd December 2021: Added in a Provisioning section for Tableau Online.
Update - 5th August 2022: Updated Provisioning Section to include the latest Tableau SCIM integration
Update - 14th October 2022: Further SCIM updates
The two Azure AD apps have different feature sets. The Tableau Online application supports the following two features, whereas Tableau Server only supports SSO.
SP-initiated SSO
REST API user provisioning
Neither apps support IdP-initiated sign-on. This means that if you publish the app in the Azure MyApps portal it will still do an SP-initiated Authentication request and therefore have the usual browser redirections for that flow. Also, SP-Initiated Single Logout (SLO) is not possible due to the use of HTTP-Post bindings.
This gives you a free renewable 90 day M365 subscription, and M365 gives you Azure AD! Nice.
There are articles to configure the authentication steps. The Microsoft ones are little simpler to follow as they have screenshots.
Microsoft Docs: Tutorial: Azure Active Directory single sign-on (SSO) integration with Tableau Online Tutorial: Azure Active Directory single sign-on (SSO) integration with Tableau Server Tableau Docs: Configure SAML with Azure Active Directory (Tableau Online) Configure Server-Wide SAML (Tableau Server)
As part of the SAML authentication flow attributes are passed between the IdP (Azure) and the Service Provider (Tableau). Getting them right is key to a successful SSO.
There are two main properties that TOL is interested in, your Email and Display Name. The Email attribute is mapped to the username in Tableau Online and must match a licensed user stored in the Tableau Server Repository. The Display Name maps to the Full Name field in Tableau Online, it is populated with the assertions for First name and Last name or Full name. If they are not provided in the authN flow then the email address is used, so are actually optional.
Claims are widely referred to in Azure AD but not really in other major IdP's like Okta or OneLogin as they tend to refer to attributes. Claims are information about user and groups that are shared between the identity provider and the service provider in the SAML token. In the SAML token they are usually contained in the Attribute Statement, so you only really need to consider them as attributes. A claim type provides context for the claim value. It is usually expressed as a Uniform Resource Identifier (URI). This URI is what is required to be put into the TOL configuration.
Name
Description
Type
Name
Provides a human readable value that identifies the subject of the token. This value is not guaranteed to be unique within a tenant and is designed to be used only for display purposes.
<Attribute Name="http://schemas.xmlsoap.org
/ws/2005/05/identity/claims/name">
<AttributeValue>frankm@contoso.com<AttributeValue>
First Name
Provides the first or "given" name of the user, as set on the Azure AD user object.
<Attribute Name="http://schemas.
xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>Frank<AttributeValue
Last Name
Provides the last name, surname, or family name of the user as defined in the Azure AD user object.
<Attribute Name=" http://schemas.xmlsoap.
org/ws/2005/05/identity/claims/surname">
<AttributeValue>Miller<AttributeValue>
We ask for the Email attribute in the configuration which in turn is used as the TOL username and cannot be changed. The guidance we give on the Azure AD attributes to use has a couple of options:
If all accounts you’re giving access to are sourced from Microsoft accounts (e.g. outlook.com/gmail.com, or any consumer email domain that has signed up for an account) this will be: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
If all accounts are sourced from Microsoft Azure Active Directory, use the following value:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name.
It is not possible to map directly to the UPN claim as that is one of the restricted claim sets in Azure AD. These can't be modified using policy. The data source cannot be changed, and no transformation is applied when generating these claims. So in this instance that is why the Name claim is used instead.
UPDATE: There is a lot of new functionality in preview for Azure AD to allow you to create claim types that was previously restricted. How to: Customize claims emitted in tokens for a specific app in a tenant (Preview)
You can choose to map mail oruserPrincipalName as the Email in TCL. However as there isn't a separate email address attribute in TCL whatever is defined as Email must be a working email address as that value is what will be used to send out the subscriptions you have setup to views or workbooks.
Enter an assertion name for either the first name and last name, or for the full name, depending on how the IdP stores this information. Tableau Online uses these attributes to set the display name.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
http://schemas.microsoft.com/identity/claims/displayname
So you can select either givenname + surname OR displayname
This is just a bit of an exercise in playing around with the configuration. Go to the recommended section below for the real steps to follow!
As it states in Azure, the only required claim is actually the Name ID. So I deleted all other for Name, Given Name etc.
The identifier format is email address and in this instance I have mapped it to the Source Attribute of userPrincipalName in the directory (more information: How to: customize claims issued in the SAML token for enterprise applications).
When logging on I received an error logging in:
The site is configured to use the "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" attribute as the username. Login failed because this is not included in the IdP Response. To fix this problem, the site admin must either choose the correct attribute or clear it to rely on the NameID.
By deleting the 'name' claim URI from the setting in Tableau Online (shown below) it forces SAML to rely on only the Name ID in the response.
You can then login successfully with only relying on the name identifier, but you won't get any useful information like First Name and Surname.
So first off you should always follow the Tableau guidance here and match the assertions for Email, First name and Last name, or for Full name.
If you are trying to decide whether to use mail or UPN then consider the following:
I am primarily interested in Enterprise organizations so consumer accounts are less of a consideration. In Azure AD and Microsoft 365 the userPrincipalName (UPN) is the attribute that is used to sign in to Office 365 services. Many organizations are likely to want to map that to the username in TOL as they know it is likely to change less than the email address.
So the best guidance is to ask:
Is theUPN the same value as the users working email account, to receive subscriptions?
Which out of the mail or UPN is more likely to change?
If it did change, in Azure AD this will not be reflected in Tableau Online.
Follow these steps to provision a new account, migrate content and delete old account.
The Azure AD Tableau Online app always uses a SP-initiated flow. This means that the user experience involves a number of redirects. There are some configuration options that can smooth this experience.
You should advise your users to check the Remember me option when signing in to TOL. Without this checked the SAML flow will take the user back to the initial TOL SSO page to input the username before redirecting to the IdP.
Keep me signed In (KMSI)
As part of the Azure AD flow you are asked whether you want to stay signed in to the service. I would also ensure users to select this to prevent them having to input credentials again for an extended period of time.
Azure AD is a fully supported provisioning method to Tableau Online and has a SCIM integration. Earlier versions of the Azure AD app relied on the Tableau REST API.
The benefits of the SCIM integration over the REST API are:
Industry standard SCIM integration
A user can be a member of multiple groups in Azure, but they will only receive the most permissive site role in Tableau Online. For example, if a user is a member of two groups with site roles Viewer and Creator, Tableau will assign the Creator site role.
Removes the need for a named user account to sync users/groups and supports a bearer token for authentication
There is a good tutorial from Microsoft that describes how to configure Azure AD provisioning which works by integrating with our REST API. There are however a number of constraints and choices to make on how you provision users and groups.
If you want to test out a simple scenario then follow these steps to get up and running:
The following points are my take on the things to look out for with the integration...
If you are already using the previous REST API app then follow these steps to migrate over and benefit from the SCIM features. Points to note:
The update process uses the Graph API to DELETE the current provisioning configuration of the sync that was using the REST API. You then POST the update in the next step that calls the SCIM endpoint. It requires broad permissions on the Graph API (Directory.ReadWrite.All) so I would only be applying this using a specific admin account and revert the permissions after the change.
There are really 2 modes of operation for provisioning with Azure AD, which is configured in the 'Settings' part of the provisioning configuration.
SUPPORTED: Sync only assigned users and groups: You pre-assign users and groups to the Azure AD Enterprise application to be included in the scope of provisioning and those are sync'ed to Tableau
NOT VIABLE: Sync all users and groups: You allow all users and groups in Azure AD to be within scope of the Azure AD Enterprise Application provisioning and then proceed to use Scoping Filters to only provision those required to Tableau.
It is important to ensure you DO NOT use 'Sync all users and groups' this is not a viable method of provisioning for Tableau.
If you choose to Sync only assigned users and groups to the Azure AD application before they can be provisioned then you have the option to define the SiteRole for Tableau. This is the default SiteRole for the group and is the simplest method for assigning Site Roles to Tableau groups.
Take note of our documentation as despite 13 different roles presented in the Azure UI (below) only specific ones are workable and I have found this to depend upon the Azure tenant.
Microsoft advises If you select a role that is not in the below list, such as a legacy (pre-v2018.1) role, you will experience an error. Creator, SiteAdministratorCreator, Explorer, SiteAdministratorExplorer, ExplorerCanPublish, Viewer, or Unlicensed. However I noticed an issue with assigning Explorer (Can Publish) in my tenant. If you do then please contact Azure AD support.
This feature is not supported by any of the SCIM integrations with Tableau.
When you attempt to assign the group you are prompted with the message that users within nested AAD groups will not be provisioned, but the actual group will sync.
Azure AD provides scoping filters for both Users and Groups. Again they provide a handy Tutorial. You can use Scoping Filters even when you 'Sync assigned user and groups'.
This allows you to filter the Group objects that are provisioned/de-provisioned. Also, to filter the users based on attributes.
It took me a bit of playing around with it to figure out the relationship between the two as the app refers to it as a way to "Define which users are in scope for provisioning". Basically they work independently. The group filter, filters the group objects in Tableau, and the user filter, filters the user objects. It's blooming obvious now...
So for example. I defined the scoping filters:
Both filters are applied independently so that...
All groups that matched 'AD' in their description are provisioned
All users that are in 'Sales' are provisioned.
All users NOT in Sales are not provisioned even if they were members of the scoped and provisioned Groups.
The Tableau Server Azure AD app supports SP-initiated sign on. You need to manage provisioning separately.
Downloading the metadata file from Tableau Server and then uploading to Azure AD simplifies the first steps in configuring the IdP. This gives you the correct URLs at least in my instance:
The claims we define in our docs are:
But if you go to the Server UI it asks you to match these assertions.
The default claims defined in the Azure AD app actually just work and shouldn't require changing but include unnecessary claims.
When you look closer at the claims it also shows the Name ID which actually contradicts the Tableau docs, but again works.
These are the results from SAML trace for a successful login.
...or at least the mistakes that I made.
2) Ensure that you use test it with an account that is synchronised from Active Directory.
I used an Azure AD created identity and it didn't have an on-premisessAMAccountName that matches the username in Tableau. So it didn't pass the username attribute as required by the Tableau server identity store and claims.
1) Remember to assign your user to the App in Azure AD first if you have "Sync only assigned users and groups"
