SSO avec SAML 2.0

User and Data Management Plus

Le Single Sign-on (SSO) avec SAML 2.0 permet à tes utilisateurs de se connecter à deskbird avec leur fournisseur d'identité (IdP) existant. Tu trouveras ci-dessous des options de démarrage rapide pour Okta et Keycloak, ainsi qu'un guide complet pour la configuration de la fédération (SSO initié par le SP).

1. SAML avec Okta
2. SAML avec Keycloak
3. Configuration de la fédération SAML 2.0
4. Renouvellement du certificat SAML
5. Quand utiliser SAML ou OAuth / OIDC

1. SAML avec Okta

Utilise notre guide dédié à Okta pour configurer une application SAML Okta, mapper les attributs requis et tester le Single Sign-on (SSO) initié par le SP vers deskbird. Le guide inclut des captures d'écran, des exemples d'attributs et des conseils de dépannage.
👉 Étape par étape : Configurer le SSO SAML avec Okta

2. SAML avec Keycloak

Tu préfères utiliser Keycloak ? Suis le guide Keycloak pour mettre en place le SSO vers deskbird.
👉 Étape par étape : Configurer le SSO SAML avec Keycloak

3. Configuration de la fédération SAML 2.0

SAML 2.0 (Security Assertion Markup Language) est un protocole basé sur XML qui permet d'échanger de façon sécurisée des données d'authentification et d'autorisation entre un fournisseur d'identité (IdP) et un fournisseur de service (SP). deskbird prend en charge le Single Sign-on (SSO) initié par le SP (l'authentification doit commencer depuis deskbird).

Si tu veux une tuile dans ton lanceur IAM (par exemple, OneLogin, JumpCloud) sur laquelle les utilisateurs peuvent cliquer, ajoute une application de type Favori qui lance le flux initié par le SP dans deskbird :
https://app.deskbird.com/saml?providerName={saml-provider-ID}
L'ID du fournisseur SAML suit le format saml.{company-name}. Exemple pour "Polaroid" : https://app.deskbird.com/saml?providerName=saml.polaroid.

Crée une application de fédération séparée et cachée dans ton IdP pour la connexion SAML elle-même (non visible par les utilisateurs).

3.1 Configuration générale

Configure ton IdP avec les informations suivantes pour le Service Provider deskbird :

💡 Pour que l'authentification SAML 2.0 fonctionne, définis NameID sur l'adresse e-mail de l'utilisateur avec le format urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.

Exemple d'extrait d'assertion

<saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="<IdP Entity ID>" SPNameQualifier="https://api.deskbird.app/saml/metadata" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> email </saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> </saml2:Subject> 

À envoyer à deskbird pour la configuration

Si tu as un fichier de métadonnées de ton IdP, tu peux simplement nous l'envoyer à la place.

3.2 Attributs utilisateur

Attribut obligatoire (utilise exactement ce nom) :

Attributs recommandés :

3.3 Synchronisation du nom depuis ton IdP

Si les utilisateurs sont créés lors de leur première connexion SAML (sans synchronisation SCIM ou HRIS), deskbird récupère leur prénom et nom depuis ton IdP et les garde synchronisés :

• Première connexion : l'utilisateur est créé avec le prénom et le nom de famille issus de l'assertion SAML.
• Connexions suivantes : si ton IdP envoie un nom différent, deskbird le met à jour. Cela remplace aussi les noms modifiés manuellement dans deskbird.
• Modification : tant que le nom vient de ton IdP, ni les utilisateurs ni les admins ne peuvent le modifier dans deskbird (web, iOS et Android). Les changements de nom doivent être faits dans ton IdP et apparaîtront à la prochaine connexion de l'utilisateur.
• Synchronisation SCIM ou HRIS : si tu utilises aussi l'une de ces synchronisations, c'est elle qui gère le nom, et SAML ne l'écrase jamais.
• Pas de nom envoyé : si l'assertion ne contient pas à la fois le prénom et le nom, les utilisateurs saisissent leur nom lors de la configuration et peuvent toujours le modifier.

💡 Seuls le prénom et le nom de famille sont synchronisés. Les autres attributs, comme le bureau ou le département, ne sont pas récupérés depuis SAML.

3.4 Fichier de métadonnées

Après avoir créé l'application SAML dans ton IdP, merci de nous envoyer le fichier de métadonnées qui inclut :

• Certificat
• Entity ID
• SSO URL

4. Renouvellement du certificat SAML

Les certificats SAML ont une date d'expiration (généralement 1 à 3 ans après leur création). Quand un certificat approche de sa date d'expiration, ton fournisseur d'identité t'en avertira. Il est important de renouveler le certificat avant son expiration pour éviter toute interruption de connexion.

Processus de renouvellement étape par étape (Microsoft Entra ID) :

1. Dans le portail Microsoft Entra ID, va sur ton application d'entreprise deskbird.
2. Va dans Single sign-on > SAML Certificates.
3. Clique sur l'icône Modifier (crayon).
4. Clique sur Nouveau certificat.
5. Définis la date d'expiration (par défaut 3 ans).
6. Clique sur Enregistrer. Le nouveau certificat apparaîtra avec le statut Inactif.
7. Télécharge le nouveau certificat (format Base64).
8. Envoie le certificat au support deskbird via un ticket. Indique le nom de ton entreprise et précise qu'il s'agit d'un renouvellement de certificat SAML.
9. Le support deskbird remplacera le certificat de notre côté et te confirmera quand ce sera prêt.
10. Une fois la confirmation reçue de deskbird, retourne dans Entra ID et active le nouveau certificat (mets-le sur Actif).

5. Quand utiliser SAML ou OAuth / OIDC

Si tu hésites entre SAML et OAuth (Microsoft SSO), prends en compte les éléments suivants :