Configurer le SSO avec Okta
Cette page couvre la partie Okta d'une connexion SSO. La partie Bird (vérifier un domaine, tester, activer et exiger le SSO) est identique pour tous les fournisseurs et se trouve sur SSO et provisionnement.
Okta et Bird ont chacun besoin de valeurs provenant de l'autre, donc le point de départ dépend du protocole. Gardez les deux ouverts pendant la configuration.
SAML
Commencez dans Bird pour SAML. L'Entity ID et l'Assertion Consumer Service URL d'une connexion SAML dérivent de la connexion elle-même : créez-la avec I have not set up my provider yet, enregistrez les valeurs affichées, puis revenez à Supply the details. Configurer SAML sans valeurs temporaires décrit ce flux.
Les noms de champs d'Okta ne correspondent pas à ceux de Bird. Deux d'entre eux sont assez proches pour être intervertis par erreur, et les intervertir envoie la réponse de connexion à une URL qui ne peut pas la traiter.
| Dans Bird, sous Register these with your identity provider | Dans Okta |
|---|---|
| Assertion Consumer Service URL | Single sign-on URL |
| Entity ID | Audience URI (SP Entity ID) |
| Sign-in URL for this connection | Pas un champ Okta. Communiquez-le aux membres comme marque-page |
Le champ Single sign-on URL d'Okta correspond à l'Assertion Consumer Service URL de Bird, et non à l'URL de connexion de Bird. Si vous collez l'URL de connexion à cet endroit, Okta envoie chaque réponse au mauvais point de terminaison et la connexion échoue.
Identifier les membres par leur adresse e-mail
Dans le champ Name ID format de l'application SAML, choisissez EmailAddress et définissez Application username sur la valeur sur laquelle vous voulez que Bird indexe chaque compte. Bird refuse Unspecified et refuse toute réponse dont le format NameID ne correspond pas au format attendu par la connexion.
Lisez Comment les membres sont identifiés avant de décider : l'identifiant est permanent pour toute personne qui se connecte via la connexion, donc un nom d'utilisateur applicatif opaque avec l'adresse envoyée séparément en tant qu'attribut email est le choix le plus sûr.
Validité de l'assertion
Okta signe les assertions valides de cinq minutes avant l'émission à cinq minutes après. Bird accepte cette fenêtre. Rien à configurer.
OIDC
Commencez dans Okta pour OIDC. Bird a besoin de l'émetteur, du client ID et du client secret pour créer une connexion OIDC : enregistrez donc l'application dans Okta en premier. Le Redirect URI de Bird est le même pour chaque connexion et s'affiche dans Add connection avant toute création, vous pouvez donc l'enregistrer d'emblée.
Créez une application web OIDC dans Okta et copiez son client ID et son secret dans Bird, avec l'émetteur d'Okta comme Issuer. Bird s'authentifie auprès du point de terminaison de jeton avec client_secret_basic.
Enregistrez le Redirect URI de Bird comme URI de redirection de connexion de l'application.
Tuile d'application Okta
Pour permettre aux membres de démarrer depuis leur tableau de bord Okta, définissez :
- Login initiated by : Either Okta or App
- Application visibility : la tuile affichée aux utilisateurs
- Login flow : Redirect to app to initiate login (OIDC Compliant)
- Initiate login URI : l'URI d'initiation de connexion de la connexion depuis Bird
Choisissez le flux conforme OIDC. Le flux Send ID Token directly to app (Okta Simplified) d'Okta envoie un jeton directement à Bird au lieu de rediriger, et Bird ne l'accepte pas.
Assigner l'application
Un membre qui n'est pas assigné à l'application Bird dans Okta est refusé par Okta, pas par Bird. Bird signale le refus comme provenant de votre fournisseur d'identité : vérifiez donc les assignations et toute politique d'accès conditionnel dans Okta avant de revérifier les paramètres de la connexion.
Effectuer la rotation du certificat de signature
Effectuez la rotation dans Okta d'abord, puis dans Bird. Bird vérifie les certificats que la connexion détient : une connexion Bird ne contenant que le nouveau certificat alors qu'Okta signe encore avec l'ancien refuse chaque connexion jusqu'à ce qu'Okta active le nouveau. Le refus est une erreur de signature et disparaît dès que les deux concordent.
Étapes suivantes
- SSO et provisionnement : vérifier un domaine, tester la connexion et exiger le SSO
- Configurer le SSO avec Google Workspace
- Configurer le SSO avec Microsoft Entra ID
Ressources associées
Poursuivez avec la documentation, les guides et les exemples sur ce sujet.