Gérer les fournisseurs d'identité

Configure un fournisseur d'identité (IdP) personnalisé pour activer l'authentification unique (SSO) pour ton organisation. Quand tu configures un IdP, Bob te redirige vers lui pour t'authentifier lorsque tu te connectes à IBM Bob depuis l'IDE, Bob Shell et Bob Web.

Tu peux configurer des fournisseurs d'identité SAML et OpenID Connect (OIDC) avec Bob. Utilise le protocole qui correspond à la plateforme d'identité de ton organisation.

IBM Bob est compatible avec les protocoles SSO suivants :

Bien que tu puisses utiliser d'autres fournisseurs OIDC qui répondent aux exigences de configuration et de token, les plateformes suivantes sont vérifiées :

L'ajout d'un IdP est un processus en deux étapes. Tu configures d'abord l'IdP et tu l'enregistres. Ensuite, tu ajoutes les domaines de messagerie qui l'utilisent.

SAML nécessite les détails de configuration suivants :

Champs identity provider — obtiens-les depuis ton IdP :

Champs service provider — utilise les fichiers générés à l'étape précédente :

Champs optionnels :

Dans la section Attribute mapping, associe les attributs utilisateur de l'IdP aux champs utilisateur d'IBM Bob. Le format de mapping est nom d'attribut Bob → nom d'attribut ou URI de l'IdP. Vérifie la configuration de ton IdP pour les noms d'attributs corrects.

Avant qu'un admin d'instance Bob puisse configurer un enregistrement IdP OIDC dans Bob, un administrateur IdP doit d'abord créer une application OIDC (client) dans le fournisseur d'identité. Les valeurs produites lors de cette étape sont celles que l'admin d'instance Bob saisit lors de l'ajout de l'IdP dans Bob.

Crée une application web (côté serveur / client confidentiel) dans ton fournisseur d'identité et active le type d'octroi Authorization Code. Bob utilise exclusivement le flux Authorization Code — ne sélectionne pas Implicit, Device Code ni Client Credentials.

Enregistre l'URL de callback suivante dans l'application OIDC. La plupart des fournisseurs effectuent une correspondance exacte de la chaîne, copie-la donc telle quelle :

Bob exige qu'un refresh_token soit présent dans chaque réponse d'échange de code d'autorisation. Si ton fournisseur émet des refresh tokens via un mécanisme différent (par exemple, un scope spécifique au fournisseur, ou de façon inconditionnelle à chaque échange de code), configure en conséquence — mais assure-toi que le client est autorisé à recevoir des refresh tokens. Si aucun refresh_token n'est renvoyé, la connexion est abandonnée.

Configure la méthode d'authentification au token endpoint de l'application OIDC sur client_secret_post. Bob envoie client_id et client_secret comme paramètres dans le corps du formulaire à chaque requête de token. client_secret_basic, private_key_jwt et none ne sont pas acceptés.

Une fois l'application cliente créée, transmets les valeurs suivantes à l'admin d'instance Bob :

Tu peux utiliser la découverte de fournisseur OIDC. Clique sur le bouton Retrieve configuration pour remplir automatiquement les champs d'endpoint depuis le document .well-known/openid-configuration de ton fournisseur, ou tu peux saisir chaque URL d'endpoint manuellement.

OIDC nécessite les détails de configuration suivants :

OIDC n'utilise pas Attribute mapping. Bob lit l'e-mail de l'utilisateur directement depuis le claim email dans le id_token.

Après avoir enregistré l'IdP, ajoute les domaines de messagerie qui doivent l'utiliser pour l'authentification.

IBM Bob exige que tu vérifies que ton organisation est propriétaire de chaque domaine avant que le SSO soit appliqué. La vérification s'effectue en ajoutant un enregistrement TXT DNS à ton domaine.

Le statut de vérification du domaine passe à Verified quand IBM Bob détecte correctement l'enregistrement TXT. Les modifications DNS peuvent prendre du temps à se propager.