L’authentification unique (SSO) dans Quire Permalink

✦
Traduit par IA
· Voir en anglais

L’authentification unique (SSO) est disponible uniquement avec le plan Enterprise. Plus d’informations sur notre page de tarifs.

L’authentification unique (SSO) dans Quire permet aux membres de s’authentifier via un fournisseur d’identité (IdP) centralisé utilisant SAML 2.0. Les fournisseurs pris en charge incluent Okta, OneLogin, Azure AD B2C et tout autre IdP compatible SAML 2.0.

Vue d’ensemble du SSO

Le SSO permet aux utilisateurs de se connecter à Quire avec un seul jeu d’identifiants via leur fournisseur d’identité, sans avoir à gérer un mot de passe Quire distinct.

Avec le SSO activé pour votre organisation Quire :

  • Les membres se connectent via le fournisseur d’identité de leur entreprise
  • Aucun mot de passe Quire distinct n’est requis
  • L’authentification est centralisée et plus sécurisée
  • La gestion des connexions est simplifiée pour les administrateurs informatiques


Quire prend en charge l’authentification SAML 2.0 et fonctionne avec :

  • Okta
  • OneLogin
  • Azure AD B2C
  • Tout IdP prenant en charge SAML 2.0


Une fois le SSO activé, les membres de l’organisation se connecteront via l’IdP au lieu d’utiliser un mot de passe Quire.

Configurer le fournisseur d’identité (IdP)

Avant d’activer le SSO dans Quire, vous devez d’abord configurer votre fournisseur d’identité.

Étape 1 : Créer une application SAML 2.0

  1. Connectez-vous à la console d’administration de votre fournisseur d’identité.
  2. Créez une nouvelle application SAML 2.0.
  3. Saisissez les informations de configuration SAML suivantes :
Attribut SAML Correspondance dans votre fournisseur d’identité
https://quire.io/sso/login URL du service consommateur d’assertion SAML (ACS) de l’application
https://quire.io/sso/metadata ID d’entité SP de l’application
Adresse e-mail du membre Format Name ID

Étape 2 : Collecter les informations SAML requises

Après avoir créé l’application, copiez les informations suivantes :

  • URL du fournisseur d’identité
  • ID d’entité
  • Certificat X.509 en Base64

Étape 3 : Affecter des utilisateurs dans votre fournisseur d’identité

  1. Ajoutez des utilisateurs ou des groupes à l’application SAML Quire nouvellement créée.
  2. Assurez-vous que les autorisations d’accès appropriées sont attribuées.


Les utilisateurs doivent être affectés dans l’IdP avant de pouvoir s’authentifier via le SSO.

Configurer le SSO dans Quire

Étape 1 : Ouvrir les paramètres de l’organisation

  1. Cliquez sur l’icône du menu déroulant à côté du nom de votre organisation.
  2. Sélectionnez Options.

paramètres de l'organisation

Étape 2 : Activer l’authentification via SAML

  1. Accédez à l’onglet Sécurité.
  2. Activez l’authentification via SAML.

Activer l'authentification via SAML dans les paramètres de sécurité de l'organisation Quire

Étape 3 : Saisir les informations de configuration SAML

  1. Collez l’URL du fournisseur d’identité.
  2. Saisissez l’ID d’entité.
  3. Collez le certificat X.509 en Base64.
  4. Cliquez sur Tester le SSO pour vérifier la configuration.
  5. Si la vérification réussit, cliquez sur Enregistrer.

Configuration SAML

SSO obligatoire ou facultatif

Vous pouvez configurer le SSO comme suit :

  • Obligatoire – Tous les membres doivent se connecter via le SSO.
  • Facultatif – Les membres peuvent se connecter avec un mot de passe ou via le SSO.

Remarque : Les administrateurs de l’organisation doivent toujours se connecter avec leur mot de passe Quire.

Une fois la configuration effectuée avec succès, les membres n’auront plus besoin d’un mot de passe Quire distinct.

Intégration Azure AD B2C

Étape 1 : Configurer Azure AD B2C

  1. Connectez-vous au portail Azure.
  2. Créez des stratégies personnalisées.
  3. Enregistrez une application SAML.
  4. Configurez les flux utilisateur pour l’authentification.


Suivez la documentation officielle de Microsoft pour obtenir des instructions de configuration détaillées.

Étape 2 : Configurer le format NameID

Quire requiert que le format NameID soit :

  • userPrincipalName ou
  • email


N’utilisez pas objectId.

Si vous utilisez userPrincipalName, modifiez :

  • TrustFrameworkBase.xml
  • SignUpOrSigninSAML.xml


Exemple pour TrustFrameworkBase.xml :

<!-- The following technical profile is used to read data after user authenticates. -->
<TechnicalProfile Id="AAD-UserReadUsingObjectId">
  <Metadata>
    <Item Key="Operation">Read</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
  </Metadata>
  <IncludeInSso>false</IncludeInSso>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="objectId" Required="true" />
  </InputClaims>
  <OutputClaims>

    <!-- Optional claims -->
    <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="otherMails" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surname" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> <!-- add -->
  </OutputClaims>
  <IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>


Exemple pour SignUpOrSigninSAML.xml :

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
      <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="userPrincipalName"/> <!-- add -->
    </OutputClaims>
    <SubjectNamingInfo ClaimType="userPrincipalName" ExcludeAsClaim="true"/> <!-- modify -->
  </TechnicalProfile>
</RelyingParty>


Si vous souhaitez utiliser le format email, vous pouvez consulter cette ressource pour des conseils supplémentaires.

Étape 3 : Récupérer les informations requises depuis Azure

Après la configuration, collectez :

  • URL des métadonnées
  • URL du fournisseur d’identité
  • ID d’entité
  • Certificat X.509 en Base64


Voici des exemples de ce à quoi ces informations peuvent ressembler :

  • Métadonnées : https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata
  • URL du fournisseur d’identité : https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/sso/login
  • ID d’entité : défini dans TrustFrameworkExtensions.xml (<Item Key="IssuerUri">). Par exemple, https://your-tenant.onmicrosoft.com/quire
  • Certificat X.509 en Base64 : à extraire des métadonnées <X509Certificate> MIIDizCCAnOgAwIBAgIUU9ndt…


Suivez ensuite les étapes de Configurer le SSO dans Quire.

Dépannage du SSO

Si un membre modifie son adresse e-mail dans Quire, il ne pourra plus se connecter via le SSO tant que le nouvel e-mail n’aura pas été mis à jour dans le fournisseur d’identité.

Pour résoudre ce problème :

  1. Mettez à jour l’adresse e-mail du membre dans le fournisseur d’identité.
  2. Assurez-vous que le NameID correspond au nouvel e-mail.
  3. Demandez au membre de réessayer de se connecter.

Pour en savoir plus, consultez notre article de blog sur l’authentification unique avec Quire.

Questions fréquentes

Quels fournisseurs d’identité sont pris en charge par le SSO de Quire ?

Tout IdP compatible SAML 2.0, notamment Okta, OneLogin et Azure AD B2C. Le SSO est disponible uniquement avec le plan Enterprise.

Comment activer le SSO dans Quire ?

Configurez une application SAML 2.0 dans votre IdP en utilisant l’URL ACS de Quire (https://quire.io/sso/login) et l’ID d’entité (https://quire.io/sso/metadata), récupérez l’URL IdP, l’ID d’entité et le certificat, puis accédez à Options de l’organisation > onglet Sécurité, activez l’authentification via SAML, collez ces informations, cliquez sur Tester le SSO et enregistrez.

Puis-je rendre le SSO obligatoire ou facultatif pour mon organisation Quire ?

Oui. Obligatoire force tous les membres à se connecter via l’IdP. Facultatif laisse les membres choisir entre leur mot de passe Quire ou le SSO.

Les administrateurs de l’organisation doivent-ils utiliser le SSO dans Quire ?

Non. Les administrateurs se connectent toujours avec leur mot de passe Quire, même lorsque le SSO est défini comme Obligatoire pour les autres membres.

Que faire si un membre ne peut pas se connecter via le SSO après avoir changé son adresse e-mail ?

Mettez à jour l’adresse e-mail du membre dans le fournisseur d’identité afin que le NameID corresponde à la nouvelle adresse. Le membre pourra alors se connecter via le SSO.

Quel format de NameID Quire requiert-il pour le SSO Azure AD B2C ?

Utilisez userPrincipalName ou email. N’utilisez pas objectId — cela provoque des échecs d’authentification.

Les clients peuvent-ils se connecter à Quire avec des comptes de réseaux sociaux comme Facebook ou LinkedIn ?

Oui, via l’intégration Azure AD B2C. Les fournisseurs pris en charge incluent Facebook, X (anciennement Twitter), LinkedIn, des comptes Microsoft et des comptes d’identité locaux.

Dernière mise à jour :

Veuillez nous contacter si vous avez besoin d'aide.