Autorisation et contrôle d'accès à l'aide de SAML
  • 30 Sep 2022
  • 6 Minutes à lire
  • Contributeurs

Autorisation et contrôle d'accès à l'aide de SAML


Objectif

Instructions et méthodologie pour définir votre politique d'accès et gérer SAML pour votre organisation.

SAML permet aux organisations de gérer l'authentification et les droits d'accès des utilisateurs de Tulip en utilisant leur fournisseur d'identité (IdP) existant. Ce guide détaillera le processus de découverte et de mise en œuvre de l'installation de SAML au niveau de l'entreprise. Pour un site unique, veuillez consulter notre article de support ici

Processus de haut niveau

Travail préalable

Comprendre les rôles des utilisateurs Tulip

Répartir les employés dans des groupes basés sur les rôles

Identifier qui, dans votre organisation, configurera votre IdP et Tulip.

Déterminer si les utilisateurs existants doivent être migrés.

Pour chaque nouveau site

Tulip active SAML sur votre site

Votre organisation configure SAML (à la fois dans votre IdP et dans Tulip) et accorde l'accès aux utilisateurs.

Processus de création d'un nouveau site

Envoyez une demande à votre Customer Success Manager Tulip pour créer un nouveau site avec SAML. Vous devez fournir les éléments suivants :

  • Le nom et l'URL du site
  • Le nom et l'adresse électronique de la personne de votre organisation qui se connectera et configurera SAML.

Tulip va créer le site et activer SAML.

La personne responsable de la configuration recevra un e-mail pour se connecter au site, elle configurera SAML comme décrit ici. Elle configurera le site en fonction de votre stratégie d'accès, dont les deux sont définies ci-dessous.

Tester l'accès avec les utilisateurs

:: :(Info) (NOTE :)
Une fois terminé, le propriétaire du compte doit supprimer le compte utilisateur de la personne qui a configuré SAML, car son compte utilise un nom d'utilisateur et un mot de passe Tulip. Si cette personne doit maintenir SAML à l'avenir, elle doit recevoir un accès de propriétaire de compte et se connecter avec SAML pour les configurations futures.

Les certificats SAML créés par Tulip expirent chaque année. Tulip contactera votre équipe 2 semaines à l'avance pour faire tourner le certificat.
:: :

Processus de conversion SAML du site actif

Comme ci-dessus, mais avant que SAML ne soit activé, nous devrons convertir tous les utilisateurs existants des comptes Tulip en comptes SAML. Pour cela, nous avons besoin d'une liste de l'email de chaque utilisateur et de leur NameId fourni par l'IdP. Nous travaillerons avec la personne responsable de la configuration pour effectuer cette conversion avec un minimum de temps d'arrêt. Si les utilisateurs existants ne sont pas nécessaires, nous pouvons simplement supprimer tous les utilisateurs. Gardez à l'esprit que les données existantes, telles que les achèvements, liées à ces utilisateurs ne seront pas migrées vers leur nouvel utilisateur. Voir la documentation ici

Références

Les instructions étape par étape pour la configuration de Tulip pour Azure Active Directory sont ici.

Configuration de l'accès

LTS 6

Avec la sortie des espaces de travail dans LTS 6, la stratégie d'autorisation SAML a changé pour mieux permettre aux organisations de gérer leurs utilisateurs sans créer une charge inutile pour l'IT.

Changements SAML

Il y a maintenant deux options pour l'autorisation :

SAML Custom Role Mapping

Lors de la première connexion, un utilisateur se voit attribuer un rôle basé sur les groupes présentés dans son attribut de rôle. Après cela, Tulip ne lira plus l'attribut role de cet utilisateur, et tout changement de rôle doit être effectué dans la plateforme par un propriétaire de compte.

Si cette méthode est choisie, vous devrez demander à votre équipe IdP d'ajouter le rôle approprié à tous les utilisateurs qui ont besoin d'un accès à Tulip.

Mappage des rôles par défaut

Lors de la première connexion, tous les utilisateurs se voient attribuer un niveau d'accès par défaut (Viewer avec accès Player). Le propriétaire du compte devra ensuite ajuster le rôle au niveau approprié.

Contrôle d'accès

Vous pouvez choisir d'ajouter un attribut de contrôle d'accès, pour lequel l'utilisateur doit posséder une valeur spécifique afin d'accéder à Tulip. Cette option est particulièrement pertinente pour les scénarios de mappage par défaut, dans lesquels vous souhaitez toujours déterminer qui doit pouvoir accéder à Tulip, indépendamment du rôle ou de l'espace de travail.

Par exemple :

  • L'attribut TulipAccessControl d'un utilisateur doit être défini sur True.
  • Un utilisateur doit appartenir à un groupe TulipUsers, qui est exposé via un attribut TulipAccessControl (voir exemple ci-dessous)

Si vous choisissez d'utiliser le contrôle d'accès, vous devrez demander à votre équipe IdP d'ajouter l'attribut et la valeur définis à tous les utilisateurs qui devraient avoir un accès quelconque à Tulip.

Espaces de travail

Pour en savoir plus sur les espaces de travail , cliquez ici.

Comme pour l'attribut "rôle", vous aurez maintenant la possibilité d'associer des utilisateurs à des espaces de travail.

Mappage personnalisé SAML des espaces de travail

Lors de la première connexion, l'accès à l'espace de travail est attribué à un utilisateur en fonction des groupes présentés dans son attribut d'espace de travail. Après cela, Tulip ne lira plus l'attribut d'espace de travail de cet utilisateur, et tout changement d'espace de travail doit être effectué dans la plateforme par un propriétaire de compte.

Si cette méthode est choisie, vous devrez demander à votre équipe IdP d'ajouter l'espace de travail approprié à tous les utilisateurs qui ont besoin d'un accès à Tulip.

Mappage par défaut de l'espace de travail

Lors de la première connexion, tous les utilisateurs ont accès à un espace de travail par défaut de votre choix. Le propriétaire du compte peut ensuite modifier l'accès à l'espace de travail.


Création de groupes d'accès

Pour l'option de mappage de rôle personnalisé (par défaut avant LTS 6)

Création de groupes d'accès Tulip standardisés :

Chaque utilisateur aura besoin d'un attribut de rôle spécifié dans votre IdP que Tulip utilise pour déterminer ses privilèges une fois qu'il s'est authentifié avec son nom d'utilisateur et son mot de passe IdP. Nous pouvons également utiliser ce champ Rôle pour déterminer à quels sites ils ont accès en utilisant une convention de dénomination standard. Bien qu'un champ "rôle" puisse être une simple variable définie, il est recommandé d'affecter l'utilisateur à des groupes spécifiques de Tulip et de les associer à un attribut.

Rôle

Passez en revue les rôles d'accès à Tulip ici. Chaque utilisateur aura besoin d'au moins un rôle. Si un utilisateur a plusieurs rôles, Tulip sélectionnera celui qui a l'accès le plus élevé.

Un exemple de rôle est celui de propriétaire de compte.

:: :(Info) (NOTE :)
Il doit y avoir au moins un propriétaire de compte par site.
:: :

Site

Supposons que votre organisation possède deux sites, avec une Instance Tulip pour chacun d'eux.

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

Combiner les deux

Nous pouvons combiner ces deux sites pour créer une matrice de groupe pour les utilisateurs à assigner. Nous recommandons aux organisations d'ajouter ou de précéder la valeur de Tulip, afin de faciliter le filtrage.

Convention : tulip-siteRole

acme-texas.tulip.co acme-london.tulip.co
Tulip-texasAccountOwner tulip-londonAccountOwner tulip-texasAccountOwner
tulip-texasApplicationSupervisor tulip-londonApplicationSupervisor tulip-texasApplicationSupervisor
Tulip-texasViewer tulip-londonViewer tulip-texasViewer
Opérateur tulip-texasOperator tulip-londonOperator
...

Si Jane Smith est le responsable du site du Texas, nous l'affecterons au groupe tulip-texasAccountOwner. Si Jane Smith a également besoin d'un accès visuel au site de Londres, elle pourrait être ajoutée au groupe tulip-londonViewer.

Exposer ces groupes comme un attribut pour Tulip

Dans votre IdP, Jane devrait avoir un attribut, tulip-role, où tous les groupes dont elle est membre et qui contiennent le préfixe "tulip-" seront mappés. Lorsqu'elle se connecte à Tulip, l'attribut tulip-role a deux valeurs : tulip-texasAccountOwner, tulip-londonViewer.

Rôles globaux

Vous pouvez également souhaiter créer des rôles d'accès globaux, comme par exemple celui de visualisateur. Le format pour cela serait :

tulip-globalViewer

:: :(Info) (NOTE :)
Si un utilisateur qui est membre du groupe de visualisation globale se connecte à un site où il a également un rôle avec plus d'accès, Tulip lui donnera l'accès le plus élevé disponible.
:: :


Cet article vous a-t-il été utile ?