k0nsult.cloud / ai-truth / ipIII / orchestrator / auth-enterprise

Enterprise Identity — specyfikacja docelowa (OIDC / mTLS)

To jest specyfikacja docelowa warstwy tożsamości enterprise dla ipIII: OIDC/JWKS, Keycloak, gotowość pod Azure AD, authorization-code flow, walidacja tokenów, mapowanie ról oraz mTLS na bramie dla konektorów. Nie jest to wdrożone na prod. Dziś na żywej instancji działa JWT + RBAC lokalny i TLS jednostronny; wszystko poniżej oznaczone jako cel enterprise ma status ROADMAP zgodnie z doktryną claim ≤ proof.

Orchestrator Roadmap dev Status matrix Connectors Enterprise Identity Znane ograniczenia Enterprise readiness ← ipIII hub

Status tej strony: ROADMAP (P0). To dokument projektowy — szkielet architektury tożsamości, do której zmierzamy. Żaden z komponentów OIDC/JWKS/Keycloak/Azure AD/mTLS opisanych poniżej nie jest uruchomiony na produkcji. Stan realnie działający dziś to JWT wystawiany lokalnie + RBAC + audit na żywej PostgreSQL (LIVE) oraz TLS jednostronny na warstwie hostingu (LIVE). Pełny rejestr granic dojrzałości: /known-limitations.

Cel: tożsamość federacyjna + transport wzajemnie uwierzytelniany.

Bank SIFI lub partner instytucjonalny oczekuje, że tożsamość użytkownika pochodzi z zewnętrznego IdP (OIDC), a konektory łączą się przez wzajemnie uwierzytelniany kanał (mTLS z certyfikatem klienta). Ta strona opisuje docelowy szkielet — co chcemy wdrożyć i jak mapuje się to na dzisiejszy stan MVP. To wsparcie decyzji integracyjnej dla zespołu bezpieczeństwa, nie deklaracja gotowości.

OŚ TOŻSAMOŚCI: JWT lokalny + RBAC (dziś)→OIDC / JWKS (walidacja z IdP)→role mapping z claims→mTLS na bramie→enterprise identity (cel)

Dziś vs cel enterprise — mapa elementów

Uczciwe rozdzielenie: kolumna Stan dziś = co realnie działa na żywej instancji; kolumna Cel enterprise = docelowa specyfikacja; kolumna Status = priorytet domknięcia. Data weryfikacji: 2026-07-05.

Element	Stan dziś	Cel enterprise	Status
Wystawianie tożsamości	LIVE JWT wystawiany lokalnie; konta seedowane. RBAC lokalny egzekwowany na endpointach.	OIDC z zewnętrznym IdP (Keycloak, gotowość pod Azure AD / Entra ID); provisioning/deprovisioning po stronie IdP.	ROADMAP P0
Walidacja tokenów	LIVE weryfikacja podpisu JWT sekretem lokalnym; sprawdzenie `exp`.	Walidacja podpisu przez JWKS (klucz publiczny z IdP), kontrola `iss`/`aud`/`nonce`, rotacja kluczy.	ROADMAP P0
Przepływ logowania	LIVE wymiana poświadczeń → JWT (przepływ lokalny, bez zewnętrznego redirectu).	Authorization-code flow (OIDC) z PKCE; przekierowanie do IdP, wymiana kodu na token po stronie serwera.	ROADMAP P0
Mapowanie ról	LIVE role przypisane lokalnie (RBAC w bazie), egzekwowane na warstwie API.	Role mapping z claims tokenu OIDC (grupy/role z IdP → role ipIII), zasada najmniejszych uprawnień.	ROADMAP P1
Transport (użytkownik → API)	LIVE TLS jednostronny na warstwie hostingu.	TLS + docelowo egzekwowanie polityk sesji; zgodność z wymogami transportu instytucji.	ROADMAP P1
Transport (konektor → brama)	LIVE TLS jednostronny; brak wzajemnego uwierzytelniania.	mTLS na bramie: certyfikat klienta dla konektora, weryfikacja łańcucha; opcjonalnie spięcie z PKI instytucji.	ROADMAP P0
Profile konektorów	szkielet konektory dziś bez rozróżnienia profilu zaufania.	Profile bank / partner: osobne CA, polityki certyfikatów i zakres uprawnień per profil na bramie mTLS.	ROADMAP P1

Docelowy przepływ OIDC (authorization-code)

Szkielet referencyjny — do wdrożenia w ramach hardeningu auth. To opis architektury, nie działający endpoint.

1. Redirect do IdP. Aplikacja przekierowuje użytkownika do Keycloak / Azure AD (authorization endpoint) z PKCE i state.

2. Uwierzytelnienie po stronie IdP. Użytkownik loguje się w zewnętrznym IdP; ipIII nie przechowuje poświadczeń.

3. Wymiana kodu na token. Serwer wymienia authorization-code na id_token/access_token (token endpoint), weryfikuje PKCE.

4. Walidacja tokenu. Podpis weryfikowany przez JWKS (klucz publiczny IdP); kontrola iss, aud, exp, nonce.

5. Mapowanie ról. Claims (grupy/role z IdP) mapowane na role ipIII; egzekwowanie RBAC na endpointach.

6. Sesja / audit. Zdarzenie logowania i mapowanie ról zapisane w audit-logu (jak dziś dla JWT lokalnego).

mTLS na bramie dla konektorów

Certyfikat klienta ROADMAP

Każdy konektor przedstawia certyfikat klienta; brama weryfikuje łańcuch względem zaufanego CA przed dopuszczeniem ruchu.

Profil bank ROADMAP

Osobne CA i polityka certyfikatów dla integracji bankowych; węższy zakres uprawnień, twardsze wymogi rotacji.

Profil partner ROADMAP

Profil dla partnerów instytucjonalnych; oddzielne zaufanie i uprawnienia niż profil bank.

Spięcie z PKI ROADMAP

Opcjonalne włączenie certyfikatów wystawianych przez PKI instytucji, jeśli wymaga tego jej polityka.

Skrót priorytetów

P0 — blokują enterprise

OIDC · JWKS · auth-code flow · mTLS brama

P1 — wymagane dla banku/partnera

role mapping · transport · profile konektorów

Fundament LIVE dziś

JWT+RBAC lokalny · TLS jednostronny

Komponentów OIDC/mTLS na prod

cała strona = specyfikacja docelowa

Czego ta strona NIE oznacza

To nie jest deklaracja gotowości. Opisane OIDC/JWKS/Keycloak/Azure AD/mTLS to ROADMAP — szkielet docelowy, do którego zmierzamy. Nie twierdzimy, że system jest zintegrowany z jakimkolwiek IdP produkcyjnie. Realnie działający fundament (JWT+RBAC lokalny, TLS) ma dowody na roadmapie dev.

„100%" u nas znaczy pokrycie dowodowe, nie nieprzenikalność. Skoro nie mamy dowodu (kod+test+endpoint) na OIDC czy mTLS, mówimy o nich jako ROADMAP, a nie jako o funkcji. Ta strona jest wsparciem decyzji integracyjnej — nie sprzedaje nieistniejących komponentów.

Granica etyczna i zakres. ipIII jest narzędziem obrony i zgodności (GRC/blue). Elementy dotyczące bezpieczeństwa działają wyłącznie defensywnie, na danych syntetycznych i po pisemnych Rules of Engagement. Ta strona to specyfikacja architektury tożsamości — wsparcie decyzji, nie deklaracja zgodności ani porada prawna.

Powiązane: pełny rejestr granic dojrzałości → /known-limitations · gotowość enterprise (checklista) → /enterprise-readiness · roadmapa sprintów z dowodami → /roadmap-dev.