1. Syfte

Denna sida anger de tekniska skillnader som förekommer mellan Inera IdP (IDP) och Säkerhetstjänsters tidigare autentiseringstjänst (SÄK). Målsättningen har varit att hålla dessa skillnader på en sådan nivå att en tekniskt sömlös övergång skall kunna göras, där enbart SP-metadata skall behöva uppdateringar. Det finns dock skillnader som KAN kräva SP anpassning. En (per driftsmiljö) ny och mer omfattande Förstudie vid anslutning till IdP behöver emellertid alltid skickas in för godkännande till https://etjanster.inera.se/DokumentGranskning.

Se Anslutningsguide till IdP för aktuell information kring anslutning till Inera IdP.

2. Förändringar

2.1. Logout (SLO)

2.1.1. Signering av LogoutRequest

I SÄK har ingen verifiering av LogoutRequest skett. Detta har varit ett frånsteg från SAML standarden och är nu åtgärdat. I IDP är det krav på att SP har signerat sitt LogoutRequest i de fall då front-channel binding används (HTTP-Redirect, HTTP-POST).

Denna förändring kan påverka SP implementation, men i de fall en standardprodukt eller ramverk använts så bör detta redan vara normalt beteende i SP.

2.1.2. Propagering av SLO

I SÄK har ett LogoutRequest från en SP automatiskt propagerats till alla de SP som ingått i samma SSO-session. Detta har skett med best-effort från SÄK, och då all propagering går vi browsern och varje inloggad SP, så har risken för fel varit överhängande. Det har även varit oklart att det är detta beteende som önskats. Det har inte gått att erhålla lokal SP logout utan att påverka andra SP.

I IDP kommer det inte längre ske någon propagering av LogoutRequest. En SP skall, precis som tidigare, initiera ett LogoutRequest, men IDP kommer nu enbart avsluta IdP-sessionen och meddela den initierade SP att utloggning skett (genom att returnera LogoutReponse enligt tidigare beteende). Då IdP-session nu är avslutad kommer ingen mer SSO erhållas, utan ny autentisering måste ske vid nästa inloggning. Eventuell andra SP som ingått i samma IdP session kommer numer alltså inte direkt signaleras och påverkas av en logout initierad av en annan SP. När dessa andra SP eventuellt åter kontrollerar SSO-status på IdP:n kommer dock även dessa behöva autentiseras på nytt.

2.2. SP-metadata

För bättre följsamhet gentemot SAMBI är det SKALL krav på följande element:

• <ContactPerson>
  • SKALL anges för typerna "technical" samt "support".
• <Organization>

För bättre följsamhet gentemot OASIS, och då framförallt för att en SP skall kunna tillgodose kravet på signering av LogoutRequest är det SKALL krav på följande element:

• <Keydescriptor>

För att minska mängden personuppgifter som Autentiseringstjänsten släpper ut är det SKALL krav att en SP anger följande element för att specificera vilka attribut som efterfrågas. Med hjälp av denna mekanism har Inera bättre kontroll på vilka SP som tar del av vilka personuppgifter. Utan elementet (1..*) kan inte <AttributeStatement> tillhandahållas.

• <AttributeConsumingService>

För anslutning av en SP till IdP så ställs det krav på vilka funktionscertifikat som SP får använda. Se Guide till IdP för information om vilka utfärdare som är godkända.

2.3. IdP-metadata

Metadata för IDP är signerat. Uppgifter om vilket certifikat som använts vid signering går att utläsa ur metadata, se Anslutningsguide till IdP under avsnitt Adresser och portar.

Förutsatt att SP litar på IDP'ns certifikatutfärdare så bör inte detta påverka SP's. Om fel vid inläsning av IDP metadata trots allt uppstår, kan någon av följande workarounds användas:

• Stäng av validering av metadata signatur i er SP.
• Ta manuellt bort signeringen ut IDP metadata innan inläsning.

2.4. Attribut (egenskaper)

2.4.1. Borttag av gamla SAMBI attributnamn

I SÄK har SAMBI-attribut leverats med både dess nuvarande "http://sambi.se/attributes/1/.....", men även med tidigare utfasade "urn:sambi:names:attribute:....". Samtliga av "urn:sambi:names:attribute:..." attributen är i IDP borttagna och enbart i de två specialfallen nedan kommer de levereras (då dessa inte är definierade i SAMBIs attributlista).

• urn:sambi:names:attribute:authnMethod
• urn:sambi:names:attribute:levelOfAssurance

2.4.2. Nya attribut

Se Attributlista för mer information om attributen

2.4.3. Förändrade attribut

2.4.3.1. http://sambi.se/attributes/1/healthcareProfessionalLicence

SAMBI-attributet "http://sambi.se/attributes/1/healthcareProfessionalLicense" kunde i SÄK innehålla antingen tvåställig kod i enlighet med SAMBI, eller i specialfall en textsträng i enlighet med HSA-katalogens data. I IDP kommer enbart tvåställiga koder erhållas för detta attribut, vilken följer definitionen i SAMBI.

2.4.3.2. urn:sambi:names:attribute:levelOfAssurance

Attributet "urn:sambi:names:attribute:levelOfAssurance" kunde i SÄK innehålla vården enligt "urn:sambi:names:ac:classes:LoA3". I IDP kommer enbart de värden som anges stämmer överens med SAMBI att returneras. Dessa specificeras i kapitel "RequestedAuthnContext" nedan.

2.5. AuthnRequest

2.5.1. RequestedAuthnContext

I SÄK har användet av värden nedan för "AuthnContextClassRef" under en längre tid varit deprikerade. Trots det har dessa använts.

• urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

• urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered

I IdP är dessa inte längre tillåtna utan enbart de värden som specificerats i SAMBI är tillåtna. I enlighet med SAMBI tekniska krav har även attributet "comparison" begränsats till "exact". Utelämning av attributet innebär implicit "exact". Tillåtna värden för "AuthnContextClassRef" i IDP är:

• http://id.sambi.se/loa/loa1
• http://id.sambi.se/loa/loa2
• http://id.sambi.se/loa/loa3
• http://id.sambi.se/loa/loa4

2.6. Inloggningsmetoder

I säkerhetstjänsters IdP har autentisering kunnat ske med SITHS-certifikat via Mutual-TLS (med Net iD Enterprise) eller One-Time Password (OTP) via SMS. I Inera IdP 1.0 stöds inte längre OTP, utan endast Net iD Enterprise. Det kommer komma stöd för ytterligare inloggningsmetoder med en out-of-band lösning liknande BankID fast med Siths-certifikat.

2.7. Sjunet/Internet

Om etjänsten har slutanvändare med nätanslutning till både Sjunet och internet kan det potentiellt påverka hur dessa ansluter till IdP för autentisering. Det beror på slutanvändarens organisations nätdesign och konfiguration. T ex hur DNS- respektive autentiseringstrafik routas eller vad som händer vid ett avbrott för det ena nätet.
Läs mer i Anslutningsguide till IdP och avsnittet om Sjunet

2.8. Webbläsartekniska aspekter

2.8.1. Headers (i urval)

GUI:t i SÄK kunde läsas in i en HTML iFrame men då detta kraftigt ökar risken för bl a Cross Site scripting (XSS) och s k Clickjacking ("UI Redress Attack") och har IdPn satt följande headers (aktuella värden 12 Nov 2019 ) för att i möjligaste mån minimera dessa risker. Om er eTjänst tidigare läst in Autentiseringstjänsten i en iFrame kommer den nya inte fungera då detta inte accepteras.

Referenser; Detectify XSS, Detectify Clickjacking, OWASP XSS, OWASP Clickjacking

2.8.2. Kakor

IdPns sessionskaka (session cookie) sätts med följande direktiv (vissa identiska med SÄK) för att minimera risken kring session hijacking.

2.8.3. Övriga säkerhetsparametrar

2.9. Buggrättningar

2.9.1. Persistent identifier

I både SÄK och IdP så anger SAML-profilen att en IdP SKALL ha stöd för:

• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
• urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Detta har varit fallet i SÄK, men där en bugg har lett till att både dessa har fungerat på samma sätt, och då som "transient". I IdP kommer "persistent" hanteras utifrån specifikation och en SP kan förutsätta att samma ID erhålls vid olika sessioner för en och samma aktör.