...
| Expandera | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||
|
Sammanfattning
Ineras IdP syftar till att erbjuda vårdgivare och dess vårdsystem en säker autentisering av aktörer/vårdpersonal för olika behov. Ineras IdP tillhandahåller s.k. single sign on (SSO) inom webbapplikationer enligt väl definierade standarder, så som SAML Web SSO Profile samt OpenID Connect. E-tjänst och system används synonymt i följande dokument.
...
Anslutning till IdP kan ske direkt för en e-tjänst, men det går också att ansluta en lokal IdP som en proxy till Ineras IdP. För jämförelse mellan olika anslutningsmönster, se Att ansluta e-tjänster.
För att anslutande e-tjänst skall få ut ytterligare användarattribut måste slutanvändare som skall autentiseras existera i den nationella HSA-katalogen. Beroende på vilka attribut som efterfrågas för en aktör kan eventuella val behöva göras i inloggningsflödet. Exempel på detta är medarbetaruppdrag och/eller autentiseringsmetod.
De e-tjänster som vill nyttja elektronisk underskrift kan ansluta till Underskriftstjänsten. I och med denna anslutning möjliggörs autentisering för underskrift via Ineras IdP, se Underskriftstjänsten /wiki/spaces/UST/pages/3475212609.
Exempel på e-tjänsts anslutning till Ineras IdP som Service Provider och med ny auteniseringsmetod och klient:
...
Ineras IdP är tillgänglig från både internet och Sjunet med samma instans och domän (se Adresser och portar nedan).
Se Nätverksinställningar för IAM-tjänster för gemensam nätverksteknisk information för alla IAM-tjänsterna (IdP, Autentiseringstjänsten, Utfärdandeportalen, etc.), inklusive information om Sjunet-routing.
...
Vilken utgivare som helst är godkänd för funktionscertifikaten som används i anslutningar till testmiljöerna.
...
Programvara som användaren behöver
En eller flera klientapplikationer/klientprogramvaror behöver vara tillgängliga för e-tjänstens slutanvändare, se avsnitt längre ner för testade versioner och länkar till klienter.
...
| Info |
|---|
Observera att Ineras lokala IdP inte kan agera proxy IdP |
Användning av iframes
...
Adresser och portar
| Ankare | ||||
|---|---|---|---|---|
|
Se Nätverksinställningar för IAM-tjänster för gemensam nätverksteknisk information för alla IAM-tjänsterna (IdP, Autentiseringstjänsten, Utfärdandeportalen, etc.) och övriga tjänster.
...
För hantering av tillitsnivå för olika typer av certifikat, se Tillitsnivå (LoA).
Autentiseringsmetoder
Aktivering av autentiseringsmetoder
...
Aktivering av ny autentiseringsmetod som använder SITHS eID-klienterna apparna görs vid ifyllande av förstudiemall version 3.x, både för nya anslutningar samt befintliga. Se den generella rutinen för livscykelhanteringen ovan
...
- ordna med brandväggsöppningar mot Autentiseringstjänsten (Nätverksinställningar för IAM-tjänster),
- säkerställa att slutanvändarna använder en webbläsare (för att anropa IdP) på ett sätt som möjliggör för autostart av SITHS eID-klienten appen (se även nedan samt SITHS eID Appväxling - Exempel för inbäddade webbläsare),
- informera och eventuellt utbilda slutanvändarna i användningen av klienterappar/mobila enheter samt
- distribuera klienterappar, (inklusive att över tid säkerställa förmåga till robust testning och uppdatering)
För mer detaljerad information om autentiseringsmetoderna för "SITHS eID på denna respektive annan enhet" och vilka krav som ställs på anslutande organisationer, se Anslutningsguide till Autentiseringstjänsten.
Användarval av autentiseringsmetod
För de tjänster som aktiverar fler än en autentiseringsmetod så kommer användarna vid autentisering att mötas av en dialog där de får välja vilken metod de vill använda. Säkerställ att e-tjänstens slutanvändare har erforderlig klient klientprogramvara installerad, har fått lämpliga instruktioner i god tid före produktionsutrullning och inte överraskas över denna dialog (samt eventuellt, lämplig mobil enhet, tillgänglig).
...
Autentiseringslösningen baseras på teknik och standard för dubbelriktad TLS/Mutual TLS (mTLS). Webbläsaren utmanar användaren om att presentera ett giltigt klientcertifikat som servern litar på. Certifikaten importeras från SITHS-kortet till datorns operativsystem med hjälp av någon av klientapplikationerna klientprogramvarorna nedan. Integrationen sker alltså egentligen mot operativsystemet/webbläsaren snarare än mot klientprogramvaran.
Förutsätter att användaren har någon av klientapplikationerna klientprogramvarorna nedan och ett SITHS-kort:
- SITHS eID-app för Windows MD (där SAC minidriver tekniskt sätt hanterar stödet för autentiseringsmetoden)
- Net iD Enterprise
Flera subdomäner
...
ger användaren
...
fler försök att välja certifikat
| Observera |
|---|
Denna funktion aktiveras först under Q3-2023 I väntan på att den aktiveras får användaren bara ett försök att välja sitt klientcertifikat per webbläsarsession. Om SITHS-kortet inte sitter i läsaren, är för fel miljö eller om importen av certifikaten till operativsystemet inte fungerar måste användaren starta om webbläsaren för att kunna göra ett nytt försök att välja klientcertifikat. Detta beror på att det är den logiken som gäller för marknadens olika webbläsare. |
...
| Expandera | ||
|---|---|---|
| ||
För att säkerställa att användaren måste välja ett certifikat när SITHS-kort på denna enhet används dirigerar IdP:n användaren om till olika subdomäner vid varje inloggningsförsök i den pågående webbläsarsessionen. OM användaren inte valde något certifikat, t ex. inte hade sitt SITHS-kort i kortläsaren, visas denna dialog och användaren får ett nytt försök genom att välja Försök igen.
OM användaren har kommit till maxvärdet för antalet inloggningsförsök innan webbläsaren måste startas om (i skrivande stund 25 försök för IdP som driftas av Inera) visas denna dialog och användaren måste starta om webbläsaren för att starta om antalet försök.
OBS! Logiken med att användaren alltid får 25 inloggningsförsök är beroende av att användarens webbläsare INTE har inställningen för att öppna flikar från föregående session aktiverad (se exempel nedan). Inställningen gör att räknaren i cookien för vilken endpoint/domännamn användaren ska hamna på inte nollställs korrekt. Användaren kommer såldes att fortsätta på det värde som webbläsaren senast hade och nollställas först när den når maxvärdet (25) och användaren då startar om webbläsaren. Rent praktiskt innebär det att användaren istället för 25st nya försök kommer ha färre försök på sig innan meddelandet ovan om För många inloggningsförsök via dubbelriktad TLS presenteras.
|
SITHS eID på denna/annan enhet - Out-of-band authentication (OOB)
...
För detaljerad information kring de nya autentiseringsmetoderna och hur de fungerar i klienterna, dess klientprogramvaror, dvs. apparna, fungerar se respektive användarhandbokAnvändarhandbok
- Användarhandbok - SITHS eID Mobilklient-app för Mobilt SITHS
- Användarhandbok - SITHS eID Windowsklient-app för Windows
Test av autentiseringsmetoder
På följande länkar kan samtliga autentiseringsmetoder testas för att försäkra sig om att autentisering mot IDP är möjlig
- PROD - https://test.idp.inera.se/
- TEST/QA - https://test.idp.ineratest.org/
Val av tjänste-id/medarbetaruppdrag
...
Under legitimerings- och signeringsflödet visar IdP:n ett namn på organisationen som användaren är på väg att logga in i eller utföra en signatur för. Samma namn visas också i SITHS eID klienterna för Windows, Android och iOS -appen om en av SITHS eID autentiseringsmetoderna har valts.
...
Vid anslutningsförfarandet hämtas organisationsnamnet som visas under legitimerings- och signeringsflödet från SAML metadatat. IdP:n letar efter ett OrganizationDisplayName under Organization-taggen (se SAML-Profil för konkreta exempel). Namnet som finns angetts under OrganizationDisplayName ska matcha med det som angetts i förstudien under Organisationens visningsnamn. Systemets visningsnamn ska inte vara definierat i SAML metadatat utom ska endast återfinnas i förstudien.
...
Därav kan användarupplevelsen variera beroende på hur klienten appen är konfigurerad lokalt. Som standard är PIN-SSO aktiverad, vilket medför att användare vid en ny inloggning inte alltid behöver slå in PIN-koden efter att de valt sitt certifikat. Även om IdP:ns SSO-session har avslutats.
...
| Info |
|---|
Uthoppslösningar Kompatibilitet för e-tjänster med s k uthoppslösningar kan behöva verifiera att inställningar för "Trusted Zones" på den tekniska stödsidan IdP med Edge och IE 11 och Trusted sites. Inbäddade webbläsare Inbäddade webbläsare samt ev. andra webbläsare kan behöva anpassningar för att stödja anpassade browser-scheman som används för att autostarta klientenappen. För SITHS eID-appen används siths://. Se mer information här: SITHS eID Appväxling - Exempel för inbäddade webbläsare |
...
SITHS eID-app för Mobila enheter
Mobilklienterna laddas Laddas ner via App Store eller Google Play.
...