Securitate

Authentik: SSO open-source cu SAML, OIDC, LDAP si RADIUS intr-un singur instrument

Daca ai mai mult de trei aplicatii self-hosted, stii deja senzatia: fiecare are propriul cont, propria parola, propriul mecanism (uneori inexistent) de MFA. Un Nextcloud pe aici, un Grafana pe acolo, un dashboard intern langa un wiki si un VPN. La un moment dat ajungi sa refolosesti aceeasi parola peste tot, ceea ce e exact opusul a ce vrei sa faci cand vorbim de securitate, sau tii un manager de parole cu 15 intrari doar pentru instrumentele proprii. Ideea de “un singur login pentru tot” e atragatoare tocmai pentru ca rezolva problema asta la radacina: un singur loc unde gestionezi utilizatorii, un singur loc unde impui MFA, un singur loc unde revoci accesul cand cineva pleaca din echipa. Problema e ca a ajunge acolo introduce o piesa noua, critica, in infrastructura ta: un identity provider (IdP) pe care il ai self-hosted si de care depinde, practic, accesul la tot restul.

authentik (repo pe GitHub , site oficial pe goauthentik.io ) e exact asta: un provider de identitate si SSO open-source, gandit sa fie self-hosted si sa acopere o gama larga de protocoale de autentificare, nu doar unul singur. Nu e un simplu proxy care pune o pagina de login in fata unei aplicatii, ci un sistem complet de identitate, cu utilizatori, grupuri, politici si fluxuri de autentificare configurabile.

Ce este, mai exact, authentik

authentik nu incearca sa fie un singur lucru: e SAML, e OAuth2/OpenID Connect (OIDC), e LDAP, e SCIM pentru provisioning automat de conturi, si e RADIUS pentru autentificare la nivel de retea sau VPN. Practic acopera cele patru moduri diferite in care aplicatiile moderne (si nu numai) vorbesc despre “cine esti tu”: aplicatii web care stiu OIDC sau SAML, servicii legacy care asteapta un director LDAP clasic, sisteme de provisioning care vorbesc SCIM, si echipamente de retea care asteapta RADIUS. In loc sa ai trei-patru instrumente diferite pentru fiecare protocol, ai unul singur care le vorbeste pe toate.

Ce il diferentiaza cu adevarat, insa, nu e lista de protocoale, e motorul de “flows si stages”. In loc sa aiba un ecran de login hardcodat, o pagina fixa de inregistrare si un proces rigid de recuperare a parolei, authentik modeleaza fiecare dintre aceste procese ca un “flow” (flux) compus din “stages” (etape) reutilizabile: o etapa de identificare, una de verificare parola, una de MFA, una de consimtamant, si asa mai departe. Poti construi un flow de login diferit pentru un grup de utilizatori fata de altul, poti insera o etapa suplimentara doar pentru admini, sau poti activa auto-inregistrarea (enrollment) doar pentru anumite aplicatii. E flexibil in sensul bun al cuvantului: nu esti blocat in designul default daca ai nevoie de altceva.

De ce conteaza

Motivul pentru care merita sa investesti timp intr-un IdP centralizat e simplu: fiecare aplicatie pe care o adaugi fara SSO e o noua suprafata de atac cu propriul ei mecanism de autentificare, de multe ori mai slab decat ai vrea (fara MFA, fara politica de complexitate parola, fara logging centralizat). Cand centralizezi identitatea, impui o singura politica de MFA peste tot, ai un singur loc unde vezi cine s-a logat unde si cand, si un singur switch pe care il opresti cand cineva paraseste organizatia, in loc sa umbli prin zece aplicatii sa ii inchizi conturile unul cate unul.

Ca sa fim onesti pana la capat: SSO-ul intern al DreamServer ruleaza pe Authelia , nu pe authentik, in principal pentru ca modelul lightweight al Authelia, binar unic plus fisier de configurare, s-a potrivit mai bine cu stack-ul nostru. Asta nu inseamna ca authentik e alegerea gresita, dimpotriva, e un provider de identitate cu adevarat solid si mai complet, mai ales daca ai nevoie de SAML, SCIM, RADIUS sau de fluxuri de auto-inregistrare pe care Authelia nici nu incearca sa le acopere. Sunt doua instrumente cu filosofii diferite, nu un “castigator” si un “invins”.

Ce primesti din cutie

Setul de facilitati din authentik e mult mai larg decat “login o data, acces peste tot”:

Suport multi-protocol real: SAML si OIDC pentru aplicatii web moderne, LDAP pentru servicii care asteapta un director clasic (multe aplicatii legacy, unele NAS-uri, unele instrumente enterprise), SCIM pentru provisioning si de-provisioning automat de conturi in servicii terte, si RADIUS pentru autentificare la nivel de retea sau VPN. Practic poti inlocui patru sisteme diferite de auth cu unul singur.
Motorul de flows si stages: login, enrollment (auto-inregistrare), recuperare parola si alte procese de identitate sunt fluxuri configurabile, nu ecrane fixe. Poti adauga, elimina sau reordona etape fara sa scrii cod.
Provider de forward-auth (proxy): pentru aplicatiile care nu au niciun mecanism nativ de autentificare, authentik se poate pune in fata lor ca un forward-auth provider si sa le gateze accesul, similar conceptual cu ce fac Authelia sau oauth2-proxy. Util pentru instrumente interne, dashboard-uri sau utilitare fara login propriu.
MFA solid: TOTP (Google Authenticator si echivalente) plus WebAuthn/passkeys, deci poti impune autentificare fara parola sau cu chei hardware acolo unde vrei nivelul acela de securitate.
UI de administrare: gestionezi aplicatii, provideri, utilizatori, grupuri si flows dintr-o interfata web, fara sa umbli prin fisiere de configurare pentru fiecare modificare mica.

Sub capota, backend-ul e scris in Python/Django, cu o componenta in Go, iar deploy-ul tipic e self-hosted, prin Docker/docker compose sau Kubernetes.

Instalare authentik pe un VPS

Un VPS e o alegere rezonabila pentru authentik: ai control complet asupra retelei si a firewall-ului, ceea ce conteaza mult cand pui in productie un sistem de identitate de care depinde accesul la restul aplicatiilor. Instalarea oficiala foloseste docker compose, cu un serviciu de server, unul de worker (pentru task-uri asincrone precum trimiterea de email-uri sau procesarea flow-urilor mai complexe), plus PostgreSQL si Redis ca dependente:

mkdir -p /opt/authentik && cd /opt/authentik

# descarca fisierul compose oficial si un .env cu secrete generate
curl -o docker-compose.yml https://goauthentik.io/docker-compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

# porneste stack-ul (server + worker + postgres + redis)
docker compose pull
docker compose up -d

Structura de baza e simpla: containerul de server serveste UI-ul si API-ul, worker-ul proceseaza task-urile in fundal, iar Postgres si Redis tin starea si coada de job-uri. Nu e un binar unic, e un mic stack de servicii care trebuie sa functioneze impreuna, si asta merita luat in calcul cand estimezi resursele necesare si complexitatea operationala.

# permite doar traficul HTTPS/HTTP necesar accesului la authentik
ufw allow 80/tcp
ufw allow 443/tcp

# in timpul configurarii initiale, ia in calcul sa restrictionezi
# accesul la interfata de administrare doar de la IP-urile tale
# (regula suplimentara pe portul admin sau proxy invers cu allowlist),
# apoi relaxeaza dupa ce ai activat MFA pentru contul de admin

Daca vrei sa nu te ocupi tu de partea de sistem de operare, firewall si mentenanta a serverului, administrarea serverelor e exact pentru genul asta de treaba: te ocupi tu de configurarea authentik, ne ocupam noi de restul.

Tipare de configurare care merita stiute

E tentant sa lasi flow-ul default de login asa cum vine din instalare, dar merita sa te opresti si sa te gandesti ce etape vrei cu adevarat: identificare prin email sau username, verificare parola, apoi MFA obligatoriu pentru toti sau doar pentru un anumit grup (de exemplu adminii). Fiindca fiecare etapa e un obiect separat pe care il poti reordona sau conditiona, poti construi un flow diferit pentru utilizatori interni fata de conturi externe sau de test, fara sa dublezi toata logica.

Multe instrumente interne (dashboard-uri, utilitare de monitorizare, panouri de status) nu au niciun mecanism de autentificare nativ, pur si simplu presupun ca oricine ajunge la ele are voie sa fie acolo. Provider-ul de forward-auth din authentik rezolva exact problema asta: pui reverse-proxy-ul sa verifice sesiunea la authentik inainte sa lase cererea sa treaca mai departe, iar aplicatia din spate nu stie nici macar ca exista un strat de auth in fata ei.

Alege OIDC, SAML sau LDAP in functie de ce stie aplicatia, nu de preferinta ta

Nu exista un protocol “cel mai bun” universal, exista doar ce suporta aplicatia tinta. Aplicatiile moderne, web-native, vorbesc aproape mereu OIDC, mai rar SAML (frecvent in medii enterprise sau educationale). Serviciile mai vechi sau echipamentele de retea vorbesc adesea doar LDAP. Inainte sa configurezi un provider nou in authentik, verifica documentatia aplicatiei respective, nu invers.

Impune politica de MFA dintr-un singur loc, nu per aplicatie

Unul dintre cele mai mari castiguri ale unui IdP centralizat e ca poti impune MFA (TOTP sau WebAuthn/passkeys) la nivelul flow-ului de login, o singura data, si politica se aplica automat tuturor aplicatiilor care folosesc authentik ca provider. Nu mai trebuie sa configurezi MFA separat in fiecare aplicatie, cu riscul sa uiti una si sa ramana o poarta deschisa.

Unde authentik nu e raspunsul potrivit

Sa fim directi: authentik e un stack mai greu decat pare la prima vedere. Django plus worker plus PostgreSQL plus Redis inseamna patru piese care trebuie sa functioneze impreuna, monitorizate si actualizate, fata de un instrument gen fisier de configurare plus binar unic. Daca tot ce iti trebuie e un forward-auth simplu in fata a cateva aplicatii self-hosted, fara SAML, fara SCIM, fara RADIUS, atunci complexitatea suplimentara probabil nu isi justifica costul operational.

Flexibilitatea motorului de flows si stages are si ea un cost: curba de invatare nu e neglijabila. Nu e un sistem “configurezi in cinci minute si uiti de el”, trebuie sa intelegi cum se compun etapele si cum interactioneaza politicile inainte sa te simti confortabil sa modifici ceva in productie.

Si daca ai deja un homelab mic, cu putine aplicatii si fara cerinte de protocoale multiple, un instrument mai simplu iti poate acoperi 90% din nevoie cu mult mai putina munca de operare. Nu tot ce merita facut merita facut cu cel mai complet instrument disponibil.

Alternative pe care le-am luat in calcul

Authelia e alternativa cea mai directa: mai usoara, un singur binar, configurare prin fisier YAML, gandita in principal pentru forward-auth SSO in fata unui set de aplicatii self-hosted. Cum am mentionat mai sus, e exact ce ruleaza intern la DreamServer, tocmai pentru simplitatea operationala. Nu are ambitiile de protocol ale authentik (fara SAML nativ, fara SCIM, fara RADIUS), dar pentru multe cazuri de utilizare acopera exact ce ai nevoie, fara balastul suplimentar.

Keycloak e la polul opus in privinta maturitatii enterprise: un provider de identitate bazat pe Java, cu o acoperire de protocoale la fel de larga ca authentik, dar cu amprenta lui proprie de JVM, mai grea, si un model de administrare diferit, mai apropiat de lumea enterprise clasica. Daca vii deja dintr-un ecosistem heavy pe Java sau ai nevoie de integrari specifice enterprise, merita luat in calcul.

Ory merita mentionat pentru o abordare diferita: un stack de identitate componentizat, gandit mai mult developer-first si API-first, unde iei bucatile de care ai nevoie (Kratos pentru identitate, Hydra pentru OAuth2/OIDC, etc.) in loc de un singur monolit cu UI de administrare. Are sens daca construiesti produsul tau si vrei control fin din cod, mai putin daca vrei ceva gata de administrat prin UI din prima zi.

Deci, sa-l rulezi?

Daca ai nevoie de acoperire larga de protocoale (SAML pentru un partener enterprise, LDAP pentru un NAS vechi, RADIUS pentru VPN, OIDC pentru restul), sau vrei fluxuri de auto-inregistrare si recuperare parola configurabile, sau ai o gramada de aplicatii eterogene pe care vrei sa le pui in spatele unui singur forward-auth, authentik e o alegere solida si matura. Daca in schimb vrei ceva mai usor de operat, cu mai putine piese mobile, si acoperirea de protocoale nu e o cerinta reala pentru tine, ia in calcul Authelia inainte sa te arunci in Django plus worker plus Postgres plus Redis.

Oricare ar fi alegerea, un VPS cu resurse dedicate si control complet asupra retelei e locul potrivit sa il rulezi, iar daca preferi sa nu te ocupi tu de partea de sistem, administrarea serverelor e acolo exact pentru asta.