SSO enterprise — AiHummer Documentație

AiHummer autentifică administratorii și utilizatorii împotriva furnizorului tău de identitate. Controlul principal, de pe calea de producție, este OIDC, care protejează API-ul de administrare; sunt implementate de asemenea SAML, LDAP/AD și provisioning SCIM, alături de autentificare locală pentru configurații fără un IdP extern.

OIDC protejează API-ul de administrare

OIDC este deny-by-default și este controlul care protejează /v1/admin/*. Configurează-l cu AIHUMMER_OIDC_ISSUER (și setările de client aferente).

# /home/.aihummer/etc/gateway.env
AIHUMMER_OIDC_ISSUER=https://idp.example.com/

Există un runbook oidc-setup (docs/runbooks/oidc-setup.md) care parcurge înregistrarea clientului și conectarea issuer-ului.

[!DANGER] Fără OIDC configurat, API-ul de administrare are încredere în antetele de dezvoltare pentru identitate. Acel mod este doar pentru dezvoltare locală — nu expune niciodată un endpoint de administrare la internet fără OIDC (sau o altă autentificare aplicată) în fața lui. Configurează AIHUMMER_OIDC_ISSUER înainte de orice implementare non-locală.

[!TIP] Suprapune OIDC cu lista de IP-uri permise și cheile API cu domeniu, astfel încât accesul de administrare să fie protejat de identitate, rețea și privilegiu împreună.

SAML

Single sign-on prin SAML este implementat, expunând endpointurile standard de furnizor de servicii:

Endpoint	Scop
`GET /saml/metadata`	Metadate de furnizor de servicii pentru IdP-ul tău.
`POST /saml/acs`	Assertion Consumer Service — primește răspunsul SAML.
`GET /saml/login`	Inițiază fluxul de login SAML.

[!NOTE] SAML este implementat, dar nu este pe deplin dovedit în direct împotriva fiecărui IdP. Tratează-l ca fiind disponibil și validează-l împotriva furnizorului tău specific de identitate înainte de a te baza pe el în producție.

LDAP / Active Directory

Autentificarea LDAP/AD este implementată pentru medii care autentifică utilizatorii împotriva unui server de director.

[!NOTE] Ca și în cazul SAML, LDAP/AD este implementat, dar nu este pe deplin dovedit în direct în toate configurațiile de director. Testează-l împotriva propriului tău director înainte de lansare.

Provisioning SCIM

SCIM permite IdP-ului tău să provisioneze și să deprovisioneze utilizatori automat, prin endpointurile standard SCIM v2 pentru utilizatori:

Endpoint	Scop
`GET /scim/v2/Users`	Listează / interoghează utilizatorii provisionați.
`POST /scim/v2/Users`	Creează un utilizator.
`GET /scim/v2/Users/{id}`	Citește un singur utilizator.
`PUT /scim/v2/Users/{id}`	Actualizează un utilizator.
`DELETE /scim/v2/Users/{id}`	Deprovisionează un utilizator.

Provisioningul prin SCIM menține directorul de utilizatori sincronizat cu IdP-ul tău, astfel încât noii angajați și plecările să fie reflectate fără muncă manuală de administrare.

Autentificare locală

Când nu există un IdP extern, AiHummer suportă autentificarea locală. Pe o bază de date nouă, gateway-ul tipărește o parolă admin unică în jurnal la prima pornire; autentifică-te și schimb-o imediat. Autentificarea locală este potrivită pentru implementări mici sau izolate, dar pentru organizațiile cu un IdP, OIDC rămâne calea de producție recomandată.

Alegerea unei abordări

Mecanism	Cel mai potrivit pentru	Stare
OIDC	Protejarea API-ului de administrare în orice implementare non-locală	Calea de producție recomandată
SAML	Întreprinderi standardizate pe SSO SAML	Implementat; validează împotriva IdP-ului tău
LDAP / AD	Autentificare bazată pe director	Implementat; validează împotriva directorului tău
SCIM	Provisioning automat de utilizatori din IdP	Implementat (SCIM v2 Users)
Autentificare locală	Implementări mici sau izolate fără un IdP	Încorporat

Unde mergi mai departe

RBAC și chei API cu domeniu — autorizează identitățile pe care le autentifică IdP-ul tău.
Rețea, audit și air-gapped — pune o poartă pe accesul de administrare în funcție de rețea și păstrează o pistă de audit.
Vault de secrete — unde locuiesc credențialele și tokenurile.