Autorisation SAML et contrôle d’accès

Instructions et méthodologie pour définir votre politique d’accès et gérer le protocole SAML au sein de votre organisation.

Le protocole SAML permet aux organisations de gérer l’authentification et les droits d’accès des utilisateurs de Tulip à l’aide de leur fournisseur d’identité (IdP) existant. Ce guide détaille les options disponibles pour la mise en œuvre d’une intégration IdP au niveau de l’entreprise via le protocole SAML.

Pré-travail

• Comprendre les rôles des utilisateurs de Tulip
• Regroupez les utilisateurs Tulip potentiels par rôle afin d’être prêt à mettre à jour un attribut SAML avec leur rôle Tulip
• Identifiez les personnes au sein de votre organisation qui seront chargées de configurer votre IdP et votre compte Tulip

Configuration de l’IdP

Lorsque votre instance Tulip est configurée pour utiliser SAML pour la connexion, Tulip établit un lien entre les utilisateurs de Tulip et ceux de votre fournisseur d’identité d’entreprise (IdP). Un utilisateur donné disposant d’un compte dans l’IdP ne doit avoir qu’un seul compte au maximum dans une instance Tulip donnée. Tulip gère ce lien à l’aide d’un concept propre à SAML appelé « NameID ». Un NameID est un type d’identifiant opaque fourni par l’authentification SAML et défini par l’IdP.

Le NameID étant utilisé pour maintenir ce lien, Tulip s’attend à ce que les NameID soient stables, ce qui signifie que le NameID que Tulip reçoit pour un utilisateur particulier de l’IdP ne doit pas changer pendant toute la durée de vie de l’utilisateur. Si le NameID d’un utilisateur venait à changer, le lien serait rompu et vous pourriez rencontrer des erreurs lors de la connexion.

Tulip recommande vivement de configurer votre IdP de manière à ce qu’il fournisse un NameID qui ne changera pas au fil du temps. C’est pourquoi Tulip déconseille d’utiliser des noms ou des adresses e-mail comme NameID, car ces valeurs peuvent évoluer avec le temps. Nous vous recommandons de configurer votre IdP pour qu’il utilise des identifiants d’objet internes ou des noms de compte dont il est garanti qu’ils ne changeront jamais.

Notez que les NameID n’ont pas besoin d’être lisibles ou reconnaissables par l’utilisateur (en fait, il est généralement préférable, pour des raisons de sécurité, d’utiliser des valeurs non reconnaissables comme NameID).

Lors de la configuration de votre IdP, nous vous recommandons de définir le format de votre NameID sur « Persistant », ce qui indique à Tulip que la valeur doit rester constante tout au long du cycle de vie d’un utilisateur.

Lors du mappage de la valeur source de l’attribut NameID, mappez-la à une valeur connue pour être immuable, telle que « ID d’objet » ou « nom principal d’utilisateur ».

Microsoft Entra

Pour les clients utilisant Microsoft Entra comme IdP, suivez ces instructions spécifiques pour configurer votre application Tulip afin d’utiliser des NameID persistants :

1. Dans Entra, commencez par l’application d’entreprise associée à votre instance Tulip.
2. Dans le menu de navigation de gauche, cliquez sur « Authentification unique » dans le groupe « Gérer ».
3. Modifiez la section « Attributs et revendications ».
4. Dans la section « Réclamations requises », cliquez sur la ligne correspondant à la réclamation intitulée « Identifiant utilisateur unique (Name ID) ».
5. Assurez-vous que le « Format de l’identifiant de nom » est défini sur « Persistant ». Définissez la « Source » sur « Attribut » et sélectionnez un attribut qui restera stable pendant toute la durée de vie de l’utilisateur. user.userprincipalname et user.objectid constituent de bons choix.

Options de configuration SAML et Tulip

Modes de contrôle

Le mode de contrôle Tulip indique que le rôle et l’espace de travail d’un utilisateur dans Tulip sont extraits du mappage d’attributs SAML uniquement lors de sa première connexion à Tulip.

Les utilisateurs désactivés dans Tulip ne peuvent pas se connecter.

Le mode de contrôle IdP signifie que le rôle et l’espace de travail d’un utilisateur dans Tulip seront mis à jour à partir de l’IdP à chaque connexion.

Mappage par défaut des rôles (mode de contrôle Tulip uniquement)

Lors de la première connexion, tous les utilisateurs se voient attribuer un niveau d’accès par défaut (Utilisateur avec accès au lecteur). Le titulaire du compte devra ensuite ajuster manuellement le rôle au niveau approprié au sein de Tulip.

Espaces de travail

En savoir plus sur les espaces de travail

À l’instar de l’attribut de rôle, vous aurez désormais la possibilité d’affecter automatiquement les utilisateurs à un espace de travail spécifique lors de leur création initiale. Une fois les utilisateurs créés, les propriétaires de compte peuvent les déplacer de manière flexible d’un espace de travail à l’autre.

Mappage personnalisé des espaces de travail SAML

Lors de sa première connexion, un utilisateur se voit attribuer un accès à un espace de travail en fonction du groupe indiqué dans son attribut « espace de travail ». Passé ce stade, Tulip ne lit plus l’attribut « espace de travail » de cet utilisateur, et toute modification d’espace de travail doit être effectuée sur la plateforme par un propriétaire de compte.

Mappage par défaut des espaces de travail

Lors de la première connexion, tous les utilisateurs se voient attribuer l’accès à un espace de travail par défaut de votre choix. Le propriétaire du compte peut ensuite ajuster les droits d’accès à l’espace de travail.

Groupes d’utilisateurs

Vous pouvez affecter des utilisateurs à la fonctionnalité « Groupes d’utilisateurs »{target=_blank} de Tulip dans toutes les configurations SAML.

Les groupes d’utilisateurs existent au niveau du compte. Une fois qu’un utilisateur est affecté à un groupe d’utilisateurs, il en devient membre dans tous les espaces de travail.

Une fois que vous aurez activé l’option « Groupes d’utilisateurs », vous pourrez associer des utilisateurs de votre fournisseur d’identité (IdP) à des groupes d’utilisateurs dans Tulip en fonction de la valeur d’un attribut dans SAML.

Vous pourrez ensuite nommer jusqu’à 100 attributs SAML et associer les valeurs de chacun d’entre eux à un groupe d’utilisateurs. Un utilisateur peut ainsi être affecté à plusieurs groupes d’utilisateurs.

Mappage des groupes d’utilisateurs et comportement du mode de contrôle

Le comportement de l’appartenance aux groupes d’utilisateurs dépend de votre paramètre de mode de contrôle.

• Mode de contrôle Tulip: les groupes mappés via SAML pour un utilisateur ne s’appliquent que lors de sa première connexion. Par la suite, l’appartenance aux groupes peut être gérée au sein de Tulip, et toute modification manuelle est conservée lors des connexions suivantes.
• Mode de contrôle IdP: l’appartenance complète d’un utilisateur à des groupes est recalculée à partir de ses attributs SAML actuels à chaque connexion. Tulip attribue les groupes déterminés par le mappage et retire l’utilisateur de tout groupe non couvert par ce mappage, y compris les groupes qui lui ont été attribués manuellement au sein de Tulip.

Options d’authentification

Si vous souhaitez utiliser des clés FIDO pour l’authentification des utilisateurs, vous devrez « désactiver la correspondance des méthodes d’authentification ».

Classe de contexte d’authentification

La classe de contexte d’authentification correspond à la méthode spécifiée par laquelle les utilisateurs s’authentifient.

Lorsqu’elle est activée, les utilisateurs ne pourront s’authentifier qu’à l’aide de la méthode spécifiée.

Lorsqu’elle est désactivée, le choix de la méthode d’authentification est entièrement confié au fournisseur d’identité.

Authentification forcée

Tulip utilise le paramètre SAML « forceAuthn » pour déterminer si les utilisateurs doivent se réauthentifier auprès de leur fournisseur d’identité (IdP) à chaque connexion, ou si une session SAML existante au niveau du système d’exploitation peut être réutilisée. Tulip n’utilise pas le paramètre isPassive. Ici, la session existante est la session SAML au niveau du système d’exploitation (par exemple, une session Windows liée à votre fournisseur d’identité), et non une session spécifique à Tulip.

Authentification forcée activée (par défaut): Tulip envoie forceAuthn=true, ce qui oblige l’utilisateur à s’authentifier activement auprès de son fournisseur d’identité à chaque connexion, indépendamment de toute session SAML existante au niveau du système d’exploitation. Ce paramètre garantit que les utilisateurs ne peuvent pas contourner la réauthentification.

Authentification forcée désactivée: Tulip envoie forceAuthn=false. Si l’utilisateur dispose déjà d’une session SAML active au niveau du système d’exploitation et reconnue par le fournisseur d’identité, il sera automatiquement connecté à Tulip sans avoir à saisir à nouveau ses identifiants.

Personnalisation

Personnalisation facultative de la connexion utilisateur.

Libellé du bouton de connexion: personnalisez le texte du bouton de connexion SAML sur les pages de connexion de Tulip.

E-mail d’assistance personnalisé: définissez une adresse e-mail personnalisée qui s’affichera aux utilisateurs en cas d’erreur de connexion SAML. Cela permet de rediriger les utilisateurs vers votre service d’assistance informatique interne. Si ce champ est laissé vide, l’adresse e-mail d’assistance par défaut « support@tulip.co » sera utilisée.

Lecteur de bureau : navigateur par défaut du système d’exploitation pour l’authentification

Si votre connexion SSO ou l’autorisation via le connecteur OAuth nécessite une intégration disponible uniquement via votre navigateur par défaut, le lecteur Tulip peut être configuré pour ouvrir les flux d’authentification dans le navigateur par défaut du système d’exploitation plutôt que dans une fenêtre intégrée.

Exigences de version

Pour l’authentification via le navigateur par défaut du système d’exploitation, vous devez respecter les exigences de version Tulip suivantes :* Lecteur de bureau 2.8 ou version ultérieure* Version d’usine 318 ou ultérieure

Comportement de la fonctionnalité

Ce comportement s'applique à la fois à la connexion au lecteur de bureau via SSO et à l'autorisation des connecteurs OAuth au sein des applications Tulip. Dans les deux cas, lorsqu'un utilisateur lance l'authentification, son navigateur par défaut s'ouvre pour gérer le flux suivant :

1. Le navigateur du système se lance et accède à la page de connexion du fournisseur d’identité (IdP) de votre organisation.
2. L’utilisateur effectue sa connexion (saisie des identifiants, validation de l’authentification multifactorielle (MFA), etc.) dans le navigateur, exactement comme il le ferait sur le Web.
3. Une fois l’authentification terminée, la page du navigateur affiche le message suivant : « C’est terminé ! Vous pouvez fermer cette fenêtre. »
4. La fenêtre du navigateur reste ouverte. Elle ne se ferme pas automatiquement. L’utilisateur doit la fermer manuellement.
5. Le Tulip Desktop Player détecte que la connexion est terminée et poursuit son fonctionnement normalement.

Demandes d’autorisation attendues

Les utilisateurs peuvent être confrontés à une ou deux demandes d'autorisation, selon la configuration de leur système d'exploitation et de leur navigateur :

1. Autorisation relative au pare-feu / serveur local du Desktop Player (au niveau du système d'exploitation)

Lorsque l'authentification est lancée, le Desktop Player crée un serveur local temporaire pour recevoir la réponse d'authentification. En fonction du système d'exploitation et des paramètres de sécurité, une fenêtre du pare-feu système ou une demande d'accès au réseau peut s'afficher pour demander si le Desktop Player est autorisé à accepter les connexions entrantes.

• Action requise: autorisez la connexion. Il s'agit d'un comportement normal et indispensable à la réussite de la connexion.
• Selon les paramètres du système d’exploitation, cette demande d’autorisation peut s’afficher uniquement la première fois ou à chaque connexion.

2. Autorisation d’accès au réseau local du navigateur (au niveau du navigateur)

Une fois que l’utilisateur a terminé sa connexion auprès de son fournisseur d’identité, la page de fin d’authentification du navigateur renvoie le résultat au Desktop Player en envoyant une requête au serveur local décrit ci-dessus. Certains navigateurs affichent une invite d’autorisation demandant si la page est autorisée à accéder aux appareils du réseau local.

• Action requise: autorisez l’accès. Il s’agit d’une étape sécurisée et normale du processus d’authentification.
• La requête est adressée uniquement à localhost et ne contient que la réponse d’authentification chiffrée. Aucune information d’identification sensible n’est transmise à ce stade.

Résumé des différences pour l'utilisateur

Le tableau ci-dessous compare les comportements de l’authentification par défaut et de l’authentification via le navigateur du système d’exploitation :

Exemple : créer des groupes d’accès au sein de votre IdP

L'exemple suivant vous aidera à comprendre comment toutes les différentes options des paramètres SAML peuvent être utilisées conjointement.

Créer des rôles Tulip standardisés

Chaque utilisateur doit disposer d’un attribut de rôle défini dans votre IdP afin que Tulip puisse déterminer ses privilèges une fois qu’il s’est authentifié avec son nom d’utilisateur et son mot de passe IdP.

Vous pouvez également utiliser ce champ « Rôle » pour déterminer les sites auxquels il a accès en utilisant une convention de nommage standard. Bien qu’un champ « Rôle » puisse simplement être une variable définie, il est recommandé d’affecter l’utilisateur à des groupes spécifiques à Tulip au sein de votre IdP et de les mapper à un attribut.

Rôle

Chaque utilisateur se verra attribuer un seul rôle dans un espace de travail.

Lorsque Tulip reçoit plusieurs rôles valides pour un utilisateur, il applique la logique suivante :

Si l’ensemble comprend des rôles intégrés (Opérateur, Développeur, etc.), Tulip sélectionne le rôle intégré ayant le rang le plus élevé selon une hiérarchie interne statique. Les rôles personnalisés sont toujours classés en dessous de tous les rôles intégrés ; ils ne seront donc jamais sélectionnés si un rôle intégré est présent.

Si l’ensemble ne comprend que des rôles personnalisés, Tulip sélectionne le premier rôle personnalisé reçu dans la charge utile SAML.

En savoir plus sur les rôles utilisateur de Tulip.

Site

Imaginons que votre organisation dispose de deux sites, chacun disposant d’une adresse Tulip Instance.

Nous pouvons désigner chaque site par son emplacement (respectivement le Texas et Londres).

Combinaison du site et du rôle

Nous pouvons combiner ces deux propriétés pour créer une matrice de groupes à laquelle affecter les utilisateurs. Nous recommandons aux organisations d’ajouter « Tulip » au début ou à la fin de la valeur, afin de faciliter le filtrage.

Convention : tulip-siteRole

Si Jane Smith est la responsable du site du Texas, vous devez l'affecter au groupe tulip-texasAccountOwner. Si Jane Smith a également besoin d'un accès en lecture au site de Londres, elle peut être ajoutée au groupe tulip-londonViewer.

Exposez ces groupes en tant qu’attribut pour Tulip

Dans votre IdP, Jane doit disposer d’un attribut, tulip-role, auquel seront mappés tous les groupes dont elle est membre et qui contiennent le préfixe « tulip- ».

Lorsqu’elle se connecte à Tulip, l’attribut « tulip-role » prend deux valeurs : « tulip-texasAccountOwner » et « tulip-londonViewer ». Vous pouvez configurer le mappage des rôles pour chaque Tulip instance individuellement afin qu’elle bénéficie des autorisations appropriées dans chaque instance.

Rôles globaux

Vous pouvez également créer des rôles d’accès globaux, comme un rôle « Viewer » par exemple. Ces utilisateurs pourront se connecter à toutes les instances de Tulip instance avec les mêmes autorisations. Le format recommandé pour cela est :

tulip-globalViewer

Vous devrez configurer ce mappage de rôle sur chaque instance individuellement, via la page de configuration SAML dans les Paramètres du compte, afin de permettre à cet utilisateur d’accéder à chaque instance.

{{snippet.Avez-vous trouvé ce que vous cherchiez ?}}