Secure Accessia käytetään käyttäjien todentamiseen Matrix42 Core-, Pro- ja IGA-ratkaisuihin sekä Self-Serviceen.

Secure Accessin avulla voit todentaa turvallisesti erityyppisiä käyttäjiä kirjautuessa:

1. Matrix42 Core-, Pro- ja IGA-Self-Serviceen
2. Matrix42 Core-, Pro- ja IGA-ratkaisuihin (kuten IGA, ITSM jne.)

Käytössä voi olla useita eri todennusmenetelmiä samanaikaisesti, ja käyttäjät voivat päästä eri palveluihin tai ratkaisuihin valitun todennuksen perusteella.

Sitä käytetään myös haitallisen toiminnan seurantaan todennuksen aikana, minkä vuoksi raa’an voiman hyökkäyksiltä (brute force) ja klikkikaappaukselta (click-jacking) suojaus on oletuksena käytössä.

Kirjautumissivu

Kaikki Matrix42 Core-, Pro- ja IGA-ratkaisut käyttävät yhteistä kirjautumissivua. Kirjautumissivua käytetään kirjautumiseen Matrix42 Core-, Pro- ja IGA-Self-Serviceen sekä ratkaisuihin.

Käytettyjen todennusprotokollien mukaan (määritettävissä) näytetään erilliset välilehdet (yrityksen) kirjautumiselle ja muille todennusmenetelmille.

Kirjautumisnäytön keskellä oleva taustakuva ja logo voidaan vaihtaa asiakkaan oman ilmeen mukaisiksi. Alla olevissa kuvakaappauksissa käytetään Matrix42-logoa ja oletustaustakuvaa. Näitä voi muuttaa vain ESA-isännästä, joten jos sinulla ei ole sinne pääsyä, sinun tulee pyytää Matrix42:ta tekemään muutos tämän ohjeen mukaisesti: Configure themes for ESA

Kielivaihtoehdot

Käyttäjät voivat vaihtaa oletuskielen toiseksi valitsemalla sen oikeassa yläkulmassa olevasta pudotusvalikosta.

Oletuskielet ovat: English, Suomi, Svenska ja Deutsch.
Käytettävissä olevat kielet ovat: englanti, suomi, saksa, ruotsi, puola, kroatia, tšekki, tanska, hollanti, viro, ranska, italia, latvia, liettua, norja, venäjä, espanja ja turkki.

Hallintakonsolit
Kun määrität, ketkä käyttäjät voivat päästä kirjautumissivulle, määritä todennuksen provisiointitehtävä Service Management -alustassa.

Todennuksen määritys vaatii lisämuutoksia vain, kun todennusprotokollia muutetaan tai otetaan käyttöön uusia.


Todennusprotokolla tulee määrittää myös Secure Accessin hallintakonsolissa, jossa määritetään myös todennuksen kartoitukset. Katso esimerkiksi: https://<oman instanssisi URL>/auth/admin

Secure Access (ESA) on Keycloakin (https://www.keycloak.org) uudelleenbrändäys; Keycloak on avoimen lähdekoodin sovellus, joka tarjoaa todennuspalveluita.

Matrix42 on mukauttanut sitä seuraavasti:

• Kirjautumisnäytöt on korvattu
• Mukautetut todentajat tarjoavat pääsyn Matrix42 Core-, Pro- ja IGA-ratkaisuihin.

Secure Accessissa on seuraavat komponentit:

Apache

Apache HTTP -palvelinta käyttävät Matrix42 Core, Pro ja IGA toimiakseen välityspalvelimena kaikille Matrix42 Core-, Pro- ja IGA-ratkaisuille. Kun käyttäjä avaa selaimen ja kirjoittaa Matrix42 Core-, Pro- tai IGA-ratkaisun tarjoaman URL-osoitteen, pyyntö lähetetään Apache-palvelimelle. Jos pyyntö on valtuutettu (käyttäjä on syöttänyt tunnuksensa oikein), se välitetään Matrix42 Core-, Pro- tai IGA-ratkaisuun, johon käyttäjä yrittää päästä (esimerkiksi: ITSM, ESS, IGA).

ESA

Secure Access tarjoaa hallintakonsolin, jonka avulla voit määrittää käyttäjille erityisvaatimuksia Matrix42 Core-, Pro- ja IGA-ratkaisuihin kirjautumiseen. Hallintakonsolissa voidaan määrittää, mitä tietoa poimitaan Identity Providerilta (IdP) ja mitä tietoa lähetetään Matrix42 Core-, Pro- tai IGA-ratkaisulle (esimerkiksi: Self-Service, ITSM, IGA jne.).

ESA-tietokanta

Secure Access käyttää PostgreSQL-tietokantaa asiakaskohtaisten määritysten ja Matrix42 Core-, Pro- ja IGA-ratkaisuihin kirjautuneiden käyttäjien tietojen yhteenvedon tallentamiseen.

Jokaisella Matrix42-pilviympäristön asiakkaalla, olipa kyseessä dedikoitu tai yksityinen ympäristö, on oma dedikoitu Apache HTTP -palvelin, joka on määritetty käyttämään Shibbolethia (https://www.shibboleth.net) palveluntarjoajanaan. Keycloak toimii välityspalvelimena varsinaiselle identiteetin tarjoajalle, joka voi olla Azure, AD, OpenLDAP tai vastaava ratkaisu.

Kun käyttäjä kirjoittaa Matrix42 Core-, Pro- tai IGA-sovelluksen URL-osoitteen, pyyntö ohjataan asiakkaan Apache HTTP -palvelimelle DNS-merkinnän kautta. Tämä toiminta on sama riippumatta siitä, onko ympäristö dedikoitu vai yksityinen. Alla oleva kuva näyttää dedikoidun pilviympäristön, joka on osoitettu yhdelle tietylle asiakkaalle/vuokraajalle:

Jokaisen asiakkaan Apache HTTP -palvelin on määritetty ohjaamaan todentamattomat pyynnöt Keycloakiin (ESA), joka hoitaa todennuksen. Todennus tapahtuu joko:

• Näyttämällä oman kirjautumisnäytön
  • Tämä tehdään, jos asiakas käyttää AD/LDAP:ia tai jos käyttäjän tunnukset on tallennettu paikallisesti ESM:ään
• Ohjaamalla käyttäjän selaimen Azuren tarjoamaan kirjautumisnäyttöön.

Jos asiakas käyttää Azurea tai ADFS:ää, Keycloak (ESA) voidaan määrittää sallimaan kertakirjautuminen (Single Sign-On, SSO). Tässä tilanteessa käyttäjän ei tarvitse kirjoittaa kirjautumistietojaan uudelleen, jos hän on jo tehnyt sen hyväksytyllä tavalla. Esimerkiksi käyttäjä on käynnistänyt kannettavansa, joka on määritetty todentamaan Azuren/ADFS:n avulla käynnistyksen yhteydessä.

ESA voi sisältää useita eri realmeja, joilla on omat todennusmenetelmänsä. Esimerkiksi sisäiset käyttäjät voivat käyttää omaa todennusmenetelmäänsä ja ulkoiset käyttäjät omaansa.

Valvonta
Secure Accessia valvotaan Matrix42:n keskitetyssä valvontajärjestelmässä. Matrix42:lla on useita antureita sovellusta kohden sen varmistamiseksi, että jos jossakin Matrix42-pilven sovelluksessa ilmenee ongelma, valvontajärjestelmä luo hälytyksen ja ongelma tutkitaan mahdollisimman pian.
Matrix42 ei tuo mitään asiakasdataa Matrix42:n valvontajärjestelmään.
 

Lokitus
Secure Access luo järjestelmälokin, josta pääkäyttäjät löytävät yksityiskohtaiset lokitiedostot auditointia ja vianmääritystä varten.

Federoitua käyttäjäidentiteettiä käytetään pääsyyn useisiin toimialueisiin tai sovelluksiin käyttämällä vain yhtä käyttäjätunnuslistaa. Käyttäjäfederaation vakiokäytäntö on, että käyttäjän identiteetti linkitetään useiden eri identiteetinhallintajärjestelmien välillä.

On hyvin yleistä, että organisaatiolla on jo käytössä hakemistopalvelu, johon tallennetaan käyttäjä- ja tunnistetiedot (käyttäjätunnus ja salasana). Käyttäjäfederaatio tarjoaa pääsyn ulkoisiin tietokantoihin ja hakemistoihin, kuten LDAP:iin ja Active Directoryyn.

Secure Access voi vahvistaa tunnukset hakemistosta ja hakea käyttäjän identiteettitiedot käyttäjän todentamiseksi Matrix42 Pro- ja IGA-ratkaisuihin. LDAP on tuettu vaihtoehto.

Kirjautumisvideo

Linkkejä määritysartikkeleihin

Customer Instructions for User Federation

Configure: User federation for Authentication

Kertakirjautuminen (Single-Sign-On, SSO) on yleisesti käytetty todennusmenetelmä, joka tarkoittaa, ettei käyttäjän tarvitse syöttää tunnuksia (käyttäjätunnus ja salasana) todentamisen yhteydessä, vaan käyttäjä todennetaan Identity Providerilta (IdP) saaduilla tunnuksilla, tavallisesti hakemistolla kuten Entra ID (formerly Azure AD) . 

SSO voidaan toteuttaa teknisesti joko SAML- tai OpenID-protokollalla, ja käytettävä protokolla vaihtelee aina asiakkaan IdP:n mukaan.

Esimerkkejä SSO:ssa käytetyistä todennusprotokollista:

ADFS (Microsoft Active Directory Federation Service) käyttää aina SAML-protokollaa.

Entra ID SSO (Microsoft Azuren kertakirjautuminen) käyttää SAML- tai OpenID-protokollaa.

Kirjautumisvideo

Linkkejä määritysartikkeleihin

Customer instructions for Entra ID configuration SAML

Customer instructions for Entra ID configuration OpenID

Configure: ESA Entra ID SSO

Customer instructions for ADFS Login

Configure: ESA ADFS Login

Secure Access tukee myös Matrix42 Pro- tai IGA (ESM) -paikallisia käyttäjiä. Paikallinen käyttäjä on henkilö, jonka tunnukset eivät sijaitse missään Identity Providerissa (esimerkiksi AD, Azure AD, OpenLDAP jne.).

Paikallisten käyttäjien tiedot tulee löytyä siitä Matrix42 Pro- tai IGA-ratkaisusta, jota asiakas käyttää. Paikalliset käyttäjät voidaan luoda manuaalisesti alustan määrityksestä, tai ne voidaan luoda työnkulkumoottorilla.

Huomaa, että sama logiikka koskee mitä tahansa Matrix42 Pro- tai IGA-alustan päälle rakennettua ratkaisua.

Kirjautumisvideo

Linkkejä määritysartikkeleihin

Configure: Efecte Local user login

Secure Access tukee mahdollisuutta myöntää vierailijapääsy Matrix42 Pro- ja IGA-Self-Serviceen.

Kirjautumissivulta käyttäjä valitsee vierailijapääsyn todennuksen, vierailijakäyttäjälle luodaan väliaikaiset tunnukset ja hänet ohjataan Self-Serviceen.

Vierailijakäyttäjillä on rajoitettu näkyvyys palveluihin ja tietoihin Self-Servicessä, eivätkä he pysty palaamaan Self-Servicestä tekemiinsä pyyntöihin tai raportteihin. Turvallisuussyistä on erittäin suositeltavaa, että käyttäjä suorittaa ReCaptcha-toiminnon, eli vahvistaa, ettei hän ole robotti.

Kirjautumisvideo – ReCaptcha-toiminto

Linkkejä määritysartikkeleihin

 Configure: ESA - Guest Access configuration

Secure Accessia voidaan käyttää anonyymin kirjautumisen toiminnon tarjoamiseen, mikä tarkoittaa, että ennen käyttäjän kirjautumista Efecte Self-Serviceen käyttäjälle luodaan satunnaisesti käyttäjätunnus ja salasana. Nämä anonyymit käyttäjät voivat kopioida tunnukset ja käyttää niitä esimerkiksi raportin tilan tarkasteluun.

Secure Access tai mikään Matrix42 Pro- tai IGA-ratkaisu ei tallenna käyttäjää tai käyttäjän istuntoa tunnistavia tietoja. Turvallisuussyistä on erittäin suositeltavaa, että käyttäjä suorittaa ReCaptcha-toiminnon, eli vahvistaa, ettei hän ole robotti.

Esimerkiksi: Matrix42 Whistleblower -ratkaisu käyttää anonyymin kirjautumisen ominaisuutta.

Kirjautumisvideo – Efecte Whistleblower

Linkkejä määritysartikkeleihin

Configure: Whistleblower Access configuration

Secure Access tukee SAML Discovery Servicea, jota käytetään Virtu-todennukseen.

Virtu on Suomen valtionhallinnon yhteinen kertakirjautumisratkaisu, josta vastaa Valtion tieto- ja viestintätekniikkakeskus Valtori, mikä tarkoittaa, että asiakkaan tulee kuulua Virtu-luottamusverkostoon.

Kirjautumissivulta käyttäjä valitsee, minkä tyyppistä todennusta tai toimintoa hän aikoo käyttää, ja jos se vaatii Virtu-todennusta, käyttäjä ohjataan Virtu-kirjautumissivulle. Kun käyttäjä on todentanut itsensä, hänet ohjataan takaisin Secure Accessiin, ja hän pääsee käyttämään Matrix42 Pro- ja IGA-ratkaisuja määritettyjen käyttöoikeuksien mukaisesti.

Lue lisää Virtusta here. 

Linkkejä määritysartikkeleihin

Configure: ESA Virtu Authentication

Customer instructions for Virtu Authentication

Secure Access tukee SAML Discovery Servicea, jota käytetään HAKA-todennukseen.

HAKA on Suomen yliopistojen, ammattikorkeakoulujen ja tutkimuslaitosten yhteinen identiteettifederaatio ja kertakirjautumisratkaisu, josta vastaa CSC – Tieteen tietotekniikan keskus Oy, mikä tarkoittaa, että asiakkaan tulee kuulua HAKA-luottamusverkostoon.

Kirjautumissivulta käyttäjä valitsee, minkä tyyppistä todennusta tai toimintoa hän aikoo käyttää, ja jos se vaatii HAKA-todennusta, käyttäjä ohjataan HAKA-kirjautumissivulle. Kun käyttäjä on todentanut itsensä, hänet ohjataan takaisin Secure Accessiin, ja hän pääsee käyttämään Matrix42 Pro- ja IGA-ratkaisuja määritettyjen käyttöoikeuksien mukaisesti.

Lue lisää HAKAsta here. 

Linkkejä määritysartikkeleihin

Configure: ESA HAKA Authentication

Customer instructions for HAKA Authentication

Secure Access tukee Google-todennusta.

Kirjautumissivulta käyttäjä valitsee, minkä tyyppistä todennusta tai toimintoa hän aikoo käyttää, ja jos se vaatii Google-todennusta, käyttäjä ohjataan Google-kirjautumissivulle. Kun käyttäjä on todentanut itsensä, hänet ohjataan takaisin Secure Accessiin, ja hän pääsee käyttämään Matrix42 Pro- ja IGA-ratkaisuja määritettyjen käyttöoikeuksien mukaisesti.

Kirjautumisvideo

Linkkejä määritysartikkeleihin

Configure: ESA Google authentication

Secure Access tukee SAML-protokollaa, jota käytetään Okta-todennukseen.

Okta on turvallinen identiteettipilvi, joka yhdistää kaikki sovelluksesi, kirjautumisesi ja laitteesi yhtenäiseksi digitaaliseksi kokonaisuudeksi.

Kirjautumissivulta käyttäjä valitsee, minkä tyyppistä todennusta tai toimintoa hän aikoo käyttää, ja jos se vaatii Okta-todennusta, käyttäjä ohjataan Okta-kirjautumissivulle. Kun käyttäjä on todentanut itsensä, hänet ohjataan takaisin Secure Accessiin, ja hän pääsee käyttämään Matrix42 Pro- ja IGA-ratkaisuja määritettyjen käyttöoikeuksien mukaisesti.

Kirjautumisvideo

Linkkejä määritysartikkeleihin

How to Configure Authentication for Okta (SAML)?

Secure Access tukee OpenID-protokollaa, jota käytetään Keycloak-todennukseen. Keycloak on avoimen lähdekoodin ohjelmistoratkaisu, joka on suunniteltu tarjoamaan kertakirjautumispääsy sovelluksiin ja palveluihin. Sen avulla käyttäjät voivat todentaa itsensä kerran ja käyttää useita sovelluksia ilman, että heidän tarvitsee syöttää tunnuksiaan uudelleen.

Kirjautumissivulta käyttäjä valitsee, minkä tyyppistä todennusta tai toimintoa hän aikoo käyttää, ja jos se vaatii Keycloak-todennusta, käyttäjä ohjataan Keycloak-kirjautumissivulle. Kun käyttäjä on todentanut itsensä, hänet ohjataan takaisin Secure Accessiin, ja hän pääsee käyttämään Matrix42 Pro- ja IGA-ratkaisuja määritettyjen käyttöoikeuksien mukaisesti.

Linkkejä määritysartikkeleihin

How to Configure Authentication for Keycloak?

SAML is a protocol designed for exchanging authentication and authorization identities between security domains. 

Secure Access supports user authentication performed by Identity Provider (IdP), for example Entra ID, using a SAML 2.0 connector/adapter.

SAML sends claims by using XML SAML format. This format is most commonly used to help organizations with multiple applications, to be able to provide single login for their end-users. 

Linkkejä määritysartikkeleihin

Configure: SAML Entra authentication
Customer instructions for SAML Entra ID authentication configuration

OAuth 2.0 ja OpenID Connect (laajennus OAuth 2.0 -protokollaan) mahdollistavat organisaatioille loppukäyttäjän identiteetin vahvistamisen Authorization Serverin suorittaman todennuksen perusteella sekä loppukäyttäjän perusprofiilitietojen hankkimisen.

Secure Access supports user authentication performed by an Identity Provider (IdP), for example Entra ID, using OpenID Connect connector/adapter.  

OpenID Connect is built on top of OAuth protocol and it sends claims by using JSON Web Token (JWT) format and it is commonly used with for example cloud-based Identity Providers, consumer websites and mobile apps.

Linkkejä määritysartikkeleihin

Configure: OIDC Entra ID authentication
Customer instructions for OIDC Entra ID configuration

Secure Access tukee Shibboleth-todennusta.

Kirjautumissivulta käyttäjä valitsee, minkä tyyppistä todennusta tai toimintoa hän aikoo käyttää, ja jos se vaatii Shibboleth-todennusta, käyttäjä ohjataan Shibboleth-kirjautumissivulle. Kun käyttäjä on todentanut itsensä, hänet ohjataan takaisin Secure Accessiin, ja hän pääsee käyttämään Matrix42 Pro- ja IGA-ratkaisuja määritettyjen käyttöoikeuksien mukaisesti.

Linkkejä määritysartikkeleihin
Configure: Shibboleth authentication

Vahva todennus on määritelmä, joka täyttyy, kun todennuksen aikana täytetään kaksi (2) seuraavasta kolmesta (3) periaatteesta:

1. Jotain, mitä sinulla on (esimerkiksi matkapuhelin)
2. Jotain, minkä tiedät (esimerkiksi käyttäjätunnus ja salasana)
3. Jotain, mitä olet (esimerkiksi sormenjälki)

Nykyään vahva todennus sisältää useimmiten:

1. Jotain, minkä tiedät (käyttäjätunnus ja salasana)
2. Jotain, mitä sinulla on (kertakäyttöinen salasana mobiililaitteeseen)

Periaatteet ovat se, mikä erottaa vahvan todennuksen kaksivaiheisesta todennuksesta (2FA) ja monivaiheisesta todennuksesta (MFA), jotka vaativat vain, että käytössä on vähintään kaksi todennusmenetelmää, mutta ne voivat olla peräisin samasta periaatteesta – tämä tarkoittaa, että 2FA tai MFA ei välttämättä ole vahvaa todennusta.

Seuraavaa esimerkkiä voidaan kutsua MFA:ksi tai 2FA:ksi, mutta ei vahvaksi todennukseksi,

1. Jotain, minkä tiedät (käyttäjätunnus ja salasana)
2. Jotain, minkä tiedät (vastaukset turvakysymyksiin)

Kertakäyttöinen salasana (OTP) voi olla osa todennusta, ja se tarkoittaa, että kertakäyttöinen salasana lähetetään käyttäjälle sähköpostitse tai tekstiviestillä (käyttäjän matkapuhelimeen).

Joissakin tapauksissa riittää, että syötetään vain kertakäyttöinen salasana, mutta jos asiakas tavoittelee vahvaa todennusta, suositus on pyytää käyttäjää antamaan esimerkiksi myös tunnukset (käyttäjätunnus ja salasana) todennusta varten.

Kertakäyttöisen salasanan toiminnallisuus tarjotaan Signicat-palveluiden kautta, eli Signicat on Efecten kumppani, jonka teknologiaa käytetään todennukseen.

Secure Access tukee kertakäyttöiseen koodiin perustuvaa todennusta, eli väliaikaisia salasanoja, jotka luodaan todennussovelluksella, kuten Google Authenticatorilla tai FreeOTP:lla.

Kun kertakäyttöinen salasana (tunnistussovelluksen avulla) on määritetty ja käyttäjä on antanut tunnuksensa (käyttäjätunnus ja salasana), Secure Access pyytää käyttäjää antamaan joko Google Authenticatorin tai FreeOTP:n luoman salasanan. Huomaa, että tunnistussovellus tulee olla asennettuna käyttäjän matkapuhelimeen.

Linkkejä määritysartikkeleihin

Configure: Two-Factor Authentication (2FA)

Bank ID -todennus on aina vahvaa todennusta, ja se tarkoittaa, että käyttäjä käyttää henkilökohtaisia Bank ID -tunnuksia (pankin tai valtion myöntämiä) todentaakseen itsensä Self-Serviceen tai Efecte-ratkaisuihin.

Se on yleinen todennusmenetelmä erityisesti Pohjoismaissa, mutta se yleistyy myös muissa Euroopan maissa. Jos tarvitset bank ID -todennusta Suomen tai Ruotsin ulkopuolella, ota yhteyttä Efecteen saadaksesi lisätietoja.

Bank ID -todennus toteutetaan maakohtaisilla protokollilla, ja Secure Access käyttää Signicat-palveluita identiteettivälittäjänä (Identity Broker) pankkien ja Secure Accessin välillä. Tällä hetkellä bank ID -todennusta tuetaan Suomessa ja Ruotsissa.

Linkkejä määritysartikkeleihin

https://docs.efecte.com/configure-authentication/configure-signicat-authentication 

Suomi:

Suomessa bank ID -todennusta käyttävät yleisimmin yksityisen sektorin yritykset sekä tapaukset, joissa valtionhallinnon organisaatio ei jostain syystä voi käyttää suomi.fi-todennusta.

Ruotsi:

Ruotsissa bank ID -todennusta käytetään yleisesti sekä valtionhallinnon että yksityisen sektorin organisaatioissa.

Suomi.fi-todennus muistuttaa bank ID -todennusta, mutta ainoa ero on se, että suomi.fi:tä voivat käyttää vain suomalaiset valtionhallinnon organisaatiot. Voit tunnistautua palveluihin suomalaisilla verkkopankkitunnuksilla, mobiilivarmenteella tai varmennekortilla.

Secure Access käyttää Signicat-palveluita identiteettivälittäjänä (Identity Broker) suomi.fi-palvelun ja Secure Accessin välillä.

Lue lisää suomi.fi-todennuksesta here.

Linkkejä määritysartikkeleihin

https://docs.efecte.com/configure-authentication/configure-signicat-authentication 

SAML is a protocol designed for exchanging authentication and authorization identities between security domains. 

Secure Access supports user authentication performed by Identity Provider (IdP), for example Entra ID, using a SAML 2.0 connector/adapter.

SAML sends claims by using XML SAML format. This format is most commonly used to help organizations with multiple applications, to be able to provide single login for their end-users. 

Linkkejä määritysartikkeleihin

Configure: SAML Entra authentication
Customer instructions for SAML Entra ID authentication configuration

OAuth 2.0 ja OpenID Connect (laajennus OAuth 2.0 -protokollaan) mahdollistavat organisaatioille loppukäyttäjän identiteetin vahvistamisen Authorization Serverin suorittaman todennuksen perusteella sekä loppukäyttäjän perusprofiilitietojen hankkimisen.

Secure Access supports user authentication performed by an Identity Provider (IdP), for example Entra ID, using OpenID Connect connector/adapter.  

OpenID Connect is built on top of OAuth protocol and it sends claims by using JSON Web Token (JWT) format and it is commonly used with for example cloud-based Identity Providers, consumer websites and mobile apps.

Linkkejä määritysartikkeleihin

Configure: OIDC Entra ID authentication
Customer instructions for OIDC Entra ID configuration

SAML Discovery Service -protokollaa käytetään Secure Accessissa HAKA- ja Virtu-todennukseen, mutta sitä käytetään yleisesti myös esimerkiksi yliopistoissa.

Linkkejä määritysartikkeleihin

Configure: ESA HAKA authentication

Configure: ESA Virtu authentication

Finnish Trust Network -protokollaa käytetään todennettaessa suomalaisilla bank ID -tunnuksilla sekä todennettaessa suomi.fi:llä. Sen käyttö on pakollista, ja lisätietoa löytyy here.

Linkkejä määritysartikkeleihin

https://docs.efecte.com/configure-authentication/configure-signicat-authentication 

Raa'an voiman hyökkäys (brute force attack) yrittää arvata käyttäjän salasanan yrittämällä kirjautua useita kertoja. Secure Accessissa on raa'an voiman hyökkäysten tunnistusominaisuudet, ja se voi väliaikaisesti poistaa käyttäjätilin käytöstä, jos epäonnistuneiden kirjautumisyritysten määrä ylittää määritetyn kynnysarvon.
Ottamalla käyttöön Brute Force -tunnistuksen (oletuksena käytössä) voimme väliaikaisesti estää järjestelmään murtautumista yrittävät hyökkääjät. Kun käyttäjätili on väliaikaisesti lukittu ja käyttäjä yrittää kirjautua, Secure Access näyttää oletusarvoisen virheellinen käyttäjätunnus tai salasana -virheilmoituksen, jotta hyökkääjä ei tiedä tilin olevan poissa käytöstä.
 

Linkkejä määritysartikkeleihin

How to Enable Brute Force Detection to ESA

Klikkikaappaussuojaus estää hyökkääjää upottamasta verkkosivua iframeen ja huijaamasta käyttäjää klikkaamaan piilotettuja tai naamioituja painikkeita tai linkkejä.

Klikkikaappaussuojaus on oletuksena käytössä.

Asiakas voi ottaa evästekäytännön käyttöön kirjautumisprosessissaan. Tämä tarkoittaa, että verkkosivuston kävijöille kerrotaan, mitä käyttäjätietoja evästeet seuraavat, miksi näitä tietoja kerätään ja minne ne lähetetään.
 

Linkkejä määritysartikkeleihin

Configure ESA cookie settings

Asiakas voi ottaa käyttäjän suostumuksen käyttöön kirjautumisprosessissaan, mikä tarkoittaa, että verkkosivuston käyttäjät antavat luvan kerätä, käyttää ja käsitellä heidän tietojaan evästeiden avulla. Kun käyttäjä on antanut tunnuksensa, ESA näyttää ponnahdusikkunan, joka kertoo, mikä asiakassovellus pyytää kirjautumista ja mitä identiteettitietoja käyttäjältä pyydetään. Käyttäjä voi päättää, myöntääkö hän pyynnön vai ei.

Linkkejä määritysartikkeleihin

Configure ESA to use User consent