SSO & SCIM. Identitate enterprise, fără friction.
Autentificare SAML / OIDC cu orice IdP major. Sincronizarea de director SCIM provizionează și deprovizionează utilizatori automat. Secretele webhook-urilor se rotesc fără a pierde starea.
- SAML / OIDC cu peste 20 de furnizori de identitate
- Sincronizare de director SCIM - provizionare și deprovizionare automată
- Rotația secretului webhook-ului fără downtime
- Jurnal de audit complet pentru conformitate
Sincronizare de director SCIM
Provizionare și deprovizionare în sub 60 de secunde
Conectează directorul IdP o singură dată. Fiecare angajare, transfer și plecare se propagă automat în Elido - fără tichet IT, fără invitație manuală, fără riscul unui offboarding uitat.
- Provizionare automatăSCIM CREATE din Okta sau Entra → cont Elido în sub 60s
- Mapare grup-la-rolGrupurile IdP se mapează la rolurile Elido; schimbările se propagă la următoarea sincronizare
- Deprovizionare instantaneeSCIM DELETE sau active: false → sesiuni revocate imediat
- Suspendarea cheilor APIToate cheile API ale utilizatorului sunt suspendate la offboarding - fără risc de acces după plecare
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika SaloMember
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika Salodeprovizionat
Furnizori de identitate
Funcționează cu orice IdP major
Elido folosește WorkOS ca broker SSO și SCIM - peste 20 de conexiuni disponibile din start, plus Generic SAML pentru orice flux inițiat de SP. Configurează aplicația Elido în IdP-ul tău o singură dată; Elido generează XML-ul de metadate SAML sau credențialele OIDC.
Orice IdP conform SAML 2.0 funcționează prin Generic SAML. Vezi ghidul de configurare →
- Utilizator provizionat prin SCIMokta-scim-svc10.0.1.409:12:04
- Autentificare SSO - Okta[email protected]91.223.4.1709:14:31
- Autentificare SSO - Azure AD[email protected]185.46.9.209:17:08
- Secret webhook rotit[email protected]77.123.11.510:05:22
- Utilizator deprovizionat prin SCIMokta-scim-svc10.0.1.414:33:51
- Rol schimbat: Member → Admin[email protected]77.123.11.515:01:09
Jurnal de audit
Jurnal imuabil de evenimente de identitate
Fiecare autentificare SSO, provizionare SCIM, schimbare de rol și rotație de secret este înregistrată append-only. Niciun administrator nu poate șterge intrări. Exportă în CSV sau trimite către SIEM-ul tău prin API.
- Marcă de timp, actor, acțiune, țintă și conexiune IdP per eveniment
- Retenție de 12 luni pe Business; mai lungă, disponibilă la cerere
- Export API pentru dovezi SOC 2, ISO 27001, DORA și NIS2
- Tentativele SSO eșuate sunt înregistrate cu codul motivului
- Alertare bazată pe IP pentru pragul de sondare SSO
- Rotațiile de secrete referențiază fereastra de suprapunere în jurnal
Ce poți face
- Okta, Azure AD / Entra, Google Workspace
- Mapare domeniu de email → conexiune
- Creare / actualizare / ștergere utilizator SCIM
- Verificarea semnăturii webhook-ului (HMAC-SHA256)
Ce necesită, de fapt, SSO enterprise și provizionarea SCIM în producție
Redirecționarea SAML este condiția minimă. Detaliile de mai jos acoperă latența de provizionare, maparea rolurilor, rotația secretelor și modurile de eșec care contează pentru echipele de securitate.
Autentificare SAML 2.0 și OIDC prin WorkOS - direcționare pe domeniu de email către conexiunea IdP corectă
Elido folosește WorkOS ca broker SSO, care suportă peste 20 de conexiuni IdP, inclusiv Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate și orice IdP conform SAML 2.0. Echipa ta IT configurează aplicația Elido în IdP-ul tău o singură dată; Elido generează un XML de metadate SAML sau credențiale de client OIDC pentru wizard-ul de configurare al IdP-ului. Direcționarea pe domeniu de email mapează domeniile de email ale utilizatorilor către conexiunea IdP corectă - utilizatorii cu @compania-ta.com sunt direcționați automat către conexiunea ta Okta, fără să fie nevoie să o selecteze. Mai multe domenii de email pot fi mapate la o singură conexiune (pentru companii cu entități fuzionate sau mai multe domenii de email). Provizionarea JIT creează contul Elido la prima autentificare SSO, dacă SCIM nu este folosit; dacă SCIM este activ, JIT este dezactivat, iar contul trebuie provizionat prin SCIM înainte de prima autentificare.
Sincronizare de director SCIM 2.0: provizionare automată, deprovizionare și mapare grup-la-rol
SCIM 2.0 sincronizează directorul de utilizatori al furnizorului tău de identitate cu Elido. Când un utilizator este adăugat în grupul aplicației Elido din Okta sau Entra, Elido primește un eveniment SCIM CREATE și provizionează contul utilizatorului - fără tichet IT, fără invitație manuală. Actualizările profilului utilizatorului (nume, email) se propagă automat. Când un utilizator este eliminat din grup sau dezactivat în IdP, Elido primește un eveniment SCIM DELETE sau PATCH (active: false) și revocă imediat accesul - sesiunile active sunt invalidate, cheile API care apartin utilizatorului sunt suspendate. Maparea grup-la-rol îți permite să mapezi grupurile din IdP-ul tău (de ex., „Elido Admins”, „Elido Viewers”) la rolurile Elido (Admin, Member, Viewer). Atribuirile de rol se actualizează automat când se schimbă apartenența la grup în IdP. Latența de provizionare de la evenimentul IdP până la crearea contului Elido este de obicei sub 60 de secunde.
Secretele de semnare a webhook-urilor se rotesc fără a pierde evenimentele în tranzit - procedură de rotație fără downtime
Receptorul de webhook SCIM al Elido și sistemul de webhook-uri de ieșire folosesc semnături HMAC-SHA256 pentru a verifica autenticitatea evenimentelor. Secretele expiră și necesită rotație - fie programat (recomandat: 90 de zile), fie după o suspiciune de compromitere. Rotația fără downtime funcționează astfel: generezi un secret nou în dashboard (secretul vechi rămâne valid timp de 15 minute în fereastra de suprapunere), implementezi secretul nou în sistemele tale, verifici că un eveniment SCIM primit este verificat cu noul secret, apoi declanșezi expirarea imediată a secretului vechi. Fereastra de suprapunere de 15 minute asigură că evenimentele în tranzit semnate cu secretul vechi sunt procesate în continuare pe durata implementării. Rotația secretului este înregistrată în jurnalul de audit cu marca de timp, actorul (administratorul care a rotit) și confirmarea expirării suprapunerii.
Jurnal complet de evenimente de identitate: autentificări SSO, evenimente de provizionare, schimbări de rol și rotații de secrete
Fiecare autentificare SSO, provizionare/deprovizionare SCIM, schimbare de atribuire a rolului și rotație de secret este înregistrată în jurnalul de audit al workspace-ului (Business). Fiecare intrare include: marca de timp, actorul (utilizator sau serviciu SCIM), tipul acțiunii, ținta (utilizatorul sau resursa afectată), conexiunea IdP folosită și ID-ul workspace-ului. Jurnalul de audit este append-only și imuabil - niciun administrator nu poate șterge intrări. Exportă în CSV sau interoghează prin API pentru ingestie în SIEM. Dacă framework-ul tău de conformitate necesită dovezi ale evenimentelor de control al accesului (SOC 2 Type II, ISO 27001, DORA, NIS2), jurnalul de audit este artefactul necesar. Retenția este de 12 luni pe Business; retenție mai lungă este disponibilă la cerere pentru industrii reglementate.
Expirare forțată a sesiunii prin SCIM - accesul este revocat în sub 60 de secunde la dezactivarea din IdP
Când SCIM semnalează că un utilizator este dezactivat (offboarding de angajat, final de contract pentru contractor), Elido invalidează imediat toate sesiunile active ale acelui utilizator și suspendă cheile API ale acestuia. Acest lucru nu depinde de TTL-ul cookie-ului de sesiune - Elido stochează un flag de revocare per ID de utilizator și îl verifică la fiecare cerere autentificată. Timpul de la dezactivarea în IdP până la revocarea accesului în Elido este latența de livrare a evenimentului SCIM: de obicei sub 30 de secunde pentru Okta, sub 60 de secunde pentru Azure Entra. Pentru offboarding cu securitate ridicată (de ex., un administrator care plecă), un administrator de workspace Elido poate revoca manual sesiunile unui utilizator specific din dashboard, înainte ca evenimentul SCIM să ajungă. Sesiunile revocate manual și revocările declanșate de SCIM apar ambele în jurnalul de audit.
Echipe de securitate enterprise care folosesc SSO & SCIM Elido
Numele sunt substituenți - studiile de caz reale ale clienților vor apărea aici pe măsură ce sunt publicate.
“Offboarding-ul SCIM a fost cerința pe care echipa noastră de securitate a avut-o din prima zi. Când un angajat este dezactivat în Entra, accesul la Elido dispare în sub un minut - fără tichet manual de deprovizionare, fără riscul de „am uitat să revoc”. Am auditat log-urile după trei luni și am găsit zero evenimente de acces după offboarding.”
“Avem cinci domenii de email de companie, provenite din două achiziții. Direcționarea domeniu de email → IdP din Elido gestionează toate cele cinci, direcționate către aceeași conexiune Okta. Utilizatorii de pe orice domeniu ajung la fluxul SSO corect, fără să aleagă dintr-o listă.”
“Rotația secretelor fără downtime a fost detaliul care ne-a convins. Rotim secretele webhook-urilor trimestrial, ca politică; fereastra de suprapunere de 15 minute înseamnă că putem rota în orele de program, fără risc de incident. Fiecare rotație este înregistrată, auditată și referențiată în pachetul nostru de dovezi SOC 2.”
SSO & SCIM Elido vs Bitly vs Rebrandly
SSO este disponibil în planul enterprise al Bitly și în planul Business al Rebrandly. Provizionarea SCIM este mai limitată la ambele. Comparația acoperă ce oferă de fapt fiecare.
| Feature | Elido | Bitly Enterprise | Rebrandly Business |
|---|---|---|---|
| SAML 2.0 SSO | Da - broker WorkOS, peste 20 de conexiuni IdP | Da - plan enterprise | Da - plan Business |
| OIDC SSO | Da - alături de SAML, prin WorkOS | Doar SAML | Doar SAML |
| Provizionare SCIM 2.0 | Creare / actualizare / ștergere completă + mapare grup-la-rol | Limitat - doar creare de utilizatori, fără mapare grup-la-rol | Indisponibil |
| Deprovizionare automată la offboarding | Da - SCIM DELETE, sesiune revocată în sub 60s | Doar manual | Doar manual |
| Direcționare IdP pe domeniu de email | Da - mai multe domenii per conexiune | Un singur domeniu per conexiune | Nedocumentat |
| Jurnal de audit pentru evenimente de identitate | Da - imuabil, 12 luni, export API | Jurnal de audit limitat | Jurnal de audit limitat |
| Rotația secretului webhook-ului (fără downtime) | Da - fereastră de suprapunere de 15 minute | Nu se aplică | Nu se aplică |
Întrebări despre SSO & SCIM
Ce furnizori de identitate sunt suportați?
Elido folosește WorkOS ca broker SSO și SCIM, care suportă Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud și orice IdP conform SAML 2.0. Sunt suportate și conexiuni OIDC pentru furnizori precum Google Workspace și Azure. Dacă IdP-ul tău nu se află pe lista standard WorkOS, tipul de conexiune „Generic SAML” al WorkOS funcționează cu orice flux SAML 2.0 inițiat de SP. Contactează-ne dacă ai nevoie de o conexiune IdP specifică, nelistată.
Care este diferența dintre provizionarea JIT și provizionarea SCIM?
Provizionarea JIT (Just-in-Time) creează un cont de utilizator în Elido la prima autentificare SSO - fără a fi nevoie de pre-provizionare. Este mai simplu de configurat, dar nu oferă niciun control asupra celor care se pot autentifica (oricine are o asertiune SSO validă obține un cont). Provizionarea SCIM îi dă IdP-ului tău controlul: doar utilizatorii din grupul provizionat se pot autentifica, iar conturile sunt create înainte de prima autentificare. Pentru medii enterprise unde accesul trebuie preaprobat, SCIM este obligatoriu. Când SCIM este activ, provizionarea JIT este dezactivată.
Cum funcționează maparea grup-la-rol în SCIM?
În setările SSO ale workspace-ului, mapezi grupurile IdP la rolurile Elido: de ex., „Grup Okta: Elido Admins” → „Rol Elido: Admin”, „Grup Okta: Elido Members” → „Rol Elido: Member”. Rolul unui utilizator în Elido urmează apartenența sa la grupul IdP - dacă este mutat din grupul Admins în grupul Members în Okta, rolul său în Elido este retrogradat la următoarea sincronizare SCIM (de obicei sub 60 de secunde). Un utilizator aflat în mai multe grupuri primește rolul cu cel mai mare privilegiu dintre mapările corespunzătoare.
Poate fi SSO obligatoriu pentru toți utilizatorii, sau este opțional?
SSO poate fi setat ca obligatoriu (toți utilizatorii trebuie să se autentifice prin SSO - autentificarea cu parolă este dezactivată) sau opțional (utilizatorii pot alege SSO sau email+parolă). Pe Business, impunerea se configurează în setările SSO ale workspace-ului. Odată impus, utilizatorii care nu au o identitate SSO activă rămân blocați - asigură-te că provizionarea SCIM sau JIT a creat conturile înainte de a activa impunerea. Conturile de administrator pot fi exceptate de la impunerea SSO, ca mecanism break-glass; acest lucru este configurabil.
Ce se întâmplă cu cheile API când un utilizator este offboardat prin SCIM?
Când SCIM dezactivează un utilizator, Elido suspendă toate cheile API create de acel utilizator. Cheile suspendate returnează HTTP 401 la autentificare. Cheile nu sunt șterse - rămân vizibile administratorilor workspace-ului în scopuri de audit, cu eticheta de stare „suspendat - utilizator offboardat”. Dacă un cont de serviciu folosea o cheie API personală (nu o cheie de serviciu la nivel de workspace), suspendarea cheii va întrerupe acea integrare - acest lucru este intenționat. Pentru integrări de producție, folosește chei de serviciu la nivel de workspace, nu chei API de utilizator.
Este SSO disponibil pe Pro, sau doar pe Business?
SSO și SCIM sunt funcții exclusive planului Business. Workspace-urile Pro folosesc autentificarea integrată a Elido (email + parolă prin stratul nostru de autentificare, cu OAuth opțional Google/GitHub). Dacă SSO este o cerință obligatorie pentru aprobarea achizițiilor tale, planul Business este punctul de start.
Cum gestionezi SSO pentru un workspace care are mai multe branduri sau sub-organizații?
Fiecare workspace Elido are propria configurație SSO - dacă operezi mai multe workspace-uri (de ex., per brand, per unitate de business), fiecare primește propria conexiune IdP și propria provizionare SCIM, separat. Utilizatorii pot fi membri ai mai multor workspace-uri, cu roluri diferite în fiecare; identitatea lor IdP este aceeași, dar mapările grup-la-rol sunt evaluate per workspace. Un grup Okta comun poate fi mapat la Admin într-un workspace și la Member în altul.
Există un jurnal de audit pentru tentativele SSO eșuate?
Da. Tentativele SSO eșuate (asertiune SAML invalidă, sesiune expirată, cont SCIM lipsă atunci când JIT este dezactivat) sunt înregistrate în jurnalul de audit al workspace-ului, împreună cu codul motivului. Acest lucru este util pentru a diagnostica de ce un anumit utilizator nu se poate autentifica și pentru a detecta sondări SSO de tip brute-force. Tentativele eșuate provenite de la adrese IP care depășesc un prag declanșează o alertă la nivel de workspace (configurabilă în setările de securitate ale workspace-ului).
Continuă lectura
SSO pentru portal white-label - clienții tăi se autentifică în dashboard-ul tău personalizat prin propriul IdP.
Webhook-uri de ieșire semnate HMAC - același model de rotație a secretelor se aplică semnăturilor webhook-urilor de ieșire.
Chei de serviciu la nivel de workspace pentru integrări API de producție - limitate la workspace, nu la utilizatori individuali.
SOC 2, ISO 27001, rezidență în UE și edge dedicat - setul complet de funcții enterprise.
Ești pregătit să încerci?
Începe cu planul gratuit, fă upgrade când ai nevoie de un domeniu personalizat.