Ce este un broker de identitate și când ar trebui să îl folosești?

Un broker de identitate este un intermediar într-un proces de conectare federat. Acesta validează informațiile de identitate de la un furnizor de identitate (IdP) din amonte și emite o nouă aserțiune sau un token în care o aplicație din aval poate avea încredere.

Această abordare devine utilă atunci când organizațiile trebuie să conecteze mai mulți furnizori de identitate și aplicații cu cerințe de federație diferite. În loc să configureze fiecare relație separat, echipele IT pot utiliza un broker pentru a gestiona relațiile de încredere acceptate, mapările de identitate și rutarea autentificării.

Brokerul acționează ca o parte de încredere față de IdP-ul din amonte și ca un furnizor de identitate față de aplicație. Cu toate acestea, devine și o dependență critică de securitate și disponibilitate. Dacă federația directă îndeplinește deja cerința, adăugarea unui broker poate crea o complexitate inutilă.

Ce este un broker de identitate?

Un broker de identitate se află între unul sau mai mulți furnizori de identitate și aplicațiile care se bazează pe aceștia. În loc ca fiecare aplicație să mențină o relație de federație separată cu fiecare IdP, aplicațiile pot avea încredere în broker, în timp ce brokerul menține relații în amonte.

În timpul conectării, un broker poate:

• Validați o aserțiune sau un token de la un IdP din amonte.
• Reemiteți informațiile de identitate într-un formular acceptat de aplicație.
• Traduceți între protocoalele, formatele sau schemele de federație acceptate.
• Conversia atributelor primite în revendicări downstream consistente.
• Aplicați regulile pentru eliberarea atributelor.
• Dirige utilizatorii către diferiți IdP-uri în funcție de organizație, domeniu sau politică.

Nu toți brokerii traduc protocoale. Unii folosesc același protocol pe ambele părți, dar oferă normalizare a revendicărilor, rutare sau gestionare centralizată a încrederii.

Brokeraj de identități versus brokeraj de conectori IAM

Brokerajul de identități este o funcție de federație în timpul rulării. Brokerul participă direct la o conectare live și creează aserțiunea sau tokenul consumat de aplicație.

„Conectorul IAM” este mai puțin precis. În funcție de produs, un conector poate sincroniza înregistrări de director, poate furniza conturi, poate interoga o API sau se poate conecta la un director, cum ar fi LDAPAceste activități pot susține gestionarea identității fără a participa la o tranzacție de autentificare interactivă.

O platformă unică de gestionare a identității și accesului poate include brokeri și conectori. Distincția operațională constă în faptul că un broker se află pe calea de încredere pentru conectare, în timp ce un conector de sincronizare sau de furnizare mută în principal datele de identitate și cele ale ciclului de viață.

Cum funcționează autentificarea intermediată?

O autentificare tipică prin broker urmează această secvență:

1. Un utilizator deschide o aplicație.
2. Aplicația redirecționează browserul către brokerul de identitate.
3. Brokerul selectează un IdP din amonte sau îi cere utilizatorului să aleagă unul.
4. IdP-ul din amonte autentifică utilizatorul cu metodele sale configurate.
5. IdP-ul din amonte returnează brokerului un răspuns specific protocolului. Într-un flux SAML, brokerul primește și validează un răspuns și o afirmație SAML. Într-un OpenID Connect (OIDC) În fluxul codului de autorizare, brokerul primește un cod de autorizare, îl schimbă la punctul final al token-ului, apoi validează token-ul de identificare.
6. Brokerul verifică emitentul așteptat, publicul, semnătura sau altă protecție necesară, perioada de valabilitate și controalele specifice protocolului.
7. Brokerul mapează subiectul din amonte și atributele aprobate la revendicările din aval.
8. Brokerul creează și protejează o nouă aserțiune sau un token downstream, conform cerințelor protocolului selectat.
9. Aplicația validează răspunsul emis de broker, creează o sesiune și aplică regulile sale de autorizare.

Aceasta creează două relații distincte de încredere: una între IdP-ul din amonte și broker și o alta între broker și aplicație. Un răspuns valid din amonte nu înlătură responsabilitatea aplicației de a valida ceea ce emite brokerul.

Cine autentifică utilizatorul, emite token-uri, mapează revendicările și acordă acces?

Părțile au responsabilități separate, chiar și atunci când o platformă îndeplinește mai multe roluri:

• Furnizor de identitate în amonte: Autentifică utilizatorul și emite răspunsul original.
• Broker de identitate: Validează răspunsul din amonte, mapează informațiile de identitate aprobate și, de obicei, emite aserțiunea sau token-ul din aval.
• Aplicație sau parte care se bazează pe aceasta: Validează răspunsul emis de broker și decide ce poate face utilizatorul în aplicație.

Brokerul poate transforma o cerere de grup, rol sau context de autentificare, dar nu ar trebui tratat ca autoritate finală pentru fiecare permisiune a aplicației. Aplicația rămâne responsabilă pentru politica sa de autorizare și pentru respingerea aserțiunilor sau token-urilor care nu trec de validare.

Când aveți nevoie de un broker de identitate în loc de federație directă?

Un broker de identitate devine util atunci când organizațiile trebuie să conecteze mai mulți furnizori de identitate și aplicații, să se adapteze la diferite cerințe de federație sau să reducă configurațiile de încredere repetate.

Federația directă este de obicei mai simplă atunci când furnizor de identitate și aplicațiile acceptă protocoale compatibile, sunt de acord asupra identificatorilor și revendicărilor și pot menține o relație de încredere securizată fără un intermediar.

Situații comune în care intermedierea identității ajută

• Fuziuni si achizitii: Angajații din organizații separate au nevoie de acces la aplicații partajate, în timp ce furnizorii lor de identitate rămân independenți.
• Acces partener: Utilizatorii externi se autentifică prin intermediul unor furnizori de identitate diferiți, dar aplicațiile au nevoie de o relație de federație consistentă.
• Compatibilitate protocol: Un furnizor de identitate și o aplicație necesită protocoale sau profiluri de federație diferite la care se poate conecta un broker acceptat.
• Standardizarea revendicărilor: Aplicațiile au nevoie de identificatori, roluri sau atribute consecvente din surse de identitate diferite.

Acestea sunt cazuri de utilizare arhitecturală, nu motive pentru a implementa automat un broker. Atunci când federația directă este compatibilă și ușor de gestionat, aceasta introduce de obicei mai puține dependențe.

Broker de identitate vs. federație directă

Următoarea comparație ajută la determinarea momentului în care federația directă este suficientă și când introducerea unui broker poate fi justificată.

Compromisul este centralizarea. Un broker poate reduce extinderea conexiunilor, dar poate, de asemenea, observa activitatea federației și emite aserțiuni downstream de încredere. Are nevoie de controale administrative puternice, monitorizare, protecție a cheilor și planificare a recuperării; centralizarea nu este automat mai sigură.

Cheie de luat masa: Folosește un broker de identitate atunci când mai mulți IdP-uri, cerințe de federație incompatibile sau configurații de încredere repetate creează o problemă semnificativă de integrare. Preferă federația directă atunci când sistemele existente sunt compatibile, iar adăugarea unui broker ar introduce complexitate fără un beneficiu clar.

Cum alegi protocoalele și cartografiazi revendicările de identitate?

Selectarea protocolului trebuie să respecte capacitățile IdP-ului, brokerului și aplicației. Nu tratați SAML, OIDC, OAuth și LDAP ca tehnologii interschimbabile.

Unde se potrivesc SAML, OpenID Connect, OAuth și LDAP

• Limbajul de marcare a afirmațiilor de securitate (SAML)Un cadru de federație bazat pe XML, utilizat în mod obișnuit pentru autentificarea unică în browser între un IdP și un furnizor de servicii. SAML definește aserțiuni, metadate, identificatori, legături și relații de încredere. Consultați Prezentare tehnică a OASIS SAML 2.0.
  
• OpenID Connect (OIDC): Un protocol de autentificare construit pe OAuth 2.0. Acesta oferă un token de identificare care conține revendicări despre utilizator și evenimentul de autentificare și poate prelua revendicări suplimentare prin intermediul punctului final UserInfo. Clienții trebuie să valideze tokenurile de identificare așa cum este specificat în OpenID Connect Core.
  
• OAuth 2.0: Un cadru de autorizare utilizat pentru a acorda acces limitat la resurse protejate. Un OAuth Un token de acces în sine nu ar trebui tratat ca o dovadă că o aplicație a autentificat un utilizator; OIDC furnizează stratul de autentificare pentru acel caz de utilizare.
  
• Protocol ușor de acces la director (LDAP): Un protocol de acces la directoare cu autentificare și mecanisme de securitate a transportului, cum ar fi operațiunile de legare, SASL și TLS. LDAP poate suporta căutarea în directoare sau validarea acreditărilor, dar nu este un protocol de federație a browserului echivalent cu SAML sau OIDC. Vedea RFC 4513.

Înainte de a selecta un broker, confirmați profilurile și fluxurile exacte acceptate de ambele părți. Afirmațiile generale privind „suportul SAML” sau „suportul OIDC” nu stabilesc compatibilitatea cu fiecare legătură, opțiune de semnare, format de revendicare sau comportament al aplicației.

Verificați identificatorii, grupurile și atributele înainte de a le transmite aplicațiilor

Conectarea conturilor ar trebui să înceapă cu un identificator de subiect durabil. Acolo unde protocolul și aplicația permit acest lucru, utilizați combinația dintre autoritatea emitentă și identificatorul său de subiect. Nu presupuneți că o adresă de e-mail, un nume de utilizator sau un nume afișat nu vor fi niciodată redenumite sau reatribuite.

Odată ce identitatea contului este stabilă, mapați doar ceea ce are nevoie aplicația:

• Definiți sursa autorizată pentru fiecare rol, grup și drept.
• Specificați dacă comparațiile sunt sensibile la majuscule/minuscule.
• Normalizați numele și formatele în mod deliberat, în loc să vă bazați pe conversia implicită.
• Testați modul în care aplicația gestionează valorile lipsă, goale, duplicate sau neașteptate.
• Testați utilizatorii cu mai multe grupuri de apartenență pentru a identifica dimensiunea specifică produsului sau comportamentul de omisiune.
• Documentați dacă un cont existent poate fi conectat automat sau necesită aprobare administrativă.
• Evitați publicarea atributelor de profil sau organizaționale pe care aplicația nu le necesită.

Transformarea revendicărilor trebuie să păstreze sensul. Un grup din amonte numit Finance, de exemplu, nu ar trebui să devină un rol de administrator din cauza unei reguli de mapare largi sau ambigue.

Ce ar trebui să configurați înainte de a conecta un broker de identitate?

Tratați conexiunile în amonte și în aval ca configurații de securitate separate. Pentru fiecare parte, documentați și verificați:

• Identificatorul exact al emitentului sau al entității.
• URI-uri de redirecționare sau URL-uri SAML Assertion Consumer Service (ACS).
• Publicul înregistrat și valorile destinatarilor.
• Chei de semnare, verificare, criptare și decriptare.
• Metadate sau puncte finale de descoperire.
• Algoritmi și fluxuri de protocoale acceptate.
• Duratele de viață ale afirmațiilor sau ale jetoanelor și asimetria permisă a ceasului.
• Cerințe privind contextul de autentificare, acolo unde este cazul.
• Proceduri de rotație a certificatelor și cheilor.
• Deconectare și comportament la sesiune.

Configurați încrederea între broker, furnizorii de identitate și aplicații

Brokerul trebuie să verifice IdP-ul din amonte, iar aplicația trebuie să verifice independent brokerul. Înregistrați ce entitate deține fiecare relație de încredere, ce chei sunt active și cum sunt actualizate metadatele și certificatele.

Nu vă bazați pe o conectare reușită a administratorului ca dovadă că încrederea este configurată corect. Testați eșecurile de validare așteptate, precum și calea fericită.

Validarea token-urilor de testare, sesiunile și conectările eșuate

Folosește o matrice de testare care include:

• O conectare normală a unui utilizator existent.
• Prima autentificare a unui utilizator nou.
• Un cont din amonte dezactivat sau șters.
• Eliminarea unui grup sau rol obligatoriu.
• Cereri lipsă și incorecte.
• O aserțiune sau un token expirat sau încă nevalid.
• Un public sau un destinatar greșit.
• O semnătură nevalidă sau o cheie de semnare necunoscută.
• Transfer de chei în amonte și broker.
• Un IdP din amonte indisponibil.
• Un broker indisponibil.

Definiți rezultatul așteptat pentru fiecare test. În special, determinați dacă accesul este refuzat imediat după o modificare a contului sau a grupului sau numai după ce expiră o sesiune existentă a aplicației.

Ce riscuri de securitate și disponibilitate ar trebui să evaluați?

Deoarece un broker poate emite aserțiuni downstream de încredere și poate observa activitatea federației, tratați-l ca o dependență de securitate și disponibilitate de mare valoare. NIST SP 800-63C-4 abordează controale precum validarea aserțiunilor, restricționarea publicului, protecția la redare, stocarea cheilor și rotația cheilor.

Controalele de securitate ar trebui să includă:

• Stocare securizată și utilizare controlată a cheilor de semnare și decriptare.
• Rotație autentificată a cheilor cu un proces testat de suprapunere și revenire la normal.
• Validare strictă a emitentului, semnăturii, publicului, destinatarului și a timpului de valabilitate.
• Protecție la reluare și validare a stării sau non-stării acolo unde protocolul le utilizează.
• Înregistrarea exactă a locațiilor de redirecționare și apel invers.
• Eliberare minimă a atributelor de identitate.
• Acces cu privilegii minime pentru administratorii brokerilor.
• Autentificare multi-factor pentru administrare privilegiată.
• Jurnale care conectează evenimentele din amonte și din aval prin identificatori de corelare.
• Monitorizarea eșecurilor de validare, a modificărilor de configurație și a activității anormale de emitere.

Protejați cheile de semnare și limitați accesul la atributele de identitate

O cheie de semnare compromisă sau un cont de broker privilegiat poate afecta fiecare aplicație care are încredere în broker. Limitați accesul la funcțiile de gestionare a cheilor și la configurația administrativă și eliberați doar atributele necesare fiecărei aplicații din aval.

Planificare pentru întreruperile brokerilor și modificările furnizorilor din amonte

Planificarea disponibilității trebuie să facă distincția între sesiunile existente și noile conectări. O întrerupere a brokerului poate bloca o nouă autentificare fără a încheia imediat sesiunile întreținute de aplicațiile din aval. Rezultatul depinde de durata sesiunii, durata de viață a aserțiunii sau a token-ului, comportamentul de reîmprospătare și verificările specifice aplicației.

Documentați comportamentul așteptat pentru erorile IdP din upstream, erorile brokerului, izolarea rețelei, întreținerea planificată, expirarea certificatului și modificările metadatelor furnizorului. Procedurile de recuperare ar trebui să restabilească configurația și cheile fără a crea accidental un nou spațiu de nume pentru emitent sau subiect.

De ce eșuează o conectare prin broker?

Începeți prin a identifica ce salt a eșuat: de la aplicație la broker, de la broker la IdP-ul din amonte, de la IdP-ul din amonte înapoi la broker sau de la broker înapoi la aplicație. O pagină de eroare a browserului arată adesea unde s-a oprit procesul, nu ce componentă a cauzat problema inițială.

Verificați redirecționările, setările protocolului, validitatea token-urilor și mapările revendicărilor

Folosește această ordine de diagnosticare:

1. Înregistrați marcajul temporal, utilizatorul afectat, aplicația, IdP-ul din amonte și ID-urile de corelare disponibile.
2. Confirmați că browserul a atins punctele finale așteptate fără o buclă de redirecționare.
3. Comparați URI-urile de redirecționare configurate sau URL-urile ACS cu solicitarea și răspunsul real.
4. Verificați identificatorii emitentului, ID-ului entității, publicului, destinatarului și clientului caracter cu caracter.
5. Verificați semnătura și confirmați că destinatarul are cheia de verificare activă.
6. Verificați expirarea, ora de expirare și sincronizarea ceasului.
7. Pentru fluxurile OIDC, validați gestionarea stării și a nonce-urilor, acolo unde este cazul, și confirmați că schimbul de coduri de autorizare are succes atunci când este utilizat fluxul respectiv.
8. Comparați cererile de identitate primite cu setul de cereri de ieșire ale brokerului.
9. Confirmați că subiectul se leagă de contul de aplicație dorit.
10. Verificați starea contului, grupurile necesare și regulile de autorizare la nivel de aplicație.
11. Repetați calea cu un utilizator de test controlat și capturați jurnale de la fiecare componentă.

Dacă autentificarea reușește la IdP-ul din amonte, dar aplicația refuză accesul, concentrați-vă pe jurnalele de validare și mapare ale brokerului, apoi pe jurnalele de validare a token-urilor și autorizare ale aplicației. Dacă brokerul nu primește niciodată un răspuns valid din amonte, investigați configurația de încredere din amonte înainte de a modifica revendicările din aval.

Cum acceptă Scalefusion OneIdP federarea identităților SAML?

Organizațiile pot avea nevoie să păstreze un furnizor de identitate SAML existent, controlând în același timp accesul la aplicațiile de business acceptate de pe dispozitivele gestionate.

Scalefusion OneIdP acceptă configurarea unui furnizor extern de identitate SAML 2.0 ca sursă de autentificare. Administratorii pot, de asemenea, configura SSO pentru aplicațiile compatibile cu SAML și pot aplica condiții de acces la dispozitive gestionate, sub rezerva cerințelor preliminare documentate.

Aceasta oferă o cale de implementare relevantă pentru organizațiile care evaluează federarea de identități SAML. Nu ar trebui interpretată ca o traducere universală a protocolului sau compatibilitate cu fiecare furnizor de identitate și aplicație.

Explorează Scalefusion OneIdP pentru a evalua potrivirea sa cu cerințele organizației dumneavoastră.

Întrebări frecvente

1. Este un broker de identitate același lucru cu un furnizor de identitate?

Nu. Un furnizor de identitate autentifică un utilizator și afirmă rezultatul. Un broker de identitate mediază între un sistem de identitate din amonte și o aplicație bazată pe aceasta, adesea validând un artefact și emitând un altul. Un produs poate îndeplini ambele roluri, așadar determinați-i responsabilitatea în fiecare relație de încredere configurată.

2. Un broker de identitate decide la ce poate accesa un utilizator?

Nu neapărat. Un broker poate refuza conectarea, poate aplica politica de federație și poate mapa grupuri sau roluri. Aplicația din aval ia de obicei decizia finală de autorizare folosind aceste revendicări, rolurile sale locale și politica specifică resursei. Prin urmare, mapările incorecte ale revendicărilor pot autentifica cu succes un utilizator, acordând în același timp prea mult sau prea puțin acces.

3. Poate un broker de identitate să lucreze cu un furnizor de identitate care nu acceptă SAML sau OpenID Connect?

Posibil. Sursa de identitate trebuie să expună o interfață pe care un adaptor acceptat, o integrare personalizată sau un intermediar o poate consuma în siguranță, iar brokerul trebuie să poată produce o metodă de federație acceptată de destinație. Un director bazat pe LDAP, de exemplu, poate necesita un IdP sau un adaptor înainte de a putea participa. Verificați compatibilitatea și modelul de încredere rezultat pentru sistemele specifice, în loc să presupuneți că este posibilă o conexiune personalizată.

4. Poate un broker de identitate să împiedice utilizatorii să acceseze o aplicație SaaS în afara unei căi de rețea securizate?

Nu de una singură. Rutarea conectării printr-un broker poate permite verificări în timp de autentificare, dar nu dovedește că traficul ulterior dintre dispozitiv și aplicația SaaS urmează o cale de rețea impusă. Acest lucru necesită controale separate, cum ar fi restricții de acces la aplicații și o arhitectură de rețea sau proxy adecvată.