SSO et provisionnement

L'authentification unique (SSO) permet aux membres de se connecter à Bird via votre fournisseur d'identité au lieu d'utiliser un mot de passe Bird distinct. Bird prend en charge les connexions SAML 2.0 et OpenID Connect (OIDC).

La mise en place est une tâche de propriétaire (Owner) d'organisation, et les contrôles se trouvent sur la page Single sign-on de votre organisation. Un membre disposant de la permission SSO peut gérer les connexions sans être Owner.

La connexion personnelle via Google ou GitHub est distincte du SSO d'organisation. Voir Connexion, mot de passe et MFA.

Fonctionnement du SSO

Une connexion SSO couvre un ou plusieurs domaines e-mail vérifiés, par exemple yourcompany.com. Les membres de ces domaines s'authentifient auprès de votre fournisseur d'identité. Leurs permissions Bird dépendent toujours de leurs rôles d'organisation et d'espace de travail.

Ce que la configuration implique

Un Owner d'organisation et un administrateur du fournisseur d'identité réalisent la configuration :

1. Prouvez que le domaine vous appartient. Bird vous fournit un enregistrement DNS à publier pour chaque domaine e-mail couvert par la connexion. L'application ne peut pas être activée tant que le domaine n'est pas vérifié.
2. Configurez la connexion. Pour SAML, fournissez les métadonnées du fournisseur d'identité, ou l'URL de connexion et les certificats de signature. Pour OIDC, fournissez l'émetteur (issuer) et les identifiants client. Copiez les informations de fournisseur de service ou de redirection de Bird dans votre fournisseur d'identité.
3. Testez la connexion. Effectuez une connexion de test avant d'activer la connexion. Quel que soit le protocole choisi, un brouillon dont le test réussit est activé pour vous, à condition que votre organisation dispose d'un domaine vérifié et n'ait pas atteint sa limite de connexions actives.
4. Choisissez si le SSO est obligatoire. Lorsque le SSO est facultatif, les membres peuvent utiliser le SSO ou une autre méthode de connexion disponible. Lorsqu'il est obligatoire, les membres doivent passer par le SSO pour accéder à l'organisation. Rendre le SSO obligatoire nécessite une connexion active et au moins un domaine vérifié.

L'obligation de SSO prend effet immédiatement, à chaque requête, et pas seulement à la prochaine connexion. Un membre dont la session en cours n'a pas été établie via votre fournisseur d'identité perd l'accès à l'organisation jusqu'à ce qu'il se reconnecte via celui-ci. Planifiez donc le changement en fonction de la journée de votre équipe plutôt que de l'annoncer après coup. Les Owners d'organisation font exception : un Owner conserve l'accès avec son mot de passe Bird, ce qui empêche une connexion mal configurée de bloquer tout le monde.

Configurez votre fournisseur d'identité

L'étape 2 est la partie qui varie selon le fournisseur : une même valeur porte un nom différent dans chacun, et chacun possède un paramètre qui refuse toutes les connexions s'il est incorrect. Les noms de champs propres à Bird sont ceux de la page de connexion, sous Register these with your identity provider.

• Configurer le SSO avec Okta
• Configurer le SSO avec Google Workspace
• Configurer le SSO avec Microsoft Entra ID

Pour tout autre fournisseur SAML 2.0 ou OpenID Connect, les quatre étapes ci-dessus constituent l'intégralité du processus.

Configurer SAML sans valeurs temporaires

L'Entity ID et l'Assertion Consumer Service URL d'une connexion SAML sont dérivés de la connexion elle-même et n'existent donc pas tant que vous ne l'avez pas créée. Cela crée un cercle : votre fournisseur d'identité a besoin de ces valeurs, et elles ont besoin de la connexion.

Créez d'abord la connexion. Dans Add connection, choisissez SAML puis I have not set up my provider yet. La connexion est créée comme brouillon sans détails de fournisseur d'identité, et son ouverture affiche les valeurs à enregistrer sous Register these with your identity provider. Configurez votre fournisseur avec celles-ci, puis revenez et utilisez Supply the details sur la même connexion, sous la forme dont vous disposez :

• une metadata URL, que nous récupérons et lisons
• le metadata document lui-même, pour un fournisseur qui distribue un fichier plutôt que de l'héberger
• l'entity ID, l'URL de connexion et les certificats de signature, saisis directement

Un document téléversé est lu pour en extraire ces trois valeurs, mais n'est pas conservé.

Tant que les détails ne sont pas fournis, la connexion reste un brouillon : elle ne traite aucune connexion et ne peut pas être activée.

Comment les membres sont identifiés

Une connexion SAML identifie chaque membre par le NameID envoyé par votre fournisseur, et cet identifiant est permanent pour toute personne qui se connecte. La configuration d'une connexion ne vous demande pas quel format utiliser. Si vous avez fourni une metadata URL ou un document, nous lisons ce que votre fournisseur y annonce et associons la connexion à ce format. Si vous avez saisi les détails manuellement, il n'y a pas de métadonnées à lire, et la connexion est associée à un identifiant permanent.

Ce que vous contrôlez, c'est la valeur sous-jacente. Définissez le nom d'utilisateur de l'application chez votre fournisseur sur quelque chose d'opaque et jamais réattribué, et envoyez l'adresse séparément en tant qu'attribut email. Une adresse e-mail comme identifiant est définitivement plus faible : si l'adresse est un jour réattribuée, la personne suivante qui la reçoit hérite du compte Bird.

Les métadonnées indiquent ce que votre fournisseur peut envoyer ; la configuration de l'application décide ce qu'il envoie réellement, et les deux peuvent différer. La connexion de test à l'étape 3 rapporte donc l'identifiant et le format que l'assertion a effectivement transportés, et ce rapport est le moyen de vérifier que les deux concordent avant que quiconque ne dépende de la connexion. Nous refusons également un identifiant étiqueté persistent qui est en réalité une adresse e-mail.

Si le test rapporte un format inattendu, vous avez deux façons de le corriger, et la bonne dépend de la cause :

• Le fournisseur envoie la mauvaise valeur. Modifiez le nom d'utilisateur de l'application chez votre fournisseur, puis testez à nouveau. C'est généralement la bonne correction, car l'identifiant opaque est celui qu'il faut conserver.
• La connexion est associée à la mauvaise valeur. Ouvrez Edit sur la connexion et changez le format du NameID pour celui que votre fournisseur envoie.

Effectuez l'une ou l'autre correction avant que les membres ne commencent à se connecter. Une fois qu'ils l'ont fait, leurs comptes sont liés à l'identifiant en vigueur, le format est donc figé et la modification est refusée. Créez plutôt une connexion pour le nouveau format.

Remplacer un fournisseur

Les détails du fournisseur d'identité d'une connexion SAML peuvent être remplacés tant que personne ne s'est connecté via celle-ci. Une fois que des membres l'ont utilisée, leurs comptes sont liés aux identifiants envoyés par votre fournisseur actuel, et le remplacement est donc refusé. Créez plutôt une connexion pour le nouveau fournisseur. Sur une connexion OIDC, vous pouvez faire tourner le secret client à tout moment, ce qui ne change pas l'identification des membres, mais le fournisseur lui-même ne peut pas être remplacé.

La connexion de test à l'étape 3 ne compte pas. Un test ne lie aucun compte et n'accorde aucun accès. Une connexion que vous avez configurée et testée mais pas encore mise à disposition de votre équipe peut donc encore être redirigée.

Ce qui change pour votre équipe

Une connexion peut accorder un accès par défaut à l'organisation et à l'espace de travail lors de la première connexion SSO réussie d'un membre. Configurez cet accès par défaut explicitement ; sinon, invitez les membres et attribuez les rôles avant qu'ils ne se connectent. Voir Utilisateurs, équipes et rôles.

Suspendre une connexion empêche les nouvelles connexions via celle-ci. Vérifiez séparément les appartenances Bird et les sessions actives lorsqu'une personne quitte votre entreprise.

Étapes suivantes

• Connexion, mot de passe et MFA : sécurité du compte individuel, y compris la connexion personnelle via Google/GitHub
• Utilisateurs, équipes et rôles : fonctionnement des rôles et des permissions une fois les membres intégrés
• Authentification et clés API : la référence d'authentification destinée aux développeurs