...
| 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.
Tjänsten tillhandahåller också funktion för att logga ut aktören och avsluta SSO-sessionen hos IdP.
Vid en lyckad autentisering utfärdas ett identitetsintyg, (SAML-biljett, eller Id-token för OIDC) som innehåller information om autentiseringen samt eventuellt ytterligare användarattribut, som kan användas av ett ABAC (Attribute Based Access Control) behörighetssystem, d.v.s. behörighet på egenskapsnivå.
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.
...
|
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.
Tjänsten tillhandahåller också funktion för att logga ut aktören och avsluta SSO-sessionen hos IdP.
Vid en lyckad autentisering utfärdas ett identitetsintyg, (SAML-biljett, eller Id-token för OIDC) som innehåller information om autentiseringen samt eventuellt ytterligare användarattribut, som kan användas av ett ABAC (Attribute Based Access Control) behörighetssystem, d.v.s. behörighet på egenskapsnivå.
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 autentisering med SITHS eID.
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 inom identitet och åtkomst för gemensam nätverksteknisk information för alla IAM-tjänsterna (IdP, Autentiseringstjänsten, Utfärdandeportalen, etc.), inklusive information om Sjunet-routing.
...
| 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änstertjänster inom identitet och åtkomst för gemensam nätverksteknisk information för alla IAM-tjänsterna (IdP, Autentiseringstjänsten, Utfärdandeportalen, etc.) och övriga tjänster.
...
- ordna med brandväggsöppningar mot Autentiseringstjänsten (Nätverksinställningar för IAM- tjänster inom identitet och åtkomst),
- 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-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 appar/mobila enheter samt
- distribuera appar, (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änstenAutentiseringstjänst SITHS.
Användarval av autentiseringsmetod
...
| 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)
...
I det här fallet kommer användaren få välja bland alla uppdrag som finns kopplade till användarens tjänste-id. Notera i bilden nedan hur HSA-id:t i kolumnen längst ut till höger är detsamma för alla uppdrag.
Filtrering av personnummer, HSA-id och organisationsnummer
IdP:n stödjer filtrering av attributen personalIdentityNumber, employeeHsaId samt organisationIdentifier. Denna funktionalitet är baseras på PrincipalSelection som främst nyttjas för signerings-syften för SAML. För IdP:n har funktionaliteten utökats att även stödja filtrering av dessa attribut för autentisering både för SAML och OIDC.
Med denna filtrering har anslutande system möjlighet att förhandsvälja exempelvis en användares HSA-id om denne har flera HSA-id:n att välja mellan så att valet av tjänste-id hoppas över. Liknande filtrering kan göras genom att ange filtrera ut ett specifikt organisationsnummer om en användare arbetar mot flera olika organisationer. Filtrering av personnummer är endast användbart för signering. Observera att idag stödjs endast dessa tre attribut för att göra filtreringar.
SAML
För att kunna tillämpa denna filtrering med SAML används PrincipalSelection. Se dokumentationen hos DIGG över hur PrincipalSelection fungerar och hur det används. Mer läsvärd information hittas under artikeln för Attributstyrning SAML.
OIDC
...
Förval av principalen
IdP stödjer förval av principalen (den inloggade användaren). Förvalet möjliggörs genom att tillåta SAML- och OIDC-anslutningar att skicka in värden som del av deras legitimerings- och signeringsbegäran. Dessa värden används sedan av IdP:n för att kunna göra ett val at tjänste-id och/eller medarbetaruppdraget utan användarinteraktion om möjligt. Alternativt om inte tillräckligt precisa värden skickats in kan IdP:n visa ett urval av valmöjligheter i tjänste-id- eller medarbetaruppdragsväljaren som på förhand har filtrerats med hjälp av de inskickade värdena.
Med denna mekanism har anslutande system möjlighet att på förhand välja vilket personnummer, tjänste-id, medarbetaruppdrag eller organisationsnummer användaren måste slutföra inloggningen med. Om något av de inskickade värden inte kan uppfyllas av användaren (antingen genom att fel kort använts eller uppgifter saknas i HSA) kommer inloggningen eller signeringen att misslyckas.
För respektive protokoll finns det väsentliga skillnader på hur dessa värden skickas in, samt vilka villkor som måste vara uppfyllda för att filtreringen och förvalet ska kunna genomföras. Läs mer om respektive implementation för OIDC och SAML här:
Visningsnamn under legitimerings- och signeringsflödet
...
Namnet som visas kan väljas själv av den anslutande organisationen och anges i förstudien. Gäller det en anslutning med SAML som protokoll ska namnet även finnas i SAML metadatat. Som del av förstudien ska både ett namn på systemet och ett namn på organisationen anges. I praktiken kommer dock endast namnet på organisationen visas för slutanvändaren.
SAML
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.
OIDC
Vid anslutningsförfarandet anges organisationens och systemets visningsnamn endast i förstudien. Dessa värden läses sedan in manuellt till IdP:n.
...