Exigences en matière d’authentification SAML

Avant de configurer SAML sur Tableau Server, assurez-vous que votre environnement présente la configuration requise.

Important : les configurations SAML, à la fois avec l’IdP et sur Tableau Server, sont sensibles à la casse. Par exemple, les URL configurées avec l’IdP et sur Tableau Server doivent correspondre exactement.

Conditions liées au certificat et au fournisseur d’identité (IdP)

La configuration de Tableau Server pour SAML nécessite le respect des conditions suivantes :

Fichier de certificat. Certificat x509 codé au format PEM possédant une extension .crt. Ce fichier est utilisé par Tableau Server, pas par l’IdP. Si vous avez un certificat SSL, il est possible, dans certains cas, d’utiliser le même certificat avec SAML. Pour plus d’informations, consultez Utilisation d’un certificat SSL et de fichiers de clé pour SAML plus loin dans cet article.
Tableau Server a besoin d’une paire de clé/certificat pour signer la demande envoyée à l’IdP. Cela réduit la menace d’une attaque de type « homme du milieu » étant donné la difficulté d’usurper une demande signée. En outre, Tableau Server vérifie que la valeur AuthNResponse qu’il reçoit provient de l’IdP de confiance. Tableau Server vérifie la valeur AuthNResponse en utilisant la signature produite par l’IdP. Les métadonnées du certificat de l’IdP sont fournies à Tableau Server dans le cadre du processus de configuration SAML initiale.
Les demandes signées ne sont pas toujours nécessaires pour tous les IdP. Par défaut, Tableau Server exige des demandes signées. Nous recommandons cette configuration pour assurer une transmission de communication plus sûre avec l’IdP. Adressez-vous à l’équipe de votre IdP pour comprendre s’il est nécessaire de désactiver les demandes signées. Pour désactiver les demandes signées, consultez Entité samlSettings.
Algorithme de signature. Le certificat doit utiliser un algorithme de signature sécurisé, par exemple SHA-256. Si vous essayez de configurer Tableau Server pour SAML avec un certificat qui utilise le hachage de signature SHA-1, Tableau Server rejettera le certificat. Vous pouvez configurer Tableau Server de manière à ce qu’il accepte le hachage SHA-1 moins sécurisé en définissant la clé de configuration tsm wgserver.saml.blocklisted_digest_algorithms.
Tailles de la clé RSA et de la courbe ECDSA. Le certificat Tableau Server doit avoir une force de clé RSA de 2048 et le certificat IdP doit avoir une force de clé RSA de 2048 ou une taille de courbe ECDSA de 256.
Vous pouvez configurer Tableau Server pour accepter les tailles moins sécurisées en définissant les clés de configuration respectives wgserver.saml.min_allowed.rsa_key_size et wgserver.saml.min_allowed.elliptic_curve_size.

Fichier de clé de certificat. Fichier de clé RSA ou DSA privée possédant une extension .key. Les clés RSA doivent être au format PKCS#1 ou PKCS#8.

Les exigences relatives à la protection par mot de passe sont les suivantes :

Le fichier de la clé PKCS# RSA ne peut pas être protégé par un mot de passe.
Pour utiliser un fichier de clé protégé par un mot de passe, vous devez configurer SAML avec un fichier RSA PKCS#8. Remarque : un fichier PKCS#8 avec un mot de passe nul n’est pas pris en charge.
Les fichiers de clé protégés par mot de passe ne sont pas pris en charge dans les déploiements SAML spécifiques au site.

Résumé de la prise en charge

Format du fichier de clé	Prise en charge de SAML à l’échelle du serveur	Prise en charge de SAML au niveau du site
RSA PKCS#8	Oui	Non
PKCS#8 (mot de passe non/null)	Non	Non
RSA PKCS#1	Oui	Oui
RSA PKCS#1 (mot de passe)	Non	Non
DSA PKCS#1 (mot de passe)	Non	Non

L’IdP doit signer les assertions SAML avec un algorithme de signature sécurisé. Par défaut, Tableau Server rejettera les assertions SAML signées avec l’algorithme SHA-1. Vous pouvez configurer Tableau Server de manière à accepter les assertions signées avec le hachage SHA-1 moins sécurisé en définissant la clé de configuration tsm wgserver.saml.blocklisted_digest_algorithms.
Compte IdP compatible avec SAML 2.0 ou version ultérieure. Vous avez besoin d’un compte auprès d’un fournisseur d’identité externe. PingFederate, SiteMinder et Open AM en sont quelques exemples.
Fournisseur IdP qui prend en charge l’importation/exportation de métadonnées XML. Un fichier de métadonnées créé manuellement peut fonctionner, mais le support technique de Tableau ne peut pas vous aider en ce qui concerne la génération manuelle du fichier ou la résolution des problèmes.

Nom d’utilisateur : Obligatoire. La configuration de l’IdP doit inclure l’attribut ou la revendication « nom d’utilisateur » et l’attribut de configuration SAML correspondant sur Tableau Server doit également être défini sur « nom d’utilisateur ».

Déchargement SSL

Si votre entreprise termine les connexions SSL de l’IdP sur un serveur proxy avant d’envoyer la demande d’authentification à Tableau Server, vous devrez peut-être effectuer une configuration proxy. Dans ce scénario, SSL est « déchargé » sur le serveur proxy, ce qui signifie que la requête https est terminée sur le serveur proxy et ensuite transférée à Tableau Server via http.

Tableau Server valide le message de réponse SAML renvoyé par l’IdP. Puisque SSL est déchargé au niveau du proxy, Tableau Server effectue la validation avec le protocole qu’il reçoit (http), mais la réponse IdP est formatée avec https. La validation échoue donc, sauf si votre serveur proxy inclut l’en-tête X-Forwarded-Proto défini sur https. Consultez Configurer Tableau Server pour qu’il fonctionne avec un serveur proxy inverse et/ou un équilibreur de charge.

Utilisation d’un certificat SSL et de fichiers de clé pour SAML

Si vous utilisez un fichier de certificat x509 encodé PEM en guise de SSL, vous pouvez utiliser le même fichier pour SAML. Avec SSL, le fichier de certificat est utilisé pour chiffrer le trafic. Avec SAML, le certificat est utilisé pour l’authentification.

Outre les conditions énumérées dans Conditions liées au certificat et au fournisseur d’identité (IdP) ci-dessus, pour que vous puissiez utiliser le même certificat à la fois pour SSL et SAML, le certificat doit également répondre à la condition suivante pour fonctionner avec SAML :

Vérifiez que le certificat inclut uniquement le certificat qui s’applique à Tableau Server et non pas d’autres certificats ou clés.
Pour cela, vous pouvez créer une copie de sauvegarde du fichier de certificat, puis ouvrir la copie dans un éditeur de texte pour consulter son contenu.

Conditions liées à la gestion des utilisateurs

Lorsque vous activez SAML, l’authentification utilisateur est effectuée en dehors de Tableau, par l’IdP. Par contre, la gestion des utilisateurs est effectuée par un magasin d’identités : soit un magasin d’identités externe (Active Directory ou LDAP), soit par Tableau Server dans un magasin d’identités local. Pour plus d’informations sur la planification de la gestion des utilisateurs avec Tableau Server, consultez Magasin d’identités.

Lorsque vous configurez le magasin d’identités lors de l’installation, vous sélectionnez l’option reflétant la manière dont vous souhaitez utiliser SAML. Remarque : si vous souhaitez utiliser SAML spécifique à un site, vous devez configurer SAML à l’échelle du serveur avant de pouvoir configurer des sites individuels.

Pour SAML spécifique au site : si vous utilisez plusieurs sites sur Tableau Server et souhaitez configurer chaque site pour un IdP ou une application d’IdP spécifique (ou configurer certains sites pour qu’ils n’utilisent pas SAML), configurez Tableau Server de manière à gérer les utilisateurs avec un magasin d’identités local. Pour SAML spécifique au site, Tableau Server se base sur l’IdP pour l’authentification et n’utilise pas de mots de passe.
Pour SAML à l’échelle du serveur : si vous configurez SAML à l’échelle du serveur avec un seul IdP, vous pouvez configurer Tableau Server de manière à utiliser un magasin d’identités local ou un magasin d’identités externe. Si vous utilisez Active Directory(AD), vous devez désactiver l’option Activer la connexion automatique (Microsoft SSPI).
Pour l’authentification SAML à l’échelle du serveur et l’authentification SAML spécifique au site :
- Lors de l’utilisation d’un magasin d’identités local, il est important que vous utilisiez un nom d’utilisateur avec un format d’adresse de courriel. L’utilisation d’une adresse de courriel complète permet de garantir l’unicité du nom d’utilisateur dans Tableau Server, même lorsque deux utilisateurs ont le même préfixe d’adresse de courriel mais des domaines différents. Pour garantir l’unicité des identités, exploitez le formatage complet des adresses de courriel sur les deux systèmes ou mettez à niveau Tableau Server vers la version 2022.1.x ou ultérieure et exécutez le travail en arrière-plan migration d’identité.
- Dans un environnement à plusieurs sites, tous les utilisateurs s’authentifient à travers un fournisseur d’identités SAML configuré au niveau du site. Dans ce scénario, vous spécifiez un IDP SAML par défaut à l’échelle du serveur pour les utilisateurs qui appartiennent à plusieurs sites. Pour configurer ce scénario, Tableau Server doit être configuré avec un magasin d’identités local.
- Ignorer le domaine lors de la correspondance avec l’attribut de nom d’utilisateur SAML. À partir des versions 2021.4.21, 2022.1.17, 2022.3.9 et 2023.1.5 de Tableau Server, vous pouvez configurer Tableau Server pour ignorer la partie domaine de l’attribut de nom d’utilisateur lors de la mise en correspondance du nom d’utilisateur du fournisseur d’identité (IdP) avec un compte d’utilisateur. sur Tableau Server. Par exemple, l’attribut de nom d’utilisateur dans le fournisseur d’identité peut être alice@example.com pour correspondre à un utilisateur nommé alice dans Tableau Server. Ignorer la partie domaine de l’attribut du nom d’utilisateur peut être utile si vous avez déjà des utilisateurs définis dans Tableau Server qui correspondent à la partie préfixe de l’attribut du nom d’utilisateur mais pas à la partie domaine de l’attribut du nom d’utilisateur.
  Important : nous vous déconseillons d’ignorer nom de domaine sans prendre de précautions. Plus spécifiquement, vérifiez que les noms d’utilisateur sont uniques dans les domaines configurés que vous avez créés dans votre IdP. La configuration de Tableau Server pour ignorer le nom de domaine peut entraîner une connexion involontaire de l’utilisateur. Prenons le cas où votre fournisseur d’identité a été configuré pour plusieurs domaines (par exemple, example.com et tableau.com). Si deux utilisateurs portant le même prénom, mais des comptes d’utilisateurs différents (par exemple, alice@tableau.com et alice@example.com) se trouvent dans votre organisation, vous pourriez alors avoir une incompatibilité de mappage.
  Pour configurer Tableau Server de manière à ce qu’il ignore les noms de domaine dans l’attribut de nom d’utilisateur depuis le fournisseur d’identité, définissez wgserver.ignore_domain_in_username_for_matching sur true. Consultez wgserver.ignore_domain_in_username_for_matching pour plus d’informations.
  Remarques :
  - Cette commande ne fonctionne que dans les déploiements Tableau Server dans legacy-identity-mode ou des déploiements qui n’ont pas été mis à jour via la migration d’identité(Le lien s’ouvre dans une nouvelle fenêtre) pour utiliser le service d’identité.
  - Lorsque vous modifiez la commande tsm pour qu’elle ignore le nom de domaine dans l’attribut du nom d’utilisateur, tous les noms d’utilisateur dans Tableau Server doivent comporter un nom de domaine.

Remarque : REST API et tabcmd ne prennent pas en charge l’authentification unique (SSO) SAML. Pour vous connecter, vous devez spécifier le nom et le mot de passe d’un utilisateur qui a été créé sur le serveur. L’utilisateur peut être géré par le magasin d’identités local ou un magasin d’identités externe, selon la façon dont vous avez configuré Tableau Server. Les appels REST API ou tabcmd disposeront des autorisations de l’utilisateur sous lequel vous êtes connecté.

Remarques sur la compatibilité SAML et les exigences

Noms d’utilisateur concordants : Le nom d’utilisateur stocké dans Tableau Server doit correspondre à l’attribut de nom d’utilisateur configuré envoyé par l’IdP dans l’assertion SAML. Par défaut, Tableau Server s’attend à ce que l’assertion entrante contienne un attribut appelé « username » avec les informations de cet utilisateur. Par exemple, si le nom d’utilisateur de Jane Smith est stocké dans PingFederate sous la forme jsmith, il doit également être stocké dans Tableau Server sous la forme jsmith.
Configuration de SAML lors de l’authentification
Si vous configurez SAML en tant que partie intégrante de l’installation initiale de Tableau Server, assurez-vous que le compte que vous comptez utiliser existe dans votre IdP avant d’exécuter l’installation. Pendant l’installation de Tableau Server, vous créez un compte d’administrateur de serveur.
Exécution de plusieurs domaines
Si vous utilisez un magasin d’identités externe Active Directory ou LDAP et que vous utilisez plusieurs domaines (à savoir, les utilisateurs appartiennent à plusieurs domaines ou votre installation Tableau Server comprend plusieurs domaines), l’IdP doit envoyer à la fois le nom d’utilisateur et le nom de domaine pour un utilisateur dans l’assertion SAML. Ces deux attributs de nom d’utilisateur et de domaine doivent correspondre exactement au nom d’utilisateur et au domaine stockés dans Tableau Server. Effectuez l’une des actions suivantes :
- Définir domain\username dans le champ Nom d’utilisateur
- Définir le domaine dans le champ Domaine et définissez le nom d’utilisateur dans le champ Nom d’utilisateur
Lors de la définition de l’attribut de domaine, vous pouvez utiliser le nom de domaine complet (FQDN) ou le nom abrégé.
Lorsque le domaine n’est pas spécifié, il sera considéré comme le domaine par défaut.
Pour plus d’informations, consultez Prise en charge de plusieurs domaines et la section « Associer des assertions » sur l’onglet Utiliser l’interface en ligne de commande TSM dans Configurer SAML à l’échelle du serveur.
Algorithme de signature : Tableau Server utilise l’algorithme de signature SHA256.
Déconnexion unique (SLO) : Tableau Server prend en charge à la fois le SLO initié par le fournisseur de services (SP) et le SLO initié par le fournisseur d’identité (IdP) pour SAML à l’échelle du serveur et SAML spécifique au site.
Types d’authentification externe : Tableau Server prend en charge l’utilisation d’un seul type d’authentification externe à la fois.
SSL mutuel : Tableau Server ne prend pas en charge le SSL mutuel (SSL réciproque) et SAML simultanément. Si vous souhaitez utiliser SSL mutuel, vous pouvez le configurer sur l’IdP.
Encodage des assertions : les assertions doivent être codées en UTF-8.
Chiffrement et assertions SAML :
- SAML à l’échelle du serveur : lorsque Tableau Server est configuré pour SAML à l’échelle du serveur, il prend en charge les assertions chiffrées de l’IdP. Les assertions de chiffrement sont activées par le certificat que vous téléversez dans le cadre de la configuration initiale pour SAML à l’échelle du serveur. Les demandes et les réponses SAML peuvent être envoyées via HTTP ou HTTPS.
- SAML spécifique au site : lorsque Tableau Sites est configuré pour SAML spécifique au site, il ne prend pas en charge les assertions chiffrées de l’IdP. Toutes les demandes et réponses SAML sont toutefois envoyées par HTTPS pour assurer la communication avec l’IdP. Les requêtes et les réponses HTTP ne sont pas prises en charge.
Identité utilisateur dans Tableau Server pour les utilisateurs tabcmd :Comme décrit dans la section Conditions liées à la gestion des utilisateurs ci-dessus, pour utiliser tabcmd, vous devez vous connecter en tant qu’utilisateur défini sur le serveur. Vous ne pouvez pas utiliser des comptes SAML avec tabcmd.
Utilisation de SAML SSO avec Tableau Desktop : par défaut, Tableau Desktop autorise l’authentification SAML initiée par le fournisseur de service.
Si votre IdP ne prend pas en charge cette fonctionnalité, vous pouvez désactiver la connexion SAML pour Tableau Desktop à l’aide de la commande suivante :
tsm authentication saml configure --desktop-access disable
Pour plus d’informations, consultez tsm authentication saml <commands>.
Installations distribuées : Les versions TSM de Tableau Server (2018.2 et ultérieur) utilisent le service de fichiers client pour partager des fichiers dans un groupement multi-nœuds. Une fois que vous avez configuré SAML sur le nœud initial de votre groupement, le service de fichiers client distribue les fichiers de certificats et de clés aux autres nœuds.
URL de connexion : pour que les utilisateurs puissent se connecter, votre IdP doit être configuré de sorte que le terminal de connexion SAML envoie une requête POST à l’URL suivant :
https://<tableauserver>/wg/saml/SSO/index.html.
URL de déconnexion : Pour que les utilisateurs puissent se déconnecter après s’être connectés avec SAML (déconnexion simple, ou SLO), votre IdP doit être configuré de sorte que le terminal de déconnexion SAML envoie une demande POST à l’URL suivante :
https://<tableauserver>/wg/saml/SingleLogout/index.html.
Remarque : Tableau Server prend en charge à la fois le SLO initié par le fournisseur de services (SP) et le SLO initié par le fournisseur d’identité (IdP) pour SAML à l’échelle du serveur et SAML spécifique au site..
URL de redirection post-déconnexion : Par défaut, lorsqu’un utilisateur se déconnecte de Tableau Server, la page de connexion s’affiche.
Pour afficher une page différente après la déconnexion, utilisez la commande tsm authentication saml configure avec la commande -su ou --signout-url.
- Pour spécifier une URL absolue, entrez une URL complète commençant par http:// ou https://, comme dans cet exemple :
  tsm authentication saml configure -su https://example.com
- Pour spécifier une URL relative à l’hôte Tableau Server entrez une page Web commençant par une / (barre oblique) :
  tsm authentication saml configure -su /ourlogoutpage.html
Active Directory Federation Service (AD FS) : Vous devez configurer AD FS pour renvoyer des attributs supplémentaires pour l’authentification Tableau avec SAML. Les attributs ID de nom et nom d’utilisateur peuvent être mappés sur le même attribut AD : Nom-Compte-SAM.
Pour des informations sur la configuration, consultez Configurer SAML avec AD FS sur Tableau Server.
AuthNContextClassRef : AuthNContextClassRef est un attribut SAML optionnel qui applique la validation de certains « contextes » d’authentification dans les flux initiés par l’IdP. Vous pouvez définir des valeurs séparées par des virgules pour cet attribut avec TSM. Une fois cet attribut défini, Tableau Server vérifie que la réponse SAML contient au moins l’une des valeurs répertoriées. Si la réponse SAML ne contient pas l’une des valeurs configurées, l’authentification sera rejetée, même si l’utilisateur s’est authentifié avec succès avec l’IdP.
Si vous laissez cet attribut optionnel vide, il en résultera un comportement par défaut : toute réponse SAML authentifiée avec succès permettra à un utilisateur d’obtenir une session dans Tableau Server.
Cette valeur n’est prise en charge que pour SAML à l’échelle du serveur. Si vous avez configuré SAML sur le site, l’attribut AuthNContextClassRef sera ignoré.
Pour définir cette valeur avec l’interface Web TSM, consultez Configurer SAML à l’échelle du serveur.
Pour définir cette valeur avec tsm configuration set, utilisez la clé wgserver.saml.authcontexts pour définir une liste de valeurs séparées par des virgules.
Pour définir cette valeur avec un fichier de configuration JSON, consultez Entité samlSettings.

Utilisation de SSO SAML dans les applications du client Tableau

Les utilisateurs Tableau Server se servant des informations d’identification SAML peuvent également se connecter au serveur depuis l’application Tableau Desktop ou Tableau Mobile. Pour assurer une compatibilité complète, nous recommandons que la version de l’application du client Tableau corresponde à celle du serveur. Pour se connecter avec SAML spécifique au site, les utilisateurs doivent exécuter la version 10.0 ou une version ultérieure de l’application du client Tableau.

La connexion à Tableau Server depuis Tableau Desktop ou Tableau Mobile utilise une connexion initiée par un fournisseur de services (SP).

Redirection d’utilisateurs authentifiés vers les clients Tableau

Lorsqu’un utilisateur se connecte à Tableau Server, Tableau Server envoie une demande SAML (AuthnRequest) à l’IdP, qui inclut la valeur RelayState de l’application Tableau. Si l’utilisateur s’est connecté à Tableau Server depuis un client Tableau tel que Tableau Desktop ou Tableau Mobile, il est important que la valeur RelayState soit renvoyée dans la réponse SAML de l’IdP à Tableau.

Si la valeur RelayState n’est pas renvoyée correctement dans ce scénario, l’utilisateur est emmené sur la page d’accueil de Tableau Server dans la navigateur Web plutôt que d’être redirigé vers l’application depuis laquelle il s’est connecté.

Adressez-vous avec votre fournisseur d’identité et votre équipe informatique interne pour vérifier que cette valeur sera incluse dans la réponse SAML de l’IdP, puis conservée par un appareil réseau (par exemple un proxy ou un équilibreur de charge) résidant entre votre IdP et Tableau Server.

Exigences liées aux données XML

Dans le cadre de la configuration SAML, vous échangez des métadonnées XML entre Tableau Server et l’IdP. Ces métadonnées XML sont utilisées pour vérifier les informations d’authentification d’un utilisateur lorsque ce dernier initie le processus de connexion à Tableau Server.

Tableau Server et l’IdP génèrent chacun leurs propres métadonnées. Chaque ensemble de métadonnées doit contenir les informations décrites dans la liste suivante. S’il manque des informations dans un ensemble, des erreurs peuvent se produire lorsque vous configurez SAML ou lorsque les utilisateurs tentent de se connecter.

HTTP POST et HTTP REDIRECT : Tableau Server prend en charge les requêtes HTTP POST et HTTP REDIRECT pour les communications SAML. Dans le document XML de métadonnées SAML qui est exporté par l’IdP, l’attribut Binding peut être défini sur HTTP-POST ou HTTP-REDIRECT.
Lorsque l’attribut Binding est défini sur HTTP-POST, les métadonnées SAML que Tableau Server et l’IdP exportent respectivement doivent contenir les éléments suivants.
- Élément qui définit l’URL vers laquelle l’IdP redirige l’utilisateur après une authentification réussie . Ceci est requis dans les métadonnées du fournisseur de services, et non dans les métadonnées du fournisseur d’identité.
  <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://<tableau-server>/wg/saml/SSO/index.html index="0" isDefault="true"/>
  Dans le cas de SAML pour le site, le point de terminaison Location est /samlservice/public/sp/metadata?alias=<site alias>.
- Cet élément de point de terminaison de déconnexion apparaît dans les métadonnées du Tableau Server et spécifie l’URL que l’IdP utilisera pour le point de terminaison de déconnexion de Tableau Server. Si cet élément n’est pas dans les métadonnées de l’IdP, Tableau Server ne peut pas négocier un point de terminaison de déconnexion avec l’IdP et la fonction de déconnexion SAML ne sera pas disponible dans Tableau Server :
  <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://SERVER-NAME:9031/idp/slo"
- Vérifiez que les métadonnées XML obtenues à partir de l’IdP incluent un élément SingleSignOnService dans lequel la liaison est définie sur HTTP-POST, comme dans l’exemple suivant :
  <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://SERVER-NAME:9031/idp/SSO.saml2"/>
- Cet élément doit apparaître dans les métadonnées de l’IdP et spécifie l’URL que Tableau Server utilisera pour le point de terminaison de déconnexion de l’IdP.
  <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://SERVER-NAME:9031/idp/slo"/>

Attribut nommé username : vous devez configurer votre IdP pour qu’il renvoie une assertion incluant l’attribut username dans l’élément saml:AttributeStatement. Le type d’attribut de l’assertion doit être xs:string (elle ne doit pas être entrée sous la forme xs:any).

L’exemple suivant montre comment cela peut se présenter.

<saml:Assertion assertion-element-attributes>
  <saml:Issuer>issuer-information</saml:Issuer>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    ...
  </Signature>
  <saml:Subject>
    ...
  </saml:Subject>
  <saml:Conditions condition-attributes >
    ...
  </saml:Conditions>
  <saml:AuthnStatement authn-statement-attributes >
    ...
  </saml:AuthnStatement>

  <saml:AttributeStatement>
    <saml:Attribute Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
          user-name
    </saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Par défaut, Tableau Server lit l’attribut username dans la réponse AuthNResponse retournée par l’IdP. Cependant, certains IdP peuvent retourner un attribut différent qui est destiné à identifier l’utilisateur.

Pour modifier l’attribut SAML qui transmet la valeur username, exécutez la commande TSM suivante :

tsm authentication saml map-assertions --user-name <USER-NAME>.

Consultez tsm authentication.

Appartenance à un groupe dynamique à l’aide d’assertions SAML :
À compter de Tableau Serveur 2024.2, si SAML (ou SAML du site) est configuré et le paramètre de la fonctionnalité est activé (à l’échelle du serveur ou au niveau du site), vous pouvez contrôler dynamiquement les membres du groupe au moyen de revendications personnalisées incluses dans la réponse SAML XML envoyée par le fournisseur d’identité (IdP).
Une fois configuré, lors de l’authentification de l’utilisateur, l’IdP envoie l’assertion SAML qui contient deux revendications personnalisées des membres du groupe : le groupe (https://tableau.com/groups) et les noms de groupe (par exemple, « Group1 » et « Group2 ») pour affirmer l’appartenance de l’utilisateur à ce groupe. Tableau valide l’assertion et autorise ensuite l’accès aux groupes et au contenu dont les autorisations dépendent de ces groupes.
Pour plus d’informations, consultez Contrôle dynamique des membres de groupes à l’aide d’assertions.
Exemple de réponse SAML XML
```
<saml2p:Response
  xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
    .....
    .....
  <saml2:Assertion
    .....
    .....
    xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
    <saml2:AttributeStatement
  		xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  		<saml2:Attribute
    		Name="https://tableau.com/groups"
			NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
  			<saml2:AttributeValue
				xmlns:xs="http://www.w3.org/2001/XMLSchema"
				xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
				xsi:type="xs:string">Group1
			</saml2:AttributeValue>
			<saml2:AttributeValue
				xmlns:xs="http://www.w3.org/2001/XMLSchema"
				xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
				xsi:type="xs:string">Group2
			</saml2:AttributeValue>
    	<saml2:Attribute>
    </saml2:AttributeStatement>
  </saml2:Assertion>
</saml2p:Response>
```

Retour en haut

Merci de vos commentaires!

Votre commentaire s été envoyé avec succès. Merci!

Aide de Tableau Server sur Windows