1. Lokala Säkerhetstjänster 2.15 Release Notes

09 Jan 2017 

2. Nya funktioner / förbättringar

2.1. Förändringar i GUI för spärradministration.

2.1.1. Spärrar hos vårdgivare

Funktionaliteten under den tidigare meny-utgången Visa spärrar - Vårdgivare har flyttats in i det, sedan förra versionen, nya spärr-GUI:t som ett nytt och tredje sökalternativ - Vårdgivare. I sökresultatet från detta sökalternativ har man nu större möjlighet att sortera, agera och ta ut listor på vårdgivarens alla spärrar.

Observera att spärrar som visas med detta sökalternativ endast är de som är skapade i den lokala spärrtjänsten. Man kan alltså inte här se de spärrar som är replikerade från andra spärrtjänster.

2.1.2. Filtrera Inre/Yttre spärrar

En ny "filter-ruta" har införts för att visa/dölja Inre respektive Yttre spärrar i sökresultatet. Därmed har kryssrutan Visa yttre spärrar, som endast gällde vid sökning med avseende på vårdenhet, blivit överflödig och tagits bort.

2.1.3. XML-export

Utöver att ta ut en PDF-fil med hela eller delar av sökresultatet kan man nu få detta i XML-format för vidare bearbetning i t.ex. Microsoft Excel.

2.1.4. Kommentarsfält vid Spärregistrering

Via tjänstekontrakt har man alltid kunnat ange en reason text vid spärregistrering men detta fält har inte använts vid registrering via Säkerhetstjänsters GUI.

Från och med denna version finns det möjlighet att skriva en kommentar kopplad till registreringen och denna kommer att visas även under utökad information för spärren.

Fältet är frivilligt att fylla i.

2.2. Förändringar i GUI för loggadministration

2.2.1. Validering

Förbättringar har gjorts i personnummer-valideringen så att ett felaktigt personnummer detekteras redan då användaren matat in personnumret istället för att man som tidigare fick detta felmeddelande när man klickade på knappen Skapa loggrapport.

2.2.2. Rensa-knapp

En ny knapp, Rensa formulär, för att rensa sökformuläret på inmatad data, har införts för att enklare komma tillbaka till ett startläge.

2.2.3. Översiktliga XML-rapporter

Översiktlig rapporttyp har aktiverats även för XML-rapporter. Den huvudsakliga skillnaden i de översiktliga rapporterna är att resurs-informationen begränsas i dessa till att bara innehålla en unik lista över de personnummer som loggposten berör.

2.2.4. Grupperad loggrapport

En ny rapporttyp har adderats de redan befintliga. Grupperad loggrapport är en rapport där man snabbt kan få en indikation vilken personal som agerat på vilka patienter för att sedan t.ex. kunna göra en mer specifik sökning.

Beroende på valt perspektiv ger rapporterna följande information:

Patient: "Vilken personal har gjort någonting med patientens journaldata"
Personal: "För vilka patienter har personalen haft åtkomst till journaldata"
Vårdgivare: "Unika kombinationer av personal och patienter" 

2.3. Förändringar i autentiseringstjänsten

2.3.1.  Förändrat utseende på uppdragsvalet

Tabellen med uppdragsval har utökats med mer information om uppdraget.

2.3.2. Nya attribut-namn i SAML-biljetten

Sambi har arbetat fram nya attributnamn som inleds med http://sambi.se/attributes/ för de attribut som beskriver egenskaper för användaren. Säkerhetstjänster publicerar nu dessa parallellt med de gamla som alla börjar med urn:sambi:names:attribute . Samtidigt har alla Carelink -attribut tagits bort.

Då de gamla attributnamnen ( urn:sambi:names:attribute ) fortfarande publiceras för bakåtkompatibilitet ska anslutna SP:s inte behöva vidta några åtgärder i denna version. Nya anslutningar bör ladda ner nytt metadata från Säkerhetstjänsters IdP för att använda de nya attributen.

Skulle någon SP fortfarande använda Carelink-attributen måste ny metadata laddas ner och SP:n anpassas till de nya attributnamnen.

2.3.3. Nya SAMBI SAML-attribut

Säkerhetstjänster utökar sitt stöd för SAMBI:s attribut med följande attribut i de fall HSAs RIV-TA kontrakt används för att hämta HSA-information.

• http://sambi.se/attributes/1/mail
• http://sambi.se/attributes/1/groupPrescriptionCode
• https://sambi.se/attributes/1/personalidentitynumber

2.3.3.1. http://sambi.se/attributes/1/mail

Levereras ifall detta attribut levereras från HSA.

2.3.3.2. http://sambi.se/attributes/1/groupPrescriptionCode

Levereras ifall detta attribut levereras från HSA.

I tidigare attributskälla (HSA-WS) har det funnits en logik som gjort att gruppförskrivarkod har hamnat i det äldre attributet med namn urn:sambi:names:attribute:personalPrescriptionCode i de fall det har funnits en sådan och inte någon personlig förskrivarkod. Denna logik är nu för bakåtkompatibilitet kopierad till Säkerhetstjänster för detta, äldre attribut. Attributen http://sambi.se/attributes/1/groupPrescriptionCode och http://sambi.se/attributes/1/personalPrescriptionCode levereras med direkt mappning från HSA ifall värden finns.

2.3.3.3. http://sambi.se/attributes/1/personalidentitynumber

Detta attribut kommer i praktiken inte att levereras i denna version då HSA inte levererar personnummer. Det finns dock med i listan över möjliga attribut som en förberedelse för framtida ändringar.

2.3.4. Stöd för LOA-nivå i RequestedAuthnContext

Säkerhetstjänsters autentiseringstjänst stödjer nu Sambis definition av LOA-nivå i AuthnRequest från SP. Säkerhetstjänster erbjuder bara autentisering enligt LOA 3 ( https://id.sambi.se/loa/loa3 ). Det tidigare sättet, att i RequestedAuthnContext ange önskad autentiseringsmetod, finns kvar för bakåtkompabilitet, t.ex. urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient för SITHS-inloggning.

Notera att vid användning av LOA-nivå i RequestedAuthnContext har autentiseringstjänsten ingen möjlighet att detektera en enskild önskad autentiseringsmetod utan måste visa en lista på de autentiseringsmetoder tjänsten erbjuder. Idag innebär det att en lista med Val av autentiseringsmetod visas med Engångslösen via SMS och SITHS Certifikat som valmöjligheter då båda dessa autentiseringsmetoder klassas som LOA 3.

Vid användning av LOA-nivå i RequestedAuthnContext kommer detta även att användas i response från IdP i elementet AuthnStatement.

2.3.5. Stöd för autentisering utan uppdragsval

Genom att en SP i sitt metadata beskriver vilka attribut denna kräver kan man, i de fall inga HSA-uppslag krävs för att returnera värden för angivna attribut, nyttja autentiseringstjänsten utan uppdragsval.

En SP som vill kunna välja om uppdragsval skall göras eller ej måste i sitt metadatas SPSSODescriptor införa ett nytt element (med sub-element): AttributeConsumingService. 

Specifikation enligt SAML v2.0 

En SP väljer att lägga till 0..n AttributeConsumingService -element i sitt metadata. Dessa kommer sedan via sitt index matchas mot ett angivet värde i sitt AuthnRequest. Baserat på vilka attribut som är angivna i matchande AttributeConsumingService-element vid autentiseringstillfället kommer IdP:n att avgöra om uppdragsval (eller HSA-uppslag generellt) behöver göras eller ej.

2.3.6.  IdP-initierad inloggning

Säkerhetstjänsters IdP hanterar nu s.k. IdP-initierad inloggning (IdPUnsolicited SSO) vilket är en del av SAMBI:s kravspecifikation. Detta koncept är inte helt standardiserat men implementerat med Shibboleths lösning som mall.

2.4. PU-tjänst

För uppslag av patientuppgifter krävs anslutning till Personuppgiftstjänst 2.0 med tjänstekontrakt LookupResidentsForProfile, version 2.0 i domänen masterdata:citizen:citizen (ersätter version 1.0 LookupResidentForFullProfile i riv:population:residentmaster).

Kontakta Inera i god tid innan installation för anslutning via Nationella Tjänsteplattformen.