Secure Access används för att autentisera användare till Matrix42 Core , Pro and IGA lösningar samt självbetjäning.

Med Secure Access kan du säkert autentisera olika typer av användare när du loggar in på:

1. Matrix42 Core , Pro and IGA självbetjäning
2. Matrix42 Core , Pro and IGA -lösningar (som IGA , ITSM etc.)

Du kan använda flera olika autentiseringsmetoder samtidigt, och användare kan få åtkomst till olika tjänster eller lösningar baserat på vald autentisering.

Den används också för att övervaka skadlig aktivitet under autentiseringen, och därför är skydd mot brute force-attacker och clickjacking aktiverade som standard.

Inloggningssida

Alla Matrix42 Core , Pro and IGA -lösningar använder en gemensam inloggningssida. Inloggningssidan används för att logga in på Matrix42 Core , Pro and IGA Self-Service och lösningar.

Beroende på vilka autentiseringsprotokoll som används (konfigurerbara) visas separata flikar för (företags)inloggning och resten av autentiseringsmetoderna.

Bakgrundsbilden och logotypen mitt på inloggningsskärmen kan ändras enligt kundens design. I skärmdumparna nedan används Matrix42 logotypen och standardbakgrundsbilden. Dessa kan endast ändras från ESA värden, så om du inte har åtkomst dit måste du be Matrix42 att göra denna ändring enligt denna uid : Konfigurera teman för ESA

Språkalternativ

Användare har möjlighet att ändra standardspråket till ett annat genom att välja det från rullgardinsmenyn i det övre högra hörnet.

Standardspråken är: engelska, finska, svenska och tyska.
Tillgängliga språk är: engelska, finska, tyska, svenska, polska, kroatiska, tjeckiska, danska, nederländska, estniska, franska, italienska, lettiska, litauiska, norska, ryska, spanska och turkiska.

Administratörskonsoler
När du definierar vilka användare som ska kunna komma in på inloggningssidan, konfigurera provisioneringsuppgiften för autentisering i Service Management-plattformen.

Autentiseringskonfigurationen kräver endast ytterligare ändringar när autentiseringsprotokollen ändras eller nya tas i bruk.


Autentiseringsprotokollet måste också konfigureras i Secure Access -administratörskonsolen, där även mappningar för autentisering definieras. Se till exempel: https://<din instans-URL>/auth/admin

Secure Access ( ESA ) är en omdöpning av Keycloak ( keycloak ), som är en öppen källkodsapplikation som tillhandahåller autentiseringstjänster.

Den har anpassats av Matrix42 enligt följande:

• Inloggningsskärmarna är utbytta
• Anpassade autentiserare ger åtkomst till Matrix42 Core , Pro and IGA lösningar.

Secure Access har följande komponenter:

Apache

En Apache HTTP-server används av Matrix42 Core , Pro and IGA som proxy för alla Matrix42 Core , Pro and IGA -lösningar. När en användare öppnar en webbläsare och skriver in URL:en till en lösning som tillhandahålls av Matrix42 Core , Pro and IGA , skickas begäran till Apache-servern. Om begäran är auktoriserad (användaren har angett sina inloggningsuppgifter korrekt) vidarebefordras den till den Matrix42 Core , Pro and IGA lösning som användaren försöker komma åt (till exempel: ITSM, ESS, IGA ).

ESA

Secure Access tillhandahåller en administratörskonsol som du kan använda för att konfigurera specifika krav för användare som ska logga in på Matrix42 Core , Pro and IGA lösningar. I administratörskonsolen är det möjligt att konfigurera vilken information som ska extraheras från Pro (IdP) och vilken information som skickas till Matrix42 Core , Pro and IGA lösningar (till exempel: självbetjäning, ITSM, IGA etc.).

ESA databas

Secure Access använder en Postgre SQL databas för att lagra kundspecifika konfigurationer och en sammanfattning av information om de användare som har loggat in på Matrix42 Core , Pro and IGA lösningar.

Varje kund i Matrix42 Cloud -miljön, oavsett om det är en dedikerad eller privat miljö, har sin egen dedikerade Apache HTTP-server, som har konfigurerats för att använda Shibboleth ( https://www.shibboleth.net ) som tjänsteleverantör. Keycloak fungerar som en proxy för den verkliga identitetsleverantören, som kan vara Azure , AD , OpenLDAP eller liknande lösningar.

När en användare skriver in URL:en för en Matrix42 Core , Pro and IGA applikation, dirigeras begäran till kundens Apache HTTP-server via en DNS-post. Detta beteende är detsamma oavsett om miljön körs som en dedikerad eller en privat miljö. Bilden nedan visar en dedikerad molnmiljö som har allokerats till en specifik kund/hyresgäst:

Varje kunds Apache HTTP-server är konfigurerad för att omdirigera oautentiserade förfrågningar till Keycloak ( ESA ), som hanterar autentiseringen. Autentiseringen görs antingen genom:

• Presenterar sin egen inloggningsskärm
  • Detta görs om kunden använder AD /LDAP eller om användarens inloggningsuppgifter lagras lokalt i ESM.
• Omdirigerar användarens webbläsare till inloggningsskärmen som tillhandahålls av Azure .

Om en kund använder Azure eller AD FS kan Keycloak ( ESA ) konfigureras för att tillåta Single Sign-On (SSO). I den här situationen behöver en användare inte skriva sina inloggningsuppgifter igen om hen redan har gjort det på ett godkänt sätt. Till exempel har användaren startat sin bärbara dator, som har konfigurerats för att autentisera med Azure / AD FS vid start.

ESA kan innehålla flera olika realms med egna autentiseringsmetoder. Till exempel kan interna användare använda sin egen autentiseringsmetod och externa användare kan använda sin egen.

Övervakning
Secure Access övervakas i Matrix42 centraliserade övervakningssystem. Matrix42 har flera sensorer per applikation för att garantera att om det uppstår ett problem i någon av applikationerna i Matrix42 Cloud , genererar övervakningssystemet ett larm och problemet undersöks så snart som möjligt.
Matrix42 överför inga kunddata till Matrix42 övervakningssystem.

Skogsavverkning
Secure Access genererar en systemlogg, där administratörer och användare kan hitta detaljerade loggfiler för granskningsändamål och felsökning.

Federerad användaridentitet används för att komma åt flera domäner eller applikationer med endast en enda uppsättning användaruppgifter. Standardpraxis med användarfederation är att användarens identitet länkas över flera olika identitetshanteringssystem.

Det är mycket vanligt att en organisation redan har en katalogtjänst i bruk, som de använder för att lagra användar- och inloggningsuppgifter (användarnamn och lösenord). Användarfederation ger åtkomst till externa databaser och kataloger, såsom LDAP och Active Directory .

Secure Access kan validera inloggningsuppgifter från en katalog och hämta användarens identitetsinformation för att autentisera användaren mot Efecte-lösningar. LDAP stöds som alternativ.

Inloggningsvideo

Länkar till konfigurationsartiklar

Kundinstruktioner för användarfederation

Konfigurera: Användarfederation för autentisering

Enkel inloggning (SSO) är en vanlig autentiseringsmetod som innebär att användaren inte behöver lägga till autentiseringsuppgifter (användarnamn och lösenord) under autentiseringen, utan istället autentiseras användaren med autentiseringsuppgifter som tas emot från Pro (IdP), vanligtvis en katalog som Entra ID (tidigare Azure AD ) .

SSO kan tekniskt implementeras med antingen SAML eller OpenID -protokoll och det varierar alltid vilket som används baserat på kundens IdP.

Exempel på autentiseringsprotokoll som används för SSO:

AD FS ( Microsoft Active Directory Federation Service) använder alltid SAML -protokollet.

Entra ID SSO (Microsoft Azure Single-Sign-On) använder SAML eller OpenID protokollet.

Inloggningsvideo

Länkar till konfigurationsartiklar

Kundinstruktioner för Entra ID konfiguration SAML

Kundinstruktioner för Entra ID konfiguration OpenID

Konfigurera: ESA Entra ID SSO

Kundinstruktioner för AD FS-inloggning

Konfigurera: ESA AD FS-inloggning

Secure Access stöder även lokala ESM-användare. En lokal användare är någon vars inloggningsuppgifter inte finns hos någon av Pro (till exempel AD , Azure AD , OpenLDAP etc.).

Information om lokala användare måste hittas i den Efecte-lösning som kunden använder. Lokala användare kan skapas manuellt från Efecte-plattformens konfiguration eller så kan lokala användare skapas med hjälp av arbetsflödesmotorn.

Observera att samma logik gäller för alla lösningar som byggs ovanpå Efecte-plattformen.

Inloggningsvideo

Länkar till konfigurationsartiklar

Konfigurera: Efecte Lokal användarinloggning

Secure Access stöder möjligheten att ge gäster åtkomst till Efecte självbetjäning.

Från Efectes inloggningssida väljer användaren gästautentisering, tillfälliga inloggningsuppgifter genereras för gästanvändaren och han/hon omdirigeras till Efectes självbetjäning.

Gästanvändare kommer att ha begränsad synlighet för tjänster och information i Efecte Self-Service, och gästanvändare kan inte återgå till sina förfrågningar eller rapporter som gjorts från Efecte Self-Service. Av säkerhetsskäl rekommenderas det starkt att användaren slutför ReCaptcha-åtgärden, vilket innebär att användaren bekräftar att han/hon inte är en robot.

Inloggningsvideo - ReCaptcha-åtgärd

Länkar till konfigurationsartiklar

Konfigurera: ESA - Konfiguration av gäståtkomst

Secure Access kan användas för att tillhandahålla anonym inloggningsfunktion, vilket innebär att användarnamn och lösenord slumpmässigt genereras för användaren innan användaren loggar in på Efecte Self-Service. Dessa anonyma användare kan kopiera inloggningsuppgifter och använda dem för att granska till exempel rapportstatus.

Secure Access eller någon annan Efecte-lösning sparar inte identifierande information om användaren eller användarsessionen. Av säkerhetsskäl rekommenderas det starkt att användaren slutför ReCaptcha-åtgärden, vilket innebär att användaren bekräftar att han/hon inte är en robot.

Till exempel: Efectes visselblåsarlösning använder en funktion för anonym inloggning.

Inloggningsvideo - Efecte visselblåsare

Länkar till konfigurationsartiklar

Konfigurera: Konfiguration av visselblåsaråtkomst

Secure Access stöder SAML Discovery Service, som används för Virtu-autentisering.

Virtu är den finska regeringens gemensamma lösning för enkel inloggning och ansvarar för statens ICT-center Valtori, vilket innebär att kunden måste vara en del av Virtus förtroendenätverk.

Från Efectes inloggningssida väljer användaren vilken typ av autentisering eller åtgärd han/hon ska använda och om det kräver Virtu-autentisering dirigeras användaren till Virtus inloggningssida. Efter att användaren har autentiserat sig omdirigeras han/hon tillbaka till Secure Access och användaren kan komma åt Efectes lösningar enligt definierade åtkomsträttigheter.

Läs mer om Virtu härifrån .

Länkar till konfigurationsartiklar

Konfigurera: ESA Virtu-autentisering

Kundinstruktioner för Virtu-autentisering

Secure Access stöder SAML Discovery Service, som används för HAKA-autentisering.

HAKA är en identitetsorganisation för finska universitet, yrkeshögskolor och forskningsinstitutioners gemensamma inloggningslösning (SSO), och ansvarar för CSC (IT Center for Science Ltd.), vilket innebär att kunden måste vara en del av HAKA:s förtroendenätverk.

Från Efectes inloggningssida väljer användaren vilken typ av autentisering eller åtgärd han/hon ska använda och om det kräver HAKA-autentisering dirigeras användaren till HAKAs inloggningssida. Efter att användaren har autentiserat sig omdirigeras han/hon tillbaka till Secure Access och användaren kan komma åt Efectes lösningar enligt definierade åtkomsträttigheter.

Läs mer om HAKA härifrån .

Länkar till konfigurationsartiklar

Konfigurera: ESA HAKA-autentisering

Kundinstruktioner för HAKA-autentisering

Secure Access stöder Google autentisering.

Från Efectes inloggningssida väljer användaren vilken typ av autentisering eller åtgärd han/hon ska använda och om det kräver Google autentisering dirigeras användaren till Google inloggningssida. Efter att användaren har autentiserat sig omdirigeras han/hon tillbaka till Secure Access och användaren kan komma åt Efectes lösningar enligt definierade åtkomsträttigheter.

Inloggningsvideo

Länkar till konfigurationsartiklar

Konfigurera: ESA Google autentisering

Secure Access stöder SAML -protokollet, som används för Okta-autentisering.

Okta är ett säkert identitetsmoln som länkar samman alla dina appar, inloggningar och enheter till en enhetlig digital struktur.

Från Efectes inloggningssida väljer användaren vilken typ av autentisering eller åtgärd han/hon ska använda och om det kräver Okta-autentisering dirigeras användaren till Oktas inloggningssida. Efter att användaren har autentiserat sig omdirigeras han/hon tillbaka till Secure Access och användaren kan komma åt Efectes lösningar enligt definierade åtkomsträttigheter.

Inloggningsvideo

Länkar till konfigurationsartiklar

Hur konfigurerar man autentisering för Okta ( SAML )?

Secure Access stöder OpenID -protokollet, som används för Keycloak autentisering. Keycloak är en öppen källkodsprogramvara som är utformad för att ge enkel inloggning till applikationer och tjänster. Den låter användare autentisera sig en gång och komma åt flera applikationer utan att behöva ange sina inloggningsuppgifter igen.

Från Efectes inloggningssida väljer användaren vilken typ av autentisering eller åtgärd han/hon ska använda och om det kräver Keycloak autentisering dirigeras användaren till Keycloak inloggningssidan. Efter att användaren har autentiserat sig omdirigeras han/hon tillbaka till Secure Access och användaren kan komma åt Efectes lösningar enligt definierade åtkomsträttigheter.

Länkar till konfigurationsartiklar

Hur konfigurerar man autentisering för Keycloak ?

Stark autentisering är en definition som uppnås när två (2) av följande tre (3) principer uppfylls under autentiseringen,

1. Något du har (till exempel mobiltelefon)
2. Något du vet (till exempel användarnamn och lösenord)
3. Något du är (till exempel fingeravtryck)

Nu för tiden innehåller den vanligaste starka autentiseringen,

1. Något du vet (användarnamn och lösenord)
2. Något du har (engångslösenord till mobil enhet)

Principer är det som skiljer stark autentisering från tvåfaktorsautentisering (2FA) och flerfaktorsautentisering, vilka bara kräver att minst två autentiseringsmetoder används, men de kan komma från samma princip, vilket innebär att 2FA eller MFA inte nödvändigtvis är stark autentisering.

Följande exempel kan kallas MFA eller 2FA, men inte stark autentisering,

1. Något du vet (användarnamn och lösenord)
2. Något du vet (svar på säkerhetsfrågor)

Engångslösenord (OTP) kan vara en del av autentiseringen och det innebär att engångslösenordet skickas till användaren via e-post eller sms (skickas till användarens mobiltelefon).

I vissa fall räcker det att bara ange engångslösenordet, men om kunden strävar efter stark autentisering rekommenderas det att be användaren att ange till exempel inloggningsuppgifter (användarnamn och lösenord) även för autentiseringen.

Engångslösenord finns tillgängligt i alla Signicat tjänster, vilket innebär att de är Efectes partner vars teknik används för autentisering.

Secure Access stöder engångsautentisering med kod, vilket är temporära lösenord som genereras av autentiseringsapplikationer som till exempel Google Authenticator eller FreeOTP.

När ett engångslösenord (med hjälp av autentiseringsprogrammet) är konfigurerat och användaren har angett sina inloggningsuppgifter (användarnamn och lösenord), ber Secure Access användaren att ange det genererade lösenordet antingen Google Authenticator eller FreeOTP. Observera att autentiseringsprogrammet måste vara installerat på användarens mobiltelefon.

Länkar till konfigurationsartiklar

Konfigurera: Tvåfaktorsautentisering (2FA)

Bank-ID-autentisering är alltid stark autentisering, och det innebär att användaren använder personliga bank-ID-uppgifter (tillhandahållna av banken eller myndigheter) för att autentisera sig mot självbetjänings- eller Efecte-lösningar.

Det är en vanlig autentiseringsmetod, särskilt i de skandinaviska länderna, men den blir allt vanligare även i andra europeiska länder. Om du behöver autentisering med bank-ID utanför Finland eller Sverige, vänligen kontakta Efecte för mer information.

Bank-ID-autentisering görs med hjälp av landsspecifika protokoll och Secure Access använder Signicat tjänster som identitetsförmedlare mellan banker och Secure Access . För närvarande stöds bank-ID-autentisering i Finland och Sverige.

Finland:

I Finland används bank-ID-autentisering oftast av privata företag och i fall där statliga organisationer av någon anledning inte kan använda suomi.fi-autentisering.

Sverige:

I Sverige används bank-ID-autentisering ofta bland statliga och privata organisationer.

Suomi.fi-autentisering liknar bank-ID-autentisering, men den enda skillnaden är att suomi.fi endast kan användas av finska myndigheter. Du kan identifiera dig i tjänster med finska nätbankskoder, ett mobilt certifikatkort eller ett certifikatkort.

Secure Access använder Signicat -tjänster som identitetsförmedlare mellan suomi.fi-tjänsten och Secure Access .

Läs mer om suomi.fi-autentisering här .

SAML är ett protokoll utformat för att utbyta autentiserings- och auktoriseringsidentiteter mellan säkerhetsdomäner.

Secure Access stöder användarautentisering som utförs av en Pro (IdP), till exempel Entra ID , med hjälp av en SAML 2.0-anslutning/adapter.

SAML skickar anspråk med hjälp av XML SAML format. Detta format används oftast för att hjälpa organisationer med flera applikationer att kunna tillhandahålla en enda inloggning för sina slutanvändare.

Länkar till konfigurationsartiklar

Konfigurera: ESA M SAML autentisering
ESA - Kundinstruktioner för Entra ID konfiguration SAML

OAuth 2.0 och OpenID Connect (en utökning av OAuth 2.0-protokollet) gör det möjligt för organisationer att verifiera slutanvändarens identitet, baserat på autentisering som utförs av en auktoriseringsserver, samt att få grundläggande profilinformation om slutanvändaren.

Secure Access stöder användarautentisering som utförs av en Pro (IdP), till exempel Entra ID , med hjälp av OpenID Connect anslutning/adapter.

OpenID Connect är byggt ovanpå OAuth-protokollet och skickar anspråk med hjälp av JSON Web Token (JWT)-format och används ofta med till exempel molnbaserade Pro , konsumentwebbplatser och mobilappar.

Länkar till konfigurationsartiklar

Konfigurera: ESA Azure AD SSO
ESA - Kundinstruktioner för Entra ID konfiguration OpenID

SAML Discovery Service-protokollet används för HAKA- och Virtu-autentisering i Secure Access , men det används också ofta, till exempel på universitet.

Länkar till konfigurationsartiklar

Konfigurera: ESA HAKA-autentisering

Konfigurera: ESA Virtu-autentisering

Protokollet Finnish Trust Network används vid autentisering med finska bank-ID, även vid autentisering med suomi.fi. Det är obligatoriskt att använda det och mer information finns här .

Svensk BankID-autentisering används vid autentisering med ett svenskt personnummer.

En brute force-attack försöker gissa en användares lösenord genom att försöka logga in flera gånger. Secure Access har funktioner för brute force-detektering och kan tillfälligt inaktivera ett användarkonto om antalet inloggningsmisslyckanden överstiger ett visst tröskelvärde.
Genom att aktivera Brute Force-detektering (aktiverat som standard) kan vi tillfälligt blockera angripare som försöker bryta sig in i systemet. När en användare är tillfälligt låst och försöker logga in visar Secure Access standardfelmeddelandet om ogiltigt användarnamn eller lösenord för att säkerställa att angriparen inte är medveten om att kontot är inaktiverat.

Länkar till konfigurationsartiklar

Hur man aktiverar Brute Force-detektering för ESA

Clickjacking-skydd förhindrar att en angripare bäddar in en webbsida i en iframe och lurar användaren att klicka på dolda eller förklädda knappar eller länkar.

Som standard är skydd mot klickkapning aktiverat.

Kunden kan aktivera cookiepolicyn i sin inloggningsprocess. Det innebär att webbplatsbesökare informeras om vilka användardata cookies spårar, varför informationen spåras och vart den skickas.

Länkar till konfigurationsartiklar

Konfigurera ESA cookieinställningar

Kunden kan aktivera användarsamtycke i sin inloggningsprocess, vilket innebär att webbplatsanvändare ger tillåtelse att hämta, använda och behandla deras data via cookies. Efter att en användare har angett sina inloggningsuppgifter kommer ESA att visa en skärm som identifierar klienten som begär en inloggning och vilken identitetsinformation som begärs av användaren. Användaren kan bestämma om begäran ska beviljas eller inte.

Länkar till konfigurationsartiklar

Konfigurera ESA för att använda användarmedgivande