> ## Documentation Index > Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt > Use this file to discover all available pages before exploring further. # Gestion automatisée > Placer automatiquement les utilisateurs SSO dans les équipes et projets appropriés en fonction de leurs attributs de métadonnées SAML. Lorsqu'un utilisateur se connecte via SSO SAML, Enterprise Knowledge peut évaluer ses attributs de métadonnées et l'assigner automatiquement à une équipe et, optionnellement, à tous les projets au sein de cette équipe — avec le rôle approprié. 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](/super-admin/sa-access-controls.mdx) 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](/super-admin/sa-teams) Validez les noms et valeurs des attributs à partir de quelques connexions SSO réussies avant d'activer l'automatisation. La vue utilisateur Super Admin affiche les métadonnées SAML stockées pour chaque utilisateur SSO — utilisez ceci comme source de vérité lors de la création des règles. ## 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 | Une règle peut également inclure : * **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, US` né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. Il n'y a pas de bris d'égalité entre les règles de spécificité égale. Si deux règles sont à égalité, EK choisit la première créée et émet un journal `WARNING` listant les IDs de règle liés. Traitez ceci comme une erreur de configuration et restructurez les règles pour éliminer le chevauchement. ### 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 ``. 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 | Consultez [Contrôles d'accès SAML — Matrice de comportement de correspondance](/super-admin/sa-access-controls#matching-behavior-matrix) pour une table de référence complète. ## 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 : 1. **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 2. **Rôle de membre d'équipe par défaut** — `Member` ou `Admin` tel 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 commutateur `is_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 : 1. **Remplacement de rôle de projet conditionnel** correspondant (correspondance la plus spécifique) 2. **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` **Résultat :** * Tous les utilisateurs `engineering` sont ajoutés à l'équipe * Les utilisateurs qui ont également `level = manager` reçoivent `Admin` sur 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). Restrictions de réassignation d'équipe | 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. | En pratique : * **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 Si la propriété ne peut pas être transférée en toute sécurité lors de la réassignation, EK applique des mesures de sauvegarde pour prévenir les états de propriété cassés. ## Configuration des règles de gestion automatisée Allez à **Super Admin → Utilisateurs et espaces de travail → Équipes → Gestion automatisée** et cliquez sur **Ajouter une règle**. 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. Nouvelle règle d'assignation d'é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. Décidez d'activer ou non **Ajout automatique aux projets d'équipe** et/ou **Réassignation d'équipe continue forcée**. Choisissez un **Rôle de projet par défaut** et ajoutez optionnellement des **Remplacements de rôle de projet conditionnel**. 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. Testez avec de vrais utilisateurs SSO représentant chaque modèle de métadonnées attendu avant d'activer en production. ## 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 projet `Viewer`) 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 * 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 * 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 * 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`, `Editor` ou `Viewer`) est défini * Autorisez un court délai pour le traitement asynchrone en arrière-plan * 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 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