Jako użytkownicy systemów SAP podczas logowania cyklicznie jesteśmy bombardowani prośbami o zmianę dotychczasowego hasła, za każdym razem stając przed wyzwaniem takiego jego skonstruowania, by spełnić oczekiwania co do długości i stopnia skomplikowania. Historia się powtarza przy każdej kolejnej aplikacji wykorzystywanej w pracy. A gdyby można było tego uniknąć? Gdyby tak zadbać tylko o jedno konto, jedno hasło, by móc bez przeszkód skupić się na pracy, a nie zapamiętywaniu haseł?

Znamy to przecież z używanych na co dzień usług mobilnych – do wielu codziennie używanych zasobów, jak chociażby platformy zakupów online, logujemy się za pośrednictwem kont mediów społecznościowych.

Dobra wiadomość jest taka, że i do SAP można się zalogować bez hasła.

Mechanizm Single Sign On w systemach SAP pozwala na uproszczenie i zautomatyzowanie dostępów. Wprowadzenie SSO to także zmniejszenie nakładu czasu pracy na zarządzanie bezpieczeństwem kont użytkowników przy jednoczesnym podniesieniu wygody użytkowania i pracy dzięki posiadaniu tylko jednego hasła dostępu do wielu systemów.

Z kolei centralne zarządzanie użytkownikami (Central User Administration) stanowi uzupełnienie pozwalające na zarządzanie kontami dostępów do systemów SAP oraz przypisanymi do nich uprawnieniami w jednym miejscu i automatyczną ich dystrybucję do systemów sprzężonych z tym mechanizmem.

To konieczność w firmach, w których na pejzaż systemu składa się nawet kilkanaście systemów i mandantów dla kilkuset użytkowników – dzięki temu mechanizmowi w prosty sposób możemy na wielu systemach powołać konto dla nowego pracownika, zmienić uprawnienia dla już istniejącego, zablokować konto czy zmienić do niego hasło, jeśli zdecydowaliśmy się na mechanizm CUA bez równoległego wdrożenia mechanizmów SSO w naszym środowisku SAP.

SSO 3.0 i SAML 2.0

W schemacie uwierzytelniania Single Sign On w systemach SAP dostępne są dwie metody komunikacji – pierwsza to SSO 3.0 oparta na tokenie Kerberos, druga wykorzystuje SSO SAML 2.0.

W metodzie komunikacji SSO 3.0 opartej na Kerberosie użytkownik loguje się kontem domenowym do swojej stacji roboczej, na której jest zainstalowany SAP Secure Login Client. W tym momencie otrzymuje token Kerberos przypisany do danej stacji i użytkownika. Podczas logowania do SAP informacja o tym fakcie jest przekazywana przez SAP Secure Login Client. W kolejnym kroku – po stronie SAP – informacja o tokenie z danej stacji roboczej jest honorowana. Następnie zostaje do niego przypisane konto użytkownika i mandant.

Podstawowe zalety tej metody to pełna integracja SAP z SSO (SAP Logon, HTTP/S, Fiori), duże bezpieczeństwo mechanizmu SSO oraz łatwa implementacja. Warto też podkreślić, że z punktu widzenia użytkowników SSO 3.0 to jedna z najwygodniejszych metod autoryzacji na stacjach roboczych.

Do wad należy zaliczyć możliwość integracji SSO jedynie z Active Directory oraz konieczność wykupienia dodatkowej licencji SAP.

W drugiej metodzie komunikacji, opartej na SSO SAML 2.0, w pierwszym kroku użytkownik próbuje się zalogować do systemu z SSO przez to rozwiązanie. Jego żądanie jest automatycznie przekazywanie do dostawcy tożsamości w celu uwierzytelnienia. Dostawca tożsamości wysyła zapytanie do użytkownika z prośbą o wpisanie poświadczeń. Po przedstawieniu przez użytkownika lub agenta użytkownika żądanych poświadczeń i ich weryfikacji wysyłana jest informacja zwrotna o przydzieleniu dostępu dla wskazanego użytkownika.

SAML 2.0 można zintegrować zarówno z Active Directory, jak i AWS, Azure i innymi chmurami publicznymi. Nie jest wymagana dodatkowa licencja SAP. Implementacja tej metody jest stosunkowo łatwa.

Do wad należy zaliczyć fakt, że SSP SAML 2.0 nie działa dla dostępu przez SAP Logon.

SSO w praktyce

Przedstawiamy przykład integracji narzędzia do logowania za pomocą Single Sign On z systemami SAP, którą wykonaliśmy dla jednego z naszych klientów w celu zniwelowania konieczności kilkukrotnego logowania.

Podczas wdrożenia SAP Fiori klient poprosił nas o zweryfikowanie możliwości wykorzystania platformy autoryzacyjnej, której używał przy dostępie do innych, wewnętrznych systemów do logowania do SAP Fiori Launchpad. Wystarczyło podanie służbowego adresu e-mail i jednokrotne wpisanie hasła i już użytkownik uzyskiwał dostęp do innych systemów w przedsiębiorstwie. Integracja pozwala nam uniknąć konieczności wykonania ponownego logowania, co zwiększyłoby komfort użytkowania SAP Fiori.

Z pomocą przyszedł nam protokół SAML 2.0, który jest wykorzystywany do pośredniczenia w uwierzytelnianiu i automatycznym przekazywaniu między systemami i aplikacjami informacji o uprawnieniach użytkownika. Warto podkreślić, że do logowania można wykorzystać aplikację każdego dostawcy tożsamości (IdP) pozwalającego na wykorzystanie SAML (np. Azure ADFS, Google).

Podstawowa konfiguracja rozwiązania w systemie SAP ogranicza się do aktywacji odpowiednich węzłów ICF (Internet Communication Framework) oraz utworzenia tzw. Local Providera po stronie systemu SAP i dostawcy tożsamości, a także wymiany danych dotyczących providerów za pomocą wygenerowanych plików .xml).

Później należało tylko skonfigurować mapowanie pola, po którym użytkownik będzie rozpoznawany w systemie SAP. Może to być np. nazwa użytkownika, adres e-mail, nazwisko lub inne pole.

Obecnie pracownicy naszego klienta mogą cieszyć się działającym logowaniem SSO.

Misja: centralizacja

Innym aspektem zarządzania użytkownikami w SAP jest rozrost skali środowisk systemowych/mandantów i związany z tym znaczny wzrost czasu obsługi użytkowników przy tworzeniu kont, zarządzaniu uprawnieniami oraz odblokowywaniu i zmianie haseł.

Jeden z klientów zgłosił się do nas, oczekując rozwiązania problemu z administracją użytkownikami, w tym zauważalnie wydłużającym się czasem obsługi.

Zaproponowaliśmy rozwiązanie centralnego zarządzania użytkownikami (Central User Administration). Obecnie dzięki CUA administratorzy klienta mogą w łatwiejszy, tańszy i szybszy sposób zarządzać użytkownikami na wszystkich systemach SAP. Z jednego miejsca tworzą konta, zarządzają uprawnieniami oraz mogą zmieniać hasła czy odblokować konta. Scentralizowane zarządzanie uprawnieniami jest dużo wydajniejsze. Poprawiło się także bezpieczeństwo, jeśli chodzi o uprawnienia dostępu do systemów i danych.

No i jeszcze jedno – co bardzo spodobało się naszemu klientowi – by korzystać z CUA, nie trzeba instalować dodatkowego systemu ani wykupywać nowych licencji.

Jeden zespół, jeden administrator bezpieczeństwa – z jednego miejsca może równocześnie wykonać zmianę dla użytkowników na wielu systemach. Zmiany wykonane w systemie centralnym są automatycznie przesyłane na systemy satelitarne za pomocą technologii SAP Application Link Enabling (ALE). Nie ma już potrzeby logowania się na każdy system/mandant osobno.

Także zmiana w danych podstawowych konkretnego użytkownika (np. numer telefonu, nazwisko) jest automatycznie propagowana na wszystkie systemy, na których występuje.

CUA jest bardzo przydatne przy zarządzaniu zespołami, wdrażaniu nowych rozwiązań, zastępstwach pracowników itp. Ułatwia również zarządzanie licencjami przydzielonymi poszczególnym użytkownikom i pozwala mieć nad nimi pełną kontrolę.