Când conectăm aplicațiile unui client la un singur furnizor de identitate, în plan apare devreme același rând: „și o să ne trebuiască și SCIM 2.0”. Pare parte din single sign-on. Nu este, iar în multe integrări îl puteți lăsa deoparte. Într-unul dintre proiectele noastre am renunțat la SCIM și am construit în schimb un mecanism joiner, mover, leaver (JML); despre el, mai jos.
Două sarcini diferite
SSO răspunde la o singură întrebare: cine este acest utilizator, acum? Aplicația trimite utilizatorul la furnizorul de identitate (IdP), IdP-ul îl autentifică și întoarce un răspuns semnat, un ID token OpenID Connect sau o aserțiune SAML, iar aplicația îl verifică și îl loghează.
SCIM 2.0 (RFC 7643 și RFC 7644) răspunde la altă întrebare: ce conturi trebuie să existe în această aplicație, cu ce atribute și grupuri? IdP-ul apelează un API din aplicație ca să creeze, să actualizeze și să dezactiveze utilizatori, fie că se loghează vreodată, fie că nu.
| Aspect | SSO (OIDC sau SAML) | SCIM 2.0 |
|---|---|---|
| Întrebarea | Cine se loghează? | Ce conturi există? |
| Când rulează | La fiecare logare | Când un utilizator se schimbă în IdP |
| Cine pe cine apelează | Redirecționări în browser, plus apelul aplicației către endpointul de tokenuri al IdP-ului (OIDC) | IdP-ul apelează API-ul aplicației |
| Ce construiți | Un flux de logare și validarea tokenurilor | Un endpoint /scim/v2, întreținut ani de zile |
Ce acoperă SSO singur
Fără SCIM, o aplicație își poate ține totuși conturile aproape de IdP:
- Creare la prima logare. Provizionarea just-in-time creează contul din claim-urile tokenului prima dată când persoana se autentifică.
- Actualizare la fiecare logare. Numele, e-mailul și claim-urile de grup sunt citite din nou de fiecare dată, așa că rolurile urmează IdP-ul de la o logare la alta. Verificați că IdP-ul chiar trimite grupurile: unii furnizori le omit implicit sau nu le mai listează peste o anumită limită.
- Legare printr-un identificator stabil. Păstrați emitentul și subiectul (
issșisub, sau un NameID SAML persistent), niciodată adresa de e-mail, care se poate schimba sau poate fi refolosită după plecarea cuiva. - Cine pleacă nu mai intră. Odată ce contul din IdP este dezactivat, nicio logare nouă nu mai reușește.
Pentru un grup de sisteme în care oamenii se loghează zilnic, de obicei ajunge, și economisiți construirea și operarea unui endpoint SCIM în fiecare aplicație.
Ce nu acoperă
SSO vede un utilizator doar când acesta se loghează. Planificați golurile, în loc să le descoperiți la un audit:
- Sesiunile deschise și tokenurile de reîmprospătare ale celui care a plecat rămân valide până expiră. Țineți-le scurte sau folosiți back-channel logout acolo unde IdP-ul îl oferă.
- Cheile API și tokenurile personale de acces nu trec niciodată prin IdP. Legați-le de cont și verificați că acesta este încă activ, ceea ce funcționează doar împreună cu punctul următor.
- Un cont există doar după prima logare, deci nimeni nu poate aloca dinainte sarcini sau drepturi unui coleg nou.
- Nimeni nu anunță aplicația că o persoană a plecat, așa că contul rămâne în baza ei de date. O verificare programată față de director, de exemplu Microsoft Graph sau LDAP, îl poate dezactiva.
Când merită SCIM
Adăugați SCIM când una dintre acestea este o cerință fermă: conturile trebuie să existe înainte de prima logare, accesul trebuie retras din toate aplicațiile la scurt timp după o încetare a contractului, fără să așteptați ca persoana să se logheze, sau un auditor cere ca lista de utilizatori a fiecărei aplicații să fie ținută sincronizată cu IdP-ul. Atunci SCIM este modul standard de a o face, iar principalii furnizori de identitate îl suportă. Nu este singurul: un proces propriu de joiner, mover, leaver poate acoperi aceleași nevoi. Niciunul nu închide singur sesiunile deschise, așa că revocați-le când un cont este dezactivat.
Ce am făcut în schimb: un mecanism JML
Într-unul dintre proiectele noastre am renunțat la SCIM și am construit un mecanism JML. SCIM ar fi însemnat un endpoint standard de provizionare în fiecare aplicație, iar revocarea sesiunilor și a tokenurilor tot ar fi rămas în sarcina noastră. Un mecanism JML gestionează direct ciclul de viață al accesului unei persoane:
- Joiner. Conturile și rolurile de pornire sunt create la angajare, de obicei din sistemul de resurse umane, înainte de prima logare.
- Mover. O schimbare de echipă sau de rol adaugă accesul nou și îl retrage pe cel vechi, ca drepturile să nu se adune.
- Leaver. Conturile sunt dezactivate, iar sesiunile și tokenurile revocate, nu doar blocată următoarea logare.
Ca și SCIM, are nevoie de un punct de integrare în fiecare aplicație; diferența este că modelați ciclul de viață după propriile sisteme, nu după un protocol standard. SSO rămâne responsabil de logare; JML decide la ce au acces oamenii și când se încheie acest acces.
Sfat
Dacă niciuna dintre aceste cerințe nu se aplică, începeți doar cu SSO: legați conturile prin subiect, țineți sesiunile scurte și adăugați SCIM sau un proces JML mai târziu, dacă apare cerința. Din prima zi, păstrați și un identificator pe care IdP-ul îl poate trimite prin SCIM ca externalId (în Microsoft Entra ID, object ID-ul), ca să se potrivească conturile provizionate cu cele existente. Oricum ați face-o, provizionarea extinde aceleași conturi; nu înlocuiește logarea.