SSO e SCIM. Enterprise identity, zero friction.
Accesso SAML / OIDC contro qualsiasi IdP principale. La sincronizzazione della directory SCIM effettua il provisioning e il deprovisioning degli utenti automaticamente. I segreti webhook ruotano senza perdere lo stato.
- SAML / OIDC against 20+ identity providers
- SCIM directory sync — provision and deprovision automatically
- Webhook secret rotation without downtime
- Full audit trail for compliance
SCIM directory sync
Provision and deprovision in under 60 seconds
Connect your IdP directory once. Every hire, transfer, and departure propagates to Elido automatically — no IT ticket, no manual invite, no forgotten offboarding gap.
- Auto-provisioningSCIM CREATE from Okta or Entra → Elido account in under 60s
- Group-to-role mappingIdP groups map to Elido roles; changes propagate on next sync
- Instant deprovisioningSCIM DELETE or active: false → sessions revoked immediately
- API key suspensionAll user API keys suspended on offboarding — no access-after-departure gap
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika SaloMember
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika Salodeprovisioned
Identity providers
Works with every major IdP
Elido uses WorkOS as the SSO and SCIM broker — 20+ connections out of the box, plus Generic SAML for any SP-initiated flow. Configure the Elido application in your IdP once; Elido generates the SAML metadata XML or OIDC credentials.
Any SAML 2.0-compliant IdP works via Generic SAML. See the setup guide →
- User provisioned via SCIMokta-scim-svc10.0.1.409:12:04
- SSO login — Oktaana@corp.com91.223.4.1709:14:31
- SSO login — Azure ADben@corp.com185.46.9.209:17:08
- Webhook secret rotatedadmin@corp.com77.123.11.510:05:22
- User deprovisioned via SCIMokta-scim-svc10.0.1.414:33:51
- Role changed: Member → Adminadmin@corp.com77.123.11.515:01:09
Audit trail
Immutable identity event log
Every SSO login, SCIM provision, role change, and secret rotation is logged append-only. No admin can delete entries. Export to CSV or stream to your SIEM via API.
- Timestamp, actor, action, target, and IdP connection per event
- 12-month retention on Business; longer available on request
- API export for SOC 2, ISO 27001, DORA, and NIS2 evidence
- Failed SSO attempts logged with reason code
- IP-based alerting for SSO probing threshold
- Secret rotations reference the overlap window in the log
What you can do
- Okta, Azure AD / Entra, Google Workspace
- Mappatura dominio email → connessione
- SCIM crea / aggiorna / elimina utente
- Verifica della firma webhook (HMAC-SHA256)
Cosa richiedono realmente l'Enterprise SSO e il provisioning SCIM in produzione
Il redirect SAML è solo il punto di partenza. I dettagli seguenti coprono la latenza di provisioning, la mappatura dei ruoli, la rotazione dei segreti e le modalità di guasto cruciali per i team di sicurezza.
Accesso SAML 2.0 e OIDC tramite WorkOS — routing del dominio email verso la corretta connessione IdP
Elido utilizza WorkOS come broker SSO, supportando oltre 20 connessioni IdP tra cui Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate e qualsiasi IdP conforme a SAML 2.0. Il tuo team IT configura l'applicazione Elido nel tuo IdP una sola volta; Elido genera un XML di metadati SAML o credenziali client OIDC per la procedura guidata dell'IdP. Il routing del dominio email associa i domini email degli utenti alla corretta connessione IdP: gli utenti con @tuasocieta.com vengono indirizzati automaticamente alla tua connessione Okta senza doverla selezionare. Più domini email possono essere mappati su una singola connessione (per aziende con entità fuse o più domini). Il provisioning JIT crea l'account Elido al primo accesso SSO se SCIM non è in uso; se SCIM è attivo, JIT è disabilitato e l'account deve essere fornito tramite SCIM prima del primo login.
Sincronizzazione directory SCIM 2.0: provisioning automatico, deprovisioning e mappatura gruppo-ruolo
SCIM 2.0 sincronizza la directory utenti del tuo identity provider con Elido. Quando un utente viene aggiunto al gruppo dell'applicazione Elido in Okta o Entra, Elido riceve un evento SCIM CREATE e crea l'account utente — nessun ticket IT, nessun invito manuale. Gli aggiornamenti del profilo utente (nome, email) si propagano automaticamente. Quando un utente viene rimosso dal gruppo o disattivato nell'IdP, Elido riceve un evento SCIM DELETE o PATCH (active: false) e revoca immediatamente l'accesso — le sessioni attive vengono invalidate, le chiavi API appartenenti all'utente vengono sospese. La mappatura gruppo-ruolo ti consente di mappare i tuoi gruppi IdP (es. 'Elido Admins', 'Elido Viewers') ai ruoli di Elido (Admin, Member, Viewer). Le assegnazioni dei ruoli si aggiornano automaticamente quando l'appartenenza al gruppo cambia nell'IdP. La latenza di provisioning dall'evento IdP alla creazione dell'account Elido è tipicamente inferiore a 60 secondi.
I segreti di firma dei webhook ruotano senza perdere eventi in corso — procedura di rotazione zero-downtime
Il ricevitore webhook SCIM di Elido e il sistema di webhook in uscita utilizzano firme HMAC-SHA256 per verificare l'autenticità degli eventi. I segreti scadono e necessitano di rotazione — sia su base programmata (raccomandata: 90 giorni) sia dopo una sospetta compromissione. La rotazione zero-downtime funziona così: genera un nuovo segreto nel dashboard (il vecchio segreto rimane valido per 15 minuti durante la finestra di sovrapposizione), distribuisci il nuovo segreto nei tuoi sistemi, verifica che un evento SCIM in arrivo sia verificato con il nuovo segreto, quindi attiva la scadenza immediata del vecchio segreto. La finestra di 15 minuti garantisce che gli eventi in corso firmati con il vecchio segreto vengano comunque elaborati durante la finestra di distribuzione. La rotazione del segreto viene registrata nell'audit trail con timestamp, autore (l'admin che ha effettuato la rotazione) e conferma della scadenza della sovrapposizione.
Log completo degli eventi di identità: accessi SSO, eventi di provisioning, cambi di ruolo e rotazioni dei segreti
Ogni accesso SSO, provisioning/deprovisioning SCIM, modifica dell'assegnazione dei ruoli e rotazione dei segreti viene registrato nell'audit trail del workspace (Business). Ogni voce include: timestamp, autore (utente o servizio SCIM), tipo di azione, target (l'utente o la risorsa interessata), connessione IdP utilizzata e ID del workspace. L'audit trail è di tipo append-only e immutabile — nessun amministratore può eliminare le voci. Esporta in CSV o interroga tramite API per l'ingestione nel SIEM. Se il tuo framework di compliance richiede prove degli eventi di controllo degli accessi (SOC 2 Type II, ISO 27001, DORA, NIS2), l'audit trail è l'artefatto necessario. La conservazione è di 12 mesi nel piano Business; periodi di conservazione più lunghi sono disponibili su richiesta per i settori regolamentati.
Scadenza forzata della sessione tramite SCIM — accesso revocato in meno di 60 secondi alla disattivazione su IdP
Quando SCIM segnala che un utente è disattivato (offboarding del dipendente, fine contratto del collaboratore), Elido invalida immediatamente tutte le sessioni attive di quell'utente e sospende le sue chiavi API. Questo non dipende dal TTL del cookie di sessione — Elido memorizza un flag di revoca per ID utente e lo controlla ad ogni richiesta autenticata. Il tempo dalla disattivazione nell'IdP alla revoca dell'accesso in Elido è la latenza di consegna dell'evento SCIM: tipicamente sotto i 30 secondi per Okta, sotto i 60 secondi per Azure Entra. Per l'offboarding ad alta sicurezza (es. un admin che lascia l'azienda), un amministratore del workspace Elido può anche revocare manualmente le sessioni di uno specifico utente dal dashboard prima che arrivi l'evento SCIM. Sia le sessioni revocate manualmente che quelle attivate da SCIM appaiono nell'audit trail.
Team di sicurezza Enterprise che utilizzano Elido SSO & SCIM
I nomi sono segnaposto — i casi studio reali dei clienti appariranno qui non appena pubblicati.
“L'offboarding SCIM era il requisito principale del nostro team di sicurezza fin dal primo giorno. Quando un dipendente viene disattivato in Entra, l'accesso a Elido sparisce in meno di un minuto — nessun ticket di deprovisioning manuale, nessun gap da 'dimenticanza'. Abbiamo controllato i log dopo tre mesi e non abbiamo trovato alcun evento di accesso post-offboarding.”
“Abbiamo cinque domini email aziendali derivanti da due acquisizioni. Il routing dominio-email → IdP in Elido gestisce tutti e cinque puntandoli alla stessa connessione Okta. Gli utenti di qualsiasi dominio atterrano sul corretto flusso SSO senza dover scegliere da una lista.”
“La rotazione dei segreti senza downtime è stato il dettaglio che ci ha convinto. Ruotiamo i segreti dei webhook trimestralmente per policy; la finestra di sovrapposizione di 15 minuti ci permette di ruotare durante l'orario lavorativo senza rischi di incidenti. Ogni rotazione è loggata, verificata e referenziata nel nostro pacchetto di prove SOC 2.”
Elido SSO & SCIM vs Bitly vs Rebrandly
L'SSO è disponibile sul piano enterprise di Bitly e sul piano Business di Rebrandly. Il provisioning SCIM è più limitato su entrambi. Il confronto copre ciò che ciascuno offre effettivamente.
| Feature | Elido | Bitly Enterprise | Rebrandly Business |
|---|---|---|---|
| SAML 2.0 SSO | Sì — broker WorkOS, 20+ connessioni IdP | Sì — piano enterprise | Sì — piano Business |
| OIDC SSO | Sì — insieme a SAML tramite WorkOS | Solo SAML | Solo SAML |
| Provisioning SCIM 2.0 | Completo (create / update / delete) + mappatura gruppo-ruolo | Limitato — solo creazione utente, no gruppo-ruolo | Non disponibile |
| Auto-deprovisioning all'offboarding | Sì — SCIM DELETE, sessione revocata sotto 60s | Solo manuale | Solo manuale |
| Routing IdP per dominio email | Sì — più domini per connessione | Singolo dominio per connessione | Non documentato |
| Audit trail per eventi di identità | Sì — immutabile, 12 mesi, esportazione API | Audit log limitato | Audit log limitato |
| Rotazione segreto webhook (zero downtime) | Sì — finestra di sovrapposizione di 15 minuti | Non applicabile | Non applicabile |
Domande su SSO & SCIM
Quali identity provider sono supportati?
Elido utilizza WorkOS come broker SSO e SCIM, che supporta Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud e qualsiasi IdP conforme a SAML 2.0. Sono supportate anche le connessioni OIDC per provider come Google Workspace e Azure. Se il tuo IdP non è nella lista standard di WorkOS, il tipo di connessione 'Generic SAML' di WorkOS funziona con qualsiasi flusso SP-initiated SAML 2.0. Contattaci se hai bisogno di una connessione IdP specifica non elencata.
Cos'è il provisioning JIT rispetto al provisioning SCIM?
Il provisioning JIT (Just-in-Time) crea un account utente in Elido al loro primo accesso SSO — non è richiesto alcun pre-provisioning. È più semplice da configurare ma non offre controllo su chi può accedere (chiunque abbia un'asserzione SSO valida ottiene un account). Il provisioning SCIM dà il controllo al tuo IdP: solo gli utenti nel gruppo fornito possono accedere e gli account vengono creati prima del primo login. Per ambienti enterprise dove l'accesso deve essere pre-approvato, SCIM è obbligatorio. Quando SCIM è attivo, il provisioning JIT è disabilitato.
Come funzionano le mappature gruppo-ruolo SCIM?
Nelle impostazioni SSO del workspace, mappi i tuoi gruppi IdP ai ruoli di Elido: es. 'Gruppo Okta: Elido Admins' → 'Ruolo Elido: Admin', 'Gruppo Okta: Elido Members' → 'Ruolo Elido: Member'. Il ruolo di un utente in Elido segue l'appartenenza al gruppo del suo IdP — se viene spostato dal gruppo Admins al gruppo Members in Okta, il suo ruolo in Elido viene declassato al successivo sync SCIM (tipicamente sotto i 60 secondi). Un utente presente in più gruppi assume il ruolo con i privilegi più elevati tra le mappature corrispondenti.
L'SSO può essere obbligatorio per tutti gli utenti o è opzionale?
L'SSO può essere impostato come forzato (tutti gli utenti devono accedere tramite SSO — l'accesso con password è disabilitato) o opzionale (gli utenti possono scegliere tra SSO o email+password). Nel piano Business, la forzatura si configura nelle impostazioni SSO del workspace. Una volta forzato, gli utenti che non hanno un'identità SSO attiva vengono esclusi — assicurati che il provisioning SCIM o JIT abbia creato gli account prima di abilitare la forzatura. Gli account Admin possono essere esentati dalla forzatura SSO come meccanismo di emergenza; questo è configurabile.
Cosa succede alle chiavi API quando un utente viene rimosso tramite SCIM?
Quando SCIM disattiva un utente, Elido sospende tutte le chiavi API che sono state create da quell'utente. Le chiavi sospese restituiscono HTTP 401 all'autenticazione. Le chiavi non vengono eliminate — rimangono visibili agli admin del workspace per scopi di audit, con l'etichetta di stato 'suspended — offboarded user'. Se un account di servizio utilizzava una chiave API personale (non una chiave di servizio del workspace), la sospensione della chiave interromperà l'integrazione — questo è intenzionale. Per le integrazioni in produzione, utilizza le chiavi di servizio a livello di workspace invece delle chiavi API dell'utente.
L'SSO è disponibile su Pro o solo su Business?
SSO e SCIM sono funzionalità esclusive del piano Business. I workspace Pro utilizzano l'autenticazione integrata di Elido (email + password tramite Ory Kratos, Google/GitHub OAuth opzionale). Se l'SSO è un requisito indispensabile per l'approvazione del tuo ufficio acquisti, il piano Business è il punto di partenza. Contatta l'ufficio vendite per una prova di Business se hai bisogno di valutare l'SSO prima di impegnarti.
Come gestisco l'SSO per un workspace che ha più brand o sub-organizzazioni?
Ogni workspace Elido ha la propria configurazione SSO — se gestisci più workspace (es. per brand o business unit), ognuno ottiene la propria connessione IdP e il proprio provisioning SCIM separatamente. Gli utenti possono essere membri di più workspace con ruoli diversi in ciascuno; la loro identità IdP è la stessa, ma le mappature gruppo-ruolo vengono valutate per ogni workspace. Un gruppo Okta condiviso può essere mappato come Admin in un workspace e Member in un altro.
Esiste un audit trail per i tentativi di accesso SSO falliti?
Sì. I tentativi di accesso SSO falliti (asserzione SAML non valida, sessione scaduta, account SCIM mancante quando JIT è disabilitato) vengono registrati nell'audit trail del workspace con il relativo codice di errore. Questo è utile per diagnosticare perché uno specifico utente non riesce ad accedere e per rilevare tentativi di brute-force sull'SSO. I tentativi falliti da indirizzi IP che superano una soglia attivano un avviso del workspace (configurabile nelle impostazioni di sicurezza del workspace).
Keep reading
SSO del portale white-label — i tuoi clienti accedono alla tua dashboard brandizzata tramite il loro IdP.
Webhook in uscita firmati con HMAC — lo stesso pattern di rotazione dei segreti si applica alle firme dei webhook in uscita.
Chiavi di servizio del workspace per integrazioni API di produzione — limitate al workspace, non ai singoli utenti.
SOC 2, ISO 27001, residenza dei dati in UE e edge dedicato — lo stack completo delle funzionalità enterprise.
Pronto a provarlo?
Inizia con il piano gratuito, effettua l'upgrade quando hai bisogno di un dominio personalizzato.