> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Configuration de SAML
> Décrit le fonctionnement d’Auth0 avec le protocole SAML (Security Assertion Markup Language).
## Fournisseurs de services SAML
Les applications, en particulier les applications personnalisées, peuvent authentifier les utilisateurs auprès d’un IdP externe au moyen de protocoles comme OpenID Connect (OIDC) ou OAuth 2.0. Cependant, vous pourriez vouloir utiliser un fournisseur SAML d’entreprise pour l’authentification, même si votre application a été conçue pour utiliser l’un ou l’autre de ces protocoles.
## Fournisseurs d’identité SAML
Certaines applications (comme Salesforce, Box et Workday) permettent aux utilisateurs de s’authentifier auprès d’un fournisseur d’identité (IdP) externe à l’aide du protocole SAML. Vous pouvez ensuite intégrer l’application à Auth0, qui agit comme fournisseur d’identité (IdP) SAML de l’application. Les utilisateurs de l’application seront redirigés vers Auth0 pour se connecter, et Auth0 peut les authentifier au moyen de n’importe quelle connexion d’authentification backend, comme un répertoire LDAP, une base de données ou un autre IdP SAML ou fournisseur social. Une fois l’utilisateur authentifié, Auth0 renvoie à l’application une assertion SAML attestant de cette authentification.
Voici une liste de services IdP reconnus comme prenant en charge le protocole SAML. Il peut exister d’autres services en plus de ceux indiqués ci-dessous. Les fournisseurs suivants ont participé à un test d’interopérabilité de Kantara et sont donc susceptibles d’être conformes à la spécification SAML.
* adAS
* ADFS
* Dot Net Workflow
* Elastic SSO Team & Enterprise
* Entrust GetAccess & IdentityGuard (vérifiez le protocole pris en charge)
* EIC (vérifiez le protocole pris en charge)
* Ilex Sign\&go
* iWelcome
* NetIQ Access Manager
* OpenAM
* RCDevs Open SAMPL IdP
* Optimal IdM VIS Federation Services
* Oracle Access Manager (Oracle Identity Federation a été fusionné à celui-ci)
* PingFederate (IDP Light)
* RSA Federated Identity (IDP Light)
* SecureAuth
* Symplified
* Tivoli Federated Identity Manager
* TrustBuilder
* Ubisecure SSO
* WSO2 Identity Server
Vous pouvez également consulter des instructions détaillées sur la façon de [configurer de nombreux fournisseurs d’identité SAML avec Auth0](/fr-CA/docs/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider).
## Auth0 comme fournisseur de services
Si Auth0 agit comme fournisseur de services dans une fédération SAML, Auth0 peut acheminer les demandes d’authentification vers un fournisseur d’identité sans qu’un compte ait déjà été créé pour un utilisateur donné. À l’aide de l’assertion renvoyée par le fournisseur d’identité, Auth0 peut recueillir les renseignements nécessaires pour créer un profil utilisateur (ce processus est parfois appelé provisionnement juste à temps). Pour en savoir plus, consultez [Select from Multiple Connection Options](/fr-CA/docs/libraries/lock/selecting-from-multiple-connection-options).
Même si Auth0 n’exige pas la création préalable de comptes utilisateur avant le processus d’authentification, l’application intégrée à Auth0 pourrait l’exiger. Si c’est le cas, vous avez plusieurs options pour gérer la situation :
* Une fois l’utilisateur créé par le fournisseur d’identité, vous pouvez utiliser un processus hors bande pour créer l’utilisateur correspondant dans l’application (ou dans Auth0) et ajouter les attributs de profil requis par l’application. Si, après l’authentification, certains attributs sont absents du profil, l’application peut les récupérer à partir de la source appropriée et les stocker dans le profil utilisateur Auth0. Les attributs supplémentaires sont ensuite envoyés à l’application (en plus de ceux ajoutés par le fournisseur d’identité) à la prochaine ouverture de session de l’utilisateur.
* Vous pouvez utiliser une Rule Auth0 pour appeler une API afin de récupérer les renseignements manquants et les ajouter dynamiquement au profil Auth0 (qui est ensuite renvoyé à l’application). Les Rules s’exécutent après une authentification réussie, et votre application peut récupérer les attributs de profil à chaque fois, ou vous pouvez enregistrer ces attributs dans le profil Auth0.
* Auth0 peut transmettre à l’application les renseignements de base du profil provenant du fournisseur d’identité, puis l’application récupère les renseignements manquants auprès d’une autre source. À partir de ces deux ensembles de renseignements, l’application crée un profil utilisateur local.
Vous pouvez spécifier des domaines de courriel dans la configuration de la connexion SAMLP Auth0 afin de contrôler l’IdP qui gère un groupe précis d’utilisateurs. Par exemple, si vous ajoutez le domaine de courriel `example.com` à la configuration de la connexion SAMLP Auth0 pour Company X, tous les utilisateurs dont le courriel se termine par `example.com` sont pris en charge par l’IdP propre à Company X.
## Auth0 comme fournisseur d’identité
Si Auth0 agit comme fournisseur d’identité dans une fédération SAML, les comptes d’utilisateur peuvent être créés de plusieurs façons :
* À l’aide d’un système d’authentification principal, comme un répertoire LDAP, une base de données ou un autre fournisseur d’identité SAML.
* À l’aide du Auth0 Dashboard.
* En appelant la Management API d’Auth0.
* En mettant en place l’inscription libre-service.
Si votre application est conçue pour récupérer les informations du profil utilisateur à partir d’un magasin local, vous devrez créer le profil local une fois les comptes créés dans Auth0. Voici quelques façons de procéder :
* Un processus hors bande qui crée des profils utilisateur dans l’application;
* Une Rule Auth0 qui s’exécute lors de la première connexion et appelle une API de l’application pour y créer le profil utilisateur;
* Modifier l’application pour créer des profils utilisateur de façon dynamique, en fonction des informations contenues dans l’assertion SAML.