La gestion automatisée et les contrôles d’accès sont des fonctionnalités indépendantes, mais elles sont généralement utilisées ensemble. Consultez le guide Contrôles d’accès SAML pour le guide complémentaire.
Conditions préalables
Avant d’activer la gestion automatisée :- SSO SAML doit être configuré et envoyer des attributs de métadonnées lors de la connexion
- L’assertion SAML doit inclure des attributs stables pour la correspondance
- Les équipes cibles doivent déjà exister dans EK. Pour les instructions sur la création d’équipes, consultez Gestion des équipes
Structure des règles
Accédez à Super Admin → Utilisateurs et espaces de travail → Équipes → Gestion automatisée pour configurer les règles. Chaque règle comprend :| Champ | Requis | Description |
|---|---|---|
| Nom d’attribut SAML | Oui | La clé d’attribut de l’assertion SAML |
| Valeur(s) d’attribut | Oui | Un ou plusieurs jetons séparés par des virgules — tous les jetons répertoriés doivent correspondre (logique ET) |
| Équipe cible | Oui | L’équipe à laquelle assigner l’utilisateur |
| Rôle de membre d’équipe par défaut | Optionnel | Member (par défaut) ou Admin |
| Ajout automatique aux projets d’équipe | Optionnel | Ajoute l’utilisateur à tous les projets non-par-défaut de l’équipe |
| Rôle de projet par défaut | Optionnel | Admin, Editor ou Viewer |
| Réassignation d’équipe continue forcée | Optionnel | Déplace les utilisateurs à chaque connexion, pas seulement à la première connexion |
- Remplacements de rôle d’équipe conditionnel — modifier le rôle d’adhésion d’équipe en fonction d’attributs SAML supplémentaires
- Remplacements de rôle de projet conditionnel — modifier le rôle du projet en fonction d’attributs SAML supplémentaires (s’applique uniquement lorsque l’ajout automatique est activé)
Fonctionnement de la correspondance des règles
La correspondance des attributs utilise le même moteur que les contrôles d’accès. Les règles et les attributs utilisateur sont tous deux traités comme des ensembles de jetons et comparés avec la sémantique des sous-ensembles — une règle correspond lorsque ses jetons requis sont un sous-ensemble des jetons de l’utilisateur.- Les virgules dans Valeur(s) d’attribut sont des séparateurs de jetons.
Accounting, USnécessite que l’utilisateur ait les deux jetons (logique ET dans une règle). - La spécificité équivaut au nombre de jetons qu’une règle nécessite. Lorsque plusieurs règles correspondent, la plus spécifique (plus de jetons) gagne.
Gestion de différentes formes de câblage SAML
Les attributs SAML peuvent arriver sous deux formes, et chaque règle expose un commutateur pour les gérer : Multi-valeur natif — le fournisseur d’identité envoie plusieurs éléments<AttributeValue>. EK traite toujours ceci comme un ensemble automatiquement.
Valeur unique en CSV — le fournisseur d’identité emballe les valeurs dans une chaîne séparée par des virgules. Utilisez le commutateur par règle :
| Commutateur : « Le fournisseur d’identité emballe les valeurs multiples en une seule chaîne » | Comportement |
|---|---|
| Désactivé (par défaut) | Chaîne de l’utilisateur traitée comme un seul jeton littéral |
| Activé | Chaîne de l’utilisateur divisée sur les virgules et associée comme un ensemble |
Comportement d’assignation d’équipe
À chaque connexion SSO, EK évalue les règles configurées par rapport aux métadonnées SAML de l’utilisateur et choisit la règle la plus spécifique correspondante.| État de l’utilisateur | Résultat |
|---|---|
| Pas encore d’équipe | Assigné à l’équipe cible |
| Déjà dans l’équipe cible | Aucun changement |
| Dans une équipe différente | Déplacé uniquement si la Réassignation d’équipe continue forcée est active |
| Propriétaire d’une équipe multi-membres | Non déplacé de force (prévient l’abandon de propriété) |
| Seul membre/propriétaire de leur équipe | Déplacé ; l’équipe désormais vide est supprimée |
Pour l’intégration initiale SSO, la réassignation est toujours forcée pour établir le placement correct.
Rôle d’adhésion à l’équipe
Le rôle auquel un utilisateur est ajouté à une équipe est résolu dans cet ordre :- Remplacement de rôle d’équipe conditionnel — le remplacement le plus spécifique sur la règle associée dont les jetons sous-ensemble correspondent à l’utilisateur
- Rôle de membre d’équipe par défaut —
MemberouAdmintel que configuré sur la règle (par défaut hérité :Member)
Les rôles d’équipe sont appliqués uniquement au moment de l’ajout. Si un utilisateur est déjà dans l’équipe cible, son rôle existant est préservé — les connexions ultérieures ne le changeront pas. Promouvoir ou rétrograder un membre existant nécessite une action d’administrateur explicite.
Remplacements de rôle d’équipe conditionnel
Chaque remplacement spécifie un Nom d’attribut, Valeur(s) d’attribut, le commutateuris_csv_value optionnel et un Rôle d’équipe (Member ou Admin). Le remplacement le plus spécifique correspondant gagne ; les égalités enregistrent un avertissement.
Ajout automatique aux projets
Lorsque Ajout automatique aux projets d’équipe est activé sur une règle, EK ajoute l’utilisateur aux projets non-par-défaut dans l’équipe cible. L’utilisateur n’est ajouté qu’aux projets dont il n’est pas déjà membre. Priorité d’assignation de rôle :- Remplacement de rôle de projet conditionnel correspondant (correspondance la plus spécifique)
- Rôle de projet par défaut défini sur la règle d’équipe
L’assignation de projet s’exécute de manière asynchrone. L’adhésion à l’équipe peut apparaître avant la réalisation de tous les adhésions au projet.
Les rôles de projet sont appliqués uniquement au moment de l’ajout. Les adhésions au projet existantes ne sont jamais réévaluées ni modifiées lors des connexions ultérieures.
Remplacements de rôle de projet conditionnel
Les remplacements de rôle permettent d’assigner un rôle de projet différent en fonction d’attributs SAML supplémentaires. Exemple :- Règle d’équipe :
department = engineering, rôle par défaut →Viewer - Remplacement de rôle :
level = manager→Admin
- Tous les utilisateurs
engineeringsont ajoutés à l’équipe - Les utilisateurs qui ont également
level = managerreçoiventAdminsur les projets ajoutés automatiquement - Les non-gestionnaires conservent
Viewer
Si plusieurs remplacements de rôle conditionnel pouvaient correspondre au même utilisateur, le plus spécifique (plus de jetons) gagne. Les égalités enregistrent un avertissement et reviennent au remplacement créé en premier — restructurez les remplacements pour éviter les égalités.
Restrictions de réassignation d’équipe
Trouvées dans Super Admin → Équipes → Gestion automatisée → Restrictions de réassignation d’équipe, ces paramètres contrôlent ce qui se passe aux adhésions au projet lorsqu’un utilisateur se déplace entre les équipes. Les trois sont par défaut désactivées (non-destructif).
| Paramètre | Description |
|---|---|
| 1. Supprimer l’utilisateur des projets de l’ancienne équipe | Commutateur principal. Supprime les adhésions aux projets existants lors de la réassignation. |
| 2. Les projets possédés par l’utilisateur les suivent | Dépend du paramètre 1. Les projets possédés se déplacent vers la nouvelle équipe. |
| 3. Supprimer les anciens membres d’équipe des projets suivis | Dépend des paramètres 1 et 2. Nettoie l’accès à l’ancienne équipe sur les projets déplacés. |
- Paramètre 1 uniquement — l’utilisateur est supprimé des projets de l’ancienne équipe ; les projets possédés restent dans l’ancienne équipe et la propriété est transférée au propriétaire de l’ancienne équipe
- Paramètres 1 + 2 — les projets que l’utilisateur possède se déplacent vers la nouvelle équipe ; les membres existants de ces projets restent en place
- Paramètres 1 + 2 + 3 — les anciens membres de l’équipe sont également supprimés des projets qui ont suivi le propriétaire
Configuration des règles de gestion automatisée
Ouvrir la gestion automatisée
Allez à Super Admin → Utilisateurs et espaces de travail → Équipes → Gestion automatisée et cliquez sur Ajouter une règle.
Entrer les critères de correspondance SAML
Fournissez le Nom d’attribut SAML, Valeur(s) d’attribut et Équipe cible.Pour les règles multi-jetons, tapez chaque jeton et appuyez sur la virgule pour créer une puce (par exemple 
accounting + us pour exiger les deux). Basculez Le fournisseur d’identité emballe les valeurs multiples en une seule chaîne si nécessaire.Définir le rôle d'adhésion à l'équipe
Choisissez un Rôle de membre d’équipe par défaut (
Member ou Admin) et ajoutez optionnellement des Remplacements de rôle d’équipe conditionnel pour les utilisateurs qui doivent recevoir un rôle d’équipe différent en fonction d’attributs supplémentaires.Configurer les paramètres optionnels
Décidez d’activer ou non Ajout automatique aux projets d’équipe et/ou Réassignation d’équipe continue forcée.
Définir le rôle du projet (si l'ajout automatique est activé)
Choisissez un Rôle de projet par défaut et ajoutez optionnellement des Remplacements de rôle de projet conditionnel.
Enregistrer et configurer les restrictions de réassignation
Enregistrez la règle, puis configurez optionnellement les Restrictions de réassignation d’équipe pour définir le comportement lors du changement d’équipes par les utilisateurs.
Meilleures pratiques de conception de règles
- Utilisez des attributs de fournisseur d’identité stables — évitez les valeurs volatiles ou changeant fréquemment
- Maintenez la cohérence des noms d’attributs avec les noms de revendications SAML exacts (sensible à la casse au niveau de la revendication dans certains fournisseurs d’identité)
- Préférez les attributs SAML multi-valeurs natifs lorsque votre fournisseur d’identité les supporte — ils sont sans ambiguïté et ne nécessitent pas le commutateur
is_csv_value - Évitez les règles chevauchantes de la même spécificité — si vous voyez un avertissement « Correspondance ambiguë », ajoutez plus de jetons à une règle pour la rendre strictement plus spécifique
- Commencez avec le principe du moindre privilège (rôle d’équipe
Member, rôle de projetViewer) et élevez uniquement où nécessaire via les remplacements conditionnels - Documentez la propriété des règles et planifiez des révisions périodiques
Liste de vérification des tests
Après la configuration, vérifiez chaque scénario :- Les utilisateurs autorisés sont placés dans la bonne équipe avec le bon rôle d’équipe
- Les remplacements de rôle d’équipe conditionnel s’appliquent aux bons utilisateurs
- L’ajout automatique aux projets se termine avec le bon rôle (attendez quelques secondes pour le traitement asynchrone)
- Les remplacements de rôle de projet conditionnel s’appliquent aux bons utilisateurs
- La réassignation forcée fonctionne comme prévu (si activée)
- Les paramètres de restriction de réassignation se comportent correctement lors du mouvement d’équipe
Dépannage
L'utilisateur s'est connecté mais n'a pas été assigné à l'équipe attendue
L'utilisateur s'est connecté mais n'a pas été assigné à l'équipe attendue
- Confirmez qu’une règle d’assignation d’équipe correspondante existe
- Confirmez que l’équipe cible existe toujours
- Vérifiez que les jetons d’attribut/valeur de la règle sont un sous-ensemble des métadonnées SAML réelles de l’utilisateur (vérifiez la vue utilisateur Super Admin)
- Activez Réassignation d’équipe continue forcée si l’utilisateur appartient déjà à une autre équipe et doit être déplacé
- Si l’utilisateur est propriétaire d’une équipe multi-membres, il ne sera pas déplacé automatiquement — c’est intentionnel
- Si les journaux contiennent un avertissement
Correspondance ambiguë, deux règles sont à égalité de spécificité ; restructurez pour éliminer le chevauchement
L'utilisateur est assigné à l'équipe mais avec le mauvais rôle d'équipe
L'utilisateur est assigné à l'équipe mais avec le mauvais rôle d'équipe
- Vérifiez si un Remplacement de rôle d’équipe conditionnel existe et correspond à l’utilisateur
- Les rôles d’équipe ne sont appliqués que lors de l’ajout — si l’utilisateur était déjà dans l’équipe avant l’ajout du remplacement, son rôle existant est préservé ; promouvez ou rétrogradez-le manuellement
- Pour les égalités entre les remplacements, vérifiez les journaux et ajoutez plus de jetons au remplacement prévu pour le rendre strictement plus spécifique
L'utilisateur est assigné à l'équipe mais pas aux projets
L'utilisateur est assigné à l'équipe mais pas aux projets
- Confirmez que Ajout automatique aux projets d’équipe est activé sur la règle associée
- Confirmez que l’équipe a des projets non-par-défaut
- Confirmez qu’un rôle de projet valide (
Admin,EditorouViewer) est défini - Autorisez un court délai pour le traitement asynchrone en arrière-plan
Le remplacement de rôle n'a pas été appliqué
Le remplacement de rôle n'a pas été appliqué
- Confirmez que le remplacement de rôle est attaché à la règle d’assignation d’équipe correcte
- Confirmez que l’attribut/valeur supplémentaire existe réellement dans les métadonnées SAML de l’utilisateur
- Si le rôle par défaut est appliqué, aucun remplacement conditionnel n’a correspondu
- Si l’attribut arrive sous forme de chaîne unique en CSV, confirmez que Le fournisseur d’identité emballe les valeurs multiples en une seule chaîne est activé sur le remplacement
Avertissement « Correspondance ambiguë » dans les journaux
Avertissement « Correspondance ambiguë » dans les journaux
Deux ou plusieurs règles (ou remplacements) de spécificité égale ont correspondu au même utilisateur. EK a choisi celle créée en premier de manière déterministe, mais la configuration est fragile.La ligne de journal liste les IDs de règle liés. Modifiez-en une pour ajouter plus de jetons requis et la rendre strictement plus spécifique, ou éliminez complètement le chevauchement.
Orientation opérationnelle
- Traitez les règles d’assignation comme une configuration sensible à la sécurité
- Utilisez les processus de gestion des changements pour les mises à jour en production
- Retestez après tout changement de revendication du fournisseur d’identité (par exemple, passer de CSV-shouvé à multi-valeur natif, ou renommer une revendication)
- Examinez périodiquement les règles et supprimez les mappages obsolètes
- Inspectez les métadonnées SAML stockées dans la vue utilisateur Super Admin avant de créer de nouvelles règles