> ## 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.

# Contrôles d'accès SAML

> Contrôlez qui peut se connecter ou s'inscrire dans EK en utilisant les attributs de métadonnées SAML.

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.

<Note>
  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](/super-admin/sa-automated-management) pour le guide d'accompagnement.
</Note>

## 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

<Tip>
  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.
</Tip>

## Modes d'accès

Accédez à **Super Admin → Sécurité et accès → Contrôles d'accès** pour sélectionner un mode.

<img src="https://mintcdn.com/automationanywhere/P9UkIpAqpipG-xbe/img/sa/access-mode.png?fit=max&auto=format&n=P9UkIpAqpipG-xbe&q=85&s=221e1cef0569afded822f8a5d8115b26" alt="Sélection du mode d'accès" width="834" height="263" data-path="img/sa/access-mode.png" />

| Mode                                         | Comportement                                                                                                     |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Autoriser tous les nouveaux utilisateurs** | Par défaut. Les inscriptions par e-mail/mot de passe, Google OAuth et SSO sont toutes autorisées.                |
| **Restreindre aux métadonnées SAML**         | Seuls 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**.

<img src="https://mintcdn.com/automationanywhere/AnqQHTb8za_1axzx/img/sa/saml-access-rules-v2.png?fit=max&auto=format&n=AnqQHTb8za_1axzx&q=85&s=0ff76c9da8d4c415e10bd1b8476cceee" alt="Règles d'accès SAML" width="1744" height="1038" data-path="img/sa/saml-access-rules-v2.png" />

### 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>` :

```xml theme={null}
<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 :

```xml theme={null}
<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 |

<Note>
  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.
</Note>

### Matrice de comportement de correspondance

| Attribut utilisateur (forme de transmission) | Curseur   | Valeur de règle | Correspondance ? |
| -------------------------------------------- | --------- | --------------- | ---------------- |
| 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

<AccordionGroup>
  <Accordion title="Ce qui est bloqué">
    * Nouvelles inscriptions par e-mail/mot de passe
    * Nouvelles inscriptions Google OAuth
    * Nouveaux utilisateurs SSO dont les attributs SAML ne correspondent à aucune règle
  </Accordion>

  <Accordion title="Ce qui est toujours autorisé">
    * 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
  </Accordion>
</AccordionGroup>

<Note>
  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.
</Note>

<Warning>
  **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.
</Warning>

## Configuration des contrôles d'accès

<Steps>
  <Step title="Ouvrir les contrôles d'accès">
    Allez à **Super Admin → Sécurité et accès → Contrôles d'accès**.
  </Step>

  <Step title="Sélectionner le mode restreint">
    Choisissez **Restreindre aux métadonnées SAML**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Enregistrer et valider">
    Enregistrez vos règles et testez avec des comptes SSO représentatifs avant de déployer largement.
  </Step>
</Steps>

### 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

<AccordionGroup>
  <Accordion title="Utilisateur refusé de manière inattendue">
    * 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
  </Accordion>

  <Accordion title="Super Admin verrouillé">
    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.
  </Accordion>
</AccordionGroup>

## 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