Observera | ||
---|---|---|
| ||
Från och med rapporteras Ineras IdP:er LoA 2 för reservkort istället för LoA 3. Detta kan kräva anpassning av SP. |
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 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.
Exempel på e-tjänsts anslutning till Ineras IdP som Service Provider och med ny auteniseringsmetod och klient:
Tekniska förutsättningar för användning Inera IdP
Nedan följer information om de övergripande tekniska kraven och komponenterna för anslutning och användning
I dagsläget utfärdas identitetsintyget enligt två protokoll, SAML (Security Assertion Markup Language) och OIDC (OpenID Connect).
Anslutande e-tjänster väljer vilket av dessa båda protokoll som de vill nytta.
SAML
Ansluten e-tjänst registreras manuellt i Ineras IdP genom förmedling av metadata. Genom metadata kan man ex. specificera vilka attribut man önskar få från IdP:n och utbyta vilka nycklar som ska användas, adresser vid utloggning, o.s.v.
Se SAML-Profilen och Attributstyrning SAML för detaljer kring hur Inera IdP implementerar SAML-protokollet.
För åtkomst till IdP:s SAML-metadata, se Adresser och portar nedan.
Förmedlingen av metadata kan ske på flera olika sätt. Som del av den förstudie som skickas in när e-tjänsten ska registreras väljs vilket sätt som ska användas. De tre möjligheterna som erbjuds idag är som följer:
Skicka in metadata på fil för engångs-inläsning
Väljs detta alternativ skickas en .xml-fil innehållandes metadatat in som senare också ska bli inläst i IdP:n. Detta görs enklast genom att skicka in filen i samband med att förstudien skickas in för granskning. Metadatat kommer då att granskas i samma veva som förstudien granskas.
Skicka in metadata via en URL för engångs-inläsning
Vid detta alternativ anges en URL varifrån metadatat kan hämtas som ska bli inläst till IdP:n. Säkerställ gärna en extra gång att URL:en funkar och att metadatat som fås via URL:en är rätt metadata för anslutningen. Under förstudiegranskningen kommer samma metadata som hämtas från URL:en användas för granskning.
Skicka in en URL där metadata hämtas löpande
Precis som alternativet ovan skickas en URL in varifrån metadatat ska hämtas. Metadatat som vi återfås vid granskningstillfället avgör om det är godkänt för inläsning.
När anslutningen är godkänd registreras URL:en som angetts i IdP:n. Sedan kommer IdP:n hämta metadatat från den angivna URL:en vid inloggningsförsöken som görs och under en viss tid lagra metadatat för att minska på nätverkstrafiken och svarstiden för IdP:n. När cachen gått ut hämtar vi metadatat från URL:en på nytt. Fördelen med detta val är att den anslutande e-tjänsten kan ändra sitt metadata utan att behöva registrera en ny förstudie.
Info | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Expandera | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Observera | ||
---|---|---|
| ||
Från och med rapporteras Ineras IdP:er LoA 2 för reservkort istället för LoA 3. Detta kan kräva anpassning av SP. |
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 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 /wiki/spaces/UST/pages/3475212609.
Exempel på e-tjänsts anslutning till Ineras IdP som Service Provider och med ny auteniseringsmetod och klient:
Tekniska förutsättningar för användning Inera IdP
Nedan följer information om de övergripande tekniska kraven och komponenterna för anslutning och användning
I dagsläget utfärdas identitetsintyget enligt två protokoll, SAML (Security Assertion Markup Language) och OIDC (OpenID Connect).
Anslutande e-tjänster väljer vilket av dessa båda protokoll som de vill nytta.
SAML
Ansluten e-tjänst registreras manuellt i Ineras IdP genom förmedling av metadata. Genom metadata kan man ex. specificera vilka attribut man önskar få från IdP:n och utbyta vilka nycklar som ska användas, adresser vid utloggning, o.s.v.
Se SAML-Profilen och Attributstyrning SAML för detaljer kring hur Inera IdP implementerar SAML-protokollet.
För åtkomst till IdP:s SAML-metadata, se Adresser och portar nedan.
Förmedlingen av metadata kan ske på flera olika sätt. Som del av den förstudie som skickas in när e-tjänsten ska registreras väljs vilket sätt som ska användas. De tre möjligheterna som erbjuds idag är som följer:
Skicka in metadata på fil för engångs-inläsning
Väljs detta alternativ skickas en .xml-fil innehållandes metadatat in som senare också ska bli inläst i IdP:n. Detta görs enklast genom att skicka in filen i samband med att förstudien skickas in för granskning. Metadatat kommer då att granskas i samma veva som förstudien granskas.
Skicka in metadata via en URL för engångs-inläsning
Vid detta alternativ anges en URL varifrån metadatat kan hämtas som ska bli inläst till IdP:n. Säkerställ gärna en extra gång att URL:en funkar och att metadatat som fås via URL:en är rätt metadata för anslutningen. Under förstudiegranskningen kommer samma metadata som hämtas från URL:en användas för granskning.
OIDC
Registrering av OIDC-klienter i Inera IdP sköts manuellt. Se OIDC-Profil och Attributstyrning OIDC för detaljer kring hur Inera IdP implementerar OIDC-protokollet.
...
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.
...
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
...
- 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 (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 klienter/mobila enheter samt
- distribuera klienter, (inklusive att över tid säkerställa förmåga till robust testning och uppdatering)
För mer detaljerad information om de nya autentiseringsmetoderna och vilka krav som ställs på anslutande organisationer, se Anslutningsguide till Autentiseringstjänsten.
Användarval av autentiseringsmetod
...
Val av tjänste-id/medarbetaruppdrag
...
Mobilklienterna laddas ner via App Store eller Google Play. Windowsklienten tillgängliggörs under SITHS eID Windowsklient-app för Windows och organisationer kan välja att distribuera den själva eller att dela länken med sina användare.
Se nedan för länkar till specifik information kring respektive applikation.
Net iD Enterprise (mTLS-inloggning)
...
Operativsystem | IE11 | Chrome | Edge | Edge Chromium | Firefox |
---|---|---|---|---|---|
Windows 7 + 8 | *, **, ***, **** Slutar supportas Juni 2022 | ***, **** | **, ***, **** | *** | (ej mTLS) |
| *, ** Slutar supportas Juni 2022 | ** | (ej mTLS) | ||
Android | Se Användarhandbok - SITHS eID Mobilklient#Plattformskrav för kompabilitet och kända begränsningar | ||||
iOS |
...
*) Kompatibilitet för e-tjänster med s k uthoppslösningar kan behöva verifiera att inställningar för IE "Trusted Zones" på den tekniska stödsidan IdP med Edge och IE 11 och Trusted sites.
**) I och med att Microsoft har avslutat sitt stöd för och uppdateringar av IE11 samt legacy Edge är det svårare att få dessa webbläsare att fungera att fungera fullt ut, i alla tjänster, i alla användningsfall och konfigurationer på ett robust sätt. Uppdateras Microsoft OS och IE11/Edge med en ny och oprövad systemuppdatering garanteras det inte att det kommer att fungera initialt med alla kombinationer.
***) I och med att Microsoft har avslutat sitt stöd för och uppdateringar av äldre Windowsversioner ges begränsad support för dessa.
****) Full funktionalitet kan ej garanteras med SITHS eID (OOB) klienter, se Användarhandbok - SITHS eID Windowsklient#Plattformskrav.