Andrei Zimin 83caf9c3c8 feat(user-display): KeycloakAdminUserResolver — Phase 2 on-demand lookup
Implements the Phase 2 hook from the previous commit. With this in
place, UserDisplayService.find chains:

  hot cache → DB (user_display_cache) → Keycloak Admin API

so any realm user resolves on first display, even if they never made
an authenticated request to ordinis. The resolved entry is persisted
via UserDisplayService.upsert with source=KEYCLOAK_ON_DEMAND, so the
next render of the same sub hits the DB tier (~ms) instead of going
back to Keycloak.

Implementation notes:

- Spring RestClient (modern blocking HTTP, replaces RestTemplate).
- client_credentials grant against
  {issuer}/realms/{realm}/protocol/openid-connect/token. Token cached
  in-memory minus a 30s safety margin from `expires_in`.
- 401 on user lookup wipes the cached token and surfaces a
  RuntimeException, so the next resolve refetches.
- 404 on user lookup → Optional.empty (definitive miss, sub not in
  realm). UserDisplayService logs and the caller falls back to short
  UUID. Negative cache TTL not implemented — added complexity not
  justified for the current realm size (~50 users).
- Bean activated only when ordinis.keycloak.admin.enabled=true AND
  the env vars are set. Default disabled — UserDisplayService treats
  KeycloakUserResolver as @Autowired(required = false), so a
  deployment without Keycloak admin creds keeps the previous behavior
  (DB cache only) instead of crashing on startup.

Application config:
- ORDINIS_KEYCLOAK_ADMIN_ENABLED      (false by default)
- ORDINIS_KEYCLOAK_ADMIN_URL          e.g. https://auth.nstart.space
- ORDINIS_KEYCLOAK_ADMIN_REALM        defaults to nstart
- ORDINIS_KEYCLOAK_ADMIN_CLIENT_ID    via vault (see docs-internal/keycloak-admin-setup.md)
- ORDINIS_KEYCLOAK_ADMIN_CLIENT_SECRET via vault

Setup runbook (docs-internal/keycloak-admin-setup.md) covers:
- creating the Keycloak service-account client + assigning view-users
- writing the secret into both vault instances (different per env)
- wiring vault.hashicorp.com agent-inject annotations into the chart
- verification steps + common failure modes

Phase 3 (scheduled bulk sync) is documented at the end of the runbook
but deferred — depends on observed cache miss rate after this lands.
2026-05-14 14:47:49 +03:00
2026-05-03 23:06:24 +03:00

Ordinis

MDM сервис для НСИ ЦУОД ОДХ (Оперативное и Долговременное Хранение). Часть линейки Terravault. Ордо/порядок (от лат. ordo) — упорядоченные классификаторы и справочные данные.

ЦУОД — anchor-клиент v1, второй клиент = свой config bundle, без code change.

Maven multimodule

ordinis/
├── ordinis-domain              JPA entities, JSONB types, bitemporal model
├── ordinis-validation          JSON Schema validator (networknt)
├── ordinis-events-api          DTO для Kafka (semver shared module)
├── ordinis-outbox              Outbox pattern + @Scheduled poller
├── ordinis-rest-api            Admin write API (CRUD, bundle import)
├── ordinis-app                 Spring Boot main: writer side
├── ordinis-read-api            Read service (PG replica + scope filtering)
├── ordinis-projection-writer   Опц.: Kafka → Redis projection (feature-flagged)
├── ordinis-cuod-bundle         ЦУОД config: JSON Schema, seed, Grafana dashboards
└── ordinis-migrations          Liquibase changelogs → Helm pre-upgrade Job (1-shot)

Стек

  • Java 21, Spring Boot 3.4
  • PostgreSQL 18 + PostGIS 3.6 + btree_gist (EXCLUSION CONSTRAINT)
  • Apache Kafka 4.2 (KRaft, SASL SCRAM-SHA-512)
  • Hibernate Envers (tx-time) + valid_from/valid_to (effective-time) — bitemporal
  • Liquibase
  • Spring Cloud Config + Spring Cloud Vault (Kubernetes auth)
  • Micrometer + Prometheus
  • LogstashEncoder JSON stdout → Loki через Alloy
  • OpenTelemetry → Tempo (OTLP gRPC)

Архитектурные принципы

  • Generic dictionary engine + ЦУОД config bundle (Approach B). Engine не знает про "КА"/"наземные станции" — узнаёт через JSON Schema из bundle
  • Bitemporal: Envers для tx-time + valid_from/valid_to для effective-time + EXCLUSION CONSTRAINT
  • 3 scope-топика Kafka (public/internal/restricted) — изоляция через ACL, не через filter в consumer
  • System boundary: 3 deployable делят БД (master+replica). Внешние consumers — только REST/Kafka, никогда прямо в БД
  • Tiered performance: 1k RPS из коробки (PG replica + Caffeine). 10k+ RPS включается per-dictionary через Redis projection
  • Audit log в БД (compliance), технические логи в Loki

Build

mvn clean install        # все модули
mvn -pl ordinis-app -am package -DskipTests  # только app + transitive
docker build -f ordinis-app/Dockerfile -t ordinis-app:0.1.0 .
docker build -f ordinis-migrations/Dockerfile -t ordinis-migrations:0.1.0 ordinis-migrations/

Связанные репо

S
Description
No description provided
Readme 3.2 MiB
Languages
TypeScript 49.7%
Java 43.7%
HTML 5.5%
CSS 0.7%
Dockerfile 0.3%