GSSO — Platforma gStack de identitate și autentificare unică (Single Sign-On) — Caiet de sarcini

Acest conținut nu este încă disponibil în limba selectată.


Cod document	SPEC-GSSO-2026 / Raportul 00
Versiune	0.1-draft (sursa EN, text care prevalează)
Data	2026-10-05
Statut	Proiect — deschis pentru revizuire; niciun ADR acceptat încă
Rapoarte însoțitoare	01 ADR · 02 Cerințe · 03 Consumatori și contract · 04 Documentație tehnică · 05 Foaie de parcurs
Design	`gsso.dc.html` (sursa inițială: `gstyle/design/src/GStack/GSSO.dc.html`, publicat la `s3.eu-west-1.amazonaws.com/gstack.awsarhitect.me/Sistem+GStack/GSSO.dc.html`)

Istoricul reviziilor

Versiune	Data	Modificări
0.1-draft	2026-10-05	Caiet de sarcini inițial: scop, problemă, domeniu de aplicare, actori, glosar, prezentare generală a arhitecturii, principii, AC-001..030, Q-GSSO-1..14

Convenții de lectură

GSSO este denumirea platformei. Scrieți „GSSO” în orice text destinat utilizatorului; „Keycloak” denumește doar motorul de identitate încorporat.
Identificatori: GSSO-ADR-nnn (decizii, raportul 01), GSSO-FR-nnn și GSSO-NFR-<AREA>-nnn (cerințe, raportul 02), AC-nnn (criterii de acceptanță, prezentul raport), Q-GSSO-n (întrebări deschise, prezentul raport), fazele S0..S5 (raportul 05).
Identificatorii nu se renumerotează niciodată. Un rând modificat este marcat [REVISED date], un rând perimat [WITHDRAWN date] motiv, iar identificatorii noi se adaugă la sfârșitul seriei lor.
Termenii de domeniu sunt în limba română (Platforma, AtribuireAcces, RolPlatforma…) în toate limbile; vocabularul de framework rămâne în limba engleză.
CAP-GSSO-nn sunt capabilitățile solicitate de aplicațiile consumatoare (raportul CRM 03 §4.1 și pachetele gDocFlow, gTenders, gFlow, gInsight).
CU-* sunt cerințele universale gStack; NFRQnn sunt codurile nefuncționale din caietul de sarcini (saas_drumuri/docs/reports/02-cerinte-functionale-nefunctionale.md).

Setul de rapoarte

#	Raport	Conținut
00	Caiet de sarcini (prezentul document)	scop, problemă, obiective, domeniu de aplicare, actori, glosar, conformitate, arhitectură, principii, criterii de acceptanță, întrebări deschise
01	ADR	GSSO-ADR-001..014
02	Cerințe	GSSO-FR-, GSSO-NFR-, trasabilitate către CAP-GSSO, CU-*, NFRQ
03	Consumatori și contract	fiecare aplicație gStack, modelul ei actual de autentificare și calea de migrare; API, evenimente, starter, conectare
04	Documentație tehnică	vederi C4, componente, model de date, fluxuri, modelul de realm-uri, securitate, implementare, testare
05	Foaie de parcurs	fazele S0–S5 cu porți de ieșire, MVP, riscuri, dependențe

1. Scop

GSSO este platforma comună gStack de identitate, autentificare, autorizare și autentificare unică (PaaS). Ea oferă fiecărui SaaS gStack (Interdicții, Cancelaria, gDocs, gRegistry, Drumuri, CRM, gDocFlow, gTenders…) și fiecărui PaaS (GLog, GNotify, gStorage, gFlow, portalul GDS…) un singur loc pentru a:

autentifica personalul, cetățenii și serviciile (OIDC/OAuth 2.1, SAML 2.0, federare MPass/eID, federare AD/LDAP, MFA);
înregistra platformele și serviciile, împreună cu clienții lor și rolurile pe care le expun;
autoriza, prin atribuirea de roluri unui anumit utilizator pe o anumită platformă, opțional limitat la o unitate organizațională și la o perioadă de valabilitate, cu cerere și aprobare;
sincroniza acest model guvernat în motorul de identitate și detecta drift-ul;
audita în GLog fiecare autentificare, token, modificare administrativă și atribuire;
opera realm-urile (tenanții), utilizatorii, sesiunile, credențialele și politicile de autentificare dintr-o consolă GDS.

GSSO este construit deasupra Keycloak 26.6.3 existent (https://sso.gstack.esempla.systems). Keycloak rămâne mediul de execuție al identității: credențiale, sesiuni, token-uri, MFA și federare. GSSO adaugă ceea ce îi lipsește lui Keycloak pentru o platformă guvernamentală:

un catalog de servicii;
un ciclu de viață guvernat al atribuirilor;
reconcilierea stării dorite;
o pistă de audit doar cu adăugare (append-only);
un kit standard de integrare;
o consolă în sistemul de design gStack.

2. Descrierea problemei

Situația actuală, așa cum a fost constatată la 2026-10-05:

Nicio platformă, doar un server. Keycloak 26.6.3 rulează ca un container configurat manual pe gazda demo partajată. Nu există infrastructură ca cod, export de realm, temă personalizată și nicio copie de rezervă a configurației în vreun depozit.
Un singur realm partajat, cu clienții tuturor aplicațiilor. Realm-ul interdictii conține interdictii-web, gregistry-web, glog-web, glog-ingest, gstack-platform, cancelarie și alții. Un realm denumit după un singur SaaS este, în practică, realm-ul personalului gStack.
Realm-uri referite, dar nereconciliate. Codul face referire la realm-urile gdocs, gnotify, gstorage, gstack și ultra. Doar gstorage este înregistrat ca fiind creat; gnotify este înregistrat ca lipsă. Nimic nu indică ce realm-uri ar trebui să existe.
Patru modele de integrare inconsecvente:
- A, autentificare dublă: aplicația emite propriul JWT HS512 după autentificarea în Keycloak (interdictii, gdocs, gnotify).
- B, resource server veritabil: aplicația validează direct token-urile Keycloak (gregistry, glog, cancelarie).
- C, doar JWT local, plus MPass SAML: drumuri.
- D, doar la nivel de design: CRM, gFlow, gDocFlow, gTenders. Rolurile se află parțial în Keycloak, parțial în bazele de date ale aplicațiilor.
Roluri grosiere. Există doar rolurile de realm ROLE_ADMIN și ROLE_USER. Ele sunt partajate de toate aplicațiile, astfel încât un administrator al unei aplicații este administrator al tuturor.
Nicio guvernanță a accesului. Atribuirile se fac manual în consola de administrare Keycloak. Nu există cerere, aprobare, expirare, motiv și nici o vedere de tipul „cine ce poate face pe care platformă”.
Niciun audit utilizabil. Evenimentele Keycloak nu sunt stocate durabil și nici redirecționate către GLog. Indicatorii tabloului de bord din design (autentificări în 24 h, autentificări eșuate, mixul metodelor de autentificare) nu pot fi produși.
Capabilități lipsă solicitate de consumatori:
- CAP-GSSO-01: realm corporativ și clienți per microserviciu.
- CAP-GSSO-02: AD/LDAP și TOTP per rol.
- CAP-GSSO-03: lista sesiunilor și încheierea forțată a acestora.
- CAP-GSSO-04: revocare ≤ 60 s și claim-uri de unitate organizațională.
- CAP-GSSO-06: provizionarea automatizabilă a clienților.
- CAP-GSSO-07: token exchange.
Fragilitate operațională. Certificatul TLS al sso. a expirat la 2026-09-23 și a blocat toate autentificările, iar secretele de administrare sunt păstrate în notițe în text clar.

3. Obiective și criterii de succes

#	Obiectiv	Criteriu de succes
G-1	O singură autentificare pentru toate aplicațiile gStack ale personalului	Un utilizator autentificat în orice aplicație a personalului deschide orice altă aplicație a personalului fără o a doua solicitare de parolă (AC-010)
G-2	Autorizare la nivel de platformă	Rolurile au spațiu de nume per platformă (`CRM_ADMIN`, `INTERDICTII_EMITENT`…); un administrator al unei platforme nu are drepturi pe alta (AC-012)
G-3	Acces guvernat	Fiecare atribuire de rol are un solicitant, un aprobator (pentru rolurile sensibile), un motiv, o valabilitate și o pistă de audit (AC-013..016)
G-4	Configurație ca cod	Realm-urile, clienții, rolurile, mapper-ele, fluxurile și tema sunt reproductibile din depozit pe un Keycloak gol (AC-005)
G-5	Drift vizibil	O modificare făcută direct în consola de administrare Keycloak este detectată și raportată într-un singur ciclu de reconciliere (AC-008)
G-6	Integrare standard	O aplicație nouă se integrează cu o singură dependență starter și trei setări; nicio aplicație nu emite propriile token-uri (AC-020)
G-7	Audit complet	Fiecare autentificare, eșec, emitere de token pentru conturi de serviciu, modificare administrativă și tranziție a unei atribuiri apare în GLog cu actorul, realm-ul, IP-ul și ora (AC-017)
G-8	Capabilitățile consumatorilor	CAP-GSSO-01, 02, 03, 04, 06 și 07 sunt livrate (trasabilitate în raportul 02 §III)

4. Părți interesate și consumatori

Parte interesată	Interes
Echipa platformei gStack	Deține GSSO: construiește, operează, actualizează Keycloak, publică starter-ul
Proprietarii platformelor (aplicațiilor)	Își înregistrează aplicația, îi definesc rolurile, aprobă atribuirile pentru aplicația lor
Ofițerul de securitate / auditorul	Revizuiește accesul, aprobă rolurile sensibile, citește rapoartele de audit și de autentificare
Administratorii IAM ai instituțiilor	Gestionează utilizatorii realm-ului sau ai unității lor organizaționale
Utilizatorii finali din personal	O singură autentificare, MFA, autoservire pentru credențiale și sesiuni
Cetățenii	Autentificare în portalurile publice prin MPass/eID
Aplicațiile consumatoare	Token-uri cu claim-uri stabile, conturi de serviciu, API de administrare pentru provizionare

Consumatorii sunt enumerați în raportul 03:

SaaS: interdictii, cancelaria, gdocs, gregistry, drumuri, CRM, gDocFlow, gTenders.
PaaS: glog, gnotify, gstorage, gflow, gportal/GDS, documentația platformei/RAG.
Mobil: gsso_mob (GovSign).
Site-uri whitelabel: ultra-, bts-, esempla-*.

5. Domeniu de aplicare

5.1 Inclus în domeniu

Keycloak 26.6.x ca motor de identitate încorporat, implementat din depozitul GSSO cu:
- o configurație de bază a realm-urilor (gstack, cetatean, șablonul de tenant);
- extensiile Keycloak ale GSSO (event listener, protocol mappers);
- temele GDS de autentificare, de cont și de e-mail în RO/RU/EN.
Gestionarea realm-urilor (tenanților): creare din șablon, activare/dezactivare, branding, federare (broker) și politici. Consola are un comutator de realm.
Catalogul de servicii: platforme și servicii (SaaS/PaaS) cu proprietari, URL-uri de bază, accente, clienții lor (public PKCE, confidential, bearer-only, cont de serviciu) și rolurile pe care le expune fiecare platformă (roluri de realm sau de client, compozite, sensibile).
Gestionarea utilizatorilor:
- creare, invitare, activare/dezactivare, editarea atributelor (IDNP, unitate organizațională, limbă);
- resetarea credențialelor, acțiuni obligatorii (required actions);
- vizualizarea și încheierea sesiunilor;
- vizualizarea și eliminarea credențialelor MFA;
- căutare în toate realm-urile printr-o proiecție.
Atribuiri de acces (AtribuireAcces): cerere → aprobare/respingere → activă → revocare/expirare. Atribuirile sunt per utilizator × rol de platformă × unitate organizațională opțională × perioadă de valabilitate, cu aprobare după principiul „patru ochi” pentru rolurile sensibile, atribuire în masă și notificări de expirare.
Unități organizaționale: un arbore, emis ca claim-ul org_unit.
Politici de autentificare per realm:
- metode: parolă, OTP, WebAuthn/passkey, QR cross-device, client credentials, broker, magic link;
- politica de parole și duratele sesiunilor;
- MFA obligatoriu pentru rolurile sensibile;
- fluxul de browser afișat ca pași ordonați.
Reconcilierea stării dorite în Keycloak: joburi idempotente, reîncercări, o reconciliere completă periodică, raportarea sau impunerea drift-ului per realm și adoptarea realm-urilor existente.
Evenimente:
- evenimentele de utilizator și de administrare Keycloak, prin extensie, către Kafka;
- evenimentele proprii GSSO, doar cu adăugare;
- redirecționarea către GLog;
- tabloul de bord: KPI, autentificări în 24 h, eșecuri, mixul metodelor de autentificare, evenimente de securitate recente.
API în zonele GovStack: admin (consola), app (aplicațiile consumatoare: autoînregistrare, căutarea utilizatorilor, cerere de atribuire, încheierea sesiunilor), plus endpoint-urile operaționale.
Kitul de integrare: gsso-spring-boot-starter, @gstack/gsso-angular, precum și un runbook și o listă de verificare pentru conectare.
Configurarea token exchange (RFC 8693) pentru apeluri în numele utilizatorului (on-behalf-of) între aplicații.
Calea de migrare pentru fiecare aplicație existentă de la modelele A/B/C la standard, inclusiv adoptarea realm-ului interdictii.

5.2 Exclus din domeniu

Reimplementarea unui furnizor de identitate. Autentificarea, token-urile, credențialele și federarea rămân în Keycloak (GSSO-ADR-001).
Autorizarea de business în interiorul unei aplicații (vizibilitate la nivel de rând, proprietatea asupra obiectelor). GSSO furnizează roluri și claim-uri, iar aplicația decide.
Semnătura electronică calificată (MSign / semnarea prin gsso_mob). GSSO autentifică; semnarea este un serviciu separat.
Un sistem de resurse umane. Angajații și structura organizațională pot fi importate, dar sursa de referință HR rămâne în afară.
Trecerea efectivă în producție (cut-over) a aplicațiilor existente și a realm-ului partajat. Aceasta este planificată în raportul 05 și executată doar cu aprobarea explicită a proprietarului.
Provider-ul Terraform și operatorul Kubernetes. Acestea sunt opționale în S5.

6. Actori și roluri

Actor	Rol GSSO	Poate
Administratorul platformei	`GSSO_ADMIN`	Totul, în toate realm-urile; gestionează realm-urile, șabloanele, setările reconcilierii
Administratorul de realm	`GSSO_REALM_ADMIN` (limitat la un realm)	Utilizatorii, clienții, rolurile, politicile unui singur realm
Proprietarul platformei	`GSSO_PLATFORM_OWNER` (limitat la o platformă)	Definește rolurile și clienții platformei, aprobă atribuirile pe acestea
Aprobatorul / ofițerul de securitate	`GSSO_APPROVER`	A doua aprobare pentru rolurile sensibile; revizuiri ale accesului
Auditorul	`GSSO_AUDITOR`	Doar citire: catalog, atribuiri, evenimente, rapoarte
Helpdesk	`GSSO_HELPDESK`	Caută utilizatori, resetează credențiale, deblochează, încheie sesiuni; nu modifică roluri
Utilizatorul final	—	Autoservire prin consola de cont Keycloak (temă GDS): parolă, MFA, sesiuni; solicită acces
Aplicația consumatoare	cont de serviciu cu scope-ul `gsso:app`	Se autoînregistrează (când este permis), caută utilizatori, solicită atribuiri, încheie sesiuni
Reconcilierea	contul de serviciu `gsso-reconciler` în `master`	Aplică starea dorită în Keycloak (nu este folosit niciodată de persoane)

7. Glosar

Termen	Semnificație
Realm	Un tenant Keycloak: utilizatori, clienți, roluri și politici izolate. Entitatea GSSO `Realm`
Platforma	Un SaaS sau PaaS gStack înregistrat în catalog (`crm`, `glog`…)
ClientAplicatie	Un client OIDC/SAML al unei platforme: SPA (public + PKCE), backend (confidential sau bearer-only), cont de serviciu
RolPlatforma	Un rol expus de o platformă, prefixat cu codul acesteia (`CRM_ADMIN`). Poate fi compozit sau sensibil
AtribuireAcces	O atribuire: un utilizator primește un rol de platformă, opțional pentru o unitate organizațională și o perioadă de valabilitate
UnitateOrganizationala	Un nod din arborele unităților organizaționale, emis ca claim-ul `org_unit`
PoliticaAutentificare	Politica de autentificare a unui realm: metode, politica de parole, MFA, duratele sesiunilor
JobSincronizare	O unitate de lucru de reconciliere (creare/actualizare/ștergere în Keycloak) sau o constatare de drift
ProiectieUtilizator	Modelul de citire, cu posibilitate de căutare, al GSSO pentru un utilizator Keycloak
EvenimentGsso	Un eveniment de audit doar cu adăugare (autentificare, administrare, atribuire, sincronizare)
Starea dorită	Configurația declarată în GSSO; Keycloak este adus în concordanță cu ea
Drift	O diferență între starea dorită și Keycloak
Adoptare	Importul unic al configurației unui realm existent în catalog
Sesiune SSO	Sesiunea de browser Keycloak partajată de toți clienții unui realm
BFF	Backend-for-frontend: gateway-ul JHipster păstrează token-urile pe server; SPA-ul primește un cookie de sesiune
MPass	Serviciul guvernamental de autentificare al Moldovei (SAML), intermediat (brokered) de realm-ul `cetatean`
IDNP	Numărul de identificare de stat al persoanei fizice (13 cifre), stocat ca atribut al utilizatorului

8. Conformitate

Domeniu	Referință	Răspunsul GSSO
Date cu caracter personal	Legea 133/2011 (RM), aliniată la GDPR	Atribute minime ale utilizatorului; IDNP accesibil doar rolurilor autorizate; ștergerea din proiecție la ștergerea utilizatorului; politică de retenție a auditului
Securitatea informației	NFRQ56–66 (privilegiu minim, OWASP Top 10, expirarea sesiunii, auditul securității)	Roluri cu spațiu de nume per platformă, principiul „patru ochi” pentru rolurile sensibile, politică MFA, durate ale sesiunilor, toate acțiunile administrative auditate
Audit	Cerința criminalistică din Legea 133, CU-AUDIT-*	`EvenimentGsso` doar cu adăugare, cu lanț de hash-uri; redirecționare către GLog WORM
Interoperabilitate	GovStack Identity BB, CU-API-003..006	OIDC/OAuth 2.1, SAML, RFC 8693, RFC 7807, zonele API GovStack
Identitatea guvernamentală	MPass / eID	Intermedierea identității (identity brokering) în realm-ul `cetatean`
Accesibilitate	NFRQ39 (WCAG 2.1 AA)	Componente GDS în consolă și în temele de autentificare
Limbi	NFRQ38	RO (nativ), RU, EN în consolă, teme și e-mailuri
AI Act	Reg. (UE) 2024/1689	Nu este un sistem de IA; nicio decizie automatizată privind accesul (triere în raportul 01, GSSO-ADR-014)

9. Arhitectura de nivel înalt

flowchart LR
  subgraph Users [Utilizatori]
    adm[Administrator IAM / proprietar / auditor]
    staff[Utilizator din personal]
    cit[Cetățean]
  end
  subgraph GSSO
    web[gsso-web<br/>Angular + GDS]
    gw[gsso-gateway<br/>JHipster BFF]
    srv[gsso<br/>microserviciu JHipster]
    db[(PostgreSQL gsso)]
    kc[Keycloak 26.6<br/>+ extensii gsso + teme GDS]
    kdb[(PostgreSQL keycloak)]
  end
  kafka[[Kafka]]
  glog[GLog]
  gnotify[GNotify]
  apps[gStack SaaS / PaaS]
  mpass[MPass / eID]
  ldap[AD / LDAP]

  adm --> web --> gw --> srv
  gw -. autentificare OIDC .-> kc
  srv -- Admin REST --> kc
  srv --- db
  kc --- kdb
  kc -- evenimente --> kafka --> srv
  srv -- audit --> glog
  srv -- e-mailuri de expirare / aprobare --> gnotify
  staff -- OIDC --> kc
  cit -- OIDC --> kc -- broker SAML --> mpass
  kc -- federare --> ldap
  apps -- token-uri / JWKS --> kc
  apps -- api/v1/app --> gw

gsso păstrează modelul guvernat și îl reconciliază în Keycloak prin Admin REST API, folosind contul de serviciu gsso-reconciler.
Keycloak publică evenimentele de utilizator și de administrare, prin extensia event-listener a GSSO, în topic-ul Kafka gsso.kc-events.v1.
gsso consumă aceste evenimente, le stochează, actualizează proiecția utilizatorilor și tabloul de bord și le redirecționează către GLog.
Aplicațiile nu apelează niciodată API-ul de administrare al Keycloak. Ele folosesc token-uri și JWKS de la Keycloak și api/v1/app de la GSSO.

10. Principii

Keycloak este mediul de execuție, GSSO este planul de control. Nicio logică de credențiale, sesiuni sau token-uri nu este reimplementată (GSSO-ADR-001).
Starea dorită este declarată în GSSO și adusă în concordanță în Keycloak. Editările manuale în Keycloak constituie drift (GSSO-ADR-004).
Un singur realm al personalului pentru SSO real. Toate aplicațiile gStack destinate personalului sunt clienți ai realm-ului gstack. Cetățenii se află în cetatean. Tenanții izolați primesc propriul realm (GSSO-ADR-002).
Rolurile aparțin platformelor. Fiecare rol este <PLATFORM>_<ROLE>. Singurele roluri transversale sunt GSSO_* și rolul implicit ROLE_USER (GSSO-ADR-005).
Accesul se atribuie, nu se editează. Mapările de roluri pentru persoane se creează doar prin AtribuireAcces, astfel încât fiecare are un solicitant, un aprobator când este necesar, o perioadă de valabilitate și un motiv (GSSO-ADR-006).
Evenimentele sunt doar cu adăugare și ies din platformă. Totul se află în EvenimentGsso și în GLog (GSSO-ADR-007).
Un singur mod de integrare. Aplicațiile sunt clienți OAuth2 sau resource server-e care validează token-urile GSSO, prin starter. Nicio aplicație nu emite propriile token-uri și nu stochează parole (GSSO-ADR-009).
Configurație ca cod. Configurațiile de bază ale realm-urilor, extensiile și temele se află în git. Keycloak-ul de producție poate fi reconstruit din depozit plus o copie de rezervă a bazei de date (GSSO-ADR-011).
Privilegiu minim și principiul „patru ochi” pentru rolurile sensibile, MFA pentru rolurile sensibile, sesiuni scurte pentru administratori.
Stiva DEV-PLAYBOOK: microserviciu + gateway JHipster 9.1.0, OAuth2, Maven, PostgreSQL, Kafka, ro,ru,en, un SPA Angular separat pe GDS (GSSO-ADR-010).

11. Rezumatul cerințelor și criteriile de acceptanță

11.1 Grupuri de cerințe (detalii în raportul 02)

Grup	Identificatori	Număr
Realm-uri și tenanți — FR-RLM	GSSO-FR-001..010	10
Catalogul de servicii — FR-CAT	GSSO-FR-011..022	12
Utilizatori și sesiuni — FR-USR	GSSO-FR-023..036	14
Roluri și atribuiri — FR-GRT	GSSO-FR-037..052	16
Unități organizaționale — FR-ORG	GSSO-FR-053..056	4
Autentificare și federare — FR-AUT	GSSO-FR-057..070	14
Reconciliere — FR-SYN	GSSO-FR-071..080	10
Evenimente și audit — FR-EVT	GSSO-FR-081..090	10
Tablou de bord și rapoarte — FR-RPT	GSSO-FR-091..096	6
API pentru aplicații și kit de integrare — FR-API	GSSO-FR-097..108	12
Consola (UI) — FR-UI	GSSO-FR-109..116	8
Nefuncționale — NFR-*	PERF, CAP, AVL, SEC, TEN, OBS, OPS, CMP, DATA	44

11.2 Criterii de acceptanță

ID	Criteriu
AC-001	`docker compose up` al stivei GSSO pe o gazdă goală produce un Keycloak cu realm-urile `gstack` și `cetatean`, tema GDS de autentificare în RO/RU/EN și extensiile GSSO încărcate
AC-002	Un administrator se autentifică în consola GSSO prin `gsso-gateway` (realm-ul `gstack`, clientul `gsso-console`); SPA-ul nu deține niciun token
AC-003	Crearea unui realm din șablonul de tenant în consolă îl creează în Keycloak cu fluxurile, mapper-ele și tema de bază
AC-004	Comutatorul de realm limitează fiecare ecran al consolei la realm-ul selectat; un `GSSO_REALM_ADMIN` vede doar realm-ul său
AC-005	Ștergerea realm-ului `gstack` într-un Keycloak de test și rularea unei reconcilieri complete recreează clienții, rolurile, mapper-ele și politicile gestionate de catalog
AC-006	Înregistrarea unei platforme cu 2 clienți și 3 roluri le creează în Keycloak în 10 s
AC-007	Reconcilierea este idempotentă: rularea ei de două ori nu produce nicio modificare și niciun duplicat
AC-008	Un rol creat manual în consola de administrare Keycloak apare ca `DRIFT` într-un singur ciclu de reconciliere; în modul `enforce` este eliminat
AC-009	Adoptarea unui realm existent importă clienții, rolurile și mapările de roluri ale acestuia în catalog fără a modifica Keycloak
AC-010	Un utilizator autentificat în aplicația A (realm-ul `gstack`) deschide aplicația B fără solicitare de parolă; deconectarea din consolă încheie sesiunea SSO
AC-011	Token-ul de acces conține `roles` (listă plată), `org_unit`, `locale` și, când este permis, `idnp`; `sub` este un UUID
AC-012	Un utilizator cu `CRM_ADMIN` nu primește nicio autoritate `GLOG_` sau `INTERDICTII_` în GLog sau în Interdicții
AC-013	O cerere de atribuire pentru un rol nesensibil, aprobată de proprietarul platformei, devine `ACTIVA`, iar rolul apare în următorul token al utilizatorului
AC-014	O atribuire pentru un rol sensibil necesită doi aprobatori distincți; solicitantul nu își poate aproba propria cerere
AC-015	O atribuire cu `validPana` în trecut este expirată de planificator, maparea este eliminată, iar utilizatorul este notificat
AC-016	Revocarea unei atribuiri elimină maparea și încheie sesiunile utilizatorului pe clienții afectați; rolul lipsește din token-uri în 60 s
AC-017	Autentificarea reușită, autentificarea eșuată, modificarea administrativă și tranziția unei atribuiri apar fiecare în lista de evenimente a consolei și în GLog, cu actorul, realm-ul, IP-ul și ora
AC-018	`UPDATE` și `DELETE` pe `eveniment_gsso` sunt respinse de repository și de un trigger al bazei de date
AC-019	Tabloul de bord afișează realm-urile, clienții, utilizatorii, sesiunile active, autentificările pe intervale de 2 h în ultimele 24 h (reușite/eșuate) și mixul metodelor de autentificare
AC-020	O aplicație Spring Boot de exemplu, doar cu `gsso-spring-boot-starter` și 3 setări, validează token-urile GSSO și mapează `roles` la autorități
AC-021	O aplicație cu scope-ul `gsso:app` își autoînregistrează platforma, clienții și rolurile prin `POST /api/v1/app/platforme` (dacă autoînregistrarea îi este permisă)
AC-022	`DELETE /api/v1/app/utilizatori/{sub}/sesiuni` încheie sesiunile utilizatorului în 60 s
AC-023	Token exchange de la clientul `crm-gateway` către audiența `gdocflow` returnează un token pentru același utilizator, cu audiența țintă; o pereche neautorizată este refuzată
AC-024	OTP este obligatoriu la autentificare pentru un utilizator care deține orice rol sensibil; WebAuthn este acceptat ca alternativă
AC-025	Autentificarea cetățeanului pe un client `cetatean` este intermediată către un mock MPass SAML și creează sau leagă un utilizator după IDNP
AC-026	Listele de utilizatori, clienți, roluri, atribuiri și evenimente permit filtrare, sortare și paginare și răspund în limitele țintelor NFR-PERF
AC-027	Toate etichetele consolei sunt traduse în RO, RU și EN; nicio cheie netradusă nu este vizibilă (verificare `/gfront`)
AC-028	`/health/live`, `/health/ready` (include accesibilitatea Keycloak), `/metrics`, `/info`, `/api/v1/openapi.json` răspund; erorile sunt RFC 7807
AC-029	`/gsast` nu raportează nicio constatare de nivel înalt/critic fără o derogare acceptată; niciun secret în depozit
AC-030	Rularea de probă (dry-run) a migrării realm-ului interdictii produce un raport de mapare (clienți, roluri, utilizatori) fără nicio scriere în producție

12. Întrebări deschise

ID	Întrebare	Răspuns propus	Responsabil
Q-GSSO-1	Păstrăm realm-ul `interdictii` ca realm al personalului și îl redenumim doar la afișare, sau creăm `gstack` și migrăm?	Se creează `gstack`, se adoptă `interdictii` în regim doar citire, se migrează aplicație cu aplicație (raportul 05 S4)	Echipa platformei + proprietarii aplicațiilor
Q-GSSO-2	Integrarea MPass de producție: metadate SAML, certificate și conturi de test de la AGE?	Mock în S2, metadate reale când sunt disponibile	Instituția
Q-GSSO-3	Ce director AD/LDAP (per instituție) și federare doar citire sau cu scriere?	Doar citire, modul de editare `READ_ONLY`, per realm	IT-ul instituției
Q-GSSO-4	Ce roluri sunt sensibile în mod implicit?	Toate `_ADMIN`, `GSSO_` cu excepția `GSSO_AUDITOR`, rolurile marcate de proprietari	Ofițerul de securitate
Q-GSSO-5	Valabilitatea implicită a atribuirilor (nedeterminată sau, de exemplu, 12 luni cu reînnoire)?	12 luni pentru rolurile sensibile, nedeterminată pentru celelalte, cu revizuire anuală a accesului	Ofițerul de securitate
Q-GSSO-6	Cine poate aproba: doar proprietarul platformei sau și șeful unității organizaționale a utilizatorului?	Proprietarul platformei, plus aprobatorul pentru rolurile sensibile; șeful unității organizaționale opțional, per platformă	Proprietarii platformelor
Q-GSSO-7	Retenția evenimentelor de autentificare (baza de date GSSO vs GLog)?	90 de zile în GSSO, conform politicii GLog în GLog	DPO
Q-GSSO-8	Realm-ul cetățenilor `cetatean` face parte din domeniul de producție al acestei platforme sau ulterior?	Proiectat acum, în producție după ce MPass este disponibil	Produs
Q-GSSO-9	Autentificarea QR cross-device gsso_mob: implementată ca authenticator Keycloak (SPI) sau se păstrează endpoint-ul de aprobare per site?	Authenticator Keycloak în S5; păstrează o singură implementare pentru toate site-urile	Echipa platformei
Q-GSSO-10	Găzduire: rămâne pe gazda demo partajată sau trece pe ținta Kubernetes din playbook?	Docker compose pe gazda demo pentru S0–S3; chart Helm pentru țintă	DevOps
Q-GSSO-11	Ar trebui aplicațiile să păstreze un cont local de administrator de urgență („break-glass”)?	Fără parole locale; break-glass = un cont de urgență în realm-ul `master`, deținut de echipa platformei	Ofițerul de securitate
Q-GSSO-12	Autoînregistrarea platformelor prin API-ul `app`: permisă pentru toate aplicațiile sau doar pentru CI-ul echipei platformei?	Doar pentru clienții marcați explicit; ceilalți prin consolă	Echipa platformei
Q-GSSO-13	`idnp` în token-uri: întotdeauna, niciodată sau per client?	Per client, opțional (opt-in) printr-un client scope `idnp`, aprobat de DPO	DPO
Q-GSSO-14	Cadența actualizărilor Keycloak (versiuni minore 26.x) și cine este responsabil?	Trimestrial, echipa platformei, cu suita de teste a configurației de bază a realm-urilor drept poartă	Echipa platformei