GSSO — платформа идентификации и единого входа gStack — Техническое задание


Код документа	SPEC-GSSO-2026 / Отчёт 00
Версия	0.1-draft (исходный текст EN, имеющий преимущественную силу)
Дата	2026-10-05
Статус	Черновик — открыт для рецензирования; ни одно ADR пока не принято
Сопутствующие отчёты	01 ADR · 02 Требования · 03 Потребители и контракт · 04 Техническая документация · 05 Дорожная карта
Дизайн	`gsso.dc.html` (исходник: `gstyle/design/src/GStack/GSSO.dc.html`, опубликован по адресу `s3.eu-west-1.amazonaws.com/gstack.awsarhitect.me/Sistem+GStack/GSSO.dc.html`)

История изменений

Версия	Дата	Изменения
0.1-draft	2026-10-05	Первоначальное техническое задание: назначение, проблема, область применения, участники, глоссарий, обзор архитектуры, принципы, AC-001..030, Q-GSSO-1..14

Условные обозначения

GSSO — название платформы. Во всех текстах для пользователей пишется «GSSO»; «Keycloak» обозначает только встроенный движок идентификации.
Идентификаторы: GSSO-ADR-nnn (решения, отчёт 01), GSSO-FR-nnn и GSSO-NFR-<AREA>-nnn (требования, отчёт 02), AC-nnn (критерии приёмки, настоящий отчёт), Q-GSSO-n (открытые вопросы, настоящий отчёт), фазы S0..S5 (отчёт 05).
Идентификаторы никогда не перенумеровываются. Изменённая строка помечается [REVISED дата], устаревшая — [WITHDRAWN дата] причина, а новые идентификаторы добавляются в конец своей серии.
Предметные термины — румынские (Platforma, AtribuireAcces, RolPlatforma…) на всех языках; лексика фреймворков остаётся английской.
CAP-GSSO-nn — возможности, запрошенные приложениями-потребителями (отчёт CRM 03 §4.1 и пакеты gDocFlow, gTenders, gFlow, gInsight).
CU-* — универсальные требования gStack; NFRQnn — коды нефункциональных требований caiet de sarcini (saas_drumuri/docs/reports/02-cerinte-functionale-nefunctionale.md).

Комплект отчётов

#	Отчёт	Содержание
00	Техническое задание (настоящий документ)	назначение, проблема, цели, область применения, участники, глоссарий, соответствие требованиям, архитектура, принципы, критерии приёмки, открытые вопросы
01	ADR	GSSO-ADR-001..014
02	Требования	GSSO-FR-, GSSO-NFR-, трассируемость к CAP-GSSO, CU-*, NFRQ
03	Потребители и контракт	каждое приложение gStack, его текущая схема аутентификации и путь миграции; API, события, starter, подключение
04	Техническая документация	представления C4, компоненты, модель данных, потоки, модель realm, безопасность, развёртывание, тестирование
05	Дорожная карта	фазы S0–S5 с контрольными точками выхода, MVP, риски, зависимости

1. Назначение

GSSO — общая платформа идентификации, аутентификации, авторизации и единого входа (PaaS) gStack. Она даёт каждому SaaS gStack (Interdicții, Cancelaria, gDocs, gRegistry, Drumuri, CRM, gDocFlow, gTenders…) и PaaS (GLog, GNotify, gStorage, gFlow, портал GDS…) единое место, чтобы:

аутентифицировать сотрудников, граждан и сервисы (OIDC/OAuth 2.1, SAML 2.0, федерация MPass/eID, федерация AD/LDAP, MFA);
регистрировать платформы и сервисы вместе с их клиентами и предоставляемыми ими ролями;
авторизовать, назначая роли конкретному пользователю на конкретной платформе, при необходимости в пределах организационной единицы и окна действия, с запросом и согласованием;
синхронизировать эту управляемую модель в движок идентификации и выявлять расхождения (drift);
аудировать каждый вход, token, административное изменение и назначение доступа в GLog;
управлять realm (тенантами), пользователями, сессиями, учётными данными и политиками аутентификации из консоли GDS.

GSSO строится поверх существующего Keycloak 26.6.3 (https://sso.gstack.esempla.systems). Keycloak остаётся средой выполнения идентификации: учётные данные, сессии, token, MFA и федерация. GSSO добавляет то, чего Keycloak не хватает для государственной платформы:

каталог сервисов;
управляемый жизненный цикл назначений доступа;
согласование с целевым состоянием (desired-state reconciliation);
журнал аудита только для добавления (append-only);
стандартный набор интеграции;
консоль в дизайн-системе gStack.

2. Постановка проблемы

Текущее состояние по наблюдениям на 2026-10-05:

Нет платформы, есть только сервер. Keycloak 26.6.3 работает как вручную настроенный контейнер на общем демо-хосте. Нет инфраструктуры как кода, нет экспорта realm, нет собственной темы и нет резервной копии конфигурации ни в одном репозитории.
Один общий realm с клиентами всех приложений. Realm interdictii содержит interdictii-web, gregistry-web, glog-web, glog-ingest, gstack-platform, cancelarie и другие. Realm, названный по одному SaaS, на практике является realm сотрудников gStack.
На realm ссылаются, но они не согласованы. Код ссылается на realm gdocs, gnotify, gstorage, gstack и ultra. Только gstorage зафиксирован как созданный; gnotify зафиксирован как отсутствующий. Ничто не указывает, какие realm должны существовать.
Четыре несогласованные схемы интеграции:
- A, двойная аутентификация: приложение выпускает собственный JWT HS512 после входа через Keycloak (interdictii, gdocs, gnotify).
- B, полноценный resource server: приложение напрямую проверяет token Keycloak (gregistry, glog, cancelarie).
- C, только локальный JWT плюс MPass SAML: drumuri.
- D, только проект: CRM, gFlow, gDocFlow, gTenders. Роли хранятся частично в Keycloak, частично в базах данных приложений.
Грубые роли. Существуют только роли realm ROLE_ADMIN и ROLE_USER. Они общие для всех приложений, поэтому администратор одного приложения является администратором всех.
Нет управления доступом. Назначения выполняются вручную в административной консоли Keycloak. Нет ни запроса, ни согласования, ни срока действия, ни обоснования, ни представления «кто что может делать на какой платформе».
Нет пригодного аудита. События Keycloak не хранятся долговременно и не пересылаются в GLog. Показатели дашборда из дизайна (входы за 24 ч, неудачные входы, структура способов аутентификации) получить невозможно.
Отсутствуют возможности, запрошенные потребителями:
- CAP-GSSO-01: корпоративный realm и клиенты для каждого микросервиса.
- CAP-GSSO-02: AD/LDAP и TOTP в зависимости от роли.
- CAP-GSSO-03: список сессий и принудительное завершение.
- CAP-GSSO-04: отзыв ≤ 60 с и claims организационной единицы.
- CAP-GSSO-06: автоматизируемое создание клиентов.
- CAP-GSSO-07: token exchange.
Эксплуатационная хрупкость. TLS-сертификат sso. истёк 2026-09-23 и сломал все входы, а административные секреты хранятся в заметках открытым текстом.

3. Цели и критерии успеха

#	Цель	Критерий успеха
G-1	Один вход во все приложения сотрудников gStack	Пользователь, вошедший в любое приложение сотрудников, открывает любое другое приложение сотрудников без повторного запроса пароля (AC-010)
G-2	Авторизация в разрезе платформ	Роли имеют пространство имён платформы (`CRM_ADMIN`, `INTERDICTII_EMITENT`…); администратор одной платформы не имеет прав на другой (AC-012)
G-3	Управляемый доступ	У каждого назначения роли есть инициатор запроса, согласующий (для чувствительных ролей), обоснование, срок действия и журнал аудита (AC-013..016)
G-4	Конфигурация как код	Realm, клиенты, роли, mappers, flows и тема воспроизводятся из репозитория на пустом Keycloak (AC-005)
G-5	Видимость расхождений	Изменение, сделанное напрямую в административной консоли Keycloak, обнаруживается и регистрируется в течение одного цикла согласования (AC-008)
G-6	Стандартная интеграция	Новое приложение интегрируется с помощью одной зависимости starter и трёх настроек; ни одно приложение не выпускает собственные token (AC-020)
G-7	Полный аудит	Каждый вход, неудача, выпуск token для сервисных учётных записей, административное изменение и переход назначения доступа появляются в GLog с указанием субъекта, realm, IP и времени (AC-017)
G-8	Возможности для потребителей	CAP-GSSO-01, 02, 03, 04, 06 и 07 реализованы (трассируемость — в отчёте 02 §III)

4. Заинтересованные стороны и потребители

Заинтересованная сторона	Интерес
Команда платформы gStack	Владеет GSSO: сборка, эксплуатация, обновление Keycloak, публикация starter
Владельцы платформ (приложений)	Регистрируют своё приложение, определяют его роли, согласуют назначения доступа к своему приложению
Офицер безопасности / аудитор	Проверяет доступ, согласует чувствительные роли, читает аудит и отчёты о входах
Администраторы IAM учреждений	Управляют пользователями своего realm или организационной единицы
Конечные пользователи-сотрудники	Один вход, MFA, самообслуживание учётных данных и сессий
Граждане	Вход на публичные порталы через MPass/eID
Приложения-потребители	Token со стабильными claims, сервисные учётные записи, административный API для создания ресурсов

Потребители перечислены в отчёте 03:

SaaS: interdictii, cancelaria, gdocs, gregistry, drumuri, CRM, gDocFlow, gTenders.
PaaS: glog, gnotify, gstorage, gflow, gportal/GDS, документация платформы/RAG.
Мобильные: gsso_mob (GovSign).
Сайты whitelabel: ultra-, bts-, esempla-*.

5. Область применения

5.1 Входит в область применения

Keycloak 26.6.x как встроенный движок идентификации, развёртываемый из репозитория GSSO с:
- базовой конфигурацией realm (gstack, cetatean, шаблон тенанта);
- расширениями Keycloak от GSSO (event listener, protocol mappers);
- темами GDS для входа, учётной записи и электронной почты на RO/RU/EN.
Управление realm (тенантами): создание из шаблона, включение/отключение, брендирование, федерация (broker) и политики. В консоли есть переключатель realm.
Каталог сервисов: платформы и сервисы (SaaS/PaaS) с владельцами, базовыми URL, акцентными цветами, их клиентами (public PKCE, confidential, bearer-only, сервисная учётная запись) и ролями, которые предоставляет каждая платформа (роли realm или клиента, составные, чувствительные).
Управление пользователями:
- создание, приглашение, включение/отключение, редактирование атрибутов (IDNP, организационная единица, локаль);
- сброс учётных данных, обязательные действия (required actions);
- просмотр и завершение сессий;
- просмотр и удаление учётных данных MFA;
- поиск по всем realm через проекцию.
Назначения доступа (AtribuireAcces): запрос → согласование/отклонение → активно → отзыв/истечение. Назначения выполняются в разрезе пользователь × роль платформы × необязательная организационная единица × окно действия, с согласованием по принципу «четырёх глаз» для чувствительных ролей, массовым назначением и уведомлениями об истечении срока.
Организационные единицы: дерево, выдаваемое в claim org_unit.
Политики аутентификации для каждого realm:
- способы: пароль, OTP, WebAuthn/passkey, QR с другого устройства (cross-device), client credentials, broker, magic link;
- парольная политика и время жизни сессий;
- обязательная MFA для чувствительных ролей;
- браузерный flow, отображаемый как упорядоченные шаги.
Согласование с целевым состоянием в Keycloak: идемпотентные задания, повторные попытки, периодическое полное согласование, режим отчёта о расхождениях или принудительного применения для каждого realm, а также принятие под управление (adoption) существующих realm.
События:
- пользовательские и административные события Keycloak через расширение в Kafka;
- собственные события GSSO только для добавления;
- пересылка в GLog;
- дашборд: KPI, входы за 24 ч, неудачи, структура способов аутентификации, последние события безопасности.
API в зонах GovStack: admin (консоль), app (приложения-потребители: саморегистрация, поиск пользователей, запрос назначения доступа, завершение сессий), плюс эксплуатационные endpoints.
Набор интеграции: gsso-spring-boot-starter, @gstack/gsso-angular, а также runbook и чек-лист подключения.
Конфигурация token exchange (RFC 8693) для вызовов от имени пользователя (on-behalf-of) между приложениями.
Путь миграции для каждого существующего приложения со схем A/B/C на стандарт, включая принятие под управление realm interdictii.

5.2 Не входит в область применения

Повторная реализация провайдера идентификации. Вход, token, учётные данные и федерация остаются в Keycloak (GSSO-ADR-001).
Бизнес-авторизация внутри приложения (видимость на уровне строк, владение объектами). GSSO предоставляет роли и claims, а решение принимает приложение.
Квалифицированная электронная подпись (MSign / подпись в gsso_mob). GSSO аутентифицирует; подпись — отдельный сервис.
Кадровая система. Сотрудники и организационная структура могут импортироваться, но кадровый мастер-источник остаётся внешним.
Фактический переход в продуктиве существующих приложений и общего realm. Он планируется в отчёте 05 и выполняется только с явного одобрения владельцев.
Terraform provider и оператор Kubernetes. Они опциональны в S5.

6. Участники и роли

Участник	Роль GSSO	Может
Администратор платформы	`GSSO_ADMIN`	Всё во всех realm; управление realm, шаблонами, настройками reconciler
Администратор realm	`GSSO_REALM_ADMIN` (в пределах realm)	Пользователи, клиенты, роли, политики одного realm
Владелец платформы	`GSSO_PLATFORM_OWNER` (в пределах платформы)	Определять роли и клиентов платформы, согласовывать назначения доступа к ним
Согласующий / офицер безопасности	`GSSO_APPROVER`	Второе согласование для чувствительных ролей; пересмотры доступа
Аудитор	`GSSO_AUDITOR`	Только чтение: каталог, назначения доступа, события, отчёты
Служба поддержки	`GSSO_HELPDESK`	Поиск пользователей, сброс учётных данных, разблокировка, завершение сессий; без изменения ролей
Конечный пользователь	—	Самообслуживание через консоль учётной записи Keycloak (тема GDS): пароль, MFA, сессии; запрос доступа
Приложение-потребитель	сервисная учётная запись со scope `gsso:app`	Саморегистрация (если разрешена), поиск пользователей, запрос назначений доступа, завершение сессий
Reconciler	сервисная учётная запись `gsso-reconciler` в `master`	Применение целевого состояния к Keycloak (никогда не используется людьми)

7. Глоссарий

Термин	Значение
Realm	Тенант Keycloak: изолированные пользователи, клиенты, роли и политики. Сущность GSSO `Realm`
Platforma	SaaS или PaaS gStack, зарегистрированный в каталоге (`crm`, `glog`…)
ClientAplicatie	Клиент OIDC/SAML платформы: SPA (public + PKCE), backend (confidential или bearer-only), сервисная учётная запись
RolPlatforma	Роль, предоставляемая платформой, с префиксом её кода (`CRM_ADMIN`). Может быть составной или чувствительной
AtribuireAcces	Назначение доступа: один пользователь получает одну роль платформы, при необходимости для организационной единицы и окна действия
UnitateOrganizationala	Узел дерева организационных единиц, выдаваемый в claim `org_unit`
PoliticaAutentificare	Политика аутентификации realm: способы, парольная политика, MFA, время жизни сессий
JobSincronizare	Одна единица работы по согласованию (создание/изменение/удаление в Keycloak) или одно обнаруженное расхождение
ProiectieUtilizator	Модель чтения GSSO с возможностью поиска для пользователя Keycloak
EvenimentGsso	Событие аудита только для добавления (вход, администрирование, назначение доступа, синхронизация)
Целевое состояние (desired state)	Конфигурация, объявленная в GSSO; Keycloak приводится к ней
Расхождение (drift)	Различие между целевым состоянием и Keycloak
Принятие под управление (adoption)	Однократный импорт конфигурации существующего realm в каталог
Сессия SSO	Браузерная сессия Keycloak, общая для всех клиентов realm
BFF	Backend-for-frontend: шлюз JHipster хранит token на стороне сервера; SPA получает сессионный cookie
MPass	Государственный сервис аутентификации Молдовы (SAML), подключаемый через broker в realm `cetatean`
IDNP	Государственный персональный идентификатор (13 цифр), хранится как атрибут пользователя

8. Соответствие требованиям

Область	Ссылка	Ответ GSSO
Персональные данные	Закон 133/2011 (РМ), согласован с GDPR	Минимальный набор атрибутов пользователя; IDNP доступен только уполномоченным ролям; очистка проекции при удалении пользователя; политика хранения аудита
Информационная безопасность	NFRQ56–66 (минимальные привилегии, OWASP Top 10, истечение сессий, аудит безопасности)	Роли с пространством имён платформы, принцип «четырёх глаз» для чувствительных ролей, политика MFA, время жизни сессий, аудит всех административных действий
Аудит	Требование криминалистической прослеживаемости Закона 133, CU-AUDIT-*	`EvenimentGsso` только для добавления с цепочкой хэшей; пересылка в GLog WORM
Интероперабельность	GovStack Identity BB, CU-API-003..006	OIDC/OAuth 2.1, SAML, RFC 8693, RFC 7807, зоны API GovStack
Государственная идентификация	MPass / eID	Брокеринг идентификации в realm `cetatean`
Доступность	NFRQ39 (WCAG 2.1 AA)	Компоненты GDS в консоли и темах входа
Языки	NFRQ38	RO (основной), RU, EN в консоли, темах и письмах
AI Act	Регламент (ЕС) 2024/1689	Не является системой ИИ; нет автоматизированных решений о доступе (классификация в отчёте 01, GSSO-ADR-014)

9. Высокоуровневая архитектура

flowchart LR
  subgraph Users[Пользователи]
    adm[Администратор IAM / владелец / аудитор]
    staff[Сотрудник]
    cit[Гражданин]
  end
  subgraph GSSO
    web[gsso-web<br/>Angular + GDS]
    gw[gsso-gateway<br/>JHipster BFF]
    srv[gsso<br/>микросервис JHipster]
    db[(PostgreSQL gsso)]
    kc[Keycloak 26.6<br/>+ расширения gsso + темы GDS]
    kdb[(PostgreSQL keycloak)]
  end
  kafka[[Kafka]]
  glog[GLog]
  gnotify[GNotify]
  apps[SaaS / PaaS gStack]
  mpass[MPass / eID]
  ldap[AD / LDAP]

  adm --> web --> gw --> srv
  gw -. вход OIDC .-> kc
  srv -- Admin REST --> kc
  srv --- db
  kc --- kdb
  kc -- события --> kafka --> srv
  srv -- аудит --> glog
  srv -- письма об истечении / согласовании --> gnotify
  staff -- OIDC --> kc
  cit -- OIDC --> kc -- SAML broker --> mpass
  kc -- федерация --> ldap
  apps -- token / JWKS --> kc
  apps -- api/v1/app --> gw

gsso хранит управляемую модель и согласует её в Keycloak через Admin REST API, используя сервисную учётную запись gsso-reconciler.
Keycloak публикует пользовательские и административные события через расширение-event listener GSSO в Kafka gsso.kc-events.v1.
gsso потребляет эти события, сохраняет их, обновляет проекцию пользователей и дашборд и пересылает их в GLog.
Приложения никогда не вызывают административный API Keycloak. Они используют token и JWKS из Keycloak и api/v1/app из GSSO.

10. Принципы

Keycloak — среда выполнения, GSSO — плоскость управления (control plane). Никакая логика учётных данных, сессий или token не реализуется повторно (GSSO-ADR-001).
Целевое состояние объявляется в GSSO и приводится в Keycloak. Ручные правки в Keycloak являются расхождением (GSSO-ADR-004).
Один realm сотрудников для настоящего SSO. Все приложения gStack для сотрудников являются клиентами realm gstack. Граждане находятся в cetatean. Изолированные тенанты получают собственный realm (GSSO-ADR-002).
Роли принадлежат платформам. Каждая роль имеет вид <PLATFORM>_<ROLE>. Единственные межплатформенные роли — GSSO_* и роль по умолчанию ROLE_USER (GSSO-ADR-005).
Доступ назначается, а не редактируется. Сопоставления ролей для людей создаются только через AtribuireAcces, поэтому у каждого есть инициатор запроса, согласующий (когда нужно), окно действия и обоснование (GSSO-ADR-006).
События только добавляются и покидают платформу. Всё находится в EvenimentGsso и в GLog (GSSO-ADR-007).
Один способ интеграции. Приложения являются клиентами OAuth2 или resource servers, проверяющими token GSSO, через starter. Ни одно приложение не выпускает собственные token и не хранит пароли (GSSO-ADR-009).
Конфигурация как код. Базовые конфигурации realm, расширения и темы хранятся в git. Продуктивный Keycloak можно восстановить из репозитория плюс резервной копии базы данных (GSSO-ADR-011).
Минимальные привилегии и принцип «четырёх глаз» для чувствительных ролей, MFA для чувствительных ролей, короткие сессии для администраторов.
Стек DEV-PLAYBOOK: микросервис + шлюз JHipster 9.1.0, OAuth2, Maven, PostgreSQL, Kafka, ro,ru,en, отдельное Angular SPA на GDS (GSSO-ADR-010).

11. Сводка требований и критерии приёмки

11.1 Группы требований (подробности в отчёте 02)

Группа	Идентификаторы	Количество
Realm и тенанты — FR-RLM	GSSO-FR-001..010	10
Каталог сервисов — FR-CAT	GSSO-FR-011..022	12
Пользователи и сессии — FR-USR	GSSO-FR-023..036	14
Роли и назначения доступа — FR-GRT	GSSO-FR-037..052	16
Организационные единицы — FR-ORG	GSSO-FR-053..056	4
Аутентификация и федерация — FR-AUT	GSSO-FR-057..070	14
Согласование — FR-SYN	GSSO-FR-071..080	10
События и аудит — FR-EVT	GSSO-FR-081..090	10
Дашборд и отчёты — FR-RPT	GSSO-FR-091..096	6
API приложений и набор интеграции — FR-API	GSSO-FR-097..108	12
Консоль (UI) — FR-UI	GSSO-FR-109..116	8
Нефункциональные — NFR-*	PERF, CAP, AVL, SEC, TEN, OBS, OPS, CMP, DATA	44

11.2 Критерии приёмки

ID	Критерий
AC-001	`docker compose up` стека GSSO на пустом хосте даёт Keycloak с realm `gstack` и `cetatean`, темой входа GDS на RO/RU/EN и загруженными расширениями GSSO
AC-002	Администратор входит в консоль GSSO через `gsso-gateway` (realm `gstack`, клиент `gsso-console`); SPA не хранит token
AC-003	Создание realm из шаблона тенанта в консоли создаёт его в Keycloak с базовыми flows, mappers и темой
AC-004	Переключатель realm ограничивает каждый экран консоли выбранным realm; `GSSO_REALM_ADMIN` видит только свой realm
AC-005	Удаление realm `gstack` в тестовом Keycloak и запуск полного согласования воссоздаёт управляемых каталогом клиентов, роли, mappers и политики
AC-006	Регистрация платформы с 2 клиентами и 3 ролями создаёт их в Keycloak в течение 10 с
AC-007	Согласование идемпотентно: двукратный запуск не даёт ни изменений, ни дубликатов
AC-008	Роль, созданная вручную в административной консоли Keycloak, появляется как `DRIFT` в течение одного цикла согласования; в режиме `enforce` она удаляется
AC-009	Принятие под управление существующего realm импортирует его клиентов, роли и сопоставления ролей в каталог без изменения Keycloak
AC-010	Пользователь, вошедший в приложение A (realm `gstack`), открывает приложение B без запроса пароля; выход из консоли завершает сессию SSO
AC-011	Access token содержит `roles` (плоский список), `org_unit`, `locale` и, если разрешено, `idnp`; `sub` — UUID
AC-012	Пользователь с `CRM_ADMIN` не получает ни одного полномочия `GLOG_` или `INTERDICTII_` в GLog или Interdicții
AC-013	Запрос назначения доступа к нечувствительной роли, согласованный владельцем платформы, переходит в `ACTIVA`, и роль присутствует в следующем token пользователя
AC-014	Назначение доступа к чувствительной роли требует двух разных согласующих; инициатор не может согласовать собственный запрос
AC-015	Назначение доступа с `validPana` в прошлом завершается планировщиком по истечении срока, сопоставление удаляется, пользователь уведомляется
AC-016	Отзыв назначения доступа удаляет сопоставление и завершает сессии пользователя в затронутых клиентах; роль отсутствует в token в течение 60 с
AC-017	Успешный вход, неудачный вход, административное изменение и переход назначения доступа отображаются в списке событий консоли и в GLog с указанием субъекта, realm, IP и времени
AC-018	`UPDATE` и `DELETE` на `eveniment_gsso` отклоняются репозиторием и триггером базы данных
AC-019	Дашборд показывает realm, клиентов, пользователей, активные сессии, входы с шагом 2 ч за 24 ч (успех/неудача) и структуру способов аутентификации
AC-020	Пример приложения Spring Boot только с `gsso-spring-boot-starter` и 3 настройками проверяет token GSSO и сопоставляет `roles` с authorities
AC-021	Приложение со scope `gsso:app` саморегистрирует свою платформу, клиентов и роли через `POST /api/v1/app/platforme` (если для него разрешена саморегистрация)
AC-022	`DELETE /api/v1/app/utilizatori/{sub}/sesiuni` завершает сессии пользователя в течение 60 с
AC-023	Token exchange от клиента `crm-gateway` к аудитории `gdocflow` возвращает token для того же пользователя с целевой аудиторией; неразрешённая пара отклоняется
AC-024	OTP требуется при входе для пользователя, имеющего любую чувствительную роль; WebAuthn принимается как альтернатива
AC-025	Вход гражданина в клиент `cetatean` передаётся через broker на mock MPass SAML и создаёт или связывает пользователя по IDNP
AC-026	Списки пользователей, клиентов, ролей, назначений доступа и событий поддерживают фильтрацию, сортировку и пагинацию и отвечают в пределах целевых значений NFR-PERF
AC-027	Все надписи консоли переведены на RO, RU и EN; ни одного непереведённого ключа не видно (проверка `/gfront`)
AC-028	`/health/live`, `/health/ready` (включает доступность Keycloak), `/metrics`, `/info`, `/api/v1/openapi.json` отвечают; ошибки соответствуют RFC 7807
AC-029	`/gsast` не сообщает ни об одной находке уровня high/critical без принятого исключения (waiver); в репозитории нет секретов
AC-030	Пробный прогон (dry-run) миграции realm interdictii формирует отчёт о сопоставлении (клиенты, роли, пользователи) без какой-либо записи в продуктив

12. Открытые вопросы

ID	Вопрос	Предлагаемый ответ	Ответственный
Q-GSSO-1	Оставить realm `interdictii` как realm сотрудников и переименовать его только в отображении или создать `gstack` и мигрировать?	Создать `gstack`, принять `interdictii` под управление в режиме только чтения, мигрировать по одному приложению (отчёт 05, S4)	Команда платформы + владельцы приложений
Q-GSSO-2	Продуктивная интеграция с MPass: метаданные SAML, сертификаты и тестовые учётные записи от AGE?	Mock в S2, реальные метаданные — когда будут доступны	Учреждение
Q-GSSO-3	Какой каталог AD/LDAP (для каждого учреждения) и федерация только для чтения или с записью?	Только чтение, режим редактирования `READ_ONLY`, для каждого realm	ИТ учреждения
Q-GSSO-4	Какие роли являются чувствительными по умолчанию?	Все `_ADMIN`, `GSSO_`, кроме `GSSO_AUDITOR`, роли, помеченные владельцами	Офицер безопасности
Q-GSSO-5	Срок действия назначений доступа по умолчанию (бессрочно или, например, 12 месяцев с продлением)?	12 месяцев для чувствительных ролей, бессрочно для остальных, с ежегодным пересмотром доступа	Офицер безопасности
Q-GSSO-6	Кто может согласовывать: только владелец платформы или также руководитель организационной единицы пользователя?	Владелец платформы плюс согласующий для чувствительных ролей; руководитель организационной единицы — опционально для каждой платформы	Владельцы платформ
Q-GSSO-7	Хранение событий входа (БД GSSO или GLog)?	90 дней в GSSO, в GLog — согласно политике GLog	DPO
Q-GSSO-8	Входит ли realm граждан `cetatean` в продуктивную область применения этой платформы или позже?	Проектируется сейчас, продуктив — после доступности MPass	Продукт
Q-GSSO-9	Вход в gsso_mob по QR с другого устройства: реализовать как authenticator Keycloak (SPI) или сохранить endpoint одобрения для каждого сайта?	Authenticator Keycloak в S5, единая реализация для всех сайтов	Команда платформы
Q-GSSO-10	Хостинг: остаться на общем демо-хосте или перейти на целевой Kubernetes из playbook?	Docker compose на демо-хосте для S0–S3; Helm chart для целевой среды	DevOps
Q-GSSO-11	Должны ли приложения сохранять локальную аварийную («break-glass») учётную запись администратора?	Никаких локальных паролей; break-glass = аварийная учётная запись в realm `master`, находящаяся у команды платформы	Офицер безопасности
Q-GSSO-12	Саморегистрация платформ через API `app`: разрешена для всех приложений или только для CI команды платформы?	Только для явно помеченных клиентов; остальные — через консоль	Команда платформы
Q-GSSO-13	`idnp` в token: всегда, никогда или для каждого клиента отдельно?	Для каждого клиента, по явному включению через client scope `idnp`, с одобрения DPO	DPO
Q-GSSO-14	Периодичность обновления Keycloak (минорные версии 26.x) и кто за неё отвечает?	Ежеквартально, команда платформы, с набором тестов базовой конфигурации realm в качестве контрольной точки	Команда платформы