Passer au contenu principal
Lorsqu’un utilisateur se connecte via SAML SSO, EK reçoit les attributs de métadonnées SAML (par exemple department, group ou role). La fonction de contrôle d’accès utilise ces attributs pour déterminer si un utilisateur est autorisé à accéder à l’application.
Les contrôles d’accès et la gestion automatique des équipes sont des fonctionnalités indépendantes, mais sont généralement utilisées ensemble. Consultez Attribution automatique des équipes et des projets pour le guide d’accompagnement.

​
Prérequis

Avant d’activer les contrôles d’accès :
  • SAML SSO doit être configuré et envoyer les attributs de métadonnées lors de la connexion
  • L’assertion SAML doit inclure des attributs stables à vérifier
Validez les noms et valeurs d’attributs à partir de quelques connexions SSO réussies avant d’activer les restrictions. L’affichage utilisateur Super Admin montre les métadonnées SAML stockées pour chaque utilisateur SSO — utilisez-le comme source de vérité lors de la rédaction des règles.

​
Modes d’accès

Accédez à Super Admin → Sécurité et accès → Contrôles d’accès pour sélectionner un mode. Sélection du mode d'accès
ModeComportement
Autoriser tous les nouveaux utilisateursPar défaut. Les inscriptions par e-mail/mot de passe, Google OAuth et SSO sont toutes autorisées.
Restreindre aux métadonnées SAMLSeuls les utilisateurs SSO dont les attributs SAML correspondent à au moins une règle configurée sont autorisés.

​
Fonctionnement de la correspondance des règles

Les règles sont définies par un nom d’attribut et une ou plusieurs valeurs d’attribut. Règles d'accès SAML

​
Le modèle mental : tout est un ensemble

Une règle et un attribut utilisateur entrant sont tous deux réduits à un ensemble de jetons et comparés avec la sémantique de sous-ensemble :
  • Une règle correspond lorsque ses jetons requis sont un sous-ensemble des jetons de l’utilisateur
  • La logique entre les règles est OU — toute correspondance d’une seule règle accorde l’accès
  • Toutes les comparaisons sont insensibles à la casse et ignorent les espaces blancs au début/fin

​
Règles multi-jetons (ET dans une règle)

Les virgules dans le champ Valeur(s) d’attribut sont des séparateurs de jetons. L’interface promeut chaque entrée séparée par des virgules en puce ; la règle nécessite que tous les jetons listés soient présents.
  • engineering — nécessite un jeton : l’attribut de l’utilisateur doit contenir engineering
  • Accounting, US — nécessite deux jetons : l’attribut de l’utilisateur doit contenir à la fois accounting et us

​
Gestion des différentes formes de transmission SAML

Les attributs SAML peuvent arriver sous deux formes : Multi-valeur natif — le fournisseur d’identité envoie plusieurs éléments <AttributeValue> dans un <Attribute> : 
<Attribute Name="memberOf">
  <AttributeValue>Accounting</AttributeValue>
  <AttributeValue>US</AttributeValue>
</Attribute>
EK traite toujours ceci comme un ensemble. Aucune configuration supplémentaire requise. C’est la forme préférée. Valeur unique CSV — le fournisseur d’identité envoie un <AttributeValue> contenant des jetons séparés par des virgules : 
<Attribute Name="memberOf">
  <AttributeValue>Accounting,US</AttributeValue>
</Attribute>
C’est ambigu (s’agit-il de deux groupes ou d’une valeur littérale contenant une virgule ?). Utilisez le curseur par règle pour le résoudre :
Curseur : « IdP compacte les valeurs multiples en une seule chaîne »Comportement
Désactivé (par défaut)La chaîne de l’utilisateur est traitée comme un jeton littéral unique
ActivéLa chaîne de l’utilisateur est fractionnée sur les virgules et correspondante en tant qu’ensemble
Ce curseur affecte uniquement la façon dont l’attribut de l’utilisateur est interprété. Les virgules du côté de la règle sont toujours des séparateurs de jetons.

​
Matrice de comportement de correspondance

Attribut utilisateur (forme de transmission)CurseurValeur de règleCorrespondance ?
natif [\"A\",\"B\",\"C\"]désactivéA✓
natif [\"A\",\"B\",\"C\"]désactivéA, B✓
unique \"A,B,C\"désactivéA✗
unique \"A,B,C\"désactivéA, B✗
unique \"A,B,C\"activéA✓
unique \"A,B,C\"activéA, B✓
unique \"A\"désactivéA✓

​
Comportement en mode restreint actif

  • Nouvelles inscriptions par e-mail/mot de passe
  • Nouvelles inscriptions Google OAuth
  • Nouveaux utilisateurs SSO dont les attributs SAML ne correspondent à aucune règle
  • Utilisateurs SSO existants qui correspondent à au moins une règle (vérifiée à chaque connexion)
  • Utilisateurs locaux existants se connectant à des comptes existants
  • Comptes Super Admin via SSO, même sans règle correspondante (sécurité délibérée)
  • Clés API appartenant à des Super Admins ou clés au niveau du projet sans ligne d’utilisateur associée
Les demandes de clé API des utilisateurs liés à SAML sont également contrôlées en mode restreint. EK vérifie les métadonnées SAML stockées de l’utilisateur (de sa dernière connexion SSO) par rapport aux règles d’accès avant d’autoriser l’accès API.
Comportement en ouverture par défaut : Si le mode restreint est ACTIVÉ mais qu’aucune règle d’accès SAML n’existe, EK autorise tous les utilisateurs SSO. Cela prévient un verrouillage accidentel, mais vous devez toujours définir au moins une règle avant d’activer une gouvernance stricte.

​
Configuration des contrôles d’accès

1

Ouvrir les contrôles d'accès

Allez à Super Admin → Sécurité et accès → Contrôles d’accès.
2

Sélectionner le mode restreint

Choisissez Restreindre aux métadonnées SAML.
3

Ajouter des règles d'accès SAML

Ajoutez une ou plusieurs règles sous Règles d’accès SAML. Exemples :
department = engineering
memberOf = ekb-users
memberOf = ekb-users, us   (nécessite les deux jetons)
Activez IdP compacte les valeurs multiples en une seule chaîne si l’attribut côté utilisateur arrive sous forme d’une chaîne séparée par des virgules.
4

Enregistrer et valider

Enregistrez vos règles et testez avec des comptes SSO représentatifs avant de déployer largement.

​
Approche de déploiement recommandée

  1. Créez des règles pendant que le mode est toujours défini sur Autoriser tous les nouveaux utilisateurs
  2. Validez en inspectant les métadonnées SAML stockées pour les comptes SSO pilotes dans l’affichage utilisateur Super Admin
  3. Passez à Restreindre aux métadonnées SAML
  4. Surveillez les connexions et les résultats d’accès refusé

​
Liste de vérification des tests

Après la configuration, vérifiez chaque scénario :
  • Un utilisateur SSO qui devrait être autorisé peut se connecter
  • Un utilisateur SSO qui ne devrait pas être autorisé est redirigé vers l’expérience d’accès refusé
  • Les utilisateurs refusés voient l’expérience d’accès refusé attendue
  • Au moins une règle valide est active pour éviter la dérive de politique

​
Dépannage

  • Confirmez que le mode d’accès n’est pas involontairement défini comme restreint
  • Vérifiez que la règle utilise le nom d’attribut et la valeur attendue exacte
  • Confirmez que le fournisseur d’identité envoie cet attribut pour cet utilisateur
  • Pour les règles multi-jetons, chaque jeton listé doit être présent dans l’attribut de l’utilisateur — vérifiez les métadonnées SAML stockées dans l’affichage utilisateur Super Admin
  • Si l’attribut arrive sous forme d’une chaîne CSV unique, confirmez que IdP compacte les valeurs multiples en une seule chaîne est activé sur la règle
  • Vérifiez si l’utilisateur tente une connexion par e-mail/mot de passe ou Google OAuth pendant que le mode restreint est actif
Les comptes Super Admin sont toujours autorisés via SSO même sans règle correspondante. S’il est verrouillé, connectez-vous via SSO en utilisant un compte Super Admin pour retrouver l’accès.

​
Guidance opérationnelle

  • Traitez les règles d’accès comme une configuration sensible à la sécurité
  • Utilisez des processus de gestion des changements pour les mises à jour de production
  • Revalidez après les modifications de réclamations du fournisseur d’identité
  • Examinez régulièrement les règles et supprimez les mappages obsolètes
  • Gardez au moins une règle valide active pour éviter les états d’ouverture par défaut involontaires