Skip to main content

​
Fournisseurs de services SAML

Les applications, surtout les applications personnalisées, peuvent authentifier les utilisateurs auprès d’un externe à l’aide de protocoles comme Connect (OIDC) ou . Toutefois, il se peut que vous souhaitiez utiliser un fournisseur d’entreprise pour l’authentification, même si votre application a été conçue pour utiliser l’un ou l’autre de ces protocoles.
Diagramme des protocoles des fournisseurs de services SAML

​
Fournisseurs d’identité SAML

Certaines applications (comme Salesforce, Box et Workday) permettent aux utilisateurs de s’authentifier auprès d’un IdP externe à l’aide du protocole SAML. Vous pouvez ensuite intégrer l’application à Auth0, qui agit comme l’IdP SAML de l’application. Les utilisateurs de l’application seront redirigés vers Auth0 pour se connecter, et Auth0 peut les authentifier à l’aide de n’importe quelle connexion d’authentification backend, comme un annuaire 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 pour le confirmer.
Diagramme des protocoles SAML IdP
Voici une liste de services IdP connus pour prendre en charge le protocole SAML. Il peut y avoir d’autres services que ceux indiqués ci-dessous. Les fournisseurs suivants ont participé à un test d’interopérabilité Kantara et sont donc susceptibles d’être bien conformes à la spécification SAML.
  • adAS
  • ADFS
  • Dot Net Workflow
  • Elastic 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 aussi consulter des instructions détaillées sur la façon de configurer de nombreux fournisseurs d’identité SAML avec Auth0.

​
Auth0 comme fournisseur de services

Si Auth0 agit comme fournisseur de services dans une fédération SAML, Auth0 peut acheminer les requêtes d’authentification vers un fournisseur d’identité sans qu’un compte d’utilisateur ait été créé au préalable pour un utilisateur précis. À 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 Choisir parmi plusieurs options de connexion. Même si Auth0 n’exige pas que des comptes d’utilisateur soient créés à l’avance avant le processus d’authentification, l’application intégrée à Auth0 pourrait l’exiger. Si c’est le cas, plusieurs options s’offrent à vous 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 le compte d’utilisateur correspondant dans l’application (ou dans Auth0) et ajouter les attributs de profil exigés par l’application. Si, après l’authentification, certains attributs sont absents du profil, l’application peut les obtenir de la source appropriée et les stocker dans le profil utilisateur Auth0. Ces attributs supplémentaires seront ensuite transmis à l’application (en plus de ceux ajoutés par le fournisseur d’identité) à la prochaine connexion de l’utilisateur.
  • Vous pouvez utiliser une règle Auth0 pour faire une requête API afin de récupérer toute information manquante et l’ajouter dynamiquement au profil Auth0 (qui est ensuite renvoyé à l’application). Les règles s’exécutent après une authentification réussie, et votre application peut récupérer les attributs du 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 l’information manquante à partir d’une autre source. À partir de ces deux ensembles de renseignements, l’application crée un profil utilisateur local.
Vous pouvez préciser des domaines de courriel dans la configuration de la connexion Auth0 SAMLP 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 Auth0 SAMLP pour Company X, tous les utilisateurs dont l’adresse courriel utilise le domaine example.com seront gérés 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 côté serveur, comme un annuaire LDAP, une base de données ou un autre fournisseur d’identité SAML.
  • À l’aide du .
  • En appelant la d’Auth0.
  • En offrant l’inscription libre-service aux utilisateurs.
Si votre application est conçue pour récupérer les renseignements du profil utilisateur à partir d’un référentiel local, vous devrez créer le profil local une fois les comptes créés dans Auth0. Voici quelques façons de le faire :
  • Un processus hors bande qui crée des profils utilisateur dans l’application;
  • Une règle Auth0 qui s’exécute à la première connexion et appelle une API de l’application pour y créer le profil utilisateur;
  • La modification de l’application pour qu’elle crée dynamiquement des profils utilisateur à partir des renseignements contenus dans l’assertion SAML.