Sari la conținut

GSSO — Foaie de parcurs

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

Cod documentSPEC-GSSO-2026 / Raportul 05
Versiune0.1-draft (sursa EN, text care prevalează)
Data2026-10-05
StatutProiect
Rapoarte însoțitoare00 RFP · 01 ADR · 02 Cerințe · 03 Consumatori și contract · 04 Documentație tehnică
VersiuneDataModificări
0.1-draft2026-10-05Fazele S0–S5, MVP, riscuri, dependențe
Etapa consumatoruluiCe necesită de la GSSOFaza GSSO
CRM F0 (fundația)CAP-GSSO-01: realm-ul gstack, crm-gateway, clienți de serviciu, locale, sub de tip UUIDS1
CRM F1+ / gDocFlow / gTendersCAP-GSSO-03, 07 (sesiuni, token exchange)S3
gFlow G1interogarea rol → utilizatori, principali de serviciu per aplicațieS3
gInsight (amânat)claim-urile org_unit (CAP-GSSO-04)S2
Consolidarea aplicațiilor existenteEliminarea modelelor A/CS4

Fiecare fază se încheie cu o poartă. În faza S0 nu se poate începe scrierea codului până când ADR-urile din raportul 01 nu sunt Acceptat (DEV-PLAYBOOK §4).

  • Se creează depozitul govtech/gstack/gsso, CLAUDE.md, gsso.jdl și test-scenarios.md și se acceptă ADR-urile.
  • keycloak/:
    • un Dockerfile pe 26.6.3;
    • configurațiile de bază gstack, cetatean și tenant-template prin keycloak-config-cli;
    • tema GDS de autentificare în RO/RU/EN. Modulul de extensii este doar un schelet în această fază.
  • deploy/docker-compose.yml cu Keycloak, două baze de date PostgreSQL și Kafka; docker-compose.test.yml.
  • Generarea JHipster 9.1.0 a gsso și gsso-gateway; scheletul gsso-web pe GDS, cu bara laterală și i18n. Versiunile sunt fixate.
  • Poartă: AC-001 și AC-002 trec local, ADR-urile sunt acceptate, iar /gsast este curat.

S1 — MVP-ul consolei și al catalogului (≈ 4 săptămâni)

Section titled “S1 — MVP-ul consolei și al catalogului (≈ 4 săptămâni)”
  • Realm-uri (registru, creare din șablon, comutator, limitare a vizibilității, adoptare în dry-run).
  • Platforme, clienți, roluri, clienți de serviciu în masă și mapper-e de audiență.
  • Utilizatori: listă, creare/invitare, editare, activare/dezactivare, credențiale, sesiuni, deblocare, proiecție.
  • Reconcilierea: joburi outbox, worker, reîncercare, reconciliere completă, drift REPORT/ENFORCE, ecranul de sincronizare.
  • Evenimentele proprii GSSO doar cu adăugare, încă fără ingestie din Kafka.
  • Ecranele din design Realm-uri, Aplicații, Utilizatori (panou lateral), Roluri și Sincronizare.
  • Poartă: AC-003..009, 026, 027 (parțial) și 028 trec. CAP-GSSO-01 este livrat local și în staging.
  • Atribuiri: ciclul de viață, principiul „patru ochi”, inbox-ul, expirarea și notificările, pachetele, unitățile organizaționale și rolurile limitate.
  • Event listener-ul Keycloak gsso-kafka, consumatorul, lanțul de hash-uri, redirecționarea către GLog, completarea retroactivă (back-fill) și tabloul de bord (KPI, autentificări în 24 h, evenimente, mixul metodelor de autentificare).
  • Politici de autentificare: ecranul metodelor, MFA condiționat de rolul sensibil, federarea LDAP, brokerul mock MPass în cetatean și branding-ul.
  • Publicatorul de revocări și raportul de acces.
  • Poartă: AC-010..019, 024, 025 trec. CAP-GSSO-02 și 04 sunt livrate.

S3 — Kitul de integrare și pilotul (≈ 3 săptămâni)

Section titled “S3 — Kitul de integrare și pilotul (≈ 3 săptămâni)”
  • gsso-spring-boot-starter și @gstack/gsso-angular.
  • api/v1/app (autoînregistrare, căutări, roluri, sesiuni, cereri de atribuire).
  • Permisiunile de token exchange.
  • Aplicația de exemplu și runbook-ul de conectare.
  • Aplicațiile pilot:
    • gregistry (modelul B): trece pe gstack și pe starter;
    • glog: starter și scope-uri, iar GSSO devine client de ingestie;
    • scheletul gateway-ului CRM.
  • Poartă: AC-020..023 trec, SSO funcționează între gsso-console + gregistry + glog, iar CAP-GSSO-03, 06 și 07 sunt livrate.

S4 — Migrarea aplicațiilor existente (≈ 6 săptămâni, aplicație cu aplicație)

Section titled “S4 — Migrarea aplicațiilor existente (≈ 6 săptămâni, aplicație cu aplicație)”
  • Preluarea în producție a Keycloak-ului activ (raportul 04 §11.1), cu aprobarea proprietarului și într-o fereastră de mentenanță.
  • Se adoptă realm-ul interdictii, apoi se decide Q-GSSO-1.
  • Se migrează aplicațiile cu modelul A (interdictii, gdocs, gnotify) și modelul C (drumuri: personalul în gstack, MPass în cetatean). Apoi gstorage (realm-ul gstorage → gstack), cancelarie, platform și gportal.
  • Se retrage ROLE_ADMIN; se șterg realm-urile perimate (gdocs, gnotify, gstorage, ultra) după migrare.
  • Se creează realm-urile tenant-* pentru site-urile whitelabel.
  • Poartă: AC-030; nicio aplicație nu emite token-uri și nu păstrează parole locale; realm-ul partajat conține doar platforme gstack.
  • Campanii de revizuire a accesului.
  • Reguli de separare a atribuțiilor (segregation of duties).
  • Raportul conturilor inactive.
  • Autentificarea QR cross-device ca authenticator Keycloak pentru gsso_mob.
  • Magic link.
  • Keycloak Organizations.
  • gsso-cli sau Terraform pentru conectarea din CI.
  • Consolidarea pentru producție a chart-ului Helm (Keycloak HA).
  • Autentificare bazată pe risc (doar pe bază de reguli, GSSO-ADR-014).

MVP-ul este S0 + S1 + tabloul de bord, evenimentele și atribuirile din S2, rulând local și pe gazda demo față de un Keycloak local sau de staging (nu de producție). Poate fi demonstrat prin:

  1. Cele 6 ecrane din design (Tablou de bord, Realm-uri, Aplicații, Utilizatori cu panou lateral, Roluri, Autentificare), plus Platforme, Atribuiri și Sincronizare, în RO/RU/EN.
  2. Înregistrarea unei platforme cu clienți și roluri, care apar apoi în Keycloak.
  3. O cerere de atribuire, aprobarea și revocarea ei, vizibile în token-ul utilizatorului și în evenimente.
  4. Un drift făcut manual în Keycloak, care este detectat și corectat.
  5. SSO între consola GSSO și o aplicație de exemplu.
#RiscImpactAtenuare
R1Preluarea Keycloak-ului activ blochează autentificarea în toate aplicațiileRidicatAceeași versiune, copie de rezervă a bazei de date, mai întâi doar înlocuirea imaginii, rollback = imaginea anterioară, fereastră de mentenanță, aprobarea proprietarului
R2Modificări ale Admin API sau ale SPI Keycloak la actualizăriMediuVersiune fixată 26.6.x; suita IT condiționează actualizările (NFR-OPS-004); adaptorul este izolat în KeycloakAdminGateway
R3Reconcilierea șterge obiecte create manualRidicatMarcajul gsso.managed; obiectele negestionate nu sunt șterse niciodată; IGNORE pentru realm-urile adoptate; rulări de probă
R4Realm-ul gstack este un punct unic de defectare pentru toate aplicațiile personaluluiRidicatKeycloak HA în arhitectura țintă; autentificările nu depind de GSSO, Kafka sau GLog (NFR-AVL-003)
R5Migrarea aplicațiilor cu modelul A este mai lentă decât s-a planificatMediuAliasuri de roluri în starter; clientul vechi păstrat în paralel pentru o versiune; câte o aplicație o dată
R6Reînnoirea TLS pe gazda demo este în continuare defectăRidicatCorectare înainte de S4; alertă de expirare a certificatului (NFR-AVL-006)
R7Accesul la MPass de producție întârzieMediuIdP mock; producția cetatean îl așteaptă (Q-GSSO-8)
R8Pașii de aprobare încetinesc administratoriiScăzutAtribuiri directe pentru rolurile nesensibile, pachete, aprobare în masă
R9Scurgerea secretelor din notițele în text clarRidicatRotirea tuturor secretelor de client și a parolelor de administrator în timpul preluării; doar un depozit de secrete
R10Presiune asupra memoriei pe gazda demo partajatăMediuBuget de memorie (raportul 04 §8.1), Kafka opțional (clusterul partajat, dacă este disponibil)
DependențăNecesară pentruStatut
Keycloak 26.6.3 (activ)Preluare, adoptareRulează
Clusterul KafkaEvenimente, revocareCluster partajat planificat; între timp, un broker local unic
GLogRedirecționarea audituluiRulează; GSSO are nevoie de un client gsso-glog cu audit:write
GNotifyNotificări, alerteRulează; OIDC dezactivat, așa că S4 îl activează
Pachetele GDS @gstack/gds-angular, @gstack/gds-coreConsolă, temePublicate (proiectul npm GitLab 581)
Mediul de test MPasscetateanÎn așteptare (Q-GSSO-2)
AD/LDAP-ul instituțieiFederareÎn așteptare (Q-GSSO-3)
nginx de margine + DNS gsso.gstack.esempla.systemsImplementarea demoNecesită aprobarea proprietarului
  • Textul EN este cel care prevalează. Traducerile RO și RU poartă antetul Translated from EN rev.
  • Modificările se fac prin revizie, fără renumerotare.
  • Porțile fazelor sunt revizuite de teamlead. Acțiunile de producție (S4) necesită de fiecare dată aprobarea explicită a proprietarului.