# TrustBroker 5.1 - SSO i MFA do SAP bez Active Directory > OpenID Connect w bibliotece SNC daje pojedyncze logowanie i MFA odporne na phishing do SAP GUI przez Entra ID, Oktę, PingID, Keycloak albo SAP IAS - Source: https://snok.ai/pl/aktualnosci/blog/trustbroker-5-1-sso-mfa-sap-bez-active-directory/ - Author: Jarosław Zdanowski - Published: 2026-09-15 --- Jeżeli w Waszej firmie ktoś pyta, po co jeszcze stoi Microsoft Active Directory, odpowiedź zwykle sprowadza się do jednego zdania: bo inaczej nie zadziała pojedyncze logowanie do **SAP**. Tożsamość pracowników przenieśliście do chmury lata temu, katalog lokalny miał zniknąć razem z ostatnią aplikacją, która go potrzebowała, a potem okazało się, że tą aplikacją jest SAP GUI. Kerberos wymaga kontrolera domeny, kontroler domeny wymaga lasu, las wymaga utrzymania, i tak przez dwadzieścia lat. Trzeciego września 2026 SecurityBridge opublikował wydanie **TrustBroker 5.1.0**, w którym **OpenID Connect** jest wbudowany w bibliotekę **SNC**. To brzmi jak przypis w informacji o wersji, a jest zdjęciem jednej z przyczyn, dla których programy modernizacji tożsamości kończą się w osiemdziesięciu procentach. **W skrócie:** **1/** pojedyncze logowanie i uwierzytelnianie wieloskładnikowe do SAP GUI działają bez Active Directory pośrodku, natywnie z Microsoft Entra ID, Oktą, PingID, Keycloakiem i SAP Cloud Identity Services, **2/** Kerberos nie znika, zostaje wspierany w tej samej bibliotece, więc przechodzicie system po systemie, we własnym tempie, **3/** logowanie do SAP GUI można teraz chronić uwierzytelnianiem odpornym na phishing - Windows Hello for Business, passkeys, tokeny FIDO2, **4/** ruch między SAP GUI a systemem SAP jest szyfrowany wymianą kluczy odporną na komputery kwantowe. ![Ręce przy laptopie w jasnym biurze, palec dotyka klucza sprzętowego FIDO2 wpiętego w bok komputera, na ekranie panel logowania](https://snok.ai/images/blog/trustbroker-5-1-sso-mfa-sap-bez-active-directory.webp) --- ## Zależność, której nikt świadomie nie wybierał Pojedyncze logowanie do SAP GUI opiera się o warstwę SNC, czyli Secure Network Communications - interfejs, przez który SAP przyjmuje uwierzytelnienie wykonane na zewnątrz jądra. Biblioteka SNC podstawiona pod ten interfejs mówiła dotąd jednym językiem: Kerberos. A Kerberos w praktyce korporacyjnej znaczy Active Directory. Dla zespołu bezpieczeństwa wynikają z tego dwa fakty, które warto trzymać osobno. Pierwszy jest organizacyjny: katalog, który miał być wygaszany, musi żyć, być łatany i audytowany, bo trzyma logowanie do systemu księgującego. Drugi jest architektoniczny i mniej oczywisty - skoro dostęp do ERP wisi na Kerberosie, to przejęcie konta w domenie jest równoznaczne z wejściem do SAP, a dodatkowe warstwy kontroli tożsamości, które zbudowaliście w chmurze, po prostu w tej ścieżce nie występują. Pisaliśmy o tym szerzej przy okazji [budowania Zero Trust dla tożsamości w świecie SAP](https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-jak-budowac-zero-trust-dla-tozsamosci-w-swiecie-sap/) - zasada „nigdy nie ufaj, zawsze weryfikuj” zatrzymuje się tam, gdzie kończy się bilet Kerberosa. ## Co dokładnie zmieniło się w bibliotece SNC TrustBroker 5.1.0 wnosi OpenID Connect do samej biblioteki SNC. Użytkownik loguje się do SAP GUI, a uwierzytelnienie leci do dostawcy tożsamości, którego już macie - producent wymienia Microsoft Entra ID, Oktę, PingID, Keycloaka i SAP Cloud Identity Services, dawniej IAS. Active Directory nie jest w tej ścieżce potrzebne. ![Diagram: do wersji 5.0 logowanie do SAP GUI szło przez Kerberos i Microsoft Active Directory, od wersji 5.1 przez OpenID Connect w bibliotece SNC do Entra ID, Okty, PingID, Keycloaka albo SAP IAS](https://snok.ai/images/blog/trustbroker-5-1-dwie-drogi-logowania.webp) Istotny jest szczegół wdrożeniowy, bo to on decyduje, czy temat w ogóle przejdzie przez architekturę. Uwierzytelnianie działa wewnątrz serwerów aplikacyjnych SAP. Producent pisze wprost, że nie dochodzi nowa infrastruktura ani zewnętrzne komponenty do łatania i utrzymania. Dla zespołu Basis oznacza to brak kolejnego serwera pośredniczącego w krytycznej ścieżce logowania, a dla zespołu bezpieczeństwa brak kolejnej powierzchni, którą trzeba objąć zarządzaniem podatnościami. ## Kerberos nie odchodzi, więc migracja jest etapowa To zdanie z materiału producenta warto przeczytać dwa razy, bo rozstrzyga o kształcie projektu: Kerberos zostaje w pełni wspierany w bibliotece SNC. Nie ma daty wyłączenia, nie ma trybu przejściowego z terminem, nie ma sytuacji, w której podnosicie wersję i tracicie działające logowanie. W praktyce znaczy to, że przechodzicie system po systemie. Zaczynacie od jednego środowiska, najlepiej takiego, w którym awaria logowania nie zatrzymuje księgowania, potwierdzacie zachowanie klienta SAP GUI i polityki, a dopiero potem ruszacie produkcję. Program, w którym odłączenie Active Directory jest jedną wielką zmianą w jeden weekend, jest programem, którego nie trzeba planować w ten sposób. ## Uwierzytelnianie odporne na phishing wchodzi do SAP GUI Druga zmiana jest dla CISO ważniejsza niż pierwsza. Logowanie do SAP GUI można chronić metodami bezhasłowymi: Windows Hello for Business, passkeys i tokenami FIDO2. Różnica wobec kodu jednorazowego nie jest kosmetyczna. Kod z aplikacji albo z wiadomości SMS użytkownik potrafi przepisać do okna, które wygląda jak Wasze, ale nim nie jest, a atakujący przepisze go dalej do prawdziwego logowania. Uwierzytelnianie odporne na phishing wiąże poświadczenie z konkretną domeną i konkretnym urządzeniem, więc nie ma czego przepisać. Jak wygląda atak, który omija drugi składnik bez łamania kryptografii, opisywaliśmy przy [kampanii Kali365 nadużywającej przepływu OAuth device code](https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-kali365-phishing-oauth-device-code/) - tam ofiara sama oddawała dostęp, mając włączone MFA. Dotąd rozmowa o silnym uwierzytelnianiu w SAP zwykle kończyła się na Fiori i na dostępie z przeglądarki, bo tam dało się to zrobić bez przebudowy. SAP GUI zostawał na boku, chociaż to w nim siedzą transakcje o największej wadze finansowej i to z niego korzystają administratorzy. Ta asymetria właśnie się domyka. ## Klucze przygotowane na erę komputerów kwantowych Trzecia zmiana dotyczy warstwy sieciowej: ruch między SAP GUI a systemami SAP jest chroniony wymianą kluczy odporną na komputery kwantowe. Chodzi o scenariusz „zbierz teraz, odszyfruj później”, w którym ktoś nagrywa dziś sesję, a odszyfrowuje ją za lat kilkanaście, kiedy dzisiejsze szyfrowanie przestanie być barierą. Dla danych kadrowych, cenników i warunków kontraktów okres poufności bywa dłuższy niż horyzont, który zwykle zakładamy. ![Diagram: trzy zmiany w wydaniu 5.1 - SSO i MFA bez Active Directory, uwierzytelnianie odporne na phishing, wymiana kluczy odporna na kwanty](https://snok.ai/images/blog/trustbroker-5-1-co-nowego.webp) To temat, który wraca w naszych rozmowach coraz częściej i który rozwijaliśmy w tekście o [szyfrowaniu w erze komputerów kwantowych](https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-quantum-i-postquantum-security-w-erze-ai-czy-twoje-szy/). Tutaj wystarczy uwaga praktyczna: producent nazywa mechanizm „quantum-safe key exchange” i nie podaje ani algorytmu, ani tego, czy tryb jest hybrydowy. Jeżeli macie własną politykę kryptograficzną, to jest pierwsze pytanie do zadania przed pilotażem. ## To nie jest wyłącznie logowanie TrustBroker sam w sobie nie jest nowością, nowe jest wydanie. Warto o tym pamiętać, bo produkt robi coś więcej, niż wpuszcza użytkownika do systemu. Polityki uwierzytelniania leżą na każdym systemie SAP osobno i to administrator po Waszej stronie decyduje, kiedy polityka jest sprawdzana i jaka metoda wystarcza. Stąd bierze się mechanizm, który w rozmowach z CFO broni się najlepiej: podniesienie wymagań już po zalogowaniu. Użytkownik wchodzi przez pojedyncze logowanie, pracuje normalnie, a kiedy otwiera wrażliwą transakcję albo dane, których nie otwiera na co dzień, system prosi o mocniejsze potwierdzenie tożsamości. Producent wymienia wśród warunków między innymi nietypową porę dostępu, inne urządzenie lub lokalizację oraz historię aktywności użytkownika, a w połączeniu z platformą SecurityBridge także alerty z wykrywania zagrożeń. ## Gdzie to działa Producent wymienia serwery aplikacyjne SAP: RISE with SAP S/4HANA Cloud Private Cloud Edition, SAP S/4HANA w instalacji własnej, SAP NetWeaver AS for ABAP, SAP BW/4HANA, SAP NetWeaver AS for Java oraz SAP BusinessObjects BI Platform. Wydanie 5.1.0 działa na serwerach Linux i Windows oraz na stacjach roboczych macOS i Windows; pozostałe platformy Unix, w tym AIX, mają trafić do późniejszego wydania. Doszło wsparcie dla Red Hat Enterprise Linux 10, SUSE Linux Enterprise Server 16 i SAP GUI 8.10, jest też certyfikacja Citrix Ready, więc sesje w Citrix Virtual Apps and Desktops korzystają z tego samego przepływu. Dla klientów w modelu RISE ważne jest jedno zdanie: producent deklaruje, że rozwiązanie jest dopuszczone dla RISE with SAP. To argument, który zdejmuje pierwszą obiekcję, jaka pada przy każdym pomyśle dołożenia czegokolwiek do systemu utrzymywanego przez SAP. ## Czego w materiale producenta nie ma Piszemy o tym osobno, bo lista rzeczy niepotwierdzonych jest częścią rzetelnej oceny produktu, a nie przypisem. Deklaracje o certyfikacji SAP i o dopuszczeniu dla RISE with SAP pochodzą ze strony producenta. Nie znaleźliśmy publicznego dokumentu SAP, który potwierdza je niezależnie, i przed decyzją poprosimy o numer scenariusza integracyjnego. Materiał nie mówi też, które przepływy OpenID Connect są obsługiwane ani jak rozwiązanie zachowuje się przy odświeżaniu tokenu w długiej sesji SAP GUI. Opisany jest klient SAP GUI dla Windows w wersji 8.10, więc zachowania dla SAP GUI for Java i dla SAP Business Client trzeba potwierdzić osobno. Nie ma publicznego cennika ani informacji o minimalnym poziomie jądra po stronie systemu SAP. Warto też wiedzieć, że strona produktowa jest starsza niż samo wydanie i nadal opisuje przepływ oparty o Active Directory - lista dostawców tożsamości jest na niej aktualna, narracja nie. ## Sześć pytań przed pilotażem **1/** Który system bierzecie pierwszy i co się dzieje, gdy logowanie w nim przestanie działać w środę rano **2/** Kto po Waszej stronie jest właścicielem polityki uwierzytelniania na poziomie systemu SAP, skoro polityka leży na każdym systemie osobno **3/** Jakie metody bezhasłowe macie już wdrożone dla pozostałych aplikacji i czy SAP wejdzie w ten sam schemat rejestracji urządzeń **4/** Które transakcje uznajecie za wrażliwe na tyle, żeby wymagały potwierdzenia tożsamości po zalogowaniu, i kto to zatwierdza **5/** Co zostaje w Active Directory po odłączeniu SAP i jaki jest wtedy harmonogram wygaszania katalogu **6/** Jak wygląda ścieżka awaryjna dla administratora, kiedy dostawca tożsamości jest niedostępny, a system produkcyjny wymaga interwencji Pytanie szóste w większości rozmów zostaje bez odpowiedzi dłużej niż pozostałe pięć razem wzięte, a to ono decyduje o tym, czy projekt jest gotowy do produkcji. ## Jak podchodzimy do tego w SNOK [SecurityBridge jest naszym partnerem technologicznym](https://snok.ai/pl/securitybridge-snok/), wdrażamy i utrzymujemy tę platformę u klientów, i mówimy o tym wprost, zanim padnie pierwsza rekomendacja. Nie twierdzimy przy tym, że TrustBroker jest jedynym rozwiązaniem tego problemu - pojedyncze logowanie i uwierzytelnianie wieloskładnikowe do SAP da się zbudować także inaczej, a wybór zależy od tego, gdzie trzymacie tożsamość, jak wygląda Wasz krajobraz i co już działa. To, co wnosi wydanie 5.1, jest natomiast zmianą w warunkach zadania, a nie w ofercie jednego dostawcy. Jeżeli Active Directory zostało u Was przy życiu głównie dla SAP, macie teraz argument, żeby wrócić do tej rozmowy z architektem tożsamości. Jeżeli chcecie, żebyśmy przeszli przez sześć pytań powyżej na Waszym krajobrazie, [odezwijcie się do nas](https://snok.ai/pl/kontakt/) - zaczynamy od przeglądu obecnej ścieżki logowania, nie od demonstracji produktu. --- *Materiał opisuje stan wiedzy na 14 września 2026 i opiera się o informacje opublikowane przez producenta. Zakres wsparcia, certyfikacje i warunki licencyjne potwierdzajcie w dokumentacji SecurityBridge oraz w swojej umowie przed podjęciem decyzji.*