Serwer autoryzacji

---

Niniejszy rozdział stanowi opis serwera autoryzacji OpenID Connect — kompleksowego systemu uwierzytelniania i autoryzacji, który odpowiada za zarządzanie tożsamościami użytkowników, kontrolę dostępu do aplikacji oraz realizację mechanizmu jednokrotnego logowania (Single Sign-On) w środowisku wieloaplikacyjnym.

Funkcje systemu:

1. Uwierzytelnianie użytkowników — weryfikacja tożsamości osób korzystających z systemu
2. Zarządzanie kontami — administrowanie kontami użytkowników, przypisywanie ról oraz definiowanie atrybutów
3. Kontrola dostępu — precyzyjne zarządzanie uprawnieniami do aplikacji i zasobów
4. Jednokrotne logowanie (SSO) — jeden zestaw poświadczeń zapewnia bezpieczny dostęp do wielu aplikacji jednocześnie
5. Uwierzytelnianie wieloskładnikowe (MFA) — dodatkowa warstwa zabezpieczeń wykraczająca poza standardowe hasło
6. Integracja z zewnętrznymi dostawcami tożsamości — obsługa logowania za pośrednictwem platform takich jak Google, Microsoft i innych
7. Audyt zdarzeń bezpieczeństwa — systematyczne rejestrowanie i przechowywanie dzienników wszystkich istotnych zdarzeń w systemie

Dostęp do systemu możliwy jest dla administratora po zalogowaniu się do aplikacji webowej.

1. Przejdź do VSoft archITekt Launcher i otwórz stronę projektu.

2. Zaloguj się i przejdź na panel Administracja.

Czym jest OpenID Connect?

OpenID Connect (OIDC) to nowoczesny protokół uwierzytelniania, który umożliwia użytkownikom dostęp do wielu aplikacji za pomocą jednego zestawu danych logowania. Zasada jego działania przypomina „klucz główny" — użytkownik loguje się jednokrotnie, po czym uzyskuje dostęp do wszystkich powiązanych aplikacji bez konieczności ponownego podawania poświadczeń.

Kluczowe pojęcia

Uwierzytelnianie vs. Autoryzacja

1. Uwierzytelnianie (Authentication) odpowiada na pytanie: Kim jesteś? — weryfikacja tożsamości za pomocą loginu i hasła.
2. Autoryzacja (Authorization) odpowiada na pytanie: Co możesz robić? — określanie uprawnień i dostępu do zasobów.

Ważne terminy:

1. Token - Bezpieczny cyfrowy identyfikator potwierdzający, że użytkownik został uwierzytelniony — jak tymczasowa przepustka.
2. Client (Klient) - Aplikacja, która chce uwierzytelnić użytkownika (np. VSoft Scheduler).
3. Scope - Określa, jakie informacje lub uprawnienia są żądane.
4. Claim - Informacja o użytkowniku (np. adres e‑mail, imię, rola).
5. Grant - Uprawnienie do dostępu do zasobów, przyznane po pomyślnym uwierzytelnieniu.
6. Redirect URI - Adres internetowy, pod który użytkownik wraca po uwierzytelnieniu.
7. Logout redirect URI - Adres internetowy, pod który użytkownik wraca po wylogowaniu.

Przepływy uwierzytelniania

Serwer autoryzacji stosuje różne schematy (flows) w zależności od tego, jaka aplikacja żąda dostępu do zasobów.

Authorization Code Flow

(Najczęściej stosowany przykład: aplikacja Scheduler)

1. Użytkownik próbuje uzyskać dostęp do aplikacji.
2. Aplikacja przekierowuje go do serwera autoryzacji.
3. Użytkownik loguje się, podając nazwę użytkownika i hasło.
4. Serwer autoryzacji zwraca aplikacji tymczasowy kod autoryzacyjny.
5. Aplikacja wymienia kod na ID token oraz access token.
6. Aplikacja wykorzystuje otrzymane tokeny, aby uzyskać dostęp do chronionych zasobów w imieniu użytkownika.

Client Credentials Flow

(Wykorzystywany do komunikacji system–system; np. auth‑api używane przez Workflow i VTS)

1. Aplikacja uwierzytelnia się bez udziału użytkownika przy użyciu client ID oraz client secret.
2. Serwer autoryzacji zwraca token dostępu.
3. Flow wykorzystywany jest głównie w zadaniach w tle oraz komunikacji między usługami (API‑to‑API).

Użytkownicy

Serwer autoryzacji obsługuje różne typy użytkowników, z których każdy ma określone cechy i możliwości zarządzania.

Typy użytkowników

System rozpoznaje trzy różne typy kont użytkowników:

1. Użytkownicy lokalni (Local Users)

1. Użytkownicy lokalni są w pełni zarządzani w obrębie serwera autoryzacji.
2. Ich dane uwierzytelniające przechowywane są lokalnie, a oni sami mają możliwość samodzielnej zmiany hasła w systemie.
3. Zapewniają pełne wsparcie wszystkich funkcjonalności, w tym uwierzytelniania wieloskładnikowego (MFA).

Typowe zastosowanie:

pracownicy wewnętrzni oraz administratorzy systemu.

2. Użytkownicy federacyjni (Federation Users)

1. Użytkownicy federacyjni to konta synchronizowane z zewnętrznych systemów katalogowych (np. Active Directory) na podstawie klucza common.param.user_provider
2. Hasła są zarządzane wyłącznie w systemie zewnętrznym, dlatego nie ma możliwości ich zmiany w systemie lokalnym. Proces uwierzytelniania również odbywa się względem zewnętrznego katalogu.
3. System obsługuje MFA, a atrybuty użytkownika oraz jego przynależność do grup są synchronizowane podczas logowania lub automatycznie (np. poprzez zadania pakietów przetwarzania danych).

Typowe zastosowanie:

użytkownicy korporacyjni korzystający z istniejącej infrastruktury katalogowej.

3. Użytkownicy dostawcy tożsamości (Identity Provider Users)

1. Konta te są powiązane z zewnętrznymi dostawcami tożsamości (np. Google, Microsoft, Azure AD).
2. Zarządzanie hasłami odbywa się całkowicie po stronie dostawcy zewnętrznego, a użytkownik nie może zmienić hasła w systemie lokalnym. Uwierzytelnianie jest delegowane na zewnętrzny system.
3. W tym przypadku lokalne MFA nie jest dostępne — mechanizmy uwierzytelniania wieloskładnikowego obsługiwane są przez dostawcę tożsamości.

Typowe zastosowanie:

logowanie społecznościowe oraz integracje B2B.

Ważne uwagi

1. Użytkownicy federacyjni oraz IdP zmieniają hasła wyłącznie w systemach zewnętrznych
2. Użytkownicy IdP nie mogą korzystać z lokalnego MFA, ponieważ uwierzytelnianie odbywa się poza systemem
3. Użytkownicy lokalni oferują największą elastyczność i pełne wsparcie funkcjonalne

Dodawanie użytkownika lokalnego

Najważniejsze dane jakie należy wprowadzić to podstawowe dane użytkownika oraz ustawienie hasła dla konta.

1. Wybierz przycisk Dodaj użytkownika.

2. W kolejnym oknie na formularzu tworzenia nowego konta wprowadź podstawowe dane i wybierz Zapisz.

Na ekranie edycji użytkownika dostępne są pola umożliwiające zarządzanie podstawowymi danymi oraz statusem ich weryfikacji.

W szczególności:

1. Email zweryfikowany – opcja pozwala oznaczyć, czy adres e-mail użytkownika został potwierdzony.
2. Numer telefonu zweryfikowany – analogicznie określa, czy numer telefonu przeszedł proces weryfikacji.

Zaznaczenie tych pól wskazuje, że dane kontaktowe zostały potwierdzone i mogą być uznane za wiarygodne (np. do komunikacji systemowej lub procesów bezpieczeństwa, takich jak MFA).

3. Zmiany wprowadzone w formularzu zatwierdź przyciskiem Zapisz.

wskazówka

Dla użytkownika, aby był w pełni aktywny należy ustawić hasło na zakładce Bezpieczeństwo.

4. Wprowadź hasło zgodne z polityką haseł i wybierz Zmień hasło.

Zarządzanie użytkownikami lokalnymi

Użytkownicy, którzy zostali dodani lokalnie w serwerze autoryzacji (czyli nie pochodzą z federacji), mogą być zarządzani bezpośrednio przez administratora.

Administrator może wykonać następujące operacje na ich kontach:

1. dezaktywować konto – użytkownik traci możliwość logowania, ale jego dane pozostają w systemie; w każdej chwili użytkownika można ponownie aktywować,
2. usunąć trwale konto – użytkownik i wszystkie powiązania zostają całkowicie usunięte z bazy danych; czynności tej nie można usunąć,
3. zarchiwizować konto – dane użytkownika pozostają dostępne do celów audytowych, ale konto nie jest aktywne; użytkownika można przywrócić w każdym momencie.

Operacje te są dostępne wyłącznie dla użytkowników lokalnych oraz zmigrowanych z poprzedniego systemu VIP.

Użytkownicy pobierani z Azure AD (lub innej federacji) są zarządzani po stronie dostawcy tożsamości i nie mogą być usuwani ani edytowani lokalnie.

Weryfikacja dwuetapowa

Każdy użytkownik po zalogowaniu do systemu może włączyć weryfikację dwuetapową dla swojego konta.

1. Przejdź do ustawień konta i wybierz Konto użytkownika.

2. Wybierz metodę weryfikacji. W zakładce Bezpieczeństwo kliknij Dodaj w sekcji Metody dwuetapowe. Możesz skorzystać z:

• aplikacji uwierzytelniającej,
• rozszerzenia przeglądarki.

Oba rozwiązania umożliwią generowanie kodów potrzebnych do logowania.

3. Dodaj konto w aplikacji uwierzytelniającej. Zeskanuj kod QR za pomocą aplikacji uwierzytelniającej.
4. Przepisz jednorazowy kod wygenerowany przez aplikację uwierzytelniającą i Zapisz dane.

5. Jeśli nie możesz zeskanować kodu kliknij klucz konfiguracji, skopiuj go i wklej do aplikacji.

6. Po zapisaniu zmian pobierz kody odzyskiwania. Umożliwią one dostęp do konta w sytuacji utraty urządzenia lub braku dostępu do aplikacji uwierzytelniającej.

Od tej chwili podczas logowania do systemu, po wprowadzeniu loginu i hasła, zobaczysz okno wymagające drugiego etapu weryfikacji.

Wprowadź kod z aplikacji uwierzytelniającej lub – w razie potrzeby – użyj jednego z kodów odzyskiwania (opcja Recovery code).

Weryfikację dwuetapową możesz w każdej chwili wyłączyć oraz wygenerować nowe kody odzyskiwania.

1. Przejdź do szczegółów swojego konta i na zakładkę Bezpieczeństwo.
2. Wybierz opcję Wyłącz weryfikację dwuetapową.

3. Przejdź do sekcji Kody odzyskiwania i wybierz Edytuj.
4. W kolejnym oknie wybierz Wygeneruj nowe kody odzyskiwania.

wskazówka

Najlepiej pobrać i zapisać kody, gdyż nie będzie można ich wyświetlić drugi raz.

Zmiana hasła

W celu zmiany hasła:

1. w prawym górnym rogu przejdź na Konto użytkownika a następnie kartę Bezpieczeństwo.
2. W sekcji Zmiana hasła:

• wpisz stare hasło,
• wpisz nowe hasło,
• potwierdź nowe hasło.

3. Hasło musi spełniać wymagania bezpieczeństwa (odpowiednia długość, różne typy znaków).
4. Kliknij Zaktualizuj hasło, aby zapisać zmiany.
5. Jeśli nie pamiętasz hasła, użyj opcji Zapomniałeś hasła?

Automatyczna migracja użytkowników i ról z poprzedniego systemu VIP

Jeżeli w poprzednim systemie zarządzania użytkownikami i rolami VIP były już utworzone konta użytkowników oraz przypisane role, wówczas po:

1. pobraniu aktualnej wersji archITekt,
2. podbiciu (aktualizacji) projektu,

proces migracji danych użytkowników i ról wykonywany jest automatycznie.

Po wykonaniu tej migracji w module Federacje użytkowników pojawi się federacja oznaczona jako: VIP.

To potwierdza, że dane użytkowników zostały zaimportowane z poprzedniego systemu i działają w trybie federacji.

wskazówka

Lista kont użytkowników jest widoczna dla administratora po zalogowaniu się każdego użytkownika do systemu.

Oznacza to, że konto pojawia się w panelu administracyjnym dopiero wtedy, gdy użytkownik wykona pierwsze logowanie.

Automatyczne podniesienie bezpieczeństwa hasła (rehash do Argon2id)

W momencie logowania użytkownika, system automatycznie ponownie przelicza (rehashuje) jego hasło, konwertując je na bardziej bezpieczny algorytm: Argon2id. Jest to nowoczesny, rekomendowany algorytm szyfrowania haseł, zapewniający:

1. wysoki poziom odporności na ataki słownikowe i brute‑force,
2. zabezpieczenia oparte na pamięci (memory-hard),
3. zgodność z aktualnymi standardami bezpieczeństwa.

Proces rehashowania odbywa się:

1. samoczynnie,
2. bez udziału użytkownika,
3. tylko przy pierwszym logowaniu po aktualizacji systemu,
4. bez konieczności zmiany hasła przez użytkownika.

Po jego wykonaniu hasło jest już przechowywane w bazie w formacie Argon2id. Sprawdzić to możesz w tabeli USER_ACCOUNT

Konfiguracja połączenia z Azure AD w celu pobierania użytkowników

Aby poprawnie skonfigurować federację użytkowników z Azure AD i umożliwić pobieranie użytkowników do serwera autoryzacji, należy wykonać dwa etapy działań: w VSoft archITekt Launcher oraz w serwerze autoryzacji.

1. Konfiguracja w VSoft archITekt Launcher

Przed skonfigurowaniem federacji użytkowników w serwerze autoryzacji konieczne jest dodanie odpowiednich kluczy konfiguracyjnych po stronie środowiska.

1. Przejdź do VSoft archITekt Launcher i otwórz stronę rekonfiguracji projektu.
2. W sekcji Modify Config Keys wybierz opcję Edit config keys.

3. Z listy Features wybierz pozycję: Configure the connection to the AD server.
4. Następnie uzupełnij wymagane klucze konfiguracyjne, aby nawiązać poprawne połączenie z usługą Active Directory.
5. Po wprowadzeniu danych kliknij OK, a następnie wybierz Reconfigure project, aby zapisać i zastosować zmiany.

ostrzeżenie

Bez prawidłowego uzupełnienia kluczy federacja użytkowników nie będzie działać, a synchronizacja zakończy się błędem.

2. Synchronizacja w serwerze autoryzacji

Po poprawnym uzupełnieniu kluczy konfiguracyjnych wykonujemy synchronizację danych.

1. Zaloguj się jako administrator i przejdź do serwera autoryzacji.
2. Otwórz zakładkę Federacje użytkowników.
3. Następnie wybierz przycisk Synchronizuj użytkowników i role.

Przycisk uruchamia wykonanie odpowiedniego pakietu przetwarzania, który znajduje się w katalogu System w aplikacji archITekt Studio.

Po synchronizacji:

1. użytkownicy zostaną pobrani z Azure AD,

2. dane zostaną zapisane w serwerze autoryzacji,

3. kolumna Ostatnia pełna synchronizacja zostanie zaktualizowana,

4. licznik Użytkownicy w federacji pokaże aktualną liczbę rekordów.

5. Przejdź do zakładki Federacje użytkowników i zaznacz na liście źródeł federacji pozycję AD.

6. Po jej wybraniu, po prawej stronie zostanie wyświetlona lista wszystkich użytkowników pobranych z Active Directory.

7. Aby podejrzeć szczegóły konfiguracji wybranej federacji użytkowników w ostatniej kolumnie wiersza znajduje się przycisk podglądu.
8. Kliknij ten przycisk — zostaniesz przeniesiona do ekranu, na którym wyświetlane są klucze konfiguracyjne.

Wszystkie klucze konfiguracyjne znajdziesz w bazie CONFIG_DB w tabeli CONFIG_KEYS

Role

Role określają, do czego użytkownik ma dostęp w systemie. Można je przypisywać użytkownikom, aby kontrolować ich uprawnienia.

System obsługuje dwa typy ról:

1. Role lokalne (Local Roles)

Role lokalne są tworzone i zarządzane w całości w serwerze autoryzacji:

1. możesz je samodzielnie tworzyć, edytować i usuwać
2. służą do nadawania uprawnień specyficznych dla aplikacji
3. dają pełną kontrolę nad tym, kto ma dostęp do konkretnych funkcji

Kiedy używać?

Gdy chcesz zarządzać dostępem w obrębie aplikacji (np. administrator, edytor, użytkownik).

2. Role federacyjne (Federation Roles)

Role federacyjne pochodzą z zewnętrznych systemów katalogowych (np. Active Directory) i są automatycznie synchronizowane.

1. są tworzone i aktualizowane automatycznie poprzez synchronizację katalogu
2. nie można ich edytować ani usuwać w systemie lokalnym
3. odzwierciedlają grupy bezpieczeństwa lub role z katalogu źródłowego na podstawie klucza common.param.role_provider
4. odzwierciedlają strukturę organizacji (np. działy, grupy)

Kiedy używać?

Gdy korzystasz z istniejącej struktury firmy i chcesz ją odwzorować w systemie.

Ważne informacje

Role federacyjne są tylko do odczytu w systemie lokalnym – zmiany należy wprowadzać w katalogu źródłowym.

Synchronizacja automatycznie aktualizuje przynależność do ról oraz może dodawać lub usuwać role.

Użytkownik może mieć jednocześnie role lokalne i federacyjne.

Przypisywanie ról opiera się na zasadzie: role lokalne służą do obsługi logiki aplikacji, a role federacyjne do struktury organizacyjnej.

Dodanie roli lokalnej

Aby dodać nową rolę lokalną w serwerze autoryzacji:

1. przejdź na zakładkę Role,
2. wybierz przycisk Dodaj rolę,
3. wprowadź nazwę roli i Zapisz dane.

Przypisanie roli lokalnej do użytkownika

Role dodane lokalnie mogą być przypisywane zarówno do kont lokalnych, jak i do kont federacyjnych (np. pobranych z Azure AD).

Aby przypisać rolę użytkownikowi, wykonaj poniższe kroki:

1. Przejdź do listy użytkowników

1. Zaloguj się do serwera autoryzacji jako administrator.
2. Otwórz zakładkę Użytkownicy.
3. Znajduje się tam pełna lista wszystkich kont:

• lokalnych,
• federacyjnych (np. z Azure AD),
• z migracji VIP.

2. Otwórz szczegóły użytkownika

W tabeli użytkowników:

1. Odszukaj odpowiednie konto.
2. W ostatniej kolumnie wybierz przycisk szczegółów.
3. Otworzy to pełne informacje o użytkowniku.

3. Przejdź na zakładkę Role i wybierz role do przypisania

W widoku szczegółów konta użytkownika:

1. Otwórz zakładkę Role.
2. Kliknij przycisk Przypisz rolę.
3. Na liście dostępnych ról zaznacz te role, które chcesz przypisać użytkownikowi.
4. Kliknij Przypisz.

Rola zostanie natychmiast dodana do użytkownika i będzie widoczna w jego profilu.

wskazówka

Role lokalne mogą być przypisywane do każdego konta, niezależnie od źródła jego pochodzenia.

Role federacyjne (jeśli istnieją) są przypisywane automatycznie na podstawie federacji i nie można ich usuwać lokalnie.

Po przypisaniu roli użytkownik od razu zyskuje odpowiednie uprawnienia w systemie.

Najlepsze praktyki w zakresie zarządzania użytkownikami i rolami

Wybór odpowiedniego typu użytkownika:

1. Używaj użytkowników lokalnych w przypadku kont systemowych, testów lub gdy nie istnieje zewnętrzny katalog.
2. Używaj użytkowników federacyjnych podczas integracji z katalogami korporacyjnymi i scentralizowanymi zasadami dotyczącymi haseł.
3. Używaj użytkowników IdP w przypadku logowania za pomocą serwisów społecznościowych, partnerów zewnętrznych lub gdy korzystasz z istniejących dostawców tożsamości.

Strategia zarządzania rolami:

1. Używaj ról lokalnych dla uprawnień specyficznych dla aplikacji, które nie istnieją w systemach zewnętrznych
2. Używaj ról federacyjnych, aby wykorzystać istniejące struktury organizacyjne i grupy bezpieczeństwa
3. Połącz oba typy, aby stworzyć elastyczną kontrolę dostępu: role federacyjne dla przynależności organizacyjnej, role lokalne dla funkcji aplikacji.

Kwestie bezpieczeństwa:

1. Użytkownicy federacyjni i IdP dziedziczą zasady dotyczące haseł z systemów zewnętrznych
2. W przypadku użytkowników lokalnych należy egzekwować zasady dotyczące silnych haseł na poziomie serwera autoryzacji
3. Regularna synchronizacja zapewnia, że użytkownicy i role federacyjne są aktualne względem katalogu źródłowego
4. Przy wyborze między metodą uwierzytelniania lokalnego a IdP należy wziąć pod uwagę wymagania dotyczące uwierzytelniania wieloskładnikowego (MFA)

Klienci

Na tej stronie znajdziesz wszystkie aplikacje (klientów), które korzystają z logowania poprzez serwer autoryzacji.

wskazówka

Aktywny klient (włączony) może być używany do logowania. Jeśli chcesz tymczasowo zablokować dostęp, wyłącz klienta zamiast go usuwać.

Konfiguracja klientów aplikacji

1. Kliknij Dodaj klienta, aby skonfigurować nową aplikację.

Na tej stronie dodajesz lub edytujesz aplikację (klienta), która będzie korzystać z logowania przez serwer autoryzacji.

Podstawowe informacje

1. Nazwa aplikacji– wpisz czytelną nazwę aplikacji (np. „Panel użytkownika”, „API systemu”)
2. Identyfikator klienta – unikalny identyfikator aplikacji (generowany automatycznie lub nadawany ręcznie)

Sposób autoryzacji

1. Użyj sekretu klienta - gdy opcja włączona wówczas klient będzie uwierzytelniany przy użyciu sekretu klienta (client secret). Stosowane najczęściej w aplikacjach serwerowych. Zalecane dla aplikacji wymagających wyższego poziomu bezpieczeństwa.
2. Logowanie użytkownika - umożliwia użytkownikom logowanie i nadanie aplikacji dostępu w ich imieniu.
3. Dostęp serwisowy - pozwala aplikacji uzyskiwać dostęp do zasobów bez zalogowanego użytkownika.

Adresy przekierowań

1. Dozwolone adresy przekierowania po logowaniu - Podaj adresy, na które użytkownik zostanie przekierowany po zalogowaniu. Muszą być dokładnie zgodne z adresami w aplikacji (ze względów bezpieczeństwa).
2. Dozwolone adresy przekierowania po wylogowaniu - dodaj adresy, na które użytkownik trafi po wylogowaniu. Np. strona główna lub ekran potwierdzenia wylogowania.
3. Adresy muszą być oddzielone przecinkiem.

System obsługuje wiele aplikacji:

archITekt Remote Client

1. Przepływ: Authorization Code + PKCE
2. Klucze:

• common.auth.client.archITekt_remote_issuer
• common.auth.client.archITekt_remote_client_id

Auth API Client

1. Przepływ: Client Credentials (bez udziału użytkownika)
2. Klucze:

• common.auth.client.auth_api_issuer
• common.auth.client.auth_api_client_id
• common.auth.client.auth_api_client_secret (wrażliwy)

Scheduler Client

1. Przepływ: Authorization Code + PKCE
2. Klucze:

• scheduler.auth.client.issuer
• scheduler.auth.client.client_id
• scheduler.auth.client.client_secret

Federacje użytkowników

Federacja użytkowników umożliwia automatyczne synchronizowanie kont oraz ról z zewnętrznych systemów (np. systemów dziedzinowych, LDAP, IdP czy baz danych) do serwera autoryzacji.

Dzięki federacji administrator nie musi ręcznie dodawać użytkowników — są oni importowani i aktualizowani zgodnie z konfiguracją źródła.

Synchronizacja użytkowników i ról

U góry strony znajduje się przycisk Synchronizuj użytkowników i role. Umożliwia ręczne wymuszenie procesu synchronizacji we wszystkich federacjach.

Po kliknięciu system:

1. pobiera użytkowników z zewnętrznego źródła,
2. aktualizuje ich dane,
3. odświeża przypisane role,
4. zapisuje wynik synchronizacji.

Synchronizacja może potrwać od kilku sekund do kilku minut — zależnie od liczby użytkowników i wydajności źródła danych.

Na podstawie ekranu możesz:

1. sprawdzić, czy synchronizacja działa,
2. ustalić kiedy ostatnio przebiegła poprawnie,
3. zweryfikować liczbę zaimportowanych użytkowników,
4. wykryć problemy (np. brak synchronizacji lub zmiana liczby użytkowników).

Po zmigrowaniu danych z poprzedniego systemu do zarządzania użytkownikami i rolami na liście będzie widoczna federacja Vip migration. Jeżeli skonfigurujesz pobranie użytkowników z Ad będzie widoczna federacja AD.

Po zmigrowaniu danych z poprzedniego systemu do zarządzania użytkownikami i rolami VIP, w sekcji Federacje użytkowników pojawi się federacja:

1. VIP (migration) - Oznacza to, że konta użytkowników oraz ich role zostały poprawnie przeniesione z dotychczasowego systemu i są obsługiwane w trybie federacji migracyjnej - patrz: Automatyczna migracja użytkowników i ról z poprzedniego systemu VIP.
2. AD - Jeżeli skonfigurujesz w systemie pobieranie użytkowników z Azure AD. Wskazuje ona, że w systemie działa federacja oparta o Azure Active Directory, a użytkownicy są pobierani z niej automatycznie zgodnie z konfiguracją - patrz: Konfiguracja połączenia z Azure AD w celu pobierania użytkowników.

wskazówka

Obie federacje mogą współistnieć równolegle w systemie.

Administrator może w każdej chwili wejść w szczegóły federacji, aby zweryfikować liczbę użytkowników oraz datę ostatniej synchronizacji.

Dostawcy tożsamości

Dostawcy tożsamości (ang. Identity Providers, IdP) to systemy lub serwisy, które uwierzytelniają użytkowników i dostarczają informacje o ich tożsamości innym aplikacjom lub usługom.

Co robią dostawcy tożsamości?

1. Sprawdzają, czy użytkownik podał poprawne dane logowania (login/hasło, token, certyfikat itp.).
2. Przekazują aplikacjom informacje o użytkowniku (np. imię, rola, uprawnienia).
3. Umożliwiają jednokrotne logowanie (SSO) między wieloma aplikacjami.

Przykłady dostawców tożsamości:

1. Google – logowanie przez konto Google
2. Microsoft / Azure AD – logowanie przez konto Microsoft lub organizacyjne
3. Facebook, GitHub – logowanie społecznościowe
4. Keycloak, Okta, Auth0 – narzędzia korporacyjne i enterprise

Dlaczego są ważni?

1. Upraszczają zarządzanie użytkownikami
2. Zwiększają bezpieczeństwo (MFA, polityki haseł)
3. Ułatwiają integrację aplikacji w firmie lub ekosystemie usług

Konfiguracja dostawcy tożsamości umożliwia logowanie użytkowników do systemu za pomocą zewnętrznego serwera OAuth/OIDC (np. Azure AD, Entra ID, Keycloak, Auth0 itd.).

1. Przejdź na menu Dostawcy użytkowników i wybierz Dodaj dostawcę tożsamości.

2. Przekaż adres URL zwrotu (callback) do dostawcy tożsamości. W górnej części ekranu wyświetla się adres, który należy skopiować do konfiguracji w zewnętrznym IdP: http://localhost:44310/Project/auth/callback/4403b9b0-e7af-4698-91ad-ccf53ac5ee1d
3. W sekcji Szczegóły dostawcy tożsamości uzupełnij następujące pola:

• Typ - wybierz dostawcę tożsamości, przez którego użytkownicy będa mogli sie logować. Możesz również wybrać opcję OpenID Connect, aby skonfigurować własnego dostawcę.
• Nazwa wyświetlana- Nazwa widoczna dla użytkownika podczas wyboru metody logowania. Powinna być krótka i rozpoznawalna.
• Wydawca - Adres URL dostawcy tożsamości. Serwer używa go do weryfikacji dostawcy i potwierdzania logowań użytkowników.
• Identyfikator klienta - Unikalny kod przypisany do twojej aplikacji przez dostawcę tożsamości. Identyfikuje aplikację podczas logowania użytkowników.
• Sekret klienta - Tajny klucz wydany przez dostawce tożsamości. Działa razem z Client ID, aby potwierdzić, że aplikacja jest zaufana. Nigy nie udostępniaj go publicznie.
• Zakres- Określa, jakie informacje o użytkowniku aplikacja pobierze od dostawcy np. imię lub adres e-mail.

Po zapisaniu:

1. Wyloguj się z aplikacji.
2. Spróbuj zalogować się ponownie wybierając skonfigurowanego dostawcę tożsamości.
3. Jeśli wystąpi błąd — najczęstsze przyczyny to:

• Wydawca nie zgadza się z konfiguracją OIDC.
• Adres URL przekierowania nie został dodany w dostawcy tożsamości (IdP).
• Nieprawidłowy sekret lub identyfikator klienta (client ID).

Struktura bazy danych

Serwer autoryzacji przechowuje wszystkie dane w bazie SQL. Baza jest zorganizowana w logiczne grupy tabel, z których każda pełni określoną funkcję.

Baza danych zawiera tabele podzielone na następujące kategorie:

Tabele zarządzania użytkownikami

1. USER_ACCOUNT - Przechowuje podstawowe informacje o koncie użytkownika, takie jak nazwa użytkownika, e-mail oraz zahaszowane hasło. Śledzi stan konta (aktywne, tymczasowo zablokowane, usunięte) oraz tzw. security stamp do unieważniania sesji.
2. USER_CLAIM - Powiązuje niestandardowe atrybuty z kontami użytkowników. Umożliwia przechowywanie elastycznych danych użytkownika wykraczających poza standardowe pola profilu, takich jak dział, numer pokoju czy niestandardowe atrybuty biznesowe.
3. USER_ROLE - Łączy użytkowników z rolami w celu realizacji kontroli dostępu opartej na rolach. Jeden użytkownik może mieć wiele ról, a tabela śledzi te powiązania.
4. USER_FEDERATION - Łączy konta użytkowników z zewnętrznymi systemami katalogowymi (np. Active Directory). Przechowuje identyfikator użytkownika w systemie zewnętrznym oraz metadane synchronizacji, utrzymując relację jeden-do-jednego między użytkownikiem lokalnym a wpisem w katalogu.
5. USER_IDENTITY_PROVIDER - Łączy konta użytkowników z zewnętrznymi dostawcami tożsamości (np. Google, Microsoft). Umożliwia scenariusze logowania społecznościowego.

Tabele OAuth 2.0 i OpenID Connect

1. CLIENT - Definiuje aplikacje, które mogą uwierzytelniać użytkowników za pośrednictwem serwera autoryzacji (np. Scheduler). Przechowuje dane uwierzytelniające klienta, dozwolone przepływy autoryzacji oraz konfigurację aplikacji.
2. CLIENT_REDIRECT_URI - Lista dozwolonych adresów (whitelist), na które użytkownik może zostać przekierowany po uwierzytelnieniu. Zapobiega atakom typu open redirect.

System obsługuje dwa typy adresów przekierowań:

Authentication Redirect URI (Callback)

1. Używany po pomyślnym logowaniu
2. Aplikacja otrzymuje kod autoryzacyjny pod tym adresem
3. Możliwość konfiguracji wielu adresów dla różnych środowisk (dev, staging, produkcja)

Przykład: https://company.com/auth/callback

Logout Redirect URI

1. Używany po wylogowaniu użytkownika
2. Przekierowanie po zakończeniu sesji
3. Umożliwia wyświetlenie potwierdzenia lub przekierowanie na stronę główną

Przykład: https://company.com/logged-out

Każda aplikacja powinna mieć co najmniej jeden Authentication Redirect URI. Logout URI są opcjonalne, ale zalecane.

PERSISTED_GRANT - Przechowuje dane bezpieczeństwa wydawane podczas uwierzytelniania, takie jak kody autoryzacyjne czy tokeny odzyskiwania hasła. Śledzi czas utworzenia, wygaśnięcia i ewentualnego unieważnienia.

Tabele uwierzytelniania wieloskładnikowego (MFA)

1. MFA_FACTOR - Reprezentuje metody MFA przypisane do użytkownika. Obsługuje wiele urządzeń MFA dla jednego użytkownika.
2. MFA_TOTP - Przechowuje konfigurację jednorazowych kodów czasowych (TOTP) dla aplikacji takich jak Google Authenticator czy Microsoft Authenticator. Zawiera klucz tajny i ustawienia algorytmu.
3. MFA_RECOVERY_CODE - Kody zapasowe umożliwiające dostęp do konta w przypadku utraty głównego urządzenia MFA. Każdy kod może być użyty tylko raz.

Tabele dotyczące claims i ról

1. CLAIM - Definiuje dostępne typy atrybutów (String, Int, Decimal, DateTime, Boolean), które mogą być przypisywane użytkownikom. Claims reprezentują dane użytkownika, uprawnienia lub inne informacje zawarte w tokenach (np. dział, poziom dostępu).
2. ROLE - Przechowuje definicje ról wykorzystywanych w kontroli dostępu. Role mogą być przypisane wielu użytkownikom i opcjonalnie pochodzić z systemów zewnętrznych (np. Active Directory).

Tabele federacji tożsamości

1. FEDERATION - Konfiguracja zewnętrznych katalogów użytkowników (głównie Active Directory).
2. IDENTITY_PROVIDER - Konfiguracja zewnętrznych dostawców tożsamości OpenID Connect. Przechowuje m.in. adresy issuer oraz dane klienta.

Tabele audytowe

1. EVENT_ENTRY - Dziennik zdarzeń bezpieczeństwa, obejmujący udane i nieudane logowania, autoryzacje klientów oraz błędy. Zawiera informacje o czasie, użytkowniku, adresie IP, przeglądarce oraz szczegółach zdarzenia.

Konfiguracja serwera autoryzacji

Serwer autoryzacji wykorzystuje klucze konfiguracyjne do kontrolowania swojego działania. Ustawienia te pozwalają dostosować sposób działania systemu bez modyfikowania kodu.

Podstawowa konfiguracja systemu

Adres URL serwera autoryzacji

1. Klucz: common.auth.server_url
2. Cel: Ustawia podstawowy adres URL serwera autoryzacji. To adres, pod który trafiają użytkownicy podczas logowania.
3. Domyślnie: używany jest publiczny adres interfejsu WWW.
4. Wpływ: wszystkie przekierowania związane z autoryzacją oraz wystawianie tokenów korzystają z tego adresu.

Tryb pracy serwera

1. Klucz: www.auth.server.mode
2. Cel: Określa, czy dana instancja działa jako serwer autoryzacji, czy jako klient łączący się do innego serwera.
3. Domyślnie: (brak wskazania w tekście)
4. Wartości:

• server – instancja działa jako serwer autoryzacji
• client – instancja korzysta z zewnętrznego serwera autoryzacji

Klucz do podpisywania tokenów

1. Klucz: common.auth.server_rsa_signing_key
2. Cel: Kryptograficzny klucz prywatny używany do podpisywania tokenów JWT, co zapewnia ich integralność.
3. Publiczny klucz jest udostępniany przez endpoint JWKS (.well-known/jwks), co umożliwia klientom weryfikację podpisów.
4. Domyślnie: nie ustawiono (musi być skonfigurowany).
5. Bezpieczeństwo: jest to ustawienie poufne i musi być chronione.

Konfiguracja klientów aplikacyjnych

System obsługuje wiele zarejestrowanych aplikacji klienckich, każda z własną konfiguracją.

archITekt Remote Client

1. Cel: konfiguracja aplikacji archITekt remote
2. Tryb autoryzacji: Authorization Code + PKCE (klient publiczny)
3. Klucze:

• common.auth.client.archITekt_remote_issuer – adres URL issuer’a (domyślnie {common.auth.server_url})
• common.auth.client.archITekt_remote_client_id – identyfikator aplikacji (domyślnie archITekt-remote)

Auth API Client

1. Cel: uwierzytelnianie system–system
2. Tryb autoryzacji: Client Credentials
3. Klucze:

• common.auth.client.auth_api_issuer – adres issuer’a (domyślnie {common.auth.server_url})
• common.auth.client.auth_api_client_id – identyfikator aplikacji (domyślnie auth-api)
• common.auth.client.auth_api_client_secret – sekret klienta (poufny)

Scheduler Client

1. Cel: konfiguracja klienta harmonogramu (scheduler)
2. Tryb autoryzacji: Authorization Code + PKCE
3. Klucze:

• scheduler.auth.client.issuer – adres issuer’a (domyślnie {common.auth.server_url})
• scheduler.auth.client.client_id – identyfikator aplikacji (domyślnie scheduler-web)
• scheduler.auth.client.client_secret – sekret (poufny)

Integracja tożsamości i katalogów (AD, LDAP)

Tryb kompatybilności tożsamości

1. Klucz: common.auth.identity_compatibility_mode
2. Cel: kontroluje format identyfikatorów użytkowników zwracanych przez funkcje typu GetCurrentUserId().
3. Domyślnie: default
4. Wartości:

• default – zwracany jest lokalny ID z bazy serwera autoryzacji (zalecane dla nowych instalacji)
• federation – zwracany jest ID zewnętrzny (np. identyfikator obiektu LDAP dla użytkowników usługi Active Directory w formacie SID)

Uwagi dotyczące zgodności: Nowe wdrożenia systemu korzystają z trybu domyślnego. Istniejące aplikacje integrujące się z katalogami federacyjnymi mogą korzystać z trybu federacyjnego w celu zapewnienia zgodności wstecznej ze starszymi integracjami.

Kontener użytkowników AD

1. Klucz: common.param.provider_ad_user_container
2. Cel: Określa ścieżkę do jednostki organizacyjnej w usłudze Active Directory, w której znajdują się konta użytkowników.
3. Domyślnie: pole pozostaje puste, co oznacza, że pobierani są wszyscy użytkownicy.
4. Przykład: OU=Users,OU=Company,DC=example,DC=com

Kontener ról AD

1. Klucz: common.param.provider_ad_role_container (dawniej klucz: common.param.provider_ad_container)
2. Cel: Określa ścieżkę do jednostki organizacyjnej w usłudze Active Directory, w której znajdują się grupy zabezpieczeń/role.
3. Domyślnie: pole pozostaje puste, co oznacza, że pobierani są wszyscy użytkownicy.
4. Przykład: OU=Groups,OU=Company,DC=example,DC=com

Zarządzanie sesją

Limit czasu sesji (odświeżany)

1. Klucz: www.param.session_timeout
2. Cel: Określa, jak długo użytkownik może pozostawać zalogowany bez aktywności, zanim nastąpi automatyczne wylogowanie.
3. Domyślnie: 30 minut
4. Działanie: Limit czasu „resetuje się” za każdym razem, gdy użytkownik wykona jakąś czynność (kliknięcie przycisków, przesłanie formularzy, nawigacja po stronach). Dopóki użytkownik aktywnie korzysta z systemu, pozostaje zalogowany. Jeśli przestanie z niego korzystać przez określony czas, zostanie automatycznie wylogowany ze względów bezpieczeństwa.
5. Przykład: Przy 30-minutowym limicie czasu użytkownik, który zaloguje się o 9:00 rano i aktywnie korzysta z systemu, pozostaje zalogowany. Jeśli zrobi 30-minutową przerwę bez klikania niczego, zostanie wylogowany. Jeśli jednak kliknie coś o 9:29 rano, licznik czasu zresetuje się i będzie miał kolejne 30 minut.

Maksymalny czas sesji

1. Klucz: www.param.max_session_timeout
2. Cel: Maksymalny czas, przez jaki użytkownik może być zalogowany niezależnie od aktywności.
3. Domyślnie: 720 minut (12 godzin)
4. Działanie: W przeciwieństwie do powyższego limitu czasowego o charakterze płynnym, jest to sztywny limit. Po jego osiągnięciu użytkownicy muszą się wylogować i zalogować ponownie, niezależnie od tego, czy aktywnie korzystają z systemu.
5. Przykład: Nawet przy ciągłej pracy — po 12 godzinach system wymaga logowania ponownie.
6. Cel bezpieczeństwa: Wymusza okresowe ponowne uwierzytelnianie w celu zwiększenia bezpieczeństwa w systemach wrażliwych.

Przykład konfiguracji:

Z session_timeout=30 i max_session_timeout=720:

1. Użytkownik loguje się o 9:00 rano
2. Pracuje aktywnie → pozostaje zalogowany (limit czasu jest resetowany)
3. Robi 35-minutową przerwę na kawę → zostaje automatycznie wylogowany
4. Maksymalny czas trwania aktywnej sesji wynosi 12 godzin, po czym konieczne jest ponowne uwierzytelnienie.

Konfiguracja e-mail

Adres nadawcy SMTP

1. Klucz: common.auth.server.smtp_sender_email
2. Cel: Adres e-mail w polu „Od”, używany przez serwer autoryzacyjny do wysyłania wiadomości e-mail (resetowanie hasła, powiadomienia) .
3. Domyślnie: noreply@yourdomain.com
4. Skutek: Adres ten pojawia się jako nadawca we wszystkich wiadomościach e-mail generowanych przez system.

Dostępne endpointy

Serwer autoryzacji udostępnia różne endpointy (adresy URL), z którymi komunikują się aplikacje i użytkownicy.

Podstawowy przepływ uwierzytelniania

Standardowy proces logowania:

Żądanie użytkownika → /auth/login → /auth/verify → Uwierzytelniony

Ten dwuetapowy proces obsługuje większość scenariuszy uwierzytelniania:

Krok 1: /auth/login

1. Cel: rozpoczęcie uwierzytelniania i weryfikacja danych logowania
2. Co się dzieje: użytkownik podaje login i hasło, system je sprawdza
3. Następny krok: jeśli dane są poprawne → przejście do /auth/verify - etapu weryfikacji

Krok 2: /auth/verify

1. Cel: weryfikacja i utworzenie sesji
2. Co się dzieje: system tworzy sesję i wydaje tokeny uwierzytelniające
3. Efekt: użytkownik jest zalogowany i może korzystać z chronionych zasobów

Przykładowy przebieg

1. Użytkownik próbuje wejść do aplikacji
2. Aplikacja przekierowuje do /auth/login
3. Użytkownik wpisuje dane
4. System przekierowuje do /auth/verify
5. Tworzona jest sesja i tokeny
6. Użytkownik wraca do aplikacji jako zalogowany

Mapowanie endpointów

Konfiguracja własnych ścieżek

Przedstawione powyżej domyślne endpointy można zmienić w pliku routes.config.

Dlaczego warto:

1. dostosowanie do wizerunku marki i konwencji nazewniczych organizacji
2. zachowanie spójności z istniejącymi adresami URL aplikacji
3. uproszczenie ścieżek uwierzytelniania dla użytkowników końcowych

Jak to działa:

Plik WWW/Configuration/Environment/routes.config umożliwia przypisanie niestandardowych ścieżek do standardowych punktów końcowych uwierzytelniania. Funkcjonalność wszystkich endpointów pozostaje niezmieniona – zmieniają się jedynie ścieżki adresów URL. Zapewnia to elastyczność bez konieczności modyfikacji kodu.

Endpointy discovery i konfiguracji

Dostarczają informacji o możliwościach i konfiguracji serwera autoryzacji.

OpenID Connect Configuration

1. Endpoint: .well-known/openid-configuration
2. Cel: Zawiera pełny opis możliwości serwera autoryzacji.
3. Kto z niego korzysta: Aplikacje klienckie, które chcą dowiedzieć się, jak zintegrować się z serwerem.
4. Co zwraca: Listę obsługiwanych punktów końcowych, metod uwierzytelniania, typów tokenów i algorytmów bezpieczeństwa.
5. Przykładowe zastosowanie: Nowa aplikacja automatycznie konfigurująca się do współpracy z serwerem autoryzacji.

Zestaw kluczy JSON Web Key (JWKS)

1. Endpoint: .well-known/jwks
2. Cel: Publikuje klucze publiczne używane do weryfikacji podpisów tokenów.
3. Kto z tego korzysta: Aplikacje, które muszą zweryfikować autentyczność tokenów.
4. Co zwraca: Klucze publiczne w formacie JSON.
5. Przykładowe zastosowanie: Interfejs API weryfikujący, czy token dostępu został rzeczywiście wydany przez ten serwer autoryzacji.

Endpointy uwierzytelniania i autoryzacji

Obsługują podstawowe procesy uwierzytelniania i autoryzacji.

Authorization Endpoint

1. Endpoint: auth/authorize
2. Cel: Rozpoczyna proces uwierzytelniania dla aplikacji (logowanie).
3. Kto z tego korzysta: Aplikacje klienckie, gdy użytkownicy muszą się zalogować.
4. Co robi: Przekierowuje użytkowników na stronę logowania i zwraca kod autoryzacyjny po pomyślnym uwierzytelnieniu.
5. Obsługa użytkownika: Użytkownik klika Zaloguj w aplikacji → zostaje przekierowany tutaj → loguje się → zostaje przekierowany z powrotem do aplikacji z kodem autoryzacyjnym.

Login page

1. Endpoint: auth/login
2. Cel: Wyświetla formularz logowania, w którym użytkownicy wprowadzają dane uwierzytelniające.
3. Kto z tego korzysta: Użytkownicy końcowi podczas uwierzytelniania.
4. Co zawiera: Pola z nazwą użytkownika i hasło, linki do resetowania hasła.
5. Obsługa użytkownika: Standardowa strona logowania, na której użytkownicy wpisują swoją nazwę użytkownika i hasło.

Single Sign-On Login

1. Endpoint: auth/login/sso
2. Cel: Obsługuje uwierzytelnianie za pomocą uwierzytelniania systemu Windows.
3. Kto z tego korzysta: Użytkownicy w sieciach korporacyjnych z uwierzytelnianiem w domenie Windows.
4. Jak działa: Inicjuje uwierzytelnianie systemu Windows przy użyciu protokołu Kerberos lub NTLM, automatycznie uwierzytelniając użytkowników już zalogowanych w swojej domenie.
5. Obsługa użytkownika: Użytkownik uzyskuje dostęp do aplikacji → jest automatycznie uwierzytelniany przy użyciu danych logowania do domeny Windows → nie jest wymagany formularz logowania, jeśli użytkownik jest już uwierzytelniony w domenie.

Logout

1. Endpoint: auth/logout
2. Cel: Zakończenie sesji użytkownika i wyczyszczenie tokenów uwierzytelniających.
3. Kto z tego korzysta: Użytkownicy i aplikacje podczas wylogowywania się.
4. Jak działa: Zniszczenie sesji, wyczyszczenie plików cookie.
5. Obsługa użytkownika: Użytkownik klika Wyloguj się → sesja wyczyszczona → przekierowanie do strony potwierdzenia wylogowania lub strony głównej.

Verify Token

1. Endpoint: auth/verify
2. Cel: Weryfikuje użytkownika po zalogowaniu i obsługuje dodatkowe etapy weryfikacji, takie jak uwierzytelnianie wieloskładnikowe.
3. Kto z tego korzysta: Serwer autoryzacji podczas procesu logowania.
4. Jak działa: Potwierdza poprawność danych uwierzytelniających użytkownika, a następnie prosi o uwierzytelnianie wieloskładnikowe, jeśli jest włączone.
5. Obsługa użytkownika: Po wprowadzeniu nazwy użytkownika/hasła użytkownik może zostać poproszony o wprowadzenie kodu TOTP z aplikacji uwierzytelniającej lub użycie kodu odzyskiwania w celu zakończenia logowania.

Endpointy zarządzania hasłem

Obsługują procesy odzyskiwania i resetowania haseł.

Forgot Password

1. Endpoint: auth/forgot-password
2. Cel: Rozpoczyna proces odzyskiwania hasła.
3. Kto z tego korzysta: Użytkownicy, którzy zapomnieli hasła.
4. Jak działa: Wysyła wiadomość e-mail z linkiem do resetowania hasła.
5. Obsługa użytkownika: Użytkownik wpisuje adres e-mail → otrzymuje wiadomość e-mail z linkiem do resetowania.

Reset Password

1. Endpoint: auth/reset-password
2. Cel: Umożliwia użytkownikom ustawienie nowego hasła
3. Kto z tego korzysta: Użytkownicy klikający link resetujący z wiadomości e-mail dotyczącej zapomnianego hasła.
4. Jak działa: Sprawdzanie poprawności tokenu resetującego i umożliwienie użytkownikowi wprowadzenia nowego hasła.
5. **Obsługa użytkownika:**Użytkownik klika link w wiadomości e-mail → wprowadza nowe hasło → hasło zaktualizowane.

Zarządzanie kontami użytkowników

Zarządzanie kontem (Account Management)

1. Endpoint: account
2. Cel: Portal samoobsługi użytkownika do zarządzania ustawieniami konta.
3. Kto z tego korzysta: Uwierzytelnieni użytkownicy zarządzający swoim profilem.
4. Co oferuje: Informacje profilowe, zmiana hasła, rejestracja w uwierzytelnianiu wieloskładnikowym.
5. Obsługa użytkownika: Użytkownicy przeglądają i aktualizują swoje dane osobowe, włączają uwierzytelnianie dwuskładnikowe.

Token Exchange Endpoints (API)

Token Endpoint

1. Endpoint: api/auth/token
2. Cel: Wymiana kodów autoryzacyjnych i poświadczeń na tokeny dostępu.
3. Kto z tego korzysta: Aplikacje klienckie i systemy uwierzytelniające się na serwerze autoryzacji.
4. Obsługiwane typy przyznania:

• Kod autoryzacyjny: Wymiana kodu autoryzacyjnego na token dostępu (procesy logowania inicjowane przez użytkownika).
• Poświadczenia klienta: Wymiana identyfikatora klienta i klucza tajnego na token dostępu (uwierzytelnianie między systemami).

5. Co zwraca: token dostępu i czas wygaśnięcia.
6. Przykładowe zastosowanie: aplikacja internetowa wymienia kod autoryzacyjny na token; usługa działająca w tle wykorzystuje poświadczenia klienta do wywołania chronionych interfejsów API.

Endpointy interfejsu API zarządzania użytkownikami

User Management API

1. Endpoint: api/auth/users
2. Cel: Pobieranie informacji o kontach użytkowników i szczegółowych danych.
3. Kto z tego korzysta: Usługi i aplikacje zewnętrzne (np. harmonogram, przepływy pracy).
4. Wymagane uwierzytelnienie: Token JWT typu „Bearer”.
5. Przykładowe operacje:

• Pobieranie szczegółowych danych użytkownika na podstawie identyfikatora
• Wyszukiwanie użytkowników

Role Management API

1. Endpoint: api/auth/roles
2. Cel: Pobieranie informacji o rolach i przypisaniach ról użytkowników.
3. Kto z tego korzysta: Usługi i aplikacje zewnętrzne (np. harmonogram, przepływy pracy).
4. Wymagane uwierzytelnienie: Token JWT typu Bearer.
5. Przykładowe operacje:

• Wyświetlanie listy dostępnych ról

Endpointy - administracja

Admin Dashboard

1. Endpoint: admin/auth-server
2. Cel: Internetowy interfejs administracyjny do zarządzania serwerem autoryzacji.
3. Kto z tego korzysta: administratorzy systemu.
4. Co oferuje:

• Zarządzanie kontami użytkowników
• Konfiguracja aplikacji klienckich
• Przeglądanie dzienników audytowych i zdarzeń uwierzytelniania
• Zarządzanie konfiguracją

5. Obsługa użytkownika: portal administracyjny z narzędziami do zarządzania systemem.

Endpoint Security

Wszystkie endpointy stosują odpowiednie środki bezpieczeństwa.

Endpointy publiczne (nie wymagają uwierzytelniania):

1. Endpointy odkrywające konfigurację(.well-known/*)
2. Strony logowania i resetowania hasła.
3. Są one celowo publiczne, aby umożliwić użytkownikom i aplikacjom dostęp do usług uwierzytelniania.

Chronione endpointy (wymagają uwierzytelniania):

1. Zarządzanie kontami
2. Wylogowanie (wymaga aktywnej sesji)
3. Punkty końcowe API (wymagają ważnych tokenów JWT Bearer)
4. Pulpit administratora (wymaga uprawnień administracyjnych)

Ograniczenia liczby prób (Rate Limiting)

Endpointy implementują ograniczenia liczby prób, aby zapobiegać nadużyciom, w szczególności:

1. Endpointy logowania - Blokada na 5 minut po 5 nieudanych próbach logowania. Mechanizm działa identycznie dla istniejących i nieistniejących kont (ochrona przed enumeracją użytkowników).
2. Weryfikacja MFA - Blokada na 5 minut po 5 nieprawidłowych kodach.

Funkcje dla low-code

Serwer autoryzacji udostępnia zestaw funkcji, z których można korzystać w formułach (wyrażeniach), procesach i konfiguracjach.

Funkcje te umożliwiają tworzenie niestandardowej logiki uwierzytelniania procesów i integracji bez konieczności pisania tradycyjnego kodu.

Użytkownik i atrybuty

Funkcje poniżej umożliwiają pobieranie informacji o aktualnie zalogowanym użytkowniku.

Pobieranie tożsamości użytkownika.

Funkcja	Co robi	Kiedy używać
GetCurrentUserSubjectId()	Zwraca unikalny, trwały identyfikator aktualnie zalogowanego użytkownika.	Gdy trzeba śledzić aktywność użytkownika lub przechowywać dane związane z jego kontem.
GetCurrentUserSessionId()	Zwraca unikalny identyfikator bieżącej sesji logowania.	Podczas śledzenia sesji użytkownika lub wykrywania wielu jednoczesnych logowań.
GetCurrentUserClaim(claimName)	Pobiera konkretną informację z tokenu użytkownika (np. email, numer telefonu).	Gdy potrzebne są standardowe dane użytkownika, takie jak email czy nazwa użytkownika.

Dostęp do niestandardowych atrybutów użytkownika

Użytkownicy mogą posiadać w systemie własne atrybuty (np. dział, numer pokoju, imię przełożonego).

Istnieją różne funkcje zależne od typu danych:

Funkcja	Typ danych	Przykładowe użycie
GetCurrentUserAttributeString(attributeName)	Tekst	Pobranie nazwy działu, stanowiska lub lokalizacji biura.
GetCurrentUserAttributeInt64(attributeName)	Liczba całkowita	Pobranie numeru pracownika, numeru centrum kosztowego, limitu akceptacji.
GetCurrentUserAttributeDateTime(attributeName)	Data i czas	Pobranie daty końca umowy, ostatniego szkolenia, daty zatrudnienia.
GetCurrentUserAttributeBool(attributeName)	Wartość True/False	Sprawdzenie, czy użytkownik jest menedżerem, ma dostęp specjalny, pracuje zdalnie.
GetCurrentUserAttributeDecimal(attributeName)	Liczba dziesiętna	Pobranie wynagrodzenia, stawki rabatowej, progów akceptacji.

Przykładowe scenariusze

1. Spersonalizowane powitanie

Wyświetlenie komunikatu powitalnego z nazwą działu:

„Witaj! Zalogowano do portalu działu [Department].”

2. Warunkowy przebieg procesu

Sprawdzenie, czy użytkownik ma rolę menedżera:

Jeśli atrybut „IsManager” = true → pokaż przyciski akceptacji.

Zarządzanie sesją

Funkcje sesyjne pozwalają przechowywać tymczasowe dane podczas trwania sesji użytkownika. Dane te istnieją tylko do momentu wylogowania.

Funkcja	Co robi	Najlepiej używać do
SetValueInUserSession(key, value)	Zapisuje informację w sesji użytkownika.	Przechowywanie postępu kreatora, wyborów tymczasowych, danych między stronami.
GetValueFromUserSession(key)	Pobiera wcześniej zapisane dane sesyjne.	Odczyt danych zapisanych w poprzednich krokach.
GetValueFromUserSession(key, removeAfterRead)	Pobiera dane sesyjne i opcjonalnie je usuwa.	Jednorazowe komunikaty, flagi, dane tylko do jednokrotnego odczytu.

Przykładowe scenariusze

Wieloetapowy formularz:

1. Strona 1: wprowadzenie danych osobowych → zapisz w sesji
2. Strona 2: dane zawodowe → zapisz w sesji
3. Strona 3: podsumowanie → pobierz wszystkie dane → zapisz do bazy

Tymczasowe komunikaty:

1. Po wykonaniu operacji zapisz komunikat w sesji
2. Po przejściu na następną stronę wyświetl komunikat i usuń go

Koszyk / wybór elementów:

1. Użytkownik zaznacza elementy na kilku ekranach
2. Zapisywane są w sesji i pobierane przy finalizacji operacji

Operacje bezpieczeństwa

Funkcje te służą do ochrony danych i bezpiecznego zarządzania hasłami.

Zarządzanie hasłami

Funkcja	Co robi	Kiedy używać
HashPassword(password)	Konwertuje hasło do bezpiecznego, nieodwracalnego hashu.	Przy zapisywaniu nowych haseł (nigdy nie przechowywać haseł w formie jawnej!).
VerifyPasswordHash(password, hash)	Sprawdza, czy hasło odpowiada zapisanej wartości.	Przy weryfikacji hasła wpisanego przez użytkownika.
GeneratePassword(length, minimumNumberOfNonAlphanumericCharacters)	Tworzy silne, losowe hasło.	Przy tworzeniu nowych kont lub resetach.

Generowanie unikalnych identyfikatorów

Funkcja	Co robi	Kiedy używać
GenerateHexId(length)	Tworzy losowy unikalny identyfikator	Tworzenie numerów referencyjnych, kodów śledzenia.
GenerateHashedHexKey(value)	Tworzy stały hash z wartości	Gdy identyczne dane mają zawsze generować ten sam identyfikator.

Szyfrowanie danych

Funkcja	Co robi	Kiedy używać
EncryptValue(value)	Szyfruje dane	Ochrona API keyów, danych osobowych, poufnych wartości.
DecryptValue(value)	Deszyfruje dane	Odczyt danych poufnych, jeśli wymagane.

Przykłady:

Rejestracja nowego użytkownika

1. Użytkownik podaje hasło
2. System używa HashPassword()
3. W bazie zapisany jest tylko hash

Ochrona poufnych danych

1. Zaszyfruj klucze API przed zapisaniem w bazie

Generowanie numerów identyfikacyjnych:

1. Twórz unikalne numery referencyjne dla zgłoszeń do pomocy technicznej, zamówień lub dokumentów.

Obsługa żądań HTTP

Funkcje te pomagają odczytywać dane z żądań HTTP, formularzy i URL.

Odczyt danych

Funkcja	Co robi	Przykład
GetQueryStringParameterFromRequest(name)	Pobiera parametr z URL	?userId=123 → zwraca 123
GetFormParameterFromRequest(name)	Pobiera wartość z przesłanego formularza	Pobranie pola „email”.
GetPathAndQueryFromRequest()	Pobiera pełną ścieżkę i parametry żądania	/login?returnUrl=/home

Sprawdzanie typu żądania

Funkcja	Zwraca True, jeśli…	Typowe zastosowanie
RequestIsGet()	Żądanie służy do wyświetlania/odczytu danych.	Wyświetlanie zawartości strony.
RequestIsPost()	Żądanie służy do przesyłania/ tworzenia danych.	Przetwarzanie danych z formularzy.
RequestIsPut()	Żądanie aktualizuje istniejące dane.	Obsługa operacji aktualizacji.
RequestIsPatch()	Żądanie częściowo aktualizuje dane	Przetwarzanie częściowych zmian.
RequestIsDelete()	Żądanie usuwa dane	Obsługa operacji usuwania.

Obsługa odpowiedzi

Funkcja	Co robi	Zastosowanie
IsLocalUrl(url)	Sprawdza, czy URL jest wewnętrzny	Zapobieganie phishingowi, weryfikacja redirectów.
ReplaceResponseContentWithJson(json, statusCode)	Zwraca odpowiedź JSON	Budowa własnych API lub webhooków.

Przykłady scenariuszy

Przekierowanie po zalogowaniu:

1. Pobierz adres URL powrotu z ciągu zapytania: GetQueryStringParameterFromRequest(„returnUrl”)

2. Sprawdź, czy jest bezpieczny: IsLocalUrl(returnUrl)

3. Jeśli jest bezpieczny, przekieruj; jeśli nie, przejdź do strony domyślnej

Przetwarzanie formularza:

1. Sprawdź, czy formularz został przesłany: RequestIsPost()

2. Jeśli tak, pobierz wartości formularza: GetFormParameterFromRequest(„email”)

3. Przetwórz dane

Tworzenie punktu końcowego API:

Zwróć odpowiedź JSON z odpowiednim kodem statusu dla użytkowników API.

Informacje o kliencie

Funkcje służące do zbierania informacji o urządzeniu użytkownika i połączeniu.

Funkcja	Zwraca	Użycie
GetClientIpAddress()	Adres IP klienta	Logi bezpieczeństwa, kontrola dostępu.
GetClientUserAgent()	Informacje o urządzeniu i przeglądarce.	Wykrywanie urządzeń mobilnych, analiza pod kątem bezpieczeństwa.

Przykładowe scenariusze:

Dziennik audytu bezpieczeństwa:

1. Rejestruj próby logowania wraz z adresem IP i informacjami o urządzeniu na potrzeby kontroli bezpieczeństwa.

Wykrywanie podejrzanej aktywności:

1. Wysyłaj powiadomienie, jeśli użytkownik loguje się z adresu IP znacznie różniącego się od zwykle używanego.

Funkcje dostosowane do urządzeń:

1. Wyświetlaj interfejs zoptymalizowany pod kątem urządzeń mobilnych, jeśli agent użytkownika wskazuje na urządzenie mobilne.

Ograniczenia dostępu:

1. Blokuj lub zezwalaj na dostęp w oparciu o zakresy adresów IP (np. zezwalaj wyłącznie na dostęp z sieci firmowej).

Lokalizacja (języki, strefy czasowe)

Funkcje umożliwiające pracę z wieloma językami i strefami czasowymi.

Obsługa języków

Funkcja	Zwraca	Użycie
GetSupportedLanguages()	Listę dostępnych języków	Budowa menu wyboru języka.
GetCurrentLanguageName()	Kod bieżącego języka	Wyświetlanie treści w odpowiednim języku.
GetCurrentUserAttributeDateTime(attributeName)	Data i czas	Pobranie daty końca umowy, ostatniego szkolenia, daty zatrudnienia.
GetCurrentUserAttributeBool(attributeName)	Wartość True/False	Sprawdzenie, czy użytkownik jest menedżerem, ma dostęp specjalny, pracuje zdalnie.
GetCurrentUserAttributeDecimal(attributeName)	Liczba dziesiętna	Pobranie wynagrodzenia, stawki rabatowej, progów akceptacji.

Konwersja czasu

Funkcja	Co robi	Kiedy używać
ToLocalTimeApp(dateTime)	Konwertuje czas UTC na lokalny	Pobranie nazwy działu, stanowiska lub lokalizacji biura.
ToUniversalTimeApp(dateTime)	Konwertuje czas lokalny na UTC	Zapisy w bazie danych.

Przykładowe scenariusze:

Wybór języka:

1. Pobierz dostępne języki: GetSupportedLanguages()

2. Wyświetl jako menu rozwijane

3. Użytkownik wybiera preferowany język

Prawidłowe wyświetlanie godzin wydarzeń:

Wydarzenie zapisane w formacie UTC → Przelicz na czas lokalny → Wyświetl użytkownikowi

Walidacja

Funkcje służące do sprawdzania, czy dane są zgodne z oczekiwanymi formatami i standardami jakości.

Funkcja	Sprawdza	Zwraca	Użycie
IsEmailValid(input) Czy tekst ma format email	True/False	Walidacja formularzy, import danych.

Przykładowe scenariusze:

Walidacja formularza:

Użytkownik wprowadza adres e-mail → Sprawdź poprawność za pomocą funkcji IsEmailValid() → Wyświetl komunikat o błędzie, jeśli adres jest nieprawidłowy

Kontrola jakości importowanych danych:

Sprawdź importowane adresy e-mail → Oznacz nieprawidłowe adresy → Poproś o poprawienie

Rejestracja użytkownika:

Sprawdź format adresu e-mail przed utworzeniem konta → Zapobiegaj wprowadzaniu nieprawidłowych adresów e-mail

Najlepsze praktyki dotyczące korzystania z funkcji

1. Stosuj odpowiednie typy danych

Dopasuj funkcję do typu danych:

1. Liczby → Użyj GetCurrentUserAttributeInt64() lub GetCurrentUserAttributeDecimal()
2. Tekst → Użyj GetCurrentUserAttributeString()
3. Daty → Użyj GetCurrentUserAttributeDateTime()
4. Tak/Nie → Użyj GetCurrentUserAttributeBool()

2. Bezpieczeństwo przede wszystkim

1. Zawsze używaj IsLocalUrl() przed przekierowaniem użytkowników
2. Nigdy nie przechowuj haseł w postaci zwykłego tekstu — zawsze używaj HashPassword()
3. Szyfruj wrażliwe dane za pomocą EncryptValue()
4. Nie rejestruj wrażliwych informacji w ścieżkach audytu

3. Wytyczne dotyczące danych sesji

1. Używaj sesji wyłącznie do przechowywania niewielkich, tymczasowych danych
2. Nie przechowuj dużych ilości danych w sesjach
3. Pamiętaj, że dane sesji są tracone po wylogowaniu się użytkownika
4. Usuń dane sesji, gdy nie są już potrzebne (użyj parametru removeAfterRead)

Zobacz również

Użytkownicy

Dostawcy tożsamości