BIF Bastjänster för InformationsFörsörjning Tekniska specifikationer Version ett Maj 2007

BIF Bastjänster för InformationsFörsörjning Tekniska specifikationer Version ett Maj 2007

Bastjänster för InformationsFörsörjning BIF Teknisk specifikationer Version Ett Maj 2007 Maj 2007 1

Innehållsförteckning 1.1 Termer... 6 2 Inledning... 10 2.1 Arbetsgång Förarbete till standard... 10 2.2 Läsanvisning... 10 2.3 Avgränsning... 11 2.4 Projektdeltagare... 11 3 BIF övergripande beskrivning... 12 3.1 Syfte med Bastjänster för InformationsFörsörjning... 12 3.2 Konceptuell beskrivning av tjänsterna... 12 3.3 Detaljerad beskrivning av IT-tjänsterna i BIF... 15 3.4 Användningsfall... 18 3.5 Generella funktionella krav... 24 3.6 Generella icke-funktionella krav... 24 3.7 Grundläggande beståndsdelar... 25 3.8 Generella behov... 30 4 IT-tjänst för autentisering... 32 4.1 Tjänstespecifikation: Autentisering 1.0... 32 4.2 Syfte med tjänsten... 32 4.3 Konceptuell beskrivning av tjänsten... 32 4.4 Avgränsning... 32 4.5 Funktionella krav... 32 4.6 Tjänstegränssnitt: Funktioner... 33 4.7 Autentisering för Webapplikationer... 37 4.8 Stöd för autentisering med verksamhetsuppdrag och/eller syfte... 39 4.9 Agent... 39 5 IT-tjänst för Åtkomstkontroll (ÅKT)... 42 5.1 Tjänstespecifikation: ÅKT 1.0... 42 5.2 Syfte med tjänsten... 42 5.3 Konceptuell beskrivning av tjänsten... 43 5.4 Avgränsning... 47 5.5 Funktionella krav... 47 5.6 Tjänstegränssnitt: Funktioner... 48 5.7 XACML protokollens användning i BIF åtkomstkontroll... 52 6 IT-tjänst för Samtycke... 54 6.1 Tjänstespecifikation: Samtycke 1.0... 54 6.2 Syfte med tjänsten... 54 Maj 2007 2

6.3 Konceptuell beskrivning... 54 6.4 Funktionella krav... 54 6.5 Tjänstegränssnitt: Funktioner... 55 6.6 Åtkomstkontrollstjänstens användning av samtyckestjänsten... 62 7 IT-tjänst för Vårdrelation... 64 7.1 Tjänstespecifikation: Vårdrelation.1.0... 64 7.2 Syfte med tjänsten... 64 7.3 Konceptuell beskrivning av tjänsten... 64 7.4 Funktionella krav... 64 7.5 Tjänstegränssnitt: Funktioner... 64 7.6 Åtkomstkontrollstjänstens användning av vårdrelationstjänsten... 69 8 IT-tjänst för Utlämnande... 71 8.1 Tjänstespecifikation: Utlämnandetjänst 1.0... 71 8.2 Syfte med tjänsten... 71 8.3 Konceptuell beskrivning av tjänsten... 71 8.4 Funktionella krav... 71 8.5 Tjänstegränssnitt: Funktioner... 72 9 IT-tjänst för Säker patientkontext... 81 9.1 Tjänstespecifikation: Säker patientkontexttjänst 1.0... 81 9.2 Syfte med tjänsten... 81 9.3 Konceptuell beskrivning av tjänsten... 81 9.4 Avgränsning... 81 9.5 Funktionella krav... 81 9.6 Tjänstegränssnitt: Funktioner... 81 9.7 Standard Kontexttopics... 86 9.8 Kontexthantering för Webapplikationer... 87 9.9 Tjänsteagent... 89 10 IT-tjänst för Notifiering... 91 10.1 Tjänstespecifikation: Notifiering 1.0... 91 10.2 Syfte med tjänsten... 91 10.3 Konceptuell beskrivning av tjänsten... 91 10.4 Administrationsgränssnitt... 92 10.5 Avgränsning... 92 10.6 Funktionella krav... 92 10.7 Tjänstegränssnitt... 93 10.8 Teknisk beskrivning... 93 11 IT-tjänst för Loggning... 96 Maj 2007 3

11.1 Tjänstespecifikation: Loggtjänst 1.0... 96 11.2 Syfte med tjänsten... 96 11.3 Konceptuell beskrivning av tjänsten... 96 11.4 Avgränsning... 96 11.5 Funktionella krav... 97 11.6 Tjänstegränssnitt: Funktioner... 97 11.7 Loggdata... 99 11.8 Icke-funktionella krav... 102 11.9 Tjänsteagent... 102 11.10 Agentens gränssnitt: funktioner... 102 12 IT-tjänst för Logganalys... 104 12.1 Tjänstespecifikation: Logganalys 1.0... 104 12.2 Syfte med tjänsten... 104 12.3 Konceptuell beskrivning av tjänsten... 104 12.4 Avgränsning... 104 12.5 Funktionella krav... 104 12.6 Tjänstegränssnitt: Funktioner... 105 12.7 Tjänsteagent... 107 13 Övriga specifikationer... 107 13.1 Resursmodell... 107 13.2 Typer av åtkomstkontroll... 108 13.3 Egenskaper och rättigheter... 111 13.4 Biljettbeskrivning... 117 13.5 SAML... 117 13.6 SAML biljettens användning... 122 13.7 Användning av biljetter i meddelanden... 123 14 BIF Implementering... 124 14.1 Inledning... 124 14.2 Grundförutsättningar... 124 14.3 Grundimplementering... 124 14.4 Scenario I... 126 15 Migration... 127 15.1 Inkapsling... 127 16 Referenser... 128 17 Förändringar jämfört med BIF Slutrapport 0.95 B... 130 17.1 Generellt... 130 17.2 Autentiseringstjänsten... 130 Maj 2007 4

17.3 ÅKT... 130 17.4 Vårdrelationstjänsten... 130 17.5 Samtyckestjänsten... 131 17.6 Utlämnandetjänsten... 131 17.7 Säker Patientkontexttjänsten... 131 17.8 Loggtjänsten... 131 17.9 Logganalystjänsten... 131 17.10 Notifieringstjänst... 131 17.11 Resursmodell, egenskaper och regler... 132 17.12 Implementering... 132 Maj 2007 5

1.1 Termer Term Aktör Användare Autentisering Behörighet BKS CA Certifikat Egenskaper e-id kort Elektronisk katalog e-underskrift HCC HSA HSA-ID HSA-katalog IT-tjänst Kaskadering Kedjad loggning Loggning Beskrivning Person eller IT-tjänst som utnyttjar IT-tjänst. Eng. Subject I denna rapport: person som utnyttjar IT-tjänst. Snävare term än aktör. Fastställande av en användares identitet. Har ofta utförts enbart med användarnamn/nummer, men i BIF ställs krav på elektronisk autentisering enligt SITHS med HCC. Utförs av autentiseringstjänsten och är en förutsättning för åtkomstkontroll och loggning. Vanlig benämning på en aktörs rättigheter (se rättigheter) Behörighetskontrollsystem: Vanlig benämning på funktionalitet i stuprörsliknande system som hanterar flera aspekter av informationssäkerhet (användarnamn, lösenord, roller, rättighet etc). I denna rapport används termen rättighet och Åtkomstkonbtroll för att markera skillnaden gentemot tidigare uppbyggnad. Certification Authority; organisation som utfärdar certifikat genom att signera certifikat med sin privata CA-nyckel. På svenska: certifikatsutfärdare. Ett av en CA elektroniskt signerat intyg som knyter en publik nyckel till en specifik nyckelinnehavare. Kännetecken på användare, aktivitet eller resurs (vårdinformation). I IT-sammanhang ofta benämnt attribut Elektroniskt ID-kort; så kallat smart card, innehållande processor. eid-kortet är bärare av innehavarens privata nycklar och skyddat av dennes personliga kod. Databas, ofta hierarkisk, innehållande information om egenskaper hos objekt, t.ex. individer, organisationer, hårdvara. En form av elektronisk signatur som skapas genom att signatären signerar digital information med den av sina två privata nyckel som är avsedda för detta enligt en speciell procedur. HealthCare Certificate = Hälso- och sjukvårds Certifikat, certifikat för svensk vård och omsorg enligt SITHS-modellen. Hälso- och sjukvårdens adressregister Sverigeunikt id som identifierar en vårdgivare. Elektronisk katalog organiserad enligt HSA-modellen. Specialiserad producent som tar emot order från konsumenter och leverera tillbaka begärda resultat. Verkar i SOA-miljö. En tjänst anropar en tjänst, som i sin tur anropar en annan tjänst osv, osv, osv På teknisk väg säkra loggar mot radering. Registrering av aktiviteter utförda av aktör, med syfte till att uppnå spårbarhet i aktiviteter avseende vårdinformation. Maj 2007 6

Menprövning Objekt Omgivningsfaktor PDP PEP PersonId Privat nyckel Publik nyckel Regelverk Resurs RIV Rättighet Rättighetsregel SAML Samtycke SDK Sekretess Sekretessområde En skadeprövning görs och det står klart att utlämnande av vårdinformation kan ske utan att den enskilde eller dennes närstående lider men. Se Resurs En uppsättning egenskaper som används av regelsystemet för att tillsammans med aktörs-, resurs- och aktivitetsegenskaper evaluera beslut. Med omgivningsfaktorerna kan en IT-tjänst förmedla egenskaper som rör den miljö och omgivning ur vilken resurserna hämtas. Policy Decision Point Policy Enforcement Point Personnummer, samordningsnummer eller reservnummer. Den privata delen av ett nyckelpar som används inom asymmetrisk kryptering. Den privata nyckeln används främst för att skapa digitala signaturer samt för dekryptering av krypterad information. Den publika delen av ett nyckelpar som används inom asymmetrisk kryptering. Den publika nyckeln används främst för att verifiera digitala signaturer samt för att kryptera information. Alla juridiska och verksamhets regler. Generisk term för tillgång som ska åtkomstskyddas (vårdinformation, skrivare etc). Regelverk för elektronisk Interoperabilitet inom Vård och omsorg Vilken/vilka aktiviteter en aktör tillåts utföra med en resurs Enskild regel som ingår i ett regelverk. Security Assertion Markup Language Xml-standard för utbyte av autentisering, attribute mm. I texten refereras till version 2.0 Patienten har rätt att efterge sekretessen dvs hon/han kan ge sitt samtycke till att viss eller all vårdinformation lämnas ut. Samtycket kan vara skriftligt eller muntligt. I vissa fall är det inte möjligt att få samtycke. Detta kan då vara underförstått, s k presumtivt samtycke. Software Development Kit, programmatiskt utvecklingspaket innehållande programfunktioner för åtkomst till intern funktionalitet och ofta en uppsättning hjälpfunktioner. lagstadgat förbud att röja uppgift Sekretesslagen (1980:100) anger vad som är sekretessbelagt och därmed undantaget från regeln att myndigheternas allmänna handlingar är offentliga. Sekretess innebär både förbud att röja en uppgift muntligt eller på annat sätt och förbud att lämna ut allmänna handlingar och gäller skydd för enskilds hälsotillstånd och andra personliga förhållanden. Enligt sekretesslagen råder sekretess mellan myndigheter och mellan olika verksamhetsgrenar inom samma myndighet - sekretessområden. Sekretesslagen gäller för uppgiftslämnande till dem som finns utanför myndigheten yttre sekretess. Maj 2007 7

SITHS SOA Subjekt Temporär Underteckna elektronisk Utlämnade Utlämnande Inom en myndighet/verksamhetsgren gäller inre sekretess. Så kallad inre sekretess är inte beskrivet i sekretesslagen, men är indirekt beskrivet i bl.a. Patientjournallagen (sekretess om ej behov och vårdrelation), Säker IT i Hälso- och Sjukvården. Projekt 1998-2000 som resulterade i den s.k. SITHS-modellen för informationssäkerhet inom hälso- och sjukvården. Tjänstebaserad arkitektur (Service Oriented Architechture) Principerna för en tjänstebaserad arkitektur kan beskrivas i följande punkter: Tjänsteleverantörer utför tjänster åt tjänstekonsumenter Tjänsterna som utförs definieras av meddelanden vars uppbyggnad publiceras Tjänstekonsumenterna hittar tjänsteleverantörerna via tjänstemäklare Tjänstekonsumenter och tjänsteleverantörer är löst kopplade till varandra, d.v.s. förbindelse mellan tjänstekonsument och tjänsteleverantör upprätthålls endast mellan anrop och avgivet svar (fysiskt lös koppling i runtime) Tjänsteleverantörerna är tillståndslösa mellan anrop, d.v.s. bevarar inte sessionstillstånd hos tidigare anrop från tjänstekonsumenter. Verksamhetsbundna status och tillstånd lagras däremot i de underliggande system som tjänsteleverantören nyttjar (logiskt lös koppling i runtime) Den inre tekniska uppbyggnaden hos tjänstekonsument eller tjänsteleverantör avspeglas inte i meddelanden eller i tjänsteleverantörernas tekniska gränssnitt (lös koppling vid design) Tjänsteleverantörerna är självständiga mot sina konsumenter, d v s ansvarar för funktionella och icke-funktionella egenskaper (säkerhet, spårbarhet, validering, versionshantering mm) Den tjänstebaserade arkitekturen säger däremot ingenting om val av teknik. Se vidare Carelink PLUS och RIV Se aktör Tidsbegränsad Se e-underskrift Begrepp som i text innebär att information flyttas till den som frågar om den I denna rapport används termen utlämnande huvudsakligen i betydelsen av den skadeprövning som görs enligt sekretesslagen (menprövning), när samtycke saknas. Maj 2007 8

Vårdinformation Vårdrelation Vårdtjänst XACML Åtkomstkontroll Både vid applicering av samtycke och menprövning, sker i bägge fallen ett utlämnande dvs vårdinformation överförs över en sekretessgräns. Detta registreras automatiskt i loggen och är därför underförstått i denna rapports beskrivningar. All information om patienten i vården. En hälso- och sjukvårdspersonal har en vårdrelation om han/hon deltar i planering, utförande och/eller uppföljning av patientens vård Andra IT-tjänster än BIF-tjänster extensible Access Control Markup Language En typ av rättighetskontroll som reglerar åtkomsten till en specifik aktivitet eller resurs (vårdinformation). Sker i Åtkomstkontrolltjänsten. Maj 2007 9

2 Inledning BIF-projektet initierades 2006 av de tre storregionerna och innebar att man i samverkan mellan flera regioner/landsting överenskom om en gemensam syn på funktionalitet och teknikval för framtida säkerhetstjänster i en tjänsteorienterad arkitektur. Resultatet publicerades i en slutrapport i två delar, 0.95 A och B. I slutrapport A gavs en övergripande beskrivning till BIF med introduktion, projektstruktur och funktionell beskrivning. I del B gavs tekniska specifikationer till en viss nivå. Från 2007 är BIF ett nationellt projekt under Beställarfunktionen på SKLs ansvar och genomförs i Carelinks regi. Hittills har tre delprojekt avlämnat delresultat: Affärsmodell, Test/Certifiering och Förarbete till standard. Det är det sistnämnda som är denna redovisning. Målet har varit att uppnå informationssäkerhetsinteroperabilitet genom att definiera en teknisk norm i en första version, som i utnyttjande kan uppnå status av de facto standard. Denna uppsättning BIF-tjänster i sin första version, ska sedan med ökande krav kunna förädlas. 2.1 Arbetsgång Förarbete till standard Föreliggande rapport är en vidarebearbetning av Slutrapport 0.95 B. Bearbetningen har skett i en samfälld process mellan teknisk experter från landsting/regioner och leverantörer. Detta har skett i gemensamma arbetsseminarier, via telefonmöten och via e-mail. Processen har hela tiden varit öppen och delresultat av arbetet har funnits tillgängligt på Carelinks hemsida för synpunkter. Resultatet består huvudsakligen i en skärpning av tjänstebeskrivningarna. Uppskärpningen har dels varit en precisering av funktionella krav, dels en precisering av funktioner och gränssnitt (WSDL). Vidare har användningen av BIF-tjänsterna förtydligats med fler exempel. För att uppnå målet, har i vissa fall preciseringen av BIF-tjänsterna givit en anpassning av funktionalitet jämfört med tidigare beskrivningar. Detta har varit nödvändigt, då ursprungliga krav varit ofullständigt penetrerade och därmed för omfattande. Grundkonceptet från rapport 0.95 är dock oförändrat. 2.2 Läsanvisning För en introduktion till BIF avseende syfte, mål och konceptuell modell, hänvisas till BIF slutrapport 0.95 A, tillgänglig via Carelinks hemsida (www.carelink.se). En detaljerad redogörelse för de förändringar som gjorts jämfört med Slutrapport 0.95 B ges i sista avsnittet. Här ges endast en översiktlig genomgång av innehållet. Rapporten inleds med översiktliga beskrivningar av funktionaliteten hos BIF-tjänsterna, med gradvis stigande komplexitet. De inledande, översiktliga beskrivningarna åskådliggör bland annat utnyttjandet av BIF inom och mellan organisationer. Därefter följer detaljerade användningsfall som beskriver tillämpningen av BIF-tjänsterna i ett verksamhetsscenario. Sedan följer en kort översikt av grundläggande beståndsdelar och en översiktlig beskrivning av en del av de generella behov som finns i en SOA-värld. Huvudparten av rapporten utgörs av de tekniska specifikationerna för varje enskild tjänst, med en detaljerad beskrivning av syfte, koncept, funktionella krav och funktioner. I en separat bilaga finns WSDL för alla tjänster. I rapportens avslutande del finns beskrivning av ingående resurs- och behörighetsmodell, och vilka oundgängliga egenskaper, som skall utnyttjas i regelverket. Här finns också detaljerad beskrivning av biljettens användning och SAML. Ett scenario för implementering av BIFtjänster har tillfogats. Maj 2007 10

Denna rapport versionssätter IT-tjänsterna inom BIF till version 1.0 och avsikten är att tjänsterna med tiden kan utvecklas och därmed versionshanteras i en här för avsedd förvaltning. 2.3 Avgränsning De tekniska beskrivningarna innefattar inte nätverksoperativsystem. Klienthårdvara med kortläsare och tillhörande mjukvara beskrivs ej heller. Den övergripande säkerheten avseende kodsäkerhet, skydd mot attacker etc behandlas ej här. För ett införande av BIF-tjänster i en SOA-värld fordras också tjänsteförmedlare och tjänsteregister på olika nivåer, vilket är ett generellt behov och ej specifikt för BIF. En kort översikt finns dock i avsnitt2.8. 2.4 Projektdeltagare Anders Beckman Region Skåne Projektledare Per Torlöf Region Skåne Stefan Holmberg Västra Götalandsregionen Yngve Svahn Örebro Läns Landsting Ted Wigefeldt Gaupe AB Lars Wahlgren Sentensia Q AB Torbjörn Dahlin Brainpool Henrik Båkman HP Henrik J Johansson Nexus Daniel Rodrigues Generic Magnus Vallstedt Microsoft Göran Melvås WM-data Martin Elwin Oracle Pontus Lindqvist/Benedikt Furrer IBM Dessutom har följande medverkat genom att kontinuerligt ge synpunkter på arbetsdokumenten: Ulf Palmgren SLL Anders Norr LiÖ Anders Lindberg Strategi AB Maj 2007 11

3 BIF övergripande beskrivning 3.1 Syfte med Bastjänster för InformationsFörsörjning Syftet med BIF-tjänsterna är att på ett enhetligt sätt säkerställa den funktionella informationssäkerheten avseende IT-tjänsters hantering av vårdinformation inom hälso- och sjukvården, såväl inom som mellan organisationer. Syftet med denna inledande och övergripande beskrivning är dels att ge en helhetsbild, dels att ge utrymme för gemensam kravställning för BIF-tjänsterna kring teknik, standarder, dokumentation och andra icke-funktionella krav. 3.2 Konceptuell beskrivning av tjänsterna IT-tjänsterna i BIF samverkar i en tjänsteorienterad arkitektur (SOA) för att stödja informationssäker elektronisk hantering av vårdinformation. IT-tjänsterna har var för sig unik funktionalitet, men det erfordras full samverkan BIF-tjänsterna emellan för att informationssäkerhet skall uppnås avseende: Tillgänglighet Åtkomlighet för behöriga Skydd för obehörig insyn Riktighet/oförvanskad Spårbarhet och oavvislighet Följande IT-tjänster är beskrivna i BIF: Autentisering Åtkomstkontroll Vårdrelation Samtycke Säker patientkontext Loggning Logganalys Notifiering Utlämnande IT-tjänsten Åtkomstkontroll kan vid behov efterfråga underlag till beslut hos IT-tjänsterna Vårdrelation, Samtyckes och Utlämnande (se figur 1). Delar av funktionaliteten för vissa IT-tjänster finns i agenter, som är inkorporerade i en fasad. Agentens uppgift är att effektivisera IT-tjänstens funktion med för tjänstekonsumenten lokal bearbetning. Effektiviseringen kan ske med varierande grad av funktionalitet i agenten. Agenterna och fasaden är dock i detta dokument ej lika strikt standardiserade som själva ITtjänsterna. Behovet av agenter är starkt, men bedömningen är att utbytbarheten är viktigast för själva BIF-tjänsterna och att olika leverantörer kommer att tillverka/leverera olika SDK för respektive miljö. Maj 2007 12

Figur 1 Samband BIF-tjänster 3.2.1Funktion och generalitet i BIF-tjänster Genom att funktionerna i BIF-tjänsterna är generiskt uppbyggda, hanteras all begäran om aktivitet (läsa, skriva etc.) på samma sätt i alla organisationer och det är de specifika reglerna som läggs in BIF-tjänsterna som styr detta. Det innebär exempelvis att en aktör endast behöver autentisera sig en gång, oavsett var han eller hon sedan söker vårdinformation. 3.2.2 Basal BIF-funktion inom en organisation Vid begäran om tillgång till vårdinformation är förenklat den övergripande händelsekedjan enligt följande: Aktören identifierar sig och erhåller biljett med certifikat och egenskaper. Därefter begär aktören tillgång till vårdinformation i en vårdtjänst. Vårdtjänsten kontrollerar då rättigheterna i Åtkomstkontrolltjänsten och aktören erhåller eller erhåller inte tillgång till vårdinformation. Alla aktiviteter loggas. Ett förenklat, schematiskt förlopp av funktionaliteten inom en organisation visas i figur 2: Maj 2007 13

Figur 2 Schematisk förlopp i BIF-tjänsterna inom en organisation 1. Aktören presenterar sitt eid-kort och sin PIN-kod på sin arbetsplats. 2. Aktörens identitet och egenskaper verifieras i Autentiseringstjänsten. 3. Aktörens identitet och egenskaper skickas i Biljett till arbetsplatsen. 4. Med Biljetten begär aktören tillgång till vårdinformation i en IT-tjänst (vårdtjänst). 5. Aktörens och resursens (vårdinformationens) identitet och egenskaper kontrolleras mot regelverket i Åtkomstkontrolltjänsten. 6. Beslut om tillgång eller nekande lämnas till IT-tjänsten. 7. Resultat i form av tillgång eller nekande lämnas av IT-tjänsten till aktören. 8. Alla aktiviteter loggas (enbart illustrerat med loggning från IT-tjänst här). 3.2.3Basal BIF-funktion mellan organisationer När en aktör begär tillgång till information över en organisationsgräns blir förfarandet det samma, med den skillnaden att åtkomstkontrollen sker i den organisation som ansvarar för resursen/vårdinformationen, se figur 3. Det är aktörens egen organisationen som ansvarar för autentiseringen, men åtkomstbeslutet fattas av organisationen som ansvarar för vårdinformationen som via sitt egna regelverk. Förloppet illustreras förenklat i figur 3. Maj 2007 14

Figur 3Schematisk förlopp i BIF-tjänsterna mellan två organisationer 1. Aktören presenterar sitt eid-kort och sin PIN-kod på sin arbetsplats. 2. Aktörens identitet och egenskaper verifieras i Autentiseringstjänsten, tillhörande aktörens organisation. 3. Aktörens identitet och egenskaper skickas i Biljett till arbetsplatsen. 4. Med Biljetten begär aktören tillgång till vårdinformation i en extern IT-tjänst (vårdtjänst). 5. Aktörens och resursens (vårdinformationens) identitet och egenskaper kontrolleras mot regelverket i Åtkomstkontrolltjänsten i den externa organisationen. 5 b Åtkomstkontrolltjänsten efterfrågar vid behov underlag från Samtyckes- och/eller Utlämnandetjänsten. 6. Beslut om tillgång eller nekande lämnas till IT-tjänsten. 7. Resultat i form av tillgång eller nekande lämnas av IT-tjänsten till aktören. 8. Alla aktiviteter loggas (enbart illustrerat med loggning från IT-tjänst här). 3.3 Detaljerad beskrivning av IT-tjänsterna i BIF 3.3.1.1Sekvens inom en organisation Aktörens identitet säkerställs med Autentiseringstjänsten. Denna funktion är beroende av en säker hantering av aktörens identitet och egenskaper, förutom certifikatshanteringen enligt SITHS. När användaren begär tillgång till vårdinformation, kontrolleras rättigheter i Åtkomstkontrolltjänst, som i sin tur kan efterfråga underlag i Vårdrelationstjänsten, Maj 2007 15

Samtyckestjänsten och/eller Utlämnandetjänsten, samt vid behov begära fler egenskaper för aktören från Autentiseringstjänsten. För att undvika förväxling av patientinformation vid val av ny patient, synkroniseras alla aktiva vårdapplikationer med hjälp av Säker patientkontexttjänsten. Alla aktiviteter loggas och placeras i Loggtjänsten, där de följs upp med Logganalystjänsten. Förloppet (förutom Säker patientkontexttjänsten), är illustrerat med sekvensdiagram i figur 4. Figur 4 Sekvensdiagram intern rättighetshantering 3.3.1.2Sekvens mellan organisationer För tillgång till vårdinformation över organisationsgränser, utnyttjas att aktören är autentiserad på överenskommet sätt i sin egen organisation och ny autentisering behöver inte göras. Åtkomstregler styr om aktören får tillgång till vårdinformation genom samtycke eller prövning av behörigt utlämnande (menprövning). Begäran om tillgång till vårdinformation i annan organisation kan initieras på olika sätt: En egen vårdtjänst kan indikera att vårdinformation finns (utan att ange källa), en specifik ITtjänst kan indikera vårdinformation utanför egen organisation och aktören kan direkt begära vårdinformation i en annan organisations vårdtjänst. Om samtycke eller utlämnandebeslut finns, får aktören tillgång till vårdinformation, i annat fall blir det ett två-stegsförfarande: Oavsett hur aktören begär tillgång till vårdinformation i en annan organisation, sker alltid kontroll av rättigheter i ÅKT. Regler har lagts in som styr tillgång till vårdinformation för aktör från annan organisation och dessa anger att samtycke eller utlämnandebeslut måste finnas. ÅKT kontrollerar då om underlag finns i Samtyckestjänst respektive Utlämnandetjänst. Om inget underlag finns för till gång till vårdinformation, blir aktören nekad tillgång, men får samtidigt besked på varför han eller hon nekas. Aktören kan då välja att få samtycke från patienten (i dagens regelverk) eller att göra en begäran om utlämnande direkt i Utlämnandetjänsten hos den andra organisationen. (Ingen automatisk begäran om utlämnande sker från ÅKT.) Utlämnandetjänsten meddelar ansvarig Maj 2007 16

prövare, så att menprövning kan ske. När prövning gjorts, meddelas aktören resultatet via Notifieringstjänsten. Den andra organisationens ÅKT efterfrågar utlämnandebeslut och ger därefter aktören rättighet till begärd vårdinformation. Denna åtkomst innebär att vårdinformationen överförs till aktörens egen organisation, för vidare hantering, figur 5. Figur 5 Sekvensdiagram för utlämnande mellan organisationer (Loggtjänst utelämnad) Maj 2007 17

3.4 Användningsfall Dessa användningsfall visar utnyttjandet av samtliga BIF-tjänster. 3.4.1Förutsättning Varje organisation har ett eget ansvar för aktörernas identitet och tillgång till resurser ( journal ). Det betyder att varje organisation själv logiskt måste hantera autentisering, åtkomstkontroll mm, men rent tekniskt kan detta lösas med gemensamma IT-tjänster. 3.4.2Vårdinformation inom eget sekretessområde Doktor A i Landstinget A har träffat patienten Nils Nilsson och skall skriva en journalanteckning och ordinera läkemedel för rosfeber. Vid datorn på sin expedition identifierar Dr A sig via Autentiseringstjänsten med sitt e-id kort och dess PIN-kod. Han får då tillgång till en vårdtjänst. Han anger där patientens personnummer och via Åtkomstkontrolltjänsten (ÅKT) får han möjlighet att skriva ny text. Han för in aktuella observationer. (Figur 6 överst) Dr A ska därefter ordinera läkemedel. Förnyad kontroll (osynligt för användaren) i Åtkomstkontrolltjänsten ger honom tillträde till en läkemedelstjänst, utan att ny inloggning behöver göras dvs det blir en funktionell single-sign-on (SSO). Genom Säker Patientkontexttjänsten aktiveras automatiskt aktuell patient i Läkemedelstjänsten. Dr A ordinerar läkemedlet, undertecknar receptet elektroniskt och aktiverar säker e-förmedling av receptet. (Figur 6 un)derst In- och utloggningen, och allt Dr A läst och gjort däremellan, loggas till Loggtjänsten. Maj 2007 18

Figur 6 Schematisk framställning av flöde i BIF - Vårdinformation inom eget sekretessområde. Grönt markerar aktiva BIF-tjänster, grått odefinierade tjänster. 3.4.3Vårdinformation mellan landsting med samtycke Doktor B på ett sjukhus i Landstinget B träffar patienten Nils Nilsson efter dennes hemkomst från Lanstinget A. I Landstinget A har Nils Nilsson fått läkemedel e-förmedlat till Apoteket, men kan inte riktigt redogöra för omständigheterna kring det besöket. Dr B ber om Nils Nilssons tillstånd att läsa vårdinformation i Landstinget A och får det - erhåller Samtycke. Vid datorn på sin expedition identifierar Dr B sig via Autentiseringstjänsten med sitt e-id kort och dess PIN-kod. Han får då efter kontroll av Åtkomstkontrolltjänsten tillgång till Samtyckestjänst och Vårdrelationstjänst och kan där registrera patientens samtycke, respektive sin vårdrelation med denne. Dr B önskar sedan söka information i Landsting A, utanför sin egen organisation, vilket han i detta fall gör via en indextjänst. En (osynlig) kontroll görs i Åtkomstkontrolltjänsten och ger Dr B tillträde till indextjänsten, där aktuell patient automatiskt blir aktiverad med hjälp av Säker patientkontexttjänsten. Via indextjänsten begär Dr B vårdinformation i Landstingets As Vårdtjänst om Nils Nilsson. Begäran kontrolleras av regelverket i Lanstinget As Åtkomstkontrolltjänsts. Intyg om samtycke och vårdrelation har överförts med biljetten till Landsting A. Enligt Landstinget As regelverk tillåts läsning av journaltext av läkare och sjuksköterskor från Landstinget B om vårdrelation och samtycke föreligger och autentiseringen av användaren skett enligt lägsta överenskomna nivå, i det här fallet med e-id kort och PIN-kod. Därmed ges Dr B tillgång till vårdinformation. (Figur 7) Begäran om tillgång och beslut loggas i Loggtjänsten i Landstinget A. Dr B kan nu läsa aktuell journaltext. Läsningen registreras i Landstinget A som utlämnande av aktuellt avsnitt och loggas dessutom i Loggtjänsten. Efter läsning beslutar Dr B att aktuellt journalavsnitt från Landstinget A läggs in i den egna journaltexten, vilket noteras där. Dr B avslutar sin konsultation med Nils Nilsson. In- och utloggningen, och allt Dr B läst och gjort däremellan, loggas till Loggtjänsten i Landstinget B. Maj 2007 19

Figur 7 Schematisk framställning av flöde i BIF - Vårdinformation mellan landsting med samtycke. Grönt markerar aktiva BIF-tjänster, grått odefinierade tjänster. Maj 2007 20

3.4.4Vårdinformation mellan landsting med menprövning Dr A i Landstinget A får en ny patient Svea Sveasson, hemmahörande i Landstinget B. Svea Sveasson är på tillfälligt besök på sitt sommarställe, som ligger inom Landsting A. Hon bor där med sin son, som med hjälp av hemtjänst sköter henne. Nu är emellertid sonen på konferens och hemtjänstpersonalen har beställt tid för läkarundersökning. Dr A kan inte erhålla någon information från Svea Sveasson pga hennes sviktande mentala funktioner och därför inte heller något samtycke. Hemtjänstpersonalen kan inte bidra med annat än namn och vistelseadress. Tidigare sjukhistoria och eventuella läkemedel har endast sonen kunskap om, och han är inte tillgänglig. Vid datorn på sin expedition loggar Dr A in via Autentiseringstjänsten med sitt e-id kort och PIN-kod. Han anger patientens personnummer och via Åtkomstkontrolltjänsten får han möjlighet att registrera sin vårdrelation i Vårdrelationstjänsten, för att ha som underlag när han begär journalinformation från Sveas hemlandsting. Genom en (osynlig) kontroll i Åtkomstkontrolltjänsten får Dr A tillträde till indextjänsten, där aktuell patient via Säker patientkontexttjänsten blir aktiverad. Dr A anger där att han vill söka vårdinformation i Landstinget B (varifrån patienten kommer). Dr A ges nu möjlighet att efterfråga vårdinformation i Landstinget B via deras Utlämnandetjänst. I Utlämnandetjänsten i Landsting B noteras från Dr A s biljett 1 dennes identitet, organisationstillhörighet, verksamhetsområde, och att vårdrelation föreligger för aktuell patient. Dr A får en kvittens via Utlämnandetjänsten i Landstinget B att begäran om utlämnande av vårdinformation mottagits. Via Notifieringstjänsten i Landstinget B meddelas samtidigt jourhavande handläggare på Funktionen för Utlämnande i Landstinget B att prövning av behörigt utlämnande skall göras. Aktuell tjänsteman med rättighet att göra denna bedömning granskar begäran och fattar beslut om att utlämna definierat avsnitt. Beslut om utlämnande registreras i Utlämnandetjänsten. 2 (Figur 8) 1 Biljett=innehåller intyg om användarens egenskaper. Genom att elektroniskt underteckna biljetten garanterar utfärdaren dess innehåll. Biljett är en grundläggande komponent i SSO-funktionaliteten. Biljetten är utfärdad av en betrodd samarbetspartner. 2 All information rörande patienten räknas till patientjournalen, oavsett i vilken IT-tjänst den är registrerad. Maj 2007 21

Figur 8 Schematisk framställning av flöde i BIF Begäran om utlämnande Dr A får via Notifieringstjänsterna i Landsting B och det egna Landsting A meddelande om att utlämnandebeslut är fattat. Dr A begär nu tillgång till aktuell vårdinformation via vårdtjänsten i Landstinget A. Åtkomstkontrolltjänsten i Landstinget B kontrollerar då i Samtyckestjänsten och Utlämnandetjänsten om underlag finns. Då det finns ett utlämnandebeslut, får Dr A tillgång till journaltexten. In- och utloggningen, och allt läkaren läst och gjort däremellan, loggas till respektive landstings Loggtjänst.(Figur 9) Maj 2007 22

Figur 9 Schematisk framställning av flöde i BIF - Tillgång till vårdinformation efter utlämnandebeslut Maj 2007 23

3.5 Generella funktionella krav K 1 Tjänsterna skall vara skalbara vertikalt och horisontellt 3. K 2 Tjänsterna skall ha grafiskt administrationsgränssnitt. K 3 Tjänsterna skall utformas så att de klarar 7:24 drift. K 4 Felhantering Om fel inträffar skall felsituationen hanteras så att information som beskriver felet kan loggas och rapporteras tillbaka till konsumenten. Felmeddelanden och felrapporter skall innehålla tillräckligt med information om felsituationen så att konsumenten har en chans att återhämta sig från avbrottet med så liten påverkan som möjligt på arbetsflödet. K 5 Tid hanteras internt och lagras i UTC, men ska kunna presenteras i lokal sommar- och vintertid. K 6 Tidssynkronisering av ingående tjänster skall ske K 7 Tjänsterna skall vara övervakningsbara avseende fysisk och logisk funktionalitet K 8 Tjänsterna skall kunna prestandamätas i drift 3.6 Generella icke-funktionella krav 3.6.1Prestanda Användbarheten för BIF står och faller med goda prestanda, eftersom svarstiderna från ITtjänsterna indirekt påverkar användarens upplevda svarstid i applikationerna. Viktiga egenskaper är därför korta svarstider från tjänsterna vid såväl registrering, läsning som notifiering. En viktig konstruktionsfaktor är möjligheten för IT-tjänster att på ett effektivt sätt utnyttja varandra utan att onödigt och tidskrävande resursutnyttjande skapas för IT-tjänsterna. I situationer där tjänster anropar varandra i kedjor, sk. kaskadering, introduceras onödiga anrop till BIF-tjänsterna om inte mekanismer för att undvika detta finns. 3.6.1.1Programmerings- utvecklings och driftsmiljö Anges vid en upphandling. Minimum.NET och Java för agenter och fasad. 3.6.1.2Övriga generella icke-funktionella krav Tjänsterna skall utformas att exponeras i öppna publika nätverk. Formuleras vid anskaffning. 3 Med det menas att tjänster fungera både i en centraliserad och i en distribuerad miljö. Designen av tjänsterna skall medge att en logisk tjänst kan vara fysiskt distribuerad (=flera instanser). Likaså skall flera organisationer kunna dela på en tjänst dvs en instans skall kunna vara logiskt uppdelad. Maj 2007 24

3.7 Grundläggande beståndsdelar Basen för IT-tjänster är en Tjänstebaserad arkitektur (Service Oriented Architecture=SOA). Principen för SOA är att tydligt urskiljbara delar med bestämda uppgifter och standardiserade gränssnitt utbyter tjänster, services, med varandra genom meddelande, se figur 9. Figur 10 Principen för en SOA-tjänst I BIF är baskonceptet för SOA kompletterat med säkerhetsfunktionalitet. 3.7.1Biljett En användare autentiseras endast en gång och detta skall ske minst på lägsta säkra och överenskomna nivå (i dagsläget SITHS). Autentiseringstjänsten skapar intyg som innehåller information om användarens identitet och egenskaper. Genom att signera dessa intyg går Autentiseringstjänsten i god för att det som intygas är korrekt Intygen samlas och paketeras i en biljett som överföres till användarens klientarbetsplats eller görs åtkomlig vid autentisering via webapplikation. Genom uppvisandet av biljetten får användaren sedan eventuell åtkomst till andra IT-tjänster. Eftersom Autentiseringstjänsten är betrodd av andra BIF-tjänster litar de på biljettinnehållet. 3.7.2Fasad 4 En fasad är en gränssnittskomponent som varje IT-tjänst instansierar och den ger på ett smidigt och enkelt sätt IT-tjänsten tillgång till BIF-tjänsternas funktionalitet. Förutom att hantera signering och kryptering av meddelanden, tolkar och verifierar fasaden rättighetssbiljetter och ansvarar för loggning. Alla meddelanden som skickas till och från BIFsäkrade tjänster passerar alltid genom fasaden. Fasaden utnyttjar många av BIF-tjänsterna och för de BIF-tjänster som har agenter placeras dessa i fasaden. 4 Fasad skall uttydas Fasadkomponent, och ej förväxlas med designmönstret Façade. Maj 2007 25

Figur 11 Fasad med agenter Genom utnyttjandet av en specificerad fasad, kan centrala och väsentliga säkerhetsrelaterade uppgifter 5 skötas på ett uniformt sätt för alla IT-tjänster. Genom att tillföra denna funktionalitet i en fasad, kan utvecklingen av IT-tjänster för vård och omsorgsverksamhet förenklas. Fasaden är av nödvändighet knuten till viss teknik genom att den skall implementeras för den runtime-miljö i vilken den länkas in. Därför skall fasader utvecklas för aktuella miljöer som i dagsläget är.net och Java. Fasaden ger enkelhet för utvecklare (läs billigare), enhetlig certifierad användning av BIFtjänsterna samt garanterar en säker kommunikation med IT-tjänster, inom och utom organisationer. 5 Säkerhetsrelaterade uppgifter är signering, kryptering, biljetthantering, autentisering, auktorisering och loggning. Maj 2007 26

Figur 12 SOA-tjänst kompletterat med säkerhetsfunktionalitet (signering, kryptering) För att säkerställa att ett meddelande inte förvanskats och för att erhålla oavvislighet signeras meddelanden med XML-Signature enligt WS-Security. Mottagaren av meddelandet skall alltid kontrollera och verifiera signaturen. Tanken är att fasaden med automatik utför dessa operationer. Om meddelandet förses med insynsskydd genom kryptering används XML- Encryption enligt WS-Security. Fasaden innehåller även funktionalitet för kryptering och dekryptering. 3.7.3Klientkomponent Hela säkerhetslösningen bygger på en biljetteknik där autentiseringstjänsten utfärdar betrodda intyg, vilka uttalar sig om användarens egenskaper. På klientsidan kan detta implementeras på två sätt, lokalt exekverande klient eller klient uppdelad på browserdel och server. 3.7.3.1Lokalt exekverande klient Genom specifikation av en arbetsstationskomponent, kan e-id kort, certifikatshantering och biljetteknik skötas på ett uniformt sätt. På användares datorarbetsplats kan dessutom funktionalitet hos fasaden utnyttjas. Fasader hanterar signering och kryptering och all biljetthantering, men på arbetsstationen behövs även stöd för att initialt knyta den inloggande användaren till en biljett. Efter det att denna knytning är gjord, representeras användaren av denna biljett. En komponent, AuthenticationAgent, finns därför på arbetsstationen med uppgift att hantera den klientspecifika biljetthanteringen. Maj 2007 27

Figur 13 Lokalt exekverande klient 3.7.3.2Browserbaserad klient I det browserbaserade fallet är den funktionalitet som i ovanstående beskrivning utförs av AuthenticationAgent flyttad till en IT-tjänst. IT-tjänsten kan exempelvis vara en portalserver. Funktionaliteten är densamma som när en IT-tjänst anropar en annan IT-tjänst. För att hantera inloggning i webmiljö används SAML 2.0 Web Browser SSO Profile. En webapplikation som önskar autentisera en aktör skickar aktören till autentiseringstjänstens webgränssnitt. Efter autentisering returneras användaren till webapplikationen tillsammans med information om hur biljett kan uthämtas. 3.7.4 Trust via biljett Säkerhetskonceptet i BIF innebär att varje IT-tjänst som mottar ett meddelande skall verifiera såväl meddelandets riktighet och ursprung som att den i meddelandet medföljande biljetten är äkta och tillförlitlig. Själva meddelandets riktighet och ursprung garanteras genom att IT-tjänsten kryptografiskt verifierar meddelandets signatur. Biljettens autenticitet måste också kontrolleras innan de ingående aktörsegenskaperna används för exekvering av rättighetsregler. Att biljetten medföljt det signerade meddelandet är inte tillräckligt. Det krävs att mottagande IT-tjänst med visshet kan verifiera att: biljetten är riktig och oförvanskad vilket görs genom att verifiera utfärdens signatur på biljetten aktören, vars egenskaper biljetten beskriver, också är den som signerat meddelandet vilket görs genom att kontrollera att signaturen på meddelandet är gjord av samma aktör som beskrivs i den medföljande biljetten. Maj 2007 28

biljetten är utfärdad av en känd och betrodd (certifierad) autentiseringstjänst Om det bara fanns en autentiseringstjänst vore detta inget problem. Men precis som andra IT-tjänster kan en organisation ha flera autentiseringstjänster, kan en autentiseringstjänst delas av flera organisationer, kan nya autentiseringstjänster tillkomma eller så kan autentiseringstjänster läggas ner osv. Trots denna föränderliga miljö måste varje IT-tjänst vid varje tillfälle kunna verifiera att en mottagen biljett utfärdats av en betrodd (certifierad) autentiseringstjänst. Detta skall ske genom en särskild certifieringsprocess där varje autenticeringstjänst godkänns och tilldelas unika egenskaper (attribut) i sina tjänstecertifikat (dvs SITHS funktions-hcc). Därvid kan IT-tjänster genom att kontrollera biljettutfärdarens certifikat avgöra om denna är den autentiseringstjänst den utger sig för att vara. Nödvändig funktionalitet för verifiering av meddelande och biljetter kommer att finnas i Fasaden vilket innebär att utvecklare av IT-tjänster inte behöver belastas med detta. 3.7.5Samverkan De tre huvudbeståndsdelarna biljett, fasad och lokalt exekverande klientkomponent samverkar, så att en säkerhetsmässig enhet nås, se figur 15. Figur 14 Biljett-fasad-kliensamverkant När istället en webbläsare används, blir förloppet enligt figur 15. Maj 2007 29

Figur 15 Samverkan i webklient 3.8 Generella behov I en tjänsteorienterad arkitektur, där IT-tjänsterna är självständiga och endast löst kopplade med anrop och svar, krävs att IT-tjänsternas funktion styrs och regleras på en högre nivå, så att bl.a. koordinering, upptäckt mm fungerar. Praktiskt kan behoven för bl.a. BIF-tjänsterna uttryckas som behov av ett Tjänstelager. Detta tjänstelager består bl.a. av själva IT-tjänsterna (BIF och vårdtjänster mm), tjänsteregister och eventuell tjänsteförmedlare. I varje organisation måste finnas en logik för att hålla reda på vilka IT-tjänster som finns ett tjänsteregister. Arbete inom RIV pågår för att uppgradera det tjänsteregister som finns beskrivet i RIV-HSA. Vidare kan anrop mellan IT-tjänster behöva förmedlas via en tjänsteförmedlare. För varje ny organisation som IT-tjänsterna ska verka i, finns behovet av att hitta relevanta IT-tjänster dvs ett tjänsteregister behövs även mellan organisationer, men kan organiseras på olika sätt (regionalt, nationellt), se figur. Ett flertal kommersiella produkter finns tillgängliga för SOA-funktioner som orkestrering, koreografering, tjänsteregister och tjänsteförmedlare, men även fria standarder som WS- BPEL 2.0, UDDI och WS-Choreografy finns. De generella behoven för IT-tjänster behandlas inte i denna rapport, men måste bearbetas och beslutas om på liknande sätt som BIF-tjänster. Detta kan i sin tur påverka vissa lösningar i BIF-tjänsterna. Maj 2007 30

Figur 16 Schematisk bild av tjänsteregister och tjänstemäklare. Maj 2007 31

4 IT-tjänst för autentisering 4.1 Tjänstespecifikation: Autentisering 1.0 4.2 Syfte med tjänsten Autentiseringstjänsten har i uppgift att vid inloggning fastställa aktörens identitet samt sammanställa och intyga dennes egenskaper i en e-underskriven biljett, som sedan kan användas som underlag för rättighetsstyrning i övriga IT-tjänster. En aktör kan vara en fysisk person eller IT-tjänst som behöver åtkomst till andra IT-tjänster. 4.3 Konceptuell beskrivning av tjänsten Autentiseringstjänsten skall Verifiera aktörens identitet genom autentisering Knyta egenskaper till aktören Intyga den styrkta identiteten och tillhörande egenskaper till de IT-tjänster som efterfrågar detta BIF hanterar olika kategorier av aktörer. En aktör kan i detta sammanhang vara: En fysisk person En IT-tjänst En aktör skall vara upplagd i en HSA-katalog och vara identifierad genom SITHS-certifikat. För allmänheten gäller medborgarcertifikat. I en IT-tjänst för administration av egenskaper e-undertecknas dessa av en administratör. Varje medarbetare är unikt identifierad med ett HSA-id, som är en global unik identitet konstruerad utifrån Hälso- och Sjukvårdens Adressregister (HSA). Personer i hälso- och sjukvården identifierar sig med ett certifikat som bygger på SITHS. Invånare autentiserar sig med en godkänd e-legitimation. Invånare behöver då inte vara registrerad eller känd sedan tidigare, men IT-tjänsten för autentisering kan verifiera certifikatets giltighet, att certifikatet är utfärdat av betrodd instans och därmed styrka användarens identitet. Vid autentiseringen knyts egenskaper till användaren och dennes identitet. IT-tjänst för autentisering försäkrar att en aktör har identifierats, autentiserats och är förknippad med vissa egenskaper. Denna försäkran skall kunna användas för åtkomst till applikationen istället för att begära ny autentisering av användaren. En sådan försäkran utgörs av en signerad biljett innehållande information om aktuell användare och dess egenskaper. I BIF används SAML standarden som biljettformat. 4.4 Avgränsning Autentiseringstjänsten placerar inga åtkomstbeslut eller regler i biljetten. 4.5 Funktionella krav KA 1. Autentiseringstjänsten skall via definierad autentiseringsmetod avkräva en godkänd autentisering av användaren innan ett intyg (SAML biljett) skapas. KA 2. En användare skall kunna vara en person eller IT-tjänst Maj 2007 32

KA 3. PKI-baserad inloggning med X.509 v3 certifikat av typen e-id (medborgarcertifikat) och Health Care Certificates (HCC) enligt SITHS-modellen skall användas. KA 4. Det skall finnas funktioner för att konfigurera vilket/vilka attribut i X.509 certifikatet som används för att identifiera användaren (t.ex. Subject Name, Serial Number, Common Name osv). I denna version gäller att medborgare som autentiserar sig med e-id identifieras med personnummer Serial Number i certifikatet medan hälso- och sjukvårdspersonal som autentiserar sig med HCC identifieras med HSA-id också Serial Number i certifikatet. KA 5. Godkända certifikatutgivare skall kunna specifieras för respektive tillämpning av PKI som metod. KA 6. Vid användning av certifikat för autentisering skall systemet kunna utföra kontroll av certifikatets status (spärrinformation). KA 7. Tjänsten skall ställa ut ett logiskt intyg om användaren i form av SAML biljett. Biljetten skall kunna innehålla: - användarens identitet - dennes egenskaper - information om aktuell autentiseringsmetod - giltighetstid KA 8. Autentiseringstjänsten skall ta fram elektroniskt undertecknade användaregenskaper och förmedla dessa i biljetten. KA 9. Vid autentisering skall verifierade certifikat kunna förmedlas tillsammans med intyg utgivet från Autentiseringstjänsten. KA 10. Intyget skall säkert kunna knytas till den användare som presenterar biljetten för ITtjänsterna (proof of posession). Detta skall göras genom att meddelandet som skickas från användarens klient e-underskrivs. KA 11. Autentiseringstjänsten skall kunna användas i lösningar som bygger på feta och/eller tunna klienter. KA 12. Alla aktiviteter i Autentiseringstjänsten skall loggas av Loggtjänsten. KA 13. I loggen skall framgå tidpunkt, om godkänd/nekad, användarid (där tillämpligt), händelsetyp, målsystem/applikation (där tillämpligt) varifrån (ip-adress/nummer) begäran om autentisering kom, samt använd autentiseringsmetod. Vid nekande skall orsak framgå. KA 14. Nationellt överenskomna egenskaper skall kunna kompletteras med lokala egenskaper. Varje mängd av lokala egenskaper skall kvalificeras med ett unikt namespace. KA 15. Stöd skall finnas för att kunna påverka informationsuppsättningen i biljetten vid inloggning. Till exempel skall verksamhetsuppdrag samt syfte kunna vara valbart. KA 16. Autentiseringstjänsten skall ha stöd för att hantera autentisering för webapplikationer. I webfallet skall tjänsten själv presentera och låta aktören välja de faktorer som påverkar biljetten, om nödvändigt. Biljett skall föras tillbaka till webapplikationen med hjälp av SAML Web Browser SSO Profile med HTTP Redirect binding (för AuthnRequest) samt HTTP Artifact binding (för Response). 4.6 Tjänstegränssnitt: Funktioner Funktion Autentisera Hämta aspekter Anm. Utifrån uppvisat identifieringsbevis autentiseras användaren Hämta lista med valbara aspekter för användaren Maj 2007 33

Funktion Begär attributintyg Anm. Hämta intyg med ytterliggare attribut för viss användare 4.6.1Autentisera (Authenticate) 4.6.1.1Beskrivning Genom att aktören levererar sin identitet och signerar med ett giltigt certifikat som med säkerhet kan knytas till aktören autentiseras denne. En SAML biljett skapas som innehåller autentiserings och attributintyg.. Biljettens innehåll kan vid autentiseringen styras med inparametrar, det som här kallas aspect. För att skapa attributintyget förlitar sig autentiseringstjänsten på undertecknade aktörsegenskaper som hämtas från andra källor t.ex. HSA-katalogen. 4.6.1.2Inparametrar Typ Namn Beskrivning xml AspectChoices AspectChoices håller en lista med de valda värdena för varje aspekt. Denna kan ses som en lista med nyckel och värdepar. Nyckeln är aspektens Key och värdet är Value. Autentiseringstjänsten måste säkerställa att aspekternas valda värden är acceptabla för den användare som autentiseras. De valda aspektvärdena som används avgör, till exempel, vilken alternativ attributuppsättning som skall läggas i biljetten eller specifika värden för olika biljettattribut. Detta kan användas för att låta en användare med ett enda certifikat få ut biljetter med olika innehåll. 4.6.1.3Resultat En biljett i form av ett SAML assertion returneras vid lyckad autentisering. Innehållet i biljetten beskrivs i avsnitt 13.4 SAML biljetten skall vara signerad av autentiseringstjänsten. 4.6.1.4Ingångsvillkor För att styrka aktörens identitet skall meddelandet vara signerat med aktörens certifikat ur vilket också aktörens id hämtas. 4.6.1.5Utgångsvillkor Om aktören kunde autentiseras skapas en SAML biljett, populerad med attribut från den säkra attributkällan som autentiseringstjänsten använder sig av. De valda aspektvärdena skall lagras för användaren och returneras som respektive aspekts CurrentValue när GetAspects anropas. 4.6.1.6Felhantering Fel levereras som beskriver varför användaren inte kunde autentiseras. Felen ska loggas. Följande fel (faults) skall användas: UnknownUserFault Certifikatet är giltigt men användarens identitet kan inte fastställas. Maj 2007 34