Single Sign-On (SSO) in Quire Permalink
Il Single Sign-On (SSO) è disponibile esclusivamente nel piano Enterprise. Per ulteriori informazioni visita la nostra pagina dei prezzi.
Il Single Sign-On (SSO) in Quire consente ai MEMBRI di autenticarsi tramite un Identity Provider (IdP) centralizzato usando SAML 2.0. I provider supportati includono Okta, OneLogin, Azure AD B2C e qualsiasi altro IdP compatibile con SAML 2.0.
Panoramica SSO
Il SSO consente agli utenti di accedere a Quire con un unico set di credenziali tramite il proprio Identity Provider, senza dover gestire una password Quire separata.
Con il SSO abilitato per la tua organizzazione Quire:
- I MEMBRI accedono tramite l’identity provider aziendale
- Non è richiesta una password Quire separata
- L’autenticazione è centralizzata e più sicura
- La gestione degli accessi è semplificata per gli amministratori IT
Quire supporta l’autenticazione SAML 2.0 e funziona con:
- Okta
- OneLogin
- Azure AD B2C
- Qualsiasi IdP che supporta SAML 2.0
Una volta abilitato il SSO, i MEMBRI dell’organizzazione accederanno tramite l’IdP anziché con una password Quire.
Configura l’Identity Provider (IdP)
Prima di abilitare il SSO in Quire, devi configurare il tuo Identity Provider.
Passaggio 1: Crea un’applicazione SAML 2.0
- Accedi alla console di amministrazione del tuo Identity Provider.
- Crea una nuova applicazione SAML 2.0.
- Inserisci i seguenti dettagli di configurazione SAML:
| Attributo SAML | Mappa nel tuo identity provider |
|---|---|
https://quire.io/sso/login |
URL Assertion Consumer Service (ACS) SAML dell’applicazione |
https://quire.io/sso/metadata |
ID Entità SP dell’applicazione |
| Indirizzo email del membro | Formato Name ID |
Passaggio 2: Raccogli i dettagli SAML necessari
Dopo aver creato l’applicazione, copia le seguenti informazioni:
- URL Identity Provider
- ID Entità
- Certificato X.509 in Base64
Passaggio 3: Assegna gli utenti nel tuo Identity Provider
- Aggiungi utenti o gruppi alla nuova applicazione SAML Quire appena creata.
- Assicurati che siano assegnati i Permessi di accesso appropriati.
Gli utenti devono essere assegnati nell’IdP prima di poter autenticarsi tramite SSO.
Configura il SSO in Quire
Passaggio 1: Apri le impostazioni dell’organizzazione
- Clicca sull’icona del menu a tendina accanto al nome della tua organizzazione.
- Seleziona Opzioni.

Passaggio 2: Abilita autenticazione SAML
- Vai alla scheda Sicurezza.
- Abilita l’autenticazione SAML.

Passaggio 3: Inserisci i dettagli di configurazione SAML
- Incolla l’URL Identity Provider.
- Inserisci l’ID Entità.
- Incolla il certificato X.509 in Base64.
- Clicca su Testa SSO per verificare la configurazione.
- Se la verifica ha esito positivo, clicca su Salva.

SSO Obbligatorio o Facoltativo
Puoi configurare il SSO come:
- Obbligatorio – Tutti i MEMBRI devono accedere tramite SSO.
- Facoltativo – I MEMBRI possono accedere con password o tramite SSO.
Nota: Gli amministratori dell’organizzazione devono sempre accedere con la propria password Quire.
Una volta configurato correttamente, i MEMBRI non avranno più bisogno di una password Quire separata.
Integrazione con Azure AD B2C
Passaggio 1: Configura Azure AD B2C
- Accedi al portale Azure.
- Crea criteri personalizzati.
- Registra un’applicazione SAML.
- Configura i flussi utente per l’autenticazione.
Segui la documentazione ufficiale di Microsoft per le istruzioni dettagliate sulla configurazione.
Passaggio 2: Configura il formato NameID
Quire richiede che il formato NameID sia:
userPrincipalNameoppureemail
Non usare objectId.
Se utilizzi userPrincipalName, modifica:
TrustFrameworkBase.xmlSignUpOrSigninSAML.xml
Esempio di 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>
Esempio di 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>
Se prevedi di cambiare il formato in email, puoi fare riferimento a questa risorsa per ulteriori indicazioni.
Passaggio 3: Recupera le informazioni necessarie da Azure
Al termine della configurazione, raccogli:
- URL dei metadati
- URL Identity Provider
- ID Entità
- Certificato X.509 in Base64
Di seguito alcuni esempi di come possono apparire queste informazioni:
- Metadati:
https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata - URL Identity Provider:
https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/sso/login - ID Entità: Lo hai definito in
TrustFrameworkExtensions.xml(<Item Key="IssuerUri">). Ad esempio,https://your-tenant.onmicrosoft.com/quire - Certificato X.509 in Base64: Estrailo dai metadati
<X509Certificate>MIIDizCCAnOgAwIBAgIUU9ndt…
Poi segui i passaggi in Configura il SSO in Quire.
Risoluzione dei problemi SSO
Se un membro cambia il proprio indirizzo email in Quire, non potrà accedere tramite SSO finché la nuova email non viene aggiornata nell’Identity Provider.
Per risolvere il problema:
- Aggiorna l’indirizzo email del membro nell’Identity Provider.
- Assicurati che il NameID corrisponda all’email aggiornata.
- Chiedi al membro di provare ad accedere nuovamente.
Leggi di più sul nostro blog riguardo al Single sign-on con Quire.
Domande frequenti
Quali identity provider supporta il SSO di Quire?
Qualsiasi IdP compatibile con SAML 2.0, tra cui Okta, OneLogin e Azure AD B2C. Il SSO è disponibile solo nel piano Enterprise.
Come si abilita il SSO in Quire?
Configura un’app SAML 2.0 nel tuo IdP usando l’ACS URL di Quire (https://quire.io/sso/login) e l’ID Entità (https://quire.io/sso/metadata), raccogli l’URL IdP, l’ID Entità e il certificato, quindi vai su Opzioni organizzazione > scheda Sicurezza, abilita l’autenticazione SAML, incolla i dettagli, clicca su Testa SSO e salva.
Posso rendere il SSO obbligatorio o facoltativo per la mia organizzazione Quire?
Sì. Obbligatorio impone a tutti i MEMBRI di accedere tramite l’IdP. Facoltativo consente ai MEMBRI di scegliere tra la propria password Quire e il SSO.
Gli amministratori dell’organizzazione devono usare il SSO in Quire?
No. Gli amministratori accedono sempre con la propria password Quire, anche quando il SSO è impostato su Obbligatorio per gli altri MEMBRI.
Cosa devo fare se un membro non riesce ad accedere tramite SSO dopo aver cambiato l’email?
Aggiorna l’email del membro nell’Identity Provider in modo che il NameID corrisponda al nuovo indirizzo. Il membro potrà quindi accedere nuovamente tramite SSO.
Quale formato NameID richiede Quire per il SSO con Azure AD B2C?
Usa userPrincipalName o email. Non usare objectId — causa errori di autenticazione.
I clienti possono accedere a Quire con account di social media come Facebook o LinkedIn?
Sì, tramite l’integrazione con Azure AD B2C. I provider supportati includono Facebook, X (ex Twitter), LinkedIn, account Microsoft e account di identità locali.