Riku Nieminen
2025-10-23T13:00:50Z

Secure Access

Secure Access (dawniej Efecte Secure Access ) to jeden z komponentów Matrix42 Core , Pro and IGA Cloud Environment. Jest on instalowany podczas instalacji środowiska Cloud i obsługuje kilka protokołów uwierzytelniania, umożliwiając korzystanie z wielu różnych dostawców tożsamości (IdP – Identity Pro ) dla różnych typów użytkowników końcowych. W przypadku Secure Access wymagana metoda uwierzytelniania może się różnić w zależności od użytkowników lub usług dostępnych po zalogowaniu.

Secure Access jest domyślnie częścią instalacji Cloud od wersji 2021/3.

Do czego służy?

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.

Wygląd i odczucia

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

Informacje techniczne

Architektura i komponenty

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.

Przepływy danych

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 i rejestrowanie

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 .

Transduktor | Opis | Działania, które należy podjąć, jeśli czujnik wykryje problem
ESA , ESA DB lub Apache | Wszystkie komponenty chmury są monitorowane, co pozwala mieć pewność, że działają bez żadnych przerw. | Został utworzony bilet monitorujący do pomocy technicznej Matrix42 .
Funkcjonalność ESA / Keycloak (server.log) | Monitorowanie odbywa się według dwóch wzorców: „spowodowane przez” i „niewykryty błąd serwera”. Jeśli oba wzorce mają zastosowanie, generowany jest alarm. | Został utworzony bilet monitorujący do obsługi 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.

Plik dziennika | Opis | Location | Dostęp

kontener-logs dzierżawca-esa

Dziennik zawiera:

Dziennik uruchamiania

Informacje o ESA ←> Synchronizacja EPE

Kontrole stanu zdrowia

Gospodarz

Tylko administratorzy mają dostęp do tego pliku dziennika. Administrator musi mieć dostęp do serwera hosta.

keycloak .log

W dzienniku znajdują się informacje o nieudanych próbach logowania, błędach uwierzytelniania, a także o pomyślnych działaniach użytkowników.

Host i interfejs użytkownika ESM

keycloak administratorzy mają dostęp do tego pliku dziennika. Administrator musi mieć dostęp do kontenera ESA na serwerze hosta (w keycloak ) lub dostęp do łączników EPE, z których można pobrać logi ESA z interfejsu użytkownika ESM.

certyfikat-odświeżacz.log | Ten dziennik zawiera informacje o statusie certyfikatu, błędach i działaniach. | Host i interfejs użytkownika ESM | Tylko administratorzy mają dostęp do tego pliku dziennika. Administrator musi mieć dostęp do kontenera ESA na serwerze hosta lub dostęp do łączników EPE, z których można pobrać dzienniki ESA z interfejsu użytkownika ESM.

Obsługiwane metody uwierzytelniania

Dzięki Secure Access możesz korzystać z różnych metod bezpiecznego logowania się do rozwiązań Matrix42 Core , Pro and IGA .

Jeśli organizacja ma kilku różnych Pro tożsamości (IdP), jej użytkownicy mogą być uwierzytelniani za pomocą różnych dostawców tożsamości (na przykład AD i Entra ID ).

Federacja użytkownikó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

Twoja przeglądarka nie obsługuje wideo HTML5.

Linki do artykułów dotyczących konfiguracji

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

Konfiguruj: Federacja użytkowników do uwierzytelniania

Logowanie jednokrotne (SSO)

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

Twoja przeglądarka nie obsługuje wideo HTML5.

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

Logowanie użytkownika lokalnego

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

Twoja przeglądarka nie obsługuje wideo HTML5.

Linki do artykułów dotyczących konfiguracji

Konfiguracja: Logowanie użytkownika lokalnego Efecte

Dostęp dla gości

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

Twoja przeglądarka nie obsługuje wideo HTML5.

Linki do artykułów dotyczących konfiguracji

Konfiguruj: ESA — konfiguracja dostępu gościa

Logowanie anonimowe

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

Twoja przeglądarka nie obsługuje wideo HTML5.

Linki do artykułów dotyczących konfiguracji

Konfiguruj: Konfiguracja dostępu sygnalisty

Uwierzytelnianie Virtu

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

Uwierzytelnianie HAKA

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

Uwierzytelnianie Google

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

Twoja przeglądarka nie obsługuje wideo HTML5.

Linki do artykułów dotyczących konfiguracji

Konfiguracja: uwierzytelnianie Google ESA

Uwierzytelnianie Okta

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

Twoja przeglądarka nie obsługuje wideo HTML5.

Linki do artykułów dotyczących konfiguracji

Jak skonfigurować uwierzytelnianie dla Okta ( SAML )?

Uwierzytelnianie Keycloak

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 ?

Obsługiwane silne metody uwierzytelniania

Silne uwierzytelnianie to połączenie różnych metod uwierzytelniania, które można osiągnąć, spełniając predefiniowane zasady (więcej informacji w artykule „Czym jest silne uwierzytelnianie”). Secure Access obsługuje różne silne uwierzytelniania i można je łączyć z dowolną inną obsługiwaną metodą uwierzytelniania.

Czym jest silne uwierzytelnianie?

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)

Hasło jednorazowe (sms / e-mail)

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.

Twoja przeglądarka nie obsługuje wideo HTML5.

Hasło jednorazowe (aplikacje Authenticator)

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 identyfikatora bankowego

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.

Twoja przeglądarka nie obsługuje wideo HTML5.

Szwecja:

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

Twoja przeglądarka nie obsługuje wideo HTML5.

Uwierzytelnianie Suomi.fi

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 .

Używane protokoły uwierzytelniania

Protokół uwierzytelniania oznacza możliwości techniczne wykorzystywane do osiągnięcia wymaganej metody uwierzytelniania. Niektóre metody uwierzytelniania nie wymagają żadnego protokołu uwierzytelniania, lecz wykorzystują żądania https, algorytmy itp. Wszystkie te elementy są opisane osobno w opisie metody.

SAML 2.0

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.

Wybierz protokół OpenID , jeśli to możliwe

SAML jest starszym protokołem, a wielu innych dostawców aplikacji kończy SAML obsługę i przechodzi na protokół OpenID . Secure Access obsługuje oba protokoły, a Efecte zaleca sprawdzenie możliwości obu metod. Jeśli żadna z funkcji nie obsługuje SAML , zalecamy użycie OpenID .

Linki do artykułów dotyczących konfiguracji

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

OpenID Connect i OAuth 2.0

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.

Wybierz protokół OpenID , jeśli to możliwe

SAML jest starszym protokołem, a wielu innych dostawców aplikacji kończy SAML obsługę i przechodzi na protokół OpenID . Secure Access obsługuje oba protokoły, a Efecte zaleca sprawdzenie możliwości obu metod. Jeśli żadna z funkcji nie obsługuje SAML , zalecamy użycie OpenID .

Więcej o różnicach między SAML i OpenID możesz przeczytać tutaj.

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

Usługa wykrywania SAML

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

Fińska Sieć Zaufania (FTN)

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 .

Identyfikator szwedzkiego banku

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

Inne funkcjonalności

Warto wiedzieć, że niektóre z tych funkcjonalności są domyślnie włączone we wszystkich konfiguracjach Secure Access , a niektóre z nich można włączyć w razie potrzeby.

Ochrona przed atakami siłowymi

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 klikaniem

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.

Polityka plików cookie

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

Zgoda użytkownika

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ę.

Interfejs użytkownika zgody ESA

Linki do artykułów dotyczących konfiguracji

Skonfiguruj ESA , aby korzystać ze zgody użytkownika