Autentifică echipa cu SSO

Ce vei construi

La finalul acestui tutorial vei avea:

• o conexiune SAML între serverul tău Control Center și un furnizor de identitate (folosim Okta ca exemplu),
• un utilizator provisionat automat la prima autentificare și
• o politică de apartenență la spațiile de lucru pe care ai ales-o deliberat.

Vei avea nevoie de un server pe care îl administrezi (proprietarul serverului — operatorul instalării) și de o aplicație IdP pe care o poți configura. Rezervă 20 de minute.

1. Deschide setările de autentificare unică

Autentifică-te în Control Center, apoi mergi la Setări → Server → Autentificare unică. Ecranul comută între SAML și OpenID Connect, plus un card Provisionare utilizatori (SCIM). Rămâi pe SAML.

Tot ce ține de acest ecran este la nivel de server: un singur IdP autentifică oamenii din toate spațiile de lucru, așa că doar proprietarul serverului îl poate edita.

2. Lipește metadatele IdP

În Okta, deschide tab-ul Sign On al aplicației tale și copiază XML-ul de metadate (sau descarcă-l și lipește conținutul fișierului). Înapoi în Control Center, lipește-l în Metadate XML IdP și apasă Testează conexiunea.

Notificarea afișează endpointul de autentificare al IdP-ului — dovada că metadatele au fost analizate, certificatul a fost citit și serverul poate construi o cerere de autentificare pe baza lor (testul exersează tot, mai puțin ciclul dus-întors din browser). Dacă eșuează, XML-ul nu a fost un EntityDescriptor complet (tab-ul SAML din Okta îl numește „Metadata URL”; deschide URL-ul și copiază ce servește). Același buton de pe OpenID Connect verifică în schimb documentul de discovery al emitentului tău. Ca să prinzi și un certificat care expiră și să vezi dacă IdP-ul recunoaște Control Center, folosește verificatorul de la pasul 6.

3. Înregistrează Control Center la IdP

Apasă Copiază metadatele SP și dă-le celui care configurează partea de Okta (sau citește cele două valori pe care ți le cere):

• URL ACS: https://<your-server>/saml/acs
• Entity ID: https://<your-server>/saml

URL-urile derivă din originea pe care o ating browserele utilizatorilor tăi. Dacă serverul rulează în spatele unui tunel sau al unui reverse proxy, asigură-te că originea este stabilă (Setări → Server → Conexiune și stare → Partajează acest server arată URL-ul public) — sau fixează entity ID-ul explicit în câmpul SP entity ID.

În spatele NAT?

Autentificarea SAML nu are nevoie de o adresă IP publică sau de un domeniu: IdP-ul nu se conectează niciodată la serverul tău — ciclul dus-întors este purtat de browserul utilizatorului, așa că localhost, LAN, VPN, Tailscale sau un tunel funcționează toate. Două lucruri de reținut:

• originea folosită de browser trebuie să corespundă cu URL-ul ACS / entity ID-ul înregistrat la IdP (fixează entity ID-ul dacă utilizatorii ating serverul sub mai multe origini),
• provisionarea SCIM este excepția — IdP-ul apelează direct serverul tău, deci are nevoie de un tunel sau de un URL public (provisionează utilizatori cu SCIM).

4. Alege ce acordă o autentificare

Două politici decid ce face o primă autentificare:

• Adaugă utilizatorii în fiecare spațiu de lucru la prima autentificare — lasă-l activat pentru o implementare cu o singură echipă, unde SSO înseamnă încredere. Dezactivează-l când mai multe echipe sau clienți împart serverul: fiecare nou-venit are atunci nevoie de o invitație explicită în spațiul de lucru, ceea ce este varianta implicită mai sigură.
• Provisionare utilizatori necunoscuți la prima autentificare — activat implicit; dezactivează-l ca să respingi pe oricine nu are deja un cont.

Opțional, mapează un atribut care poartă numele grupurilor (la Okta este de obicei groups) și traduce grupurile în roluri cu ajutorul mapării — de exemplu {"platform-leads": "admin"}. SSO nu poate acorda niciodată rolul de proprietar.

5. Activează și fă o autentificare

Activează Folosește SAML pentru autentificare, apasă Salvează conexiunea, apoi deschide o fereastră privată de browser la https://<your-server>/saml/login. Autentifică-te la Okta și ajungi înapoi în clientul web — autentificat, cu contul creat și apartenența acordată conform politicii pe care ai ales-o.

Același punct de intrare apare pe ecranul de conectare web (Autentifică-te cu SAML) în momentul în care tastezi adresa serverului — formularul se adaptă la ce oferă serverul (OpenID Connect afișează Autentifică-te cu OpenID Connect). Butonul deschide autentificarea într-un tab nou; când ciclul dus-întors se încheie, tab-ul care aștepta preia sesiunea automat. Ecranul de configurare a serverului din aplicația desktop face la fel: tastează URL-ul serverului, apare un buton Autentifică-te cu SAML care îți deschide browserul, iar aplicația se autentifică atunci când ciclul dus-întors se încheie.

6. Verifică din această pagină

Înainte să extinzi SSO, sau când o autentificare eșuează, verifică aici componentele. Verificatorul rulează în întregime în browserul tău: citește metadatele pe care le lipești în acest tab și aplică aceleași reguli ca serverul. Dacă îi dai adresa serverului, întreabă acel server și dacă autentificarea SAML este activă.

Prinde ceea ce Testează conexiunea din aplicație nu poate vedea: un certificat de semnare aproape de expirare, un IdP care insistă pe cereri semnate și, cu autentificarea de test, dacă IdP-ul recunoaște deloc Control Center.

Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.

IdP metadata XMLLoad a file

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

SP entity ID (optional)

Only if you pinned one in the app.

Check metadata

Unde mergi mai departe

• Dă-i IdP-ului tău și controlul ciclului de viață: provisionează și deprovisionează utilizatori cu SCIM.
• IdP-ul tău vorbește OpenID Connect în loc de SAML? Conectează un provider OpenID Connect.
• Ești curios ce verifică de fapt ciclul dus-întors din browser? Cum funcționează autentificarea unică.