Wprost, na górze strony: SSO, OIDC, Entra ID/Azure AD, SAML i mTLS nie są dziś wdrożone na produkcji. To, co realnie działa na żywej instancji, to JWT wystawiany lokalnie + RBAC — konta zakłada operator w sposób kontrolowany (nie ma samoobsługowej rejestracji ani federacji tożsamości z zewnętrznym IdP). Poniżej opisujemy specyfikację docelową (OIDC/JWKS, Keycloak, gotowość pod Azure AD/Entra ID, SAML jako alternatywna federacja, authorization-code flow, mapowanie ról, mTLS na bramie dla konektorów) — to szkielet architektoniczny, nie deklaracja gotowości enterprise. Każdy element poniżej, którego nie ma na prod, ma status ROADMAP zgodnie z doktryną claim ≤ proof.
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.
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 zakładane kontrolowanie przez operatora (bez samoobsługowej rejestracji). RBAC lokalny egzekwowany na endpointach. | OIDC z zewnętrznym IdP (Keycloak, gotowość pod Azure AD / Entra ID); provisioning/deprovisioning po stronie IdP. | ROADMAP P0 |
| Federacja SAML | brak nie ma dziś obsługi SAML w żadnej formie. | SAML 2.0 jako alternatywna ścieżka federacji dla IdP klienta, które nie obsługują OIDC (typowe w części instytucji finansowych). | ROADMAP P1 |
| 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 |
Szkielet referencyjny — do wdrożenia w ramach hardeningu auth. To opis architektury, nie działający endpoint.
state.id_token/access_token (token endpoint), weryfikuje PKCE.iss, aud, exp, nonce.Każdy konektor przedstawia certyfikat klienta; brama weryfikuje łańcuch względem zaufanego CA przed dopuszczeniem ruchu.
Osobne CA i polityka certyfikatów dla integracji bankowych; węższy zakres uprawnień, twardsze wymogi rotacji.
Profil dla partnerów instytucjonalnych; oddzielne zaufanie i uprawnienia niż profil bank.
Opcjonalne włączenie certyfikatów wystawianych przez PKI instytucji, jeśli wymaga tego jej polityka.
Powiązane: pełny rejestr granic dojrzałości → /known-limitations · gotowość enterprise (checklista) → /enterprise-readiness · roadmapa sprintów z dowodami → /roadmap-dev.