Secure Access służy do uwierzytelniania użytkowników rozwiązań Matrix42 Core , Pro and IGA oraz samoobsługi.

Dzięki Secure Access możesz bezpiecznie uwierzytelniać różne typy użytkowników podczas logowania do:

1. Samoobsługa Matrix42 Core , Pro and IGA
2. Rozwiązania Matrix42 Core , Pro and IGA (takie jak IGA , ITSM itp.)

Można korzystać z kilku różnych metod uwierzytelniania jednocześnie, a użytkownicy mogą uzyskiwać dostęp do różnych usług lub rozwiązań na podstawie wybranego uwierzytelniania.

Służy on również do monitorowania złośliwej aktywności podczas uwierzytelniania, dlatego zabezpieczenia przed atakami siłowymi i przechwytywaniem kliknięć są domyślnie włączone.

Strona logowania

Wszystkie rozwiązania Matrix42 Core , Pro and IGA korzystają ze wspólnej strony logowania. Strona logowania służy do logowania się do samoobsługi i rozwiązań Matrix42 Core , Pro and IGA .

W zależności od tego, jakie protokoły uwierzytelniania są używane (konfigurowalne), wyświetlane są oddzielne zakładki dla logowania (firmowego) i pozostałych metod uwierzytelniania.

Obraz tła i logo na środku ekranu logowania można zmienić zgodnie z projektem klienta. Na poniższych zrzutach ekranu użyto logo Matrix42 i domyślnego obrazu tła. Można je zmienić tylko z hosta ESA , więc jeśli nie masz do niego dostępu, poproś Matrix42 o dokonanie tej zmiany zgodnie z uid instrukcjami: Konfigurowanie motywów dla ESA

Opcje językowe

Użytkownicy mają możliwość zmiany domyślnego języka na inny, wybierając go z menu rozwijanego w prawym górnym rogu.

Językami domyślnymi są: angielski, fiński, szwedzki i niemiecki.
Dostępne języki: angielski, fiński, niemiecki, szwedzki, polski, chorwacki, czeski, duński, holenderski, estoński, francuski, włoski, łotewski, litewski, norweski, rosyjski, hiszpański i turecki.

Konsole administracyjne
Definiując, którzy użytkownicy mogą wejść na stronę logowania, skonfiguruj zadanie provisioningu na potrzeby uwierzytelniania na platformie zarządzania usługami.

Konfiguracja uwierzytelniania wymaga dalszych modyfikacji tylko wtedy, gdy protokoły uwierzytelniania ulegną zmianie lub zostaną wprowadzone nowe.


Protokół uwierzytelniania należy również skonfigurować w konsoli administracyjnej Secure Access , gdzie zdefiniowano również mapowania uwierzytelniania. Na przykład: https://<adres URL Twojej instancji>/auth/admin

Secure Access ( ESA ) to nowa nazwa Keycloak ( keycloak ), aplikacji Open Source zapewniającej usługi uwierzytelniania.

Został on dostosowany przez Matrix42 w następujący sposób:

• Ekrany logowania zostały zastąpione
• Niestandardowe uwierzytelniacze zapewniają dostęp do rozwiązań Matrix42 Core , Pro and IGA .

Secure Access składa się z następujących komponentów:

Apacz

Serwer HTTP Apache jest używany przez Matrix42 Core , Pro and IGA jako serwer proxy dla wszystkich rozwiązań Matrix42 Core , Pro and IGA . Gdy użytkownik otwiera przeglądarkę i wpisuje adres URL rozwiązania oferowanego przez Matrix42 Core , Pro and IGA , żądanie jest wysyłane do serwera Apache. Jeśli żądanie zostanie autoryzowane (użytkownik poprawnie wprowadził swoje dane logowania), jest ono przekazywane do rozwiązania Matrix42 Core , Pro and IGA do którego użytkownik próbuje uzyskać dostęp (na przykład: ITSM, ESS, IGA ).

ESA

Secure Access udostępnia konsolę administracyjną, za pomocą której można skonfigurować określone wymagania dla użytkowników, aby mogli się logować do rozwiązań Matrix42 Core , Pro and IGA . W konsoli administracyjnej można skonfigurować, jakie informacje będą pobierane z Pro tożsamości (IdP) oraz jakie informacje będą wysyłane do rozwiązań Matrix42 Core , Pro and IGA (na przykład: samoobsługa, ITSM, IGA itp.).

Baza danych ESA

Secure Access wykorzystuje bazę SQL PostgreSQL do przechowywania konfiguracji specyficznych dla klienta oraz podsumowania informacji o użytkownikach, którzy zalogowali się do Matrix42 Core , Pro and IGA Solutions.

Każdy klient korzystający ze środowiska Matrix42 Cloud , niezależnie od tego, czy jest to środowisko dedykowane, czy prywatne, ma własny, dedykowany serwer HTTP Apache, który został skonfigurowany do korzystania z Shibboleth ( https://www.shibboleth.net ) jako dostawcy usług. Keycloak działa jako serwer proxy dla rzeczywistego dostawcy tożsamości, którym może być Azure , AD , OpenLDAP lub podobne rozwiązanie.

Gdy użytkownik wpisuje adres URL aplikacji Matrix42 Core , Pro and IGA , żądanie jest kierowane do serwera Apache HTTP klienta za pośrednictwem wpisu DNS. To zachowanie jest takie samo niezależnie od tego, czy środowisko działa jako dedykowane, czy prywatne. Poniższy obraz przedstawia dedykowane środowisko chmurowe, które zostało przypisane do jednego konkretnego klienta/najemcy:

Serwer HTTP Apache każdego klienta jest skonfigurowany do przekierowywania nieuwierzytelnionych żądań do Keycloak ( ESA ), który zajmie się uwierzytelnianiem. Uwierzytelnianie odbywa się poprzez:

• Prezentuje własny ekran logowania
  • Dzieje się tak, jeśli klient korzysta z usługi AD /LDAP lub jeśli dane uwierzytelniające użytkownika są przechowywane lokalnie w ESM
• Przekierowanie przeglądarki użytkownika do ekranu logowania udostępnionego przez Azure .

Jeśli klient korzysta z Azure lub AD FS, Keycloak ( ESA ) można skonfigurować tak, aby zezwalał na logowanie jednokrotne (SSO). W takiej sytuacji użytkownik nie musi ponownie wpisywać swoich danych logowania, jeśli zrobił to już w zatwierdzony sposób. Na przykład, użytkownik włączył laptopa, który został skonfigurowany do uwierzytelniania w Azure / AD FS podczas uruchamiania.

ESA może zawierać wiele różnych domen z własnymi metodami uwierzytelniania. Na przykład użytkownicy wewnętrzni mogą korzystać z własnej metody uwierzytelniania, a użytkownicy zewnętrzni z własnej.

Monitorowanie
Secure Access jest monitorowany w scentralizowanym systemie monitorowania Matrix42 . Matrix42 posiada wiele czujników dla każdej aplikacji, co gwarantuje, że w przypadku wystąpienia problemu w którejkolwiek z aplikacji w Cloud Matrix42 , system monitorowania wygeneruje alarm, a problem zostanie zbadany tak szybko, jak to możliwe.
Matrix42 nie przekazuje żadnych danych klientów do systemu monitorującego Matrix42 .

Wycięcie lasu
Secure Access generuje dziennik systemowy, w którym użytkownicy z uprawnieniami administratora mogą znaleźć szczegółowe pliki dziennika, służące do celów audytu i rozwiązywania problemów.

Federacyjna tożsamość użytkownika umożliwia dostęp do wielu domen lub aplikacji przy użyciu tylko jednego zestawu danych uwierzytelniających użytkownika. Standardową praktyką w federacji użytkowników jest powiązanie tożsamości użytkownika w kilku różnych systemach zarządzania tożsamością.

Bardzo często organizacje korzystają już z usług katalogowych, które służą do przechowywania danych użytkowników i danych uwierzytelniających (nazwy użytkownika i hasła). Federacja użytkowników zapewnia dostęp do zewnętrznych baz danych i katalogów, takich jak LDAP i Active Directory .

Secure Access umożliwia weryfikację danych uwierzytelniających z katalogu i pobieranie informacji o tożsamości użytkownika w celu uwierzytelnienia go w rozwiązaniach Efecte. Obsługiwana jest opcja LDAP.

Wideo logowania

Linki do artykułów dotyczących konfiguracji

Instrukcje dla klienta dotyczące federacji użytkowników

Konfiguruj: Federacja użytkowników do uwierzytelniania

Powszechnie stosowaną metodą uwierzytelniania jest Single-Sign-On (SSO), dzięki któremu użytkownik nie musi podawać danych uwierzytelniających (nazwy użytkownika i hasła) podczas uwierzytelniania, lecz zamiast tego jest uwierzytelniany za pomocą danych uwierzytelniających otrzymanych od Pro tożsamości (IdP), zazwyczaj katalogu takiego jak Entra ID (dawniej Azure AD ) .

Logowanie jednokrotne (SSO) można wdrożyć technicznie przy użyciu protokołu SAML lub OpenID . Wybór protokołu zawsze zależy od dostawcy tożsamości klienta.

Przykłady protokołów uwierzytelniania używanych do logowania jednokrotnego (SSO):

Usługa AD FS ( Microsoft Active Directory Federation Service) zawsze używa protokołu SAML .

Usługa Entra ID SSO (Microsoft Azure Single-Sign-On) korzysta z protokołu SAML lub OpenID .

Wideo logowania

Linki do artykułów dotyczących konfiguracji

Instrukcje dla klienta dotyczące konfiguracji Entra ID SAML

Instrukcje dla klienta dotyczące konfiguracji Entra ID OpenID

Konfiguracja: ESA Entra ID SSO

Instrukcje dla klienta dotyczące logowania do usługi AD FS

Konfiguruj: Logowanie do usługi ESA AD FS

Secure Access obsługuje również użytkowników lokalnych ESM. Użytkownik lokalny to osoba, której dane uwierzytelniające nie znajdują się w żadnym z Pro tożsamości (np. AD , Azure AD , OpenLDAP itp.).

Informacje o użytkownikach lokalnych należy uzyskać z rozwiązania Efecte, z którego korzysta klient. Użytkowników lokalnych można utworzyć ręcznie w konfiguracji platformy Efecte lub za pomocą modułu Workflow Engine.

Należy pamiętać, że ta sama logika ma zastosowanie do każdego rozwiązania zbudowanego na platformie Efecte.

Wideo logowania

Linki do artykułów dotyczących konfiguracji

Konfiguracja: Logowanie użytkownika lokalnego Efecte

Secure Access umożliwia udzielanie gościom dostępu do usługi samoobsługowej Efecte.

Na stronie logowania Efecte użytkownik wybiera opcję uwierzytelniania dostępu gościa, generowane są tymczasowe dane uwierzytelniające dla użytkownika gościa, który następnie zostaje przekierowany do systemu samoobsługowego Efecte.

Użytkownicy gościnni będą mieli ograniczony dostęp do usług i informacji w systemie Efecte Self-Service, a także nie będą mogli powrócić do swoich zapytań ani raportów utworzonych w systemie Efecte Self-Service. Ze względów bezpieczeństwa zdecydowanie zaleca się, aby użytkownik wykonał akcję ReCaptcha, co oznacza, że użytkownik potwierdzi, że nie jest robotem.

Wideo logowania – akcja ReCaptcha

Linki do artykułów dotyczących konfiguracji

Konfiguruj: ESA — konfiguracja dostępu gościa

Funkcja Secure Access może być wykorzystana do zapewnienia anonimowego logowania, co oznacza, że przed zalogowaniem się użytkownika do Efecte Self-Service, jego nazwa użytkownika i hasło są generowane losowo. Anonimowi użytkownicy mogą kopiować dane uwierzytelniające i wykorzystywać je na przykład do sprawdzania statusu raportu.

Secure Access ani żadne inne rozwiązanie Efecte nie zapisuje informacji identyfikujących użytkownika ani jego sesji. Ze względów bezpieczeństwa zdecydowanie zaleca się, aby użytkownik wykonał akcję ReCaptcha, co oznacza, że potwierdza, że nie jest robotem.

Na przykład: rozwiązanie Efecte Whistleblower wykorzystuje funkcję anonimowego logowania.

Wideo logowania - Efecte Whistleblower

Linki do artykułów dotyczących konfiguracji

Konfiguruj: Konfiguracja dostępu sygnalisty

Secure Access obsługuje usługę SAML Discovery Service, która służy do uwierzytelniania Virtu.

Virtu to wspólne rozwiązanie rządu Finlandii w zakresie jednokrotnego logowania, za które odpowiada rządowe centrum ICT Valtori. Oznacza to, że klient musi należeć do zaufanej sieci Virtu.

Na stronie logowania Efecte użytkownik wybiera rodzaj uwierzytelnienia lub akcję, której chce użyć. Jeśli wymaga ona uwierzytelnienia Virtu, zostanie przekierowany na stronę logowania Virtu. Po uwierzytelnieniu użytkownik zostanie przekierowany z powrotem do Secure Access , gdzie będzie mógł korzystać z rozwiązań Efecte zgodnie ze zdefiniowanymi uprawnieniami.

Więcej o Virtu możesz przeczytać tutaj .

Linki do artykułów dotyczących konfiguracji

Konfiguracja: Uwierzytelnianie ESA Virtu

Instrukcje dla klienta dotyczące uwierzytelniania Virtu

Secure Access obsługuje usługę SAML Discovery Service, która służy do uwierzytelniania HAKA.

HAKA to federacja tożsamości fińskich uniwersytetów, politechnik i instytucji badawczych, która wspólnie oferuje rozwiązanie jednokrotnego logowania. Odpowiedzialnością CSC (Centrum Informatyczne ds. Nauki Sp. z o.o.) jest zapewnienie, że klient musi należeć do zaufanej sieci HAKA.

Na stronie logowania Efecte użytkownik wybiera rodzaj uwierzytelnienia lub akcję, której chce użyć. Jeśli wymaga to uwierzytelnienia HAKA, zostanie przekierowany na stronę logowania HAKA. Po uwierzytelnieniu użytkownik zostanie przekierowany z powrotem do Secure Access , gdzie będzie mógł korzystać z rozwiązań Efecte zgodnie z zdefiniowanymi uprawnieniami.

Więcej o HAKA możesz przeczytać tutaj .

Linki do artykułów dotyczących konfiguracji

Konfiguracja: Uwierzytelnianie ESA HAKA

Instrukcje dla klienta dotyczące uwierzytelniania HAKA

Secure Access obsługuje uwierzytelnianie Google .

Na stronie logowania Efecte użytkownik wybiera rodzaj uwierzytelnienia lub akcję, której chce użyć. Jeśli wymaga to uwierzytelnienia Google , zostanie przekierowany na stronę logowania Google . Po uwierzytelnieniu użytkownik zostanie przekierowany z powrotem do Secure Access , gdzie będzie mógł korzystać z rozwiązań Efecte zgodnie ze zdefiniowanymi uprawnieniami.

Wideo logowania

Linki do artykułów dotyczących konfiguracji

Konfiguracja: uwierzytelnianie Google ESA

Secure Access obsługuje protokół SAML , który jest używany do uwierzytelniania Okta.

Okta to bezpieczna chmura tożsamości łącząca wszystkie aplikacje, dane logowania i urządzenia w jednolitą cyfrową strukturę.

Na stronie logowania Efecte użytkownik wybiera rodzaj uwierzytelnienia lub akcję, której chce użyć. Jeśli wymaga to uwierzytelnienia Okta, zostanie przekierowany na stronę logowania Okta. Po uwierzytelnieniu użytkownik zostanie przekierowany z powrotem do Secure Access , gdzie będzie mógł korzystać z rozwiązań Efecte zgodnie ze zdefiniowanymi uprawnieniami.

Wideo logowania

Linki do artykułów dotyczących konfiguracji

Jak skonfigurować uwierzytelnianie dla Okta ( SAML )?

Secure Access obsługuje protokół OpenID , który jest używany do uwierzytelniania Keycloak . Keycloak to rozwiązanie open source, które zapewnia dostęp do aplikacji i usług za pomocą jednokrotnego logowania. Umożliwia użytkownikom jednorazowe uwierzytelnienie i dostęp do wielu aplikacji bez konieczności ponownego wprowadzania danych uwierzytelniających.

Na stronie logowania Efecte użytkownik wybiera rodzaj uwierzytelnienia lub akcję, której chce użyć. Jeśli wymaga ona uwierzytelnienia Keycloak , zostanie przekierowany na stronę logowania Keycloak . Po uwierzytelnieniu użytkownik zostanie przekierowany z powrotem do Secure Access , gdzie będzie mógł korzystać z rozwiązań Efecte zgodnie z zdefiniowanymi uprawnieniami.

Linki do artykułów dotyczących konfiguracji

Jak skonfigurować uwierzytelnianie dla Keycloak ?

Silne uwierzytelnianie to definicja, która jest osiągana, gdy podczas uwierzytelniania spełnione są dwie (2) z trzech (3) poniższych zasad,

1. Coś, co posiadasz (np. telefon komórkowy)
2. Coś, co wiesz (na przykład nazwa użytkownika i hasło)
3. Coś, czym jesteś (na przykład odcisk palca)

Obecnie najczęściej silne uwierzytelnianie obejmuje:

1. Coś, co wiesz (nazwa użytkownika i hasło)
2. Coś, co posiadasz (jednorazowe hasło do urządzenia mobilnego)

To właśnie zasady odróżniają silne uwierzytelnianie od uwierzytelniania dwuskładnikowego (2FA) i uwierzytelniania wieloskładnikowego. Wymaga ono jedynie użycia co najmniej dwóch metod uwierzytelniania, ale mogą one opierać się na tej samej zasadzie, co oznacza, że 2FA lub MFA niekoniecznie oznaczają silne uwierzytelnianie.

Poniższy przykład można nazwać MFA lub 2FA, ale nie silnym uwierzytelnianiem,

1. Coś, co wiesz (nazwa użytkownika i hasło)
2. Coś, co wiesz (odpowiedzi na pytania bezpieczeństwa)

Jednorazowe hasło (OTP) może stanowić część uwierzytelniania. Oznacza to, że jednorazowe hasło jest wysyłane użytkownikowi za pośrednictwem wiadomości e-mail lub SMS (wysłanej na telefon komórkowy użytkownika).

W niektórych przypadkach wystarczy wpisać tylko jednorazowe hasło, ale jeśli klientowi zależy na silnym uwierzytelnianiu, zaleca się poproszenie użytkownika o podanie np. danych uwierzytelniających (nazwy użytkownika i hasła) również w celu uwierzytelnienia.

Funkcjonalność jednorazowego hasła jest zapewniona we wszystkich usługach Signicat , co oznacza, że firma Signicat jest partnerem Efecte, którego technologia jest wykorzystywana do uwierzytelniania.

Secure Access obsługuje uwierzytelnianie za pomocą jednorazowych kodów, czyli haseł tymczasowych generowanych przez aplikacje uwierzytelniające, np. Google Authenticator lub FreeOTP.

Po skonfigurowaniu hasła jednorazowego (za pomocą aplikacji uwierzytelniającej) i podaniu przez użytkownika danych uwierzytelniających (nazwy użytkownika i hasła), Secure Access poprosi użytkownika o podanie hasła wygenerowanego przez Google Authenticator lub FreeOTP. Należy pamiętać, że aplikacja uwierzytelniająca musi być zainstalowana na telefonie komórkowym użytkownika.

Linki do artykułów dotyczących konfiguracji

Konfiguruj: Uwierzytelnianie dwuskładnikowe (2FA)

Uwierzytelnianie za pomocą identyfikatora bankowego jest zawsze silnym uwierzytelnianiem i oznacza, że użytkownik korzysta z osobistych danych identyfikacyjnych banku (podanych przez bank lub rząd) w celu uwierzytelnienia się w rozwiązaniach samoobsługowych lub Efecte.

Jest to powszechna metoda uwierzytelniania, szczególnie w krajach skandynawskich, ale staje się coraz bardziej powszechna również w innych krajach europejskich. Jeśli potrzebujesz uwierzytelnienia identyfikatora bankowego poza Finlandią lub Szwecją, skontaktuj się z Efecte, aby uzyskać więcej informacji.

Uwierzytelnianie identyfikatorów bankowych odbywa się za pomocą protokołów krajowych, a Secure Access korzysta z usług Signicat jako pośrednika tożsamości między bankami a Secure Access . Obecnie uwierzytelnianie identyfikatorów bankowych jest obsługiwane w Finlandii i Szwecji.

Finlandia:

W Finlandii uwierzytelnianie identyfikatora bankowego jest najczęściej stosowane przez firmy z sektora prywatnego oraz w przypadkach, gdy organizacje rządowe z jakiegoś powodu nie są w stanie skorzystać z uwierzytelniania suomi.fi.

Szwecja:

W Szwecji uwierzytelnianie identyfikatorów bankowych jest powszechnie stosowane w organizacjach sektora rządowego i prywatnego.

Uwierzytelnianie Suomi.fi jest podobne do uwierzytelniania identyfikatora bankowego, z tą różnicą, że z suomi.fi mogą korzystać wyłącznie fińskie instytucje rządowe. W usługach można dokonać identyfikacji za pomocą fińskich kodów bankowości internetowej, mobilnej karty certyfikacyjnej lub karty certyfikacyjnej.

Secure Access wykorzystuje usługi Signicat jako brokera tożsamości pomiędzy usługą suomi.fi i Secure Access .

Więcej informacji o uwierzytelnianiu suomi.fi znajdziesz tutaj .

SAML to protokół przeznaczony do wymiany tożsamości uwierzytelniania i autoryzacji między domenami zabezpieczeń.

Secure Access obsługuje uwierzytelnianie użytkowników wykonywane przez Identity Pro (IdP), na przykład Entra ID , przy użyciu łącznika/adaptera SAML 2.0.

SAML wysyła zgłoszenia za pomocą formatu XML SAML . Ten format jest najczęściej używany w organizacjach z wieloma aplikacjami, aby umożliwić użytkownikom końcowym jedno logowanie.

Linki do artykułów dotyczących konfiguracji

Konfiguruj: Uwierzytelnianie ESA M SAML
ESA – Instrukcje dla klienta dotyczące konfiguracji Entra ID SAML

OAuth 2.0 i OpenID Connect (rozszerzenie protokołu OAuth 2.0) umożliwiają organizacjom weryfikację tożsamości użytkownika końcowego na podstawie uwierzytelniania przeprowadzonego przez serwer autoryzacji, a także uzyskanie podstawowych informacji o profilu użytkownika końcowego.

Secure Access obsługuje uwierzytelnianie użytkowników wykonywane przez Pro tożsamości (IdP), np. Entra ID , przy użyciu łącznika/adaptera OpenID Connect .

OpenID Connect został zbudowany na bazie protokołu OAuth i wysyła żądania przy użyciu formatu JSON Web Token (JWT). Jest powszechnie używany na przykład przez Pro tożsamości działających w chmurze, witryny konsumenckie i aplikacje mobilne.

Linki do artykułów dotyczących konfiguracji

Konfiguruj: Logowanie jednokrotne w usłudze ESA Azure AD
ESA - Instrukcja dla klienta dotycząca konfiguracji Entra ID OpenID

Protokół SAML Discovery Service jest używany do uwierzytelniania HAKA i Virtu w ramach Secure Access , ale jest też powszechnie stosowany, na przykład na uniwersytetach.

Linki do artykułów dotyczących konfiguracji

Konfiguracja: uwierzytelnianie ESA HAKA

Konfiguracja: uwierzytelnianie ESA Virtu

Protokół Finnish Trust Network jest używany do uwierzytelniania za pomocą danych identyfikacyjnych fińskiego banku, a także do uwierzytelniania za pośrednictwem suomi.fi. Korzystanie z niego jest obowiązkowe. Więcej informacji można znaleźć tutaj .

Uwierzytelnianie za pomocą szwedzkiego numeru identyfikacyjnego (personnummer) odbywa się za pomocą szwedzkiego BankID.

Atak siłowy polega na próbie odgadnięcia hasła użytkownika poprzez wielokrotne próby logowania. Secure Access posiada funkcje wykrywania prób siłowych i może tymczasowo zablokować konto użytkownika, jeśli liczba nieudanych logowań przekroczy określony próg.
Włączając wykrywanie ataków siłowych (domyślnie włączone), możemy tymczasowo zablokować atakujących próbujących włamać się do systemu. Gdy użytkownik jest tymczasowo zablokowany i próbuje się zalogować, Secure Access wyświetla domyślny komunikat o błędzie nieprawidłowej nazwy użytkownika lub hasła, aby upewnić się, że atakujący nie wie, że konto jest wyłączone.

Linki do artykułów dotyczących konfiguracji

Jak włączyć wykrywanie ataków siłowych w ESA

Ochrona przed clickjackingiem uniemożliwia atakującemu osadzenie strony internetowej w ramce iframe i nakłonienie użytkownika do kliknięcia ukrytych lub zamaskowanych przycisków lub linków.

Domyślnie ochrona przed klikaniem jest włączona.

Klient może włączyć obsługę plików cookie w procesie logowania. Oznacza to, że odwiedzający witrynę są informowani o tym, jakie dane użytkownika śledzą pliki cookie, dlaczego te informacje są śledzone i gdzie są wysyłane.

Linki do artykułów dotyczących konfiguracji

Skonfiguruj ustawienia plików cookie ESA

Klient może włączyć opcję zgody użytkownika w procesie logowania, co oznacza, że użytkownicy witryny wyrażają zgodę na uzyskiwanie, wykorzystywanie i przetwarzanie swoich danych za pośrednictwem plików cookie. Po podaniu danych uwierzytelniających przez użytkownika, ESA wyświetli okno dialogowe z informacją o kliencie żądającym logowania oraz o tym, jakie dane identyfikacyjne są od niego wymagane. Użytkownik może zdecydować, czy zaakceptować prośbę.

Linki do artykułów dotyczących konfiguracji

Skonfiguruj ESA , aby korzystać ze zgody użytkownika