Gérer la configuration d’entreprise en libre-service

Utilisez la configuration d’entreprise en libre-service pour déléguer la configuration du SSO à vos clients B2B.

La configuration d’entreprise en libre-service fournit aux clients interentreprises (B2B) les outils nécessaires pour déléguer la configuration du SSO à leurs clients d’entreprise. Elle ne requiert qu’une configuration minimale dans votre locataire Auth0 pour offrir à vos clients un assistant libre-service qui les guide tout au long du processus d’activation.

Une fois qu’un client a terminé sa configuration, l’intégration SSO est automatiquement ajoutée à votre locataire en tant que connexion d’entreprise.

Les utilisateurs ayant les rôles suivants dans l’Auth0 Dashboard peuvent utiliser cette fonctionnalité :

• Les utilisateurs Admin et Editor - Connections peuvent créer et gérer des profils libre-service.
• Les utilisateurs Viewer - Config peuvent uniquement consulter les profils libre-service.

Pour mettre en place la configuration d’entreprise en libre-service, vous configurerez les composants suivants à l’aide de la Management API ou de l’Auth0 Dashboard :

• Profil libre-service : définit les éléments clés des implémentations SSO des clients, y compris les fournisseurs d’identité (IdP) qu’ils peuvent utiliser et les attributs utilisateur qu’ils doivent recueillir, comme le courriel. Vous pouvez créer jusqu’à 20 profils dans votre locataire pour différents clients ou segments.
• Ticket d’accès libre-service : accorde aux administrateurs clients l’accès à l’assistant en libre-service et définit certains détails de la connexion d’entreprise qui en résulte. Les tickets d’accès permettent aux administrateurs clients de créer de nouvelles connexions ou de modifier des connexions existantes.

Les sections ci-dessous présentent les étapes détaillées pour configurer des profils libre-service et générer des tickets d’accès libre-service à partager avec les administrateurs clients.

​

Créer des profils libre-service

Vous pouvez créer des profils libre-service à l’aide d’Auth0 Dashboard ou de la Management API.

Les profils libre-service servent à définir les éléments clés des implémentations des clients, notamment :

• Les fournisseurs d’identité que les administrateurs des clients peuvent utiliser pour le SSO.
• Les attributs des utilisateurs qu’ils doivent recueillir au moyen du SSO, comme le courriel ou le nom de famille.
• Les options d’image de marque qui personnalisent l’apparence et l’expérience de l’assistant libre-service.

Vous pouvez créer jusqu’à 20 profils, selon les besoins, pour répondre à ceux de différents clients ou segments.

Auth0 Dashboard

Pour créer un profil libre-service dans Auth0 Dashboard : 

1. Accédez à Authentication > Enterprise et ouvrez la section Self-Service Enterprise Configuration. Sélectionnez ensuite Create Profile.

2. Dans l’espace prévu, saisissez un nom et, au besoin, une description pour le profil. Sélectionnez ensuite Create.
      A. Facultatif Joignez un User Attribute Profile.    

3. Dans l’onglet Settings, remplissez les sections ci-dessous. Sélectionnez ensuite Save.

   • Identity Providers (IdP) : Activez un ou plusieurs fournisseurs d’identité. Dans l’assistant libre-service, les administrateurs clients peuvent choisir leur option préférée dans la liste des fournisseurs activés.
   • Branding : Fournissez un logo et une couleur principale pour l’assistant libre-service.
   • Custom Introduction : Modifiez ou remplacez le message par défaut au besoin. Ce texte d’introduction s’affiche aux administrateurs clients sur la page d’accueil de l’assistant libre-service. Votre message peut inclure des options de mise en forme de base, comme le gras ou des hyperliens, et est limité à 2 000 caractères.

4. Dans l’onglet User Profile, ajoutez jusqu’à 20 attributs utilisateur que vos clients doivent recueillir au moyen du SSO, comme le courriel ou le nom de famille. Vous pouvez définir chaque attribut comme required ou optional.

   • Pendant le flux de l’assistant libre-service, les administrateurs clients seront invités à associer ces attributs utilisateur définis à leur fournisseur d’identité afin de s’assurer que les valeurs requises sont transmises à Auth0.

Management API

Pour créer un profil en libre-service, appelez d’abord le point de terminaison Self-Service Profiles pour créer le profil. Ensuite, utilisez un appel PUT pour modifier son texte d’introduction au besoin.

​

Créer un profil en libre-service :

1. Effectuez une requête POST vers le point de terminaison Self-Service Profiles.
2. Spécifiez les paramètres suivants dans le corps de la requête, si nécessaire :

Paramètre	Obligatoire ?	Description
name	Oui	Chaîne de caractères. Longueur maximale : 100. Un nom explicite pour le profil en libre-service.
description	Non	Chaîne de caractères. Longueur maximale : 140. Description du profil libre-service.
allowed_strategies	Non	Tableau. Un ou plusieurs fournisseurs d’identité que les administrateurs du client peuvent utiliser pour mettre en place le SSO. Si aucun paramètre n’est sélectionné, ils sont tous transmis par défaut. Les options comprennent : okta pour Okta Workforce Identity waad pour Entra ID google-apps pour Google Workspace keycloak-samlp pour Keycloak adfs pour Microsoft Active Directory Federation Services pingfederate pour PingFederate oidc pour OIDC générique samlp pour SAML générique
branding	Non	Objet. Utilisé pour personnaliser l’apparence de l’assistant en libre-service destiné aux administrateurs clients.
branding.logo_url	Non	Chaîne. Longueur maximale : 1024. URL HTTPS pointant vers une image de logo. Si elle est fournie, ce logo s’affiche dans le coin supérieur droit de l’assistant libre-service.
branding.colors	Non	Objet. Définit une couleur principale pour certains éléments de l’assistant en libre-service, comme les boutons interactifs.
branding.colors.primary	Oui, lors de la définition de branding.colors.	Chaîne. Indique la valeur hexadécimale de la couleur principale utilisée par l’assistant libre-service.
user_attributes	Non	Objet. Longueur maximale : 20. Stocke les informations de mappage présentées aux administrateurs clients pendant le flux de l’assistant libre-service. Les administrateurs clients doivent associer ces attributs à leur fournisseur d’identité afin de s’assurer que les attributs spécifiés sont transmis à Auth0.
user_attributes[].name	Oui, lors de la définition de user_attributes.	Chaîne de caractères. Longueur maximale de 255. Nom de l’attribut de l’utilisateur dans Auth0.
user_attributes[].description	Oui, lors de la définition des attributs utilisateur.	Chaîne. La longueur maximale est de 255. Description de l’attribut utilisateur en langage clair.
user_attributes[].is_optional	Oui, lors de la définition des attributs utilisateur.	Booléen. Indique si un attribut est facultatif ou obligatoire pour le client afin que l’application fonctionne. Pour définir un attribut comme obligatoire, utilisez true. Pour les attributs facultatifs, utilisez false.
user_attribute_profile_id	Non.	ID du profil d’attributs de l’utilisateur à associer aux comptes en libre-service.

Exemple de corps de requête

{
  "name": "Example Profile",
  "description": "An example profile for all customers",
  "allowed_strategies": ["okta","adfs","google-apps"],
  "user_attributes": [
    {
      "name": "email",
      "description": "User's email",
      "is_optional": false,
    }
  ],
  "branding": {
     "logo_url": "https://example.com/logo.png",
     "colors": {
       "primary": "#334455"
     }
  }
}

​

Personnaliser votre texte d’introduction

Lorsqu’un administrateur client accède à l’assistant en libre-service, il arrive d’abord sur une page d’introduction qui lui souhaite la bienvenue. Par défaut, le message suivant est fourni :

“Vous êtes à quelques étapes simples de la configuration du SSO. Ce processus de configuration nécessite d’apporter des modifications à votre fournisseur d’identité. Avant de commencer, ouvrez votre fournisseur d’identité dans un onglet ou une fenêtre de navigateur séparé.”

Vous pouvez modifier ce texte en effectuant un appel PUT vers le point de terminaison Custom Text for Self-Service Profiles.

Sachez que cet appel remplace tout le contenu de messagerie actuellement défini pour le profil libre-service. Assurez-vous que votre appel comprend l’intégralité du texte que vous souhaitez afficher à vos administrateurs clients.

1. Effectuez un appel à PUT /api/v2/self-service-profiles/{id}/custom-text/{language}/{page}, où

   • id correspond à l’id du profil libre-service
   • language est défini sur en
   • page est défini sur get-started

2. Dans le corps de la requête, précisez ce qui suit :

Propriété

Description

introduction

Chaîne. La longueur maximale est de 2 000. Texte d’introduction complet à afficher sur la page d’accueil de l’assistant libre-service. Le texte peut inclure des options de mise en forme de base, comme le texte en gras ou des hyperliens. Le texte personnalisé fourni par ce paramètre remplace entièrement tout message précédent. Pour de meilleurs résultats, veillez à fournir le message complet que vous souhaitez afficher aux administrateurs clients. L’envoi d’un corps vide \{} rétablit le texte par défaut pour tout message personnalisé.

3. L’entité créée est renvoyée dans la réponse.

Exemple d’appel

PUT /api/v2/self-service-profiles/ssp_1234567890/custom-text/en/get-started

{
  introduction: "Welcome! With <b>only a few steps</b>, you'll be able to setup your new connection. For assistance, contact <a href="https://www.examplesupportsite.com"> our support team </a>." 
}

Exemple de réponse

{
  introduction: "Welcome! With <b>only a few steps</b>, you'll be able to setup your new connection. For assistance, contact <a href="https://www.examplesupportsite.com"> our support team </a>." 
}

​

Gérer les tickets d’accès en libre-service

Après avoir créé au moins un profil en libre-service, vous pouvez générer des tickets d’accès en libre-service à l’aide de l’Auth0 Dashboard ou de la Management API.

Les tickets d’accès en libre-service ont deux objectifs principaux :

• Accorder aux administrateurs du client l’accès à l’assistant en libre-service, où ils peuvent configurer une nouvelle connexion SSO ou modifier une connexion existante.
• Prédéfinir des détails et comportements clés des nouvelles connexions SSO que vos administrateurs clients configureront, par exemple les applications ou les organisations qui seront activées pour la nouvelle connexion.

Lors de la génération des tickets d’accès, vous pouvez aussi activer certaines fonctionnalités, comme le SAML SSO initié par l’IdP, configurer les domaines du fournisseur d’identité (qui pilotent la détection du domaine d’origine) et la vérification du domaine.

​

SSO SAML initié par l’IdP

Le SSO SAML initié par l’IdP est un mode d’implémentation qui permet aux fournisseurs d’identité d’initier le SSO et de rediriger les utilisateurs vers le fournisseur de services afin qu’ils s’authentifient.

Lorsque vous activez cette option pour la configuration d’entreprise en libre-service, vous devez fournir votre application par défaut et votre protocole de réponse. Vous pouvez aussi fournir une chaîne de requête facultative pour personnaliser davantage le comportement de la connexion.

Pour en savoir plus sur ces options, consultez Configurer l’authentification unique SAML initiée par le fournisseur d’identité.

​

Vérification du domaine de courriel et domaines prévérifiés

La configuration d’entreprise en libre-service prend en charge trois façons d’associer des domaines de courriel à une connexion d’entreprise. Ces méthodes alimentent le même champ : options.domain_aliases , qui sert à Home Realm Discovery (HRD) et, selon le cas, aux domaines d’organisation pour la découverte :

1. Domaines prévérifiés (gérés par le locataire) : l’administrateur du locataire ajoute directement les domaines connus à la connexion.
2. Domaines à vérifier : l’administrateur du locataire précise les domaines que l’administrateur TI doit vérifier lors de la configuration. Ces domaines sont affichés comme en attente dans l’organisation et/ou ne sont pas automatiquement associés à la connexion tant que l’administrateur TI n’a pas terminé la vérification.
3. Vérification du domaine de courriel (autogérée) : l’administrateur de votre client vérifie le domaine lors de la configuration dans l’assistant libre-service.

Ces mécanismes d’association de domaines de courriel s’appliquent aux domaines de courriel utilisés pour le routage HRD et SSO. Ils ne sont pas liés à la vérification d’un domaine personnalisé au niveau du locataire.

Pour qu’un domaine soit renseigné à la fois dans les domaines d’organisation pour la découverte et dans HRD, le ticket doit :

• Inclure un seul enabled_organization
• Avoir soit des domaines prévérifiés, soit l’option Vérification du courriel définie à Required ou Optional
• Activer la case à cocher Autoriser l’utilisation des domaines pour la découverte de l’organisation

Domaine prévérifié

Utilisez un domaine prévérifié pour associer des domaines de courriel à une connexion d’entreprise à l’échelle du locataire. Les domaines ajoutés sont considérés comme fiables et sont inscrits directement dans options.domain_aliases.

Vous pouvez fournir des domaines lors de la génération de tickets d’accès en libre-service, soit dans Auth0 Dashboard, soit au moyen de la Management API.

• Auth0 Dashboard : Sur la page Generate Ticket, indiquez votre liste de domaines dans le champ Pre-verified Domains.
• Management API : Définissez connection_config.options.domain_aliases avec la liste des domaines. Par défaut, use_for_organization_discovery est défini à true. Au besoin, sélectionnez Allow the Use of Domains for Organization Discovery.

Les domaines ajoutés par les administrateurs du locataire sont considérés comme fiables et n’exigent pas que l’administrateur du client effectue la vérification. Si vous voulez que les administrateurs TI vérifient un domaine au lieu de le considérer comme fiable, définissez domain_aliases_config.domain_verification à required ou optional afin de demander une vérification dans l’assistant en libre-service. L’option Allow Use of Domains for Organization Discovery exige exactement un enabled_organization dans le ticket.

Domaines à vérifier

Utilisez les domaines à vérifier pour indiquer les domaines que les administrateurs TI doivent vérifier pendant la configuration. Contrairement aux domaines prévérifiés, les domaines en attente ne sont pas automatiquement associés à la connexion ou à l’Organisation. Les administrateurs TI doivent terminer la vérification dans l’assistant de configuration avant qu’ils ne prennent effet.

Vous pouvez fournir des domaines lorsque vous générez des tickets d’accès en libre-service, soit dans l’Auth0 Dashboard, soit au moyen de la Management API :

• Auth0 Dashboard : Sur la page Generate Ticket, indiquez votre liste de domaines dans le champ Domains to be Verified.
• Management API : Définissez connection_config.options.domain_aliases avec la liste des domaines. Par défaut, use_for_organization_discovery est défini sur true. Au besoin, sélectionnez l’option Allow the Use of Domains for Organization Discovery

Les limites suivantes s’appliquent :

• Si une Organisation est associée au ticket, le total combiné des domaines d’Organisation existants et en attente ne doit pas dépasser 100.
• Si aucune Organisation ou plus d’une Organisation n’est associée au ticket, le total combiné des alias de domaine existants et en attente ne doit pas dépasser 1 000.

Si l’ajout des domaines en attente dépasse l’une ou l’autre de ces limites, la création du ticket échoue et renvoie une erreur.

Vérification du domaine de courriel

Contrairement aux domaines prévérifiés, la vérification du domaine de courriel confirme qu’un administrateur TI est bien propriétaire du domaine qu’il fournit lors de la configuration en libre-service. Une fois la vérification terminée, le domaine vérifié est ajouté au même tableau options.domain_aliases de la connexion.

Vous pouvez activer la vérification pour les administrateurs TI lorsque vous générez des tickets d’accès en libre-service :

• Auth0 Dashboard : Dans la page Generate Ticket, utilisez le champ Domain Verification Requirement. Au besoin, sélectionnez aussi Allow the Use of Domains for Organization Discovery.
• Management API : Utilisez domain_aliases_config.domain_verification et, au besoin, use_for_organization_discovery avec l’une des options suivantes :
  • none (par défaut) : L’assistant en libre-service ne demande pas à l’administrateur client de vérifier son domaine.
  • required : L’assistant en libre-service demande à l’administrateur client de vérifier ses domaines.
  • optional : L’assistant en libre-service demande à l’administrateur client de vérifier son domaine. L’administrateur client peut soit saisir son domaine pour le faire vérifier, soit passer cette étape.

L’option Allow Use of Domains for Organization Discovery exige exactement une Organisation dans le champ Enabled Organizations et que la vérification du domaine soit définie sur Optional, Required ou Pre-Verified Domain(s). Dans certains cas, la vérification peut prendre jusqu’à 48 heures, et vous devrez peut-être émettre un ticket d’accès de suivi pour permettre à l’administrateur client de revenir et d’activer la connexion. Les tickets d’accès expirent cinq heures après leur première ouverture. Consultez Generate access tickets for existing connections.

Supprimer un domaine

Les administrateurs TI peuvent supprimer des domaines vérifiés dans l’assistant libre-service. Les règles suivantes s’appliquent selon l’option Exigence de vérification du domaine définie sur le billet :

Facultatif : tous les domaines vérifiés peuvent être supprimés. Obligatoire : au moins un domaine vérifié doit être conservé. Un avertissement s’affiche si l’administrateur TI tente de supprimer le dernier domaine vérifié.

​

Générer des tickets d’accès pour les nouvelles connexions

Vous pouvez générer des tickets d’accès pour les nouvelles connexions à partir de l’Auth0 Dashboard ou de la Management API.

Par défaut, les URL des tickets d’accès demeurent valides pendant cinq jours après leur génération. Après avoir accédé à l’URL du ticket, l’administrateur du client dispose de cinq heures pour terminer la configuration. Une URL de ticket d’accès peut être consultée au maximum 10 fois; une fois cette limite atteinte, un nouveau ticket d’accès doit être demandé.

Au besoin, vous pouvez révoquer un ticket d’accès avant son expiration pour mettre immédiatement fin à l’accès à l’assistant en libre-service.

Auth0 Dashboard

Pour générer un ticket d’accès pour une nouvelle connexion dans l’Auth0 Dashboard :

1. Accédez à Authentication > Enterprise et ouvrez la section Self-Service Enterprise Configuration. Sélectionnez ensuite le profil libre-service avec lequel vous souhaitez créer un ticket d’accès.

2. Sélectionnez Generate Ticket pour ouvrir le formulaire du ticket. Sous Select ticket type, choisissez Create a new connection.

3. Sous Ticket configuration, saisissez le nom requis pour la connexion que l’administrateur de votre client configurera.

4. Dans la section Settings, configurez au besoin des options supplémentaires pour la nouvelle connexion :

   • Domain : Sélectionnez le domaine personnalisé à utiliser dans l’URL du ticket. Disponible uniquement lorsque plusieurs domaines personnalisés existent.
   • Display Name : Nom convivial de la connexion qui s’affiche dans les écrans de Universal Login.
   • Enabled Clients : Liste d’ID client séparés par des virgules à associer à la connexion.
   • Enabled Organizations : Liste d’ID d’organisation séparés par des virgules à associer à la connexion.
   • Display connection a as button : Affiche la connexion comme option d’authentification sur l’écran de connexion.
   • Display connection as a button for organizations : Affiche la connexion comme option d’authentification sur l’écran de connexion pour les organisations spécifiées.
   • Assign membership on login for organizations : Accorde automatiquement l’appartenance à l’organisation aux utilisateurs qui s’authentifient avec la connexion.
   • Enable as a domain level connection : Permet aux applications tierces d’utiliser la connexion; nécessite Dynamic Client Registration.
   • Accept SAML IdP-initiated SSO : Active le SSO SAML initié par le fournisseur d’identité.

5. Sous Domain-Based Discovery, fournissez au besoin une liste de domaines IdP déjà vérifiés ou à vérifier, séparés par des virgules, à comparer aux domaines de courriel des utilisateurs. Ces domaines sont stockés dans options.domain_aliases et servent au HRD. Pour en savoir plus, consultez Home Realm Discovery.

6. Sous Domain Verification Requirement, choisissez le niveau de vérification souhaité :

   • Off : Les administrateurs clients ne sont pas invités à vérifier leur domaine lors de la configuration du SSO. Off est le paramètre par défaut pour les nouveaux tickets d’accès.
   • Optional : Les administrateurs clients sont invités à vérifier leur domaine lors de la configuration du SSO. Toutefois, ils peuvent ignorer cette étape et activer leur connexion sans terminer la vérification.
   • Required : Les administrateurs clients doivent vérifier leur domaine lors de la configuration du SSO. Ils ne pourront pas activer leur connexion tant que la vérification ne sera pas terminée.

7. Sous Provisioning, activez au besoin Sync user profiles using provisioning. Lorsqu’elle est activée, une configuration supplémentaire est disponible :

   • Bearer Token Expiration : Définissez une date d’expiration pour le jeton Bearer SCIM. Par défaut, les jetons Bearer n’expirent pas.
   • Bearer Token Permissions (Scopes) : Choisissez les actions que le jeton peut effectuer. Par défaut, tous les scopes de provisionnement sont activés :
     • get:users
     • post:users
     • put:users
     • patch:users
     • delete:users

8. Sous Time to Live, définissez une période d’expiration pour le ticket d’accès en secondes. Par défaut, la durée de vie est définie à 432000 secondes (ce qui équivaut à cinq jours).

   • La durée de vie détermine combien de temps une URL de ticket d’accès demeure active avant qu’un administrateur client lance l’assistant libre-service. Elle ne détermine pas combien de temps l’administrateur client a accès à l’assistant après son lancement. L’assistant libre-service expire après 5 heures, et cette valeur ne peut pas être configurée.

9. Sous Metadata, ajoutez jusqu’à 10 entrées de métadonnées associées à la connexion.

10. Vérifiez l’exactitude de la configuration de votre ticket d’accès. Sélectionnez ensuite Create Ticket.

Une fenêtre contextuelle Ticket Information contenant l’URL du ticket d’accès s’affiche alors. Copiez et enregistrez cette URL dans un endroit sûr, car vous ne pourrez plus la récupérer après avoir fermé la fenêtre contextuelle.

Vous pouvez partager l’URL du ticket d’accès avec l’administrateur de votre client par courriel, clavardage ou un autre canal de communication afin de lui donner accès à l’assistant libre-service. L’assistant le guidera ensuite dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Self-service assistant experience.

Management API

Pour générer un ticket d’accès via la Management API.

1. Récupérez l’ID du profil libre-service que vous souhaitez associer au ticket d’accès à l’aide du point de terminaison Retrieve Self-Service Profiles.
2. Appelez le point de terminaison Ticket d’accès SSO à l’aide de l’ID du profil libre-service correspondant :

POST  /api/v2/self-service-profiles/{id}/sso-ticket

Utilisez l’en-tête auth0-custom-domain pour définir le domaine personnalisé à utiliser dans l’URL du ticket. Cette option n’est disponible que lorsque la fonctionnalité de domaines personnalisés multiples est activée.

Dans le corps de la requête, spécifiez les paramètres décrits dans le tableau ci-dessous.

Paramètre	Description
connection_config	Objet. Obligatoire lors de la génération d’un ticket d’accès pour une nouvelle connexion SSO. Les administrateurs du client pourront modifier des éléments clés de la connexion, comme le certificat SAML, l’ID OIDC ou le secret OIDC.
connection_config.name	Obligatoire. Chaîne. Nom de la connexion créée à l’aide de l’assistant de configuration SSO. Longueur maximale : 128.
connection_config.display_name	Facultatif. String. Nom d’affichage de la nouvelle connexion créée à l’aide de l’assistant en libre-service. Ce nom s’affiche dans les invites d’Universal Login. Longueur maximale : 128.
connection_config.is_domain_connection	Facultatif. Booléen. Définissez-la à true si la connexion est au niveau du domaine; nécessite l’enregistrement dynamique des applications.
connection_config.show_as_button	Facultatif. Booléen. Lorsque true, la connexion s’affiche comme option d’authentification sur l’écran de connexion de votre application.
connection_config.metadata	Facultatif. Object[]. Métadonnées associées à la nouvelle connexion. L’objet peut contenir jusqu’à 10 paires clé-valeur. Les valeurs de type chaîne sont limitées à 255 caractères.
connection_config.options	Facultatif. Objet[]. Options pour la nouvelle connexion, notamment : icon_url domain_aliases[] idpinitiated
connection_config.options.icon_url	Facultatif. Chaîne de caractères. URL de l’icône à utiliser si connection_config.show_as_button est activé. L’URL doit utiliser HTTPS.
connection_config.options.domain_aliases	Facultatif. String[]. Domaines à utiliser pour la découverte du domaine d’origine. Les domaines saisis dans domain_aliases sont automatiquement marqués comme vérifiés. Si vous voulez qu’un administrateur client vérifie lui-même un domaine, ne spécifiez pas cet attribut et utilisez plutôt domain_aliases_config (décrit plus loin dans ce tableau). Cette option vous permet d’inviter l’administrateur client à vérifier son domaine au moyen de l’assistant libre-service.
connection_config.options.idpinitiated	Facultatif. Objet. Permet le SSO initié par l’IdP SAML et inclut les attributs suivants : enabled client_id client_protocol client_authorizequery Pour plus de détails, consultez le point de terminaison SSO Access Ticket dans l’explorateur de la Management API.
domain_aliases_config	Facultatif. Objet. Contient les propriétés domain_verification et pending_domains servant à configurer le comportement de la vérification du domaine.
domain_aliases_config.domain_verification	Facultatif. Chaîne de caractères. Détermine si la vérification du domaine est requise, facultative ou désactivée. Les options sont les suivantes : none : Désactive la vérification du domaine. Vous pouvez également désactiver la vérification du domaine en omettant l’objet domain_aliases_config dans votre requête. optional : Permet aux administrateurs du client d’ignorer la vérification du domaine lors de la configuration. required : Exige que les administrateurs du client vérifient leur domaine lors de la configuration.
domain_aliases_config.pending_domains	Facultatif. String[]. Domaines devant être vérifiés par l’administrateur TI pendant la configuration. Contrairement aux domaines prévérifiés, ces domaines sont indiqués comme en attente pour l’organisation et ne sont pas automatiquement associés à la connexion — l’administrateur TI doit terminer la vérification dans l’assistant en libre-service avant qu’ils prennent effet. domain_aliases_config.domain_verification doit être défini sur optional ou required pour utiliser ce paramètre. Les quotas suivants s’appliquent : Si une organisation est associée au ticket, le total combiné des domaines d’organisation existants et en attente ne doit pas dépasser 100. Si aucune organisation ou plus d’une organisation n’est associée au ticket, le total combiné des alias de domaine existants et en attente ne doit pas dépasser 1 000.
enabled_organizations	Facultatif. Object[]. Liste des organisations à associer à la nouvelle connexion.
enabled_organizations[].organization_id	Obligatoire lors de l’utilisation de enabled_organizations. Chaîne de caractères. ID d’une organisation précise à associer à la nouvelle connexion. Vous pouvez récupérer les ID dans la section Organisations de l’Auth0 Dashboard, au point de terminaison Get Organizations ou au point de terminaison Get Organization by Name.
enabled_organizations[].assign_membership_on_login	Facultatif. Booléen. Lorsque la valeur est true, les utilisateurs qui se connectent avec la nouvelle connexion deviennent automatiquement membres de l’organisation spécifiée.
enabled_organizations[].show_as_button	Facultatif. Booléen. Lorsque true, la nouvelle connexion s’affiche comme option d’authentification sur l’écran de connexion de l’organisation pour votre application.
provisioning_config	Facultatif. Objet. Détermine si l’administrateur du client peut configurer SCIM. Si la connexion est créée sans tous les scopes d’approvisionnement requis — get:users,post:users,put:users, patch:users,delete:users — SCIM ne sera pas activé. Utilisez google_workspace pour configurer Google Workspace Directory Sync.
ttl_sec	Facultatif. Nombre. Nombre de secondes pendant lesquelles l’URL d’un ticket d’accès reste active avant qu’un administrateur du client lance l’assistant libre-service. S’il n’est pas précisé ou s’il est défini sur 0, la valeur par défaut est 432000 (maximum de 5 jours). Notez que cette période d’expiration ne détermine pas pendant combien de temps un administrateur du client a accès au libre-service après son lancement. L’assistant lui-même expire au bout de 5 heures, et cette durée ne peut pas être configurée.
use_for_organization_discovery	Facultatif. Booléen. Indique si un domaine vérifié doit être utilisé pour la détection de l’organisation pendant l’authentification.

Exemple de corps de requête

{
   "connection_config":{
      "name":"string",
      "display_name":"string",
      "is_domain_connection":true,
      "show_as_button":true,
      "metadata":{
         "key1":"value1",
         "key2":"value2"
      },
      "options":{
         "icon_url":"string",
         "domain_aliases":[
            "acme.corp",
            "okta.com"
         ],
         "idpinitiated": { 
            "enabled": true, 
            "client_id": "string", 
            "client_protocol": "string", 
            "client_authorizequery": "string" 
        }
      }
   },
   "enabled_organizations":[
      {
         "organization_id":"string",
         "assign_membership_on_login":true,
         "show_as_button":true
      }
   ],
   "ttl_sec":0,
   "domain_aliases_config": {
       "domain_verification": "string"
       "pending_domains": [
              "acme2.com"
       ]
    }
}

En réponse, vous recevez une URL vers le ticket d’accès en libre-service :

{
  "ticket": "https://{domain}/self-service/connections-flow?ticket={id}"
}

Une fois que vous avez reçu l’URL du ticket, partagez le lien avec l’administrateur de votre client pour lui donner accès à l’assistant en libre-service. L’assistant le guidera ensuite dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Expérience de l’assistant en libre-service.

Vous pouvez intégrer la génération de tickets d’accès dans votre propre portail libre-service ou envoyer les URL des tickets directement aux administrateurs clients par courriel, clavardage ou tout autre canal de communication.

​

Générer des tickets d’accès pour des connexions existantes

Vous pouvez générer des tickets d’accès pour des connexions existantes dans l’Auth0 Dashboard ou au moyen de la Management API.

Par défaut, les URL des tickets d’accès demeurent valides pendant cinq jours après leur génération. Après avoir accédé à l’URL du ticket, l’administrateur du client dispose de cinq heures pour terminer sa configuration. Une URL de ticket d’accès peut être utilisée au maximum 10 fois; une fois cette limite atteinte, un nouveau ticket d’accès doit être demandé.

Au besoin, vous pouvez révoquer un ticket d’accès avant son expiration afin de mettre immédiatement fin à l’accès à l’assistant en libre-service.

Si un administrateur du client amorce la vérification du domaine au moyen de l’assistant en libre-service, il pourrait avoir besoin d’un ticket d’accès supplémentaire pour terminer le processus de configuration.

La vérification du domaine constitue la dernière étape de l’assistant en libre-service. À ce stade du flux de travail, la connexion a été créée, mais n’est pas activée. Si la vérification du domaine est requise, l’administrateur du client ne peut pas activer sa connexion tant que la vérification n’est pas terminée.

Bien que la vérification s’effectue généralement rapidement, elle peut prendre de 24 à 48 heures dans certains cas. Si cela se produit, l’administrateur du client ne pourra pas utiliser son ticket d’accès initial pour activer sa connexion, puisque les tickets expirent cinq heures après leur première utilisation.

Pour terminer ce processus, vous pouvez générer un ticket d’accès qui permet à l’administrateur du client de modifier la connexion qu’il a configurée avec son ticket initial. Lors de la création de ce ticket, veillez à préciser l’ID de la connexion qu’il a configurée avec son premier ticket d’accès.

Auth0 Dashboard

Pour modifier un ticket d’accès dans Auth0 Dashboard :

1. Accédez à Authentication > Enterprise, puis ouvrez la section Self-Service Enterprise Configuration. Sélectionnez ensuite le profil libre-service à partir duquel vous voulez créer un ticket d’accès.

2. Sélectionnez Generate Ticket pour ouvrir le formulaire du ticket. Sous Select ticket type, choisissez Edit an existing connection.

3. Sous Ticket configuration, indiquez l’ID de la connexion existante que l’administrateur client doit pouvoir modifier.

4. Sélectionnez Next.

5. Sous Enabled features, choisissez les flux auxquels l’administrateur TI peut accéder. Toutes les options sont activées par défaut.

   • Edit SSO connection : Permet à l’administrateur TI de modifier la connexion SSO. Désactivez cette option pour lui donner accès uniquement au provisionnement ou à la configuration du domaine, sans lui permettre de modifier la connexion.
   • Provisioning : Permet à l’administrateur TI de configurer le provisionnement.
   • Domain configuration : Permet à l’administrateur TI de vérifier ou de gérer les domaines.

6. Sous Domain Verification, choisissez le niveau de vérification souhaité :

   • Off : Les administrateurs clients ne sont pas invités à vérifier leur domaine lors de la configuration du SSO. Cette option est sélectionnée par défaut pour les nouveaux tickets d’accès.
   • Optional : Les administrateurs clients sont invités à vérifier leur domaine lors de la configuration du SSO. Toutefois, ils peuvent ignorer cette étape et activer leur connexion sans terminer la vérification.
   • Required : Les administrateurs clients doivent vérifier leur domaine lors de la configuration du SSO. Ils ne pourront pas activer leur connexion tant que la vérification ne sera pas terminée.

7. Sous Provisioning, activez au besoin Sync user profiles using provisioning. Lorsqu’elle est activée, des options de configuration supplémentaires sont offertes :

   • Bearer Token Expiration : Définissez une date d’expiration pour le jeton Bearer SCIM. Par défaut, les jetons Bearer n’expirent pas.
   • Bearer Token Permissions (Scopes) : Choisissez les actions que le jeton peut effectuer. Par défaut, tous les scopes de provisionnement sont activés :
     • get:users
     • post:users
     • put:users
     • patch:users
     • delete:users

8. Sous Time to Live, définissez une période d’expiration pour le ticket d’accès, en secondes. Par défaut, la durée de vie est réglée à 432000 secondes (ce qui équivaut à cinq jours).

   A. La durée de vie détermine pendant combien de temps l’URL d’un ticket d’accès est active avant qu’un administrateur client lance l’assistant libre-service. Elle ne détermine pas pendant combien de temps l’administrateur client a accès à l’assistant après son lancement. La durée de validité de l’assistant libre-service lui-même est de cinq heures et ne peut pas être configurée.

9. Vérifiez l’exactitude de la configuration de votre ticket d’accès. Sélectionnez ensuite Create Ticket.

Une fenêtre contextuelle Ticket Information contenant l’URL du ticket d’accès s’affiche ensuite. Copiez et enregistrez cette URL dans un endroit sûr, car vous ne pourrez plus la récupérer après la fermeture de la fenêtre contextuelle.

Vous pouvez partager l’URL du ticket d’accès avec votre administrateur client par courriel, par clavardage ou par un autre canal de communication afin de lui donner accès à l’assistant libre-service. L’assistant le guidera ensuite dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Self-service assistant experience.

Management API

Pour générer un ticket d’accès via la Management API, suivez les étapes ci-dessous.

Vous ne pouvez pas mettre à jour les détails de connection_config d’une connexion existante à l’aide du point de terminaison SSO Access Ticket. Si vous devez modifier ces renseignements pour une connexion existante, utilisez plutôt le point de terminaison Update a Connection.

1. Récupérez l’ID du profil libre-service que vous souhaitez associer au ticket d’accès à l’aide du point de terminaison Retrieve Self-Service Profiles.

2. Appelez le point de terminaison SSO Access Ticket à l’aide de l’id du profil en libre-service approprié :

   POST /api/v2/self-service-profiles/{id}/sso-ticket

   Dans le corps de la requête, indiquez les paramètres suivants :

Paramètre	Description
connection_id	Obligatoire. String. ID de la connexion qu’un administrateur client peut mettre à jour à l’aide de l’assistant libre-service. Les administrateurs clients peuvent modifier des éléments clés de la connexion, comme le certificat SAML ou l’ID et le secret OIDC. Les ID de connexion peuvent être obtenus dans la section Authentication de l’Auth0 Dashboard ou à l’aide du point de terminaison Get All Connections.**
domain_aliases_config.pending_domains	Facultatif. String[]. Domaines à faire vérifier par l’administrateur TI lors de la configuration. Ces domaines sont indiqués comme étant en attente pour l’organisation et ne sont pas automatiquement associés à la connexion — l’administrateur TI doit terminer la vérification dans l’assistant libre-service avant qu’ils ne prennent effet. domain_aliases_config.domain_verification doit être défini sur optional ou required pour utiliser ce paramètre. Les quotas suivants s’appliquent : Si une organisation est associée au ticket, le nombre total combiné de domaines d’organisation existants et en attente ne doit pas dépasser 100. Si aucune organisation ou plus d’une organisation est associée au ticket, le nombre total combiné d’alias de domaine existants et en attente ne doit pas dépasser 1 000.
enabled_features	Facultatif. Objet. Détermine les flux auxquels l’administrateur TI peut accéder. Pris en charge uniquement pour les tickets de type edit-connection. S’il est omis, les fonctionnalités actives sont déterminées en fonction de la présence d’autres propriétés de configuration dans la requête (le comportement actuel est conservé). S’il est inclus, l’objet doit contenir au moins une propriété; toute propriété non explicitement définie prend la valeur par défaut false, et l’objet ne peut pas être nul ni vide. Si enabled_features.provisioning est true, provisioning_config est requis dans le corps de la requête.
enabled_features.sso	Facultatif. Booléen. Lorsque true, l’administrateur TI peut modifier la connexion SSO. Définissez cette valeur sur false pour autoriser l’accès uniquement aux flux de provisionnement ou de vérification du domaine, sans pouvoir modifier la connexion.
enabled_features.provisioning	Facultatif. Booléen. Lorsque true, l’administrateur TI peut configurer le provisionnement. Nécessite provisioning_config dans le corps de la requête.
enabled_features.domain_verification	Facultatif. Booléen. Lorsque la valeur est true, l’administrateur informatique peut vérifier ou gérer les domaines.
provisioning_config	Facultatif. Objet. Détermine si l’administrateur du client peut configurer SCIM. Si la connexion est créée sans tous les scopes de provisionnement, get:users,post:users,put:users, patch:users,delete:users, SCIM ne sera pas activé. Utilisez google_workspace pour configurer Google Workspace Directory Sync.
ttl_sec	Facultatif. Nombre. Nombre de secondes pendant lesquelles l’URL d’un ticket d’accès reste active avant qu’un administrateur client lance l’assistant libre-service. Si aucune valeur n’est précisée ou si elle est définie sur 0, la valeur par défaut est 432000 (ce qui équivaut à 5 jours). Veuillez noter que cette période d’expiration ne détermine pas pendant combien de temps un administrateur client a accès à l’assistant libre-service une fois celui-ci lancé. L’assistant lui-même expire au bout de cinq heures, et ce délai ne peut pas être configuré.
domain_aliases_config	Facultatif. Objet. Contient domain_verification, qui sert à déterminer si la vérification du domaine est requise, facultative ou désactivée. Les options de domain_verification sont les suivantes : none : Désactive la vérification du domaine. Vous pouvez également désactiver la vérification du domaine en omettant l’objet domain_aliases_config de votre requête. optional : Permet aux administrateurs client d’ignorer la vérification du domaine pendant la configuration. required : Exige que les administrateurs client vérifient leur domaine pendant la configuration.
use_for_organization_discovery	Facultatif. Booléen. Indique si un domaine vérifié doit être utilisé pour la détection de l’organisation lors de l’authentification.

Exemple de corps de requête

{
  "connection_id": "string",
   "ttl_sec":0,
   "domain_aliases_config": {
       "domain_verification": "string"
       "pending_domains": [
             "acme.com"
          ]
    }
}

En réponse, vous recevez une URL vers le ticket d’accès en libre-service :

{
  "ticket": "https://{domain}/self-service/connections-flow?ticket={id}"
}

Une fois que vous avez reçu l’URL du ticket, partagez le lien avec votre administrateur client pour lui accorder l’accès à l’assistant en libre-service. L’assistant les guidera ensuite dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Expérience de l’assistant en libre-service.

Vous pouvez intégrer la génération de tickets d’accès dans votre propre portail libre-service ou envoyer les URL des tickets directement aux administrateurs clients par courriel, clavardage ou tout autre canal de communication.

​

Révoquer un ticket d’accès

Par défaut, l’URL d’un ticket d’accès reste valide pendant cinq jours. Après avoir accédé à l’URL, l’administrateur du client dispose de cinq heures pour terminer la configuration.

Au besoin, vous pouvez révoquer un ticket d’accès avant son expiration. Par exemple, si un ticket d’accès est partagé avec la mauvaise audience, vous pouvez révoquer le ticket pour empêcher tout accès non autorisé à l’assistant en libre-service.

Lorsque vous révoquez un ticket d’accès, son URL devient immédiatement invalide et toutes les sessions associées prennent fin. Les administrateurs du client qui disposent de l’URL ne pourront plus accéder à l’assistant en libre-service. Vous pourrez ensuite générer et partager de nouveaux tickets d’accès au besoin.

Pour révoquer un ticket d’accès :

1. Récupérez l’ID du profil en libre-service associé au ticket d’accès à l’aide du point de terminaison Récupérer les profils en libre-service.
2. Repérez l’ID du ticket d’accès que vous souhaitez révoquer. Les ID se trouvent à la fin de l’URL du ticket d’accès.
3. Appelez le point de terminaison Révoquer le ticket d’accès SSO en utilisant les ID appropriés :

POST  /api/v2/self-service-profiles/{id}/sso-ticket/{id}/revoke

En réponse, un 202 Accepted est renvoyé.

​

Références

​

API

Pour gérer la configuration d’entreprise en libre-service, les points de terminaison Management API suivants sont disponibles :

• Obtenir les profils en libre-service
• Créer un profil en libre-service
• Obtenir un profil en libre-service par identifiant
• Supprimer un profil en libre-service par identifiant
• Mettre à jour un profil en libre-service
• Obtenir le texte personnalisé d’un profil en libre-service
• Définir le texte personnalisé d’un profil en libre-service
• Créer un ticket d’accès pour lancer le flux de configuration d’entreprise en libre-service
• Révoquer un ticket d’accès pour le libre-service

​

Limites de débit

Lorsque vous utilisez Self-Service Enterprise Configuration, les limites de débit suivantes s’appliquent :

Description	Point de terminaison	Limites
Gérer les profils SSO	/api/v2/self-service-profiles	Consultez les limites de débit de la Management API pour votre type d’abonnement.
Créer un ticket d’accès	/api/v2/self-service-profiles/{id}/sso-ticket	Consultez les limites de débit de la Management API pour votre type d’abonnement.
Utiliser un ticket d’accès	/self-service/connection-flows?ticket={id}	6 / min / IP
Charger l’application web (y compris l’assistant de configuration) et les points de terminaison de l’application web	/self-service/*	50 / min / IP 90 / min / locataire