Panoramica di SSO
La nostra piattaforma SSO (WorkOS) aiuta le organizzazioni a gestire in modo efficace l'accesso degli utenti. Imponendo accessi controllati dal dominio tramite il provider di identità (IdP), le organizzazioni controllano chi può accedere a Perplexity dalla loro parte.
Come funziona il provisioning degli utenti
Predefinito: gli amministratori dell’organizzazione devono invitare gli utenti in Perplexity.
Just-in-time provisioning: Gli utenti vengono creati in Perplexity quando accedono per la prima volta tramite SSO/IdP, non quando vengono aggiunti nell'IdP. Le istruzioni per attivare il provisioning JIT sono disponibili qui.
Funzionalità tecniche opzionali:
Abilita l'accesso automatico per gli utenti con il dominio email della tua organizzazione.
Aggiungi automaticamente al tuo account Perplexity tutti gli utenti con il dominio email di proprietà.
SCIM (System for Cross-domain Identity Management): automatizza il provisioning e il deprovisioning degli utenti. Perplexity supporta SCIM per le organizzazioni con 50 o più utenti o se è presente almeno un utente Enterprise Max.
Come funziona il deprovisioning degli utenti
Gli utenti rimossi dall'IdP non vengono eliminati automaticamente da Perplexity.
Se l’SSO è obbligatorio, gli utenti deprovisionati non possono accedere, ma continuano a comparire in Perplexity finché un amministratore non li rimuove.
Raccomandazione: gli amministratori dovrebbero esaminare regolarmente e rimuovere manualmente gli utenti deprovisionati per mantenere accurati i registri.
Passaggi chiave per la risoluzione dei problemi
Risoluzione dei problemi generali
Se la tua organizzazione riscontra problemi con l'SSO, per prima cosa conferma che l'opzione Require SSO sia attiva. Quando questa opzione è attiva, gli accessi controllati dal dominio tramite il tuo IdP sono obbligatori per la tua organizzazione.
Puoi farlo accedendo alla schermata Identità nelle impostazioni della tua organizzazione e attivando l'opzione Richiedi SSO.
Se l’SSO è richiesto per la tua organizzazione, ma non viene visualizzato il flusso SSO, verifica che il dominio o il sottodominio utilizzato sia verificato (vedi sotto).
Puoi anche chiedere loro di aggiornare il browser (premendo ctrl+F5 su Windows o command+shift+R su Mac), nel caso in cui ciò sia causato da un problema di cache.
Problemi con la verifica del dominio
Tutti i domini e i sottodomini utilizzati dalla tua organizzazione per l'accesso SSO devono essere verificati in modo indipendente.
Se la verifica del dominio risulta "in sospeso" o "non riuscita", è probabile che il record TXT DNS non sia stato ancora aggiunto alla configurazione DNS del dominio.
Per verificare i tuoi domini:
Vai alla schermata Identità nelle impostazioni della tua organizzazione.
Fai clic su "Aggiungi" accanto alla sezione Dominio.
Inserisci il dominio della tua organizzazione (ad esempio, yourdomain.com).
Copia il record DNS TXT fornito.
Aggiungi questo record alla configurazione DNS del tuo dominio con il valore completo
"verification_token=string"incluso tra virgolette doppie. Imposta il TTL su 60 secondi.Attendi almeno un minuto, quindi utilizza
nslookup -q=text yourdomain.comper confermare che il nuovo record DNS TXT sia stato propagato su Internet.Clicca su "Verifica" una volta aggiunto il record DNS TXT.
Ripeti l'operazione per tutti i domini utilizzati dalla tua organizzazione.
Una volta verificato correttamente un dominio, puoi aumentare l’impostazione TTL a 12 o 24 ore (43200 o 86400 secondi).
Provisioning just-in-time
Se desideri attivare le funzionalità di accesso automatico o di acquisizione automatica, dovrai abilitare il provisioning just-in-time per la tua organizzazione.
Puoi farlo nella schermata Identity nelle impostazioni dell’organizzazione, impostando su «Abilitato» l’interruttore «Provisioning dell’account just-in-time»:
Se il JIT è attivo per la tua organizzazione, ma riscontri problemi con il provisioning just-in-time di un utente specifico, prova ad accedere con un nuovo utente.
Se questo funziona con un nuovo utente ma non con utenti specifici, è molto probabile che eventuali problemi di onboarding degli utenti in corso non siano dovuti a SSO o a una configurazione errata del provisioning da parte dell'organizzazione. Al contrario, i problemi potrebbero riguardare le assegnazioni dei singoli utenti, le autorizzazioni, le appartenenze ai gruppi nell'IdP o questioni specifiche di tali account.
Se non funziona, potrebbe esserci un problema con la configurazione SSO/JIT tra il tuo IdP e Perplexity. Le cause più comuni includono attributi configurati in modo errato, autorizzazioni mancanti o parametri SAML/OIDC errati.
Problemi di deprovisioning:
Se SCIM non è attivo per la tua organizzazione, quando un utente viene rimosso dall’Identity Provider (IdP), quell’utente perderà la possibilità di accedere a Perplexity se l’SSO è obbligatorio e l’IdP rifiuta l’accesso. Tuttavia, l'account e i dati dell'utente rimarranno nel sistema Perplexity fino a quando un amministratore non li cancellerà o rimuoverà manualmente. L’SSO standard controlla solo l’autenticazione al momento dell’accesso, non la gestione del ciclo di vita degli utenti né la loro eliminazione.
SCIM aggiunge la gestione automatizzata del ciclo di vita. Quando un utente viene deprovisionato dall'IdP, SCIM invia una richiesta a Perplexity per disabilitare o rimuovere automaticamente l'account utente. Ciò significa che le organizzazioni che utilizzano SCIM possono automatizzare sia la creazione che la rimozione degli utenti, riducendo al minimo il lavoro di pulizia manuale e migliorando la sicurezza.
SCIM è disponibile per le organizzazioni con 50 o più postazioni, o con almeno una postazione Enterprise Max.
Messaggi di errore comuni e correzioni
Messaggio di errore | Significato | Soluzione |
AADSTS50105 (Microsoft Entra ID) | L'utente non è un membro diretto di un gruppo autorizzato o non dispone dell'accesso diretto. | Contatta il tuo amministratore IT o Enterprise Pro per essere aggiunto direttamente o a un gruppo con accesso. Prova ad accedere di nuovo dopo la sincronizzazione. |
L'utente non è assegnato a questa applicazione (Okta) | L'account non è assegnato all'applicazione Perplexity in Okta. | Chiedi al tuo amministratore IT o Enterprise Pro di assegnare il tuo account all'app Perplexity Enterprise in Okta. |
Errore 408: App_not_enabled_for_user (Google SSO) | L'accesso all'app non è abilitato per il tuo account o gruppo in Google Admin Console. | L'amministratore deve abilitare l'accesso utente per te o il tuo gruppo nella console di amministrazione di Google Workspace in Apps > Web and mobile apps. Quindi riprova ad accedere. |
Migrazione del dominio
Quando un'organizzazione migra a un nuovo dominio, il Single Sign-On (SSO) potrebbe non funzionare più se gli account utente o le impostazioni del dominio non vengono aggiornati in Perplexity.
Per evitare errori di SSO durante la migrazione di un dominio, la prassi migliore consiste nell' aggiungere e verificare in modo proattivo il nuovo dominio all'interno di Perplexity prima di apportare modifiche al provider di identità o agli indirizzi email degli utenti.
È inoltre importante aggiornare la configurazione del provider di identità per includere il nuovo dominio e modificare di conseguenza le assegnazioni di gruppi o utenti, in modo che gli utenti conservino le autorizzazioni SSO necessarie dopo la migrazione.
Se hai migrato i domini prima di verificare quello nuovo e hai ancora accesso alla tua precedente email con diritti di amministratore, accedi con quell'email. In questo modo potrai verificare il nuovo dominio. Tuttavia, se non hai più accesso alla tua vecchia email, contattaci: possiamo disabilitare temporaneamente l'SSO, in modo che tu possa verificare il nuovo dominio.
Hai bisogno di ulteriore assistenza?
Se hai altri problemi o se questi passaggi non risolvono il problema che stai riscontrando, contattaci e i nostri tecnici dell’assistenza saranno lieti di aiutarti.


