Webbseminarium BIF-Utbildning för utvecklare Version 1.0.0

Typ av dokument Webbseminarium Datum 2009-07-02 Sida 1(85) Webbseminarium BIF-Utbildning för utvecklare Version 1.0.0

Innehållsförteckning 1. Introduktion... 4 1.1. Inledning... 4 1.2. Implementering... 5 2. BIF Arkitektur... 6 2.1. Inledning... 6 2.2. Tjänstebaserad arkitektur... 6 2.3. Flexibel plattform... 7 2.4. Säkerhet... 8 2.5. Egenskapsbaserad åtkomstkontroll... 9 2.6. BIF Beståndsdelar... 11 2.6.1. Biljett (SAML-intyg)... 11 2.6.2. Fasadkomponent... 13 2.6.3. Klienter... 14 2.6.4. Agenter... 17 2.6.5. Certifikat... 18 2.7. Webbtjänster i BIF... 19 2.8. Driftsättningsvy... 20 3. BIF SDK... 21 3.1. Inledning... 21 3.2. BIF SDK Java... 21 3.3. BIF SDK.NET... 22 4. Autentiseringstjänsten... 23 4.1. Inledning... 23 4.2. Applikationens ansvar... 24 4.3. Inloggningsaspekter... 24 4.4. Egenskapskällor... 25 4.5. Tjänsteagenten... 26 4.5.1. Registrera lyssnare för kortläsare i Java... 28 4.5.2. Registrera lyssnare för kortläsare i.net... 28 4.6. Webbtjänstegränssnitt... 29 4.7. Autentisering... 30 4.7.1. Autentisering från lokalt exekverande klient... 30 4.7.2. Autentisering från webbklient... 32 5. Loggtjänsten... 33 5.1. Inledning... 33 5.2. Applikationens ansvar... 34 5.3. Tjänsteagenten... 35 5.3.1. Logga mot loggagenten i Java... 35 5.3.2. Logga mot loggagenten i.net... 36 5.4. Webbtjänstegränssnitt... 36 6. Åtkomstkontrolltjänsten... 36 6.1. Inledning... 36 6.2. XACML protokollens användning av BIF... 38 6.3. Mönster för åtkomstkontroll... 41 6.3.1. Resurser... 42 6.3.2. Resurser Java... 43 6.3.3. Resurser.NET... 44 6.3.4. Åtaganden... 45 6.3.5. Hantering av åtaganden med Java... 46 6.3.6. Hantering av åtaganden med.net... 47 6.4. Tjänsteagenten & webbtjänstegränssnitt... 48 6.4.1. Tjänsteagenten kodexempel med Java... 49 6.4.2. Tjänsteagenten kodexempel med.net... 52 6.5. Applikationens ansvar... 55 6.6. Åtkomstkontroll... 56 6.6.1. Flöde över åtkomstkontroll... 56 2

7. Samtyckestjänsten... 59 7.1. Inledning... 59 7.2. Webbtjänstegränssnitt... 61 7.2.1. Registrera samtycke via webbtjänstegränssnittet i Java... 62 7.2.2. Registrera samtycke via webbtjänstegränssnittet i.net... 63 8. Vårdrelationstjänsten... 65 8.1. Inledning... 65 8.2. Webbtjänstegränssnitt... 66 9. Utlämnandetjänsten... 67 9.1. Inledning... 67 9.2. Webbtjänstegränssnitt... 69 9.3. Beskrivning av utlämnandeflöde... 70 9.3.1. Sekvensdiagram över utlämnandeflöde... 71 10. Säker kontexttjänsten... 73 10.1. Inledning... 73 10.2. Tjänsteagenten & webbtjänstegränssnitt... 74 10.2.1. Implementeringsexempel... 75 10.2.2. Tjänsteagenten kodexempel Java... 76 10.2.3. Tjänsteagenten kodexempel.net... 76 10.2.4. Sekvensdiagram... 77 11. Notifieringstjänsten... 79 11.1. Inledning... 79 11.2. Adresserad notifiering... 79 11.2.1. Agent- och webbtjänstegränssnitt... 80 11.2.2. Adresserad notifiering i Java... 80 11.2.3. Adresserad notifiering i.net... 81 11.3. Icke adresserad notifiering... 82 11.3.1. Agentgränssnitt... 82 11.3.2. Sekvensdiagram... 82 11.3.3. Icke adresserad notifiering i Java... 83 11.3.4. Icke adresserad notifiering i.net... 84 12. Logganalystjänsten... 85 12.1. Inledning... 85 3

1. Introduktion 1.1. Inledning Välkommen till denna utbildning i BIF Bastjänster för informationsförsörjning. Utbildningen är till för dig som utvecklar vårdapplikationer som ska anslutas till IT-bastjänsterna i BIF. Utbildningen visar hur IT-bastjänsterna ska nyttjas och integreras med omgivande system. Är du osäker på din roll och hur du kommer att komma i kontakt med BIF, bör du först läsa målgruppsbeskrivningen för BIF Utbildning. För att du som utvecklare ska få ut så mycket som möjligt av denna utbildning är det bra om du först går igenom introduktionsutbildningen. Den ger en förståelse för vad BIF är och en överblick över de IT-bastjänster som ingår. Den här utbildningen består av ett antal webbseminarier som i sin tur är indelade i avsnitt. Till varje webbseminarium finns ett antal frågor. Det är inget prov, utan bara repetitionsfrågor för din egen skull. Inga resultat kommer att sparas. När du har gått igenom denna utbildning kommer du att ha god förståelse kring BIFs arkitektur och uppbyggnad och en grundläggande kunskap kring de nio IT-bastjänsterna och dess funktioner. Denna utbildning kommer att ge dig de förutsättningar du behöver för att kunna analysera och se vad du som utvecklare behöver göra för att integrera ett vårdsystem mot BIF. Autentiserings -tjänst Klient Säker kontexttjänst IT-tjänst Loggtjänst Logganalystjänst Samtyckestjänst Vårdrelationstjänst Utlämnandetjänst Notifieringstjänst Åtkomstkontrolltjänst 4

1.2. Implementering I dagens hälso- och sjukvård, med många aktörer, ständigt förändrade organisationsformer och ett utökat användande av modern teknik, ställs höga krav på att informationssäkerheten kan tillgodoses. BIF är utvecklade som ett stöd för verksamheten att uppnå informationssäkerhet avseende vårdinformation. BIF har dock i sig inget egenvärde, utan ska stå för informationssäkerhetsservice till vårdapplikationer. Det innebär att BIF ska verka men inte synas. BIF möjliggör säker informationshantering Vårdsystem Vårdsystem vårdsystem BIF server 9 Bastjänster för säker informationsöverföring Vårdinformation Vid vård av patienter inom hälso- och sjukvård ska patientjournal föras. Varje organisation, oavsett om det är en enmansorganisation eller om den har flera tusen medarbetare, har vidare ett eget ansvar för informationssäkerhet avseende vårdinformationen. BIF är delvis ett nytt sätt att tänka kring informationssäkerhet och det är ny teknik som utnyttjas. Vi ska här försöka tydliggöra vad detta innebär och vad varje organisation behöver göra i samband med införandet av BIF. Som utvecklare så blir ditt jobb att utifrån BIF SDK:n anpassa ditt vårdsystem eller applikation mot BIF och IT-bastjänsterna. 5

2. BIF Arkitektur 2.1. Inledning Det här webbseminariet handlar om arkitekturen i BIF. Du kommer att få en djupare kunskap kring hur BIF är uppbyggd vad gäller säkerhet, tjänstebaserad arkitektur och webbtjänster. En central del i BIF är egenskapsbaserad åtkomstkontroll som vi även kommer att redogöra för. Det är administratörerna som sätter upp och administrerar reglerna. Däremot är det ett förkunskapskrav att du ska ha kännedom om XACML så vi kommer inte att beröra det på djupet. Vi kommer att gå igenom olika grundläggande beståndsdelar inom BIF för att du ska kunna få en bra grund att stå på när vi sedan går in på den konceptuella beskrivningen av ITbastjänsterna. 2.2. Tjänstebaserad arkitektur BIF bygger på tjänstebaserad arkitektur SOA (Service Oriented Architecture). Principen för SOA är att tydligt urskiljbara delar med bestämda uppgifter och standardiserade gränssnitt utbyter tjänster, services, med varandra genom meddelanden. SOA är en metod och inget mål. Tjänstebaserad arkitektur SOA App. Front End Service Respository Service Bus Contract Impl. interface Business Logic Data Denna arkitektur gäller även de slutprodukter som har utvecklats inom ramen för BIF, alltså de faktiska ITbastjänsterna. På så sätt är BIF en plattform som är flexibel, förändringstålig och lämplig att bygga vidare på. Den tjänstebaserade arkitekturen säger däremot ingenting om val av teknik. Ser man utifrån ett utvecklarperspektiv, så kan vi låta affärslogik och källdata var beständiga. Det är gränssnittet utåt som ska anpassas till BIF. 6

2.3. Flexibel plattform En löst bunden SOA-arkitektur ger stor frihet för hur tjänster införs och nyttjas. Därför baseras BIF på en flexibel lättviktsarkitektur med komponentbaserad modell. I arkitekturen har man strävat efter att inte införa mer komplexitet än vad som är nödvändigt för att uppfylla de krav som ställs. De komponenter som är byggstenarna i arkitekturen har tydliga syften och har inte mer funktionalitet än vad som behövs. Integrationen med andra system sker via en SDK, Software Development Kit. SDK:n återfinns för både Java och.net. Autentiserings -tjänst Klient Säker kontexttjänst IT-tjänst Loggtjänst Logganalystjänst Samtyckestjänst Vårdrelationstjänst Utlämnandetjänst Notifieringstjänst Åtkomstkontrolltjänst 7

Arkitekturen möjliggör en stor valfrihet för exakt hur man vill sköta implementeringen av BIF, oavsett om man verkar i en centraliserad, distribuerad eller mixad miljö. Det går att implementera BIF på många olika sätt. Mer information finns i utbildningen för drift- och förvaltarpersonal. Landsting A Landsting B Kommun 1 Vårdsystem Kommun 3 Vårdsystem Vårdsystem Vårdsystem Kommun 2 BIF Server Kommun 4 BIF Server Vårdsystem Vårdsystem BIF Server BIF Server BIF Server 2.4. Säkerhet IT-bastjänsterna i BIF samverkar för att stödja informationssäker elektronisk hantering av vårdinformation. ITtjänsterna har var för sig unik funktionalitet, men det behövs full samverkan bastjänsterna emellan för att informationssäkerhet skall uppnås avseende: Tillgänglighet Åtkomlighet för behöriga Skydd för obehörig insyn Oförvanskade meddelande Spårbarhet och oavvislighet Administration av tjänsterna för BIF kommer att hanteras av BIF-ramverket för att säkerställa en hög säkerhetsnivå. Administrationen kommer även att styras och kontrolleras utifrån en resursmodell och en uppsättning regler som beskriver vad olika slags användare har rätt att göra i systemet. Alla händelser i BIF loggas. Du blir alltså ansvarig för vad som görs i BIF under tiden du är inloggad. 8

Tjänstegränssnitt Tjänstegränssnitt Fasad Tjänst Signerat meddelande IT-basjänsterna är utformade för att exponeras i öppna publika nätverk genom att innehållet i de meddelanden som skickas mellan bastjänsterna är krypterat. Dessutom måste en giltig signering följa med meddelandet för att man i mottagande tjänst ska kunna verifiera att meddelandet kom från en pålitlig källa och därmed kunna använda bastjänsten. Signeringen följer med meddelanden oavsett om det är en människa som står bakom det ursprungliga anropet eller om det är en tjänst som har anropat en bastjänst via så kallad kaskadering. När en bastjänst svarar på ett anrop så signeras returmeddelandet av tjänsten. WS-security är kommunikationsprotokollet som användas för att säkerställa en säker kommunikation mellan bastjänsterna. I och med att meddelanden är signerade åt båda håll så kan båda parter försäkra sig om att ingen förvanskning har skett. 2.5. Egenskapsbaserad åtkomstkontroll Grunden i BIF för att ta fram åtkomstbeslut är egenskapsbaserad åtkomstkontroll, så kallad Attribute Based Access Control (ABAC). De två viktigaste begreppen i egenskapsbaserad åtkomstkontroll är egenskaper och regler. Åtkomstbeslut kan grunda sig på i princip vilka säkerhetsrelevanta egenskaper som helst. Egenskaperna utgörs av fyra grupper av attribut: Aktörsegenskaper Resursegenskaper Omgivningsegenskaper Aktivitetsegenskaper I egenskapsbaserad åtkomstkontroll görs inga direkta knytningar av rättigheter till resurser, utan istället konstrueras regler som använder sig av egenskaperna. Åtkomstbeslut fattas genom att evaluera de regler som är relevanta för aktörs-, resurs- och omgivningsegenskaper. Eftersom resurser inte knyts till id eller roller, kan mycket finfördelade beslutsunderlag skapas utan att systemen blir svåradministrerade. 9

Aktivitet Läsa Skriva Resurs Patient-ID Organisation Regelverk Aktör HSA-ID Organisation Yrkestitel Omgivningsfaktorer Aktuell tid IP-nummer De regler som används skrivs enligt XACML. Applikationen Axiomatics Policy Administration som ingår i BIF används för att förenkla framtagandet av regler. Regler skrivs utifrån de egenskaper som finns angivna i förfrågan. Mer om regler hittar du i seminariet om Åtkomstkontrolltjänsten. När det gäller de fyra grupperna av egenskaper så ska de ha en tydlig förankring i verksamheten då de måste kunna användas i regelformulerandet. För aktörens egenskaper finns tre huvudområden. Identiteten är unik genom användandet av HSA-Id för vårdpersonal. Personliga egenskaper är tydliga för legitimerad personal genom legitimation och eventuell specialistkompetens. Uppdrag kan vara en eller flera av till exempel arbetsbeskrivning, organisatorisk tillhörighet och syfte. För resursegenskaper finns bland annat följande egenskaper: Resurs-Id är en unik identitet på resursen. Avser-Id är patientens identitet som personnummer, samordningsnummer eller reservnummer. Organisatorisk tillhörighet är den organisation som resursen tillhör och har samma differentiering som för aktören. Här används organisationens HSA-ID. Informationstyp är ett brett område, där ett användningsområde är att underlätta sökning av information. Tid kan det finnas flera varianter av, men där händelsetid är det som är mest verksamhetsnära. Ansvarig-id avser den aktör som är ansvarig för resursen. Skapande-Id avser den aktör som skapat själva resursen. För omgivningsegenskaper och framförallt aktivitetsegenskaper finns många fler egenskaper som är mer specifika för Hälso- och sjukvården som till exempel ordinera och beställa. 10

XACML Request context 2.6. BIF Beståndsdelar Vi ska nu gå igenom några av BIFs beståndsdelar. Det är Biljett, fasad och klientkomponent. Dessutom kommer vi även att ta upp agenter och certifikat. De tre huvudbeståndsdelarna samverkar, så att en säkerhetsmässig enhet nås. 2.6.1. Biljett (SAML-intyg) En viktig beståndsdel i säkerhetshanteringen i BIF är biljetten, det vill säga SAML-intyget. En användare autentiseras endast en gång genom så kallad Single Sign On och detta skall ske via ett SITHS-kort och tillhörande pinkod. På korten finns användarens certifikat som man identifierar sig med. Autentiseringstjänsten skapar ett SAML-intyg, en biljett 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örs till användarens klientarbetsplats. Genom uppvisandet av biljetten får användaren sedan eventuell åtkomst till andra IT-bastjänster eftersom Autentiseringstjänsten är betrodd av andra bastjänster. Autentisering Åtkomstkontroll XACML Response context Tjänstefråga (Signerad och krypterad biljett) Arbetsplatsklient IT-tjänst Tjänstegränssnitt Autentiseringsagent Fasadkomponent SAML, Security Assertion Markup language är ett standardiserat sätt att definiera och utbyta autentiserings-, attribut- och åtkomstkontrollsinformation i XML-format. SAML-specifikationen definierar inte någon ny teknologi för detta, utan utnyttjar redan befintlig teknik för att definiera ett gemensamt språk i XML. 11

SAML-standarden indelas på en övergripande nivå i fyra beståndsdelar: Security Assertion Markup Language (SAML) Profiles En delmängd av bindings, protokoll och intyg för en speciell applikation Bindings Hur SAML meddelande knyts till vanliga kommunikationsprotokoll Protocol Fråga och svarsformat för att hämta intyg Assertions Autentisering, attribut och auktorisering Användning av SAML: Tillhandahålla autentiseringsbeviset Förutsättning för Single Sign On (SSO) Samordnad identitetshantering Säker distribution av behörighetsregler Säker distribution av behörighetsbeslut Assertions: Assertions kan i detta fall lämpligen översättas med intyg eller påståenden som rör säkerhet. SAML definierar tre typer av intyg, vilka är deklarationer för en eller flera fakta knutna till en aktör. I BIF används typen egenskapsintyg (Attribute statement) som innehåller specifika egenskaper knutna till aktören som t.ex. organisationstillhörighet eller medicinsk specialitet. Request/response protocol: Dessa protokoll definierar hur SAML efterfrågar och får svar på de intyg som är knutna till aktören. De tre typerna av intyg har motsvarande tre typer av frågor. Bindings: Denna del av SAML definierar exakt hur request och respons protokollet och intygen mappar in i olika transportprotokoll som t.ex. SOAP, Simple Object Access Protocol. Profiles: Profiler anger på vilket sätt SAML intygen med hjälp av transportprotokollen kan utbytas mellan de kommunicerande parterna. Användningen av SAML används för att tillhandahålla autentiseringsbeviset, dvs biljetten. SAML stöder metoden för Single Sign On, d.v.s. att en aktör endast ska behöva logga in en gång. Med biljetten kan applikationer som startas känna av att aktören redan är inloggad. Detta kräver att applikationerna är integrerade med BIF. Samordnad identitetshantering används då SITHS-kort krävs för autentisering. Säker distribution av behörighetsregler. Det görs t.ex. genom att XACML-regler inbäddas i ett SAML påstående och definieras i SAML profilen. Säker distribution av behörighetsbeslut. XACML beslutet skickas i påståendet. 12

2.6.2. Fasadkomponent Fasadkomponenten i BIF används för att på ett smidigt och enkelt sätt ge IT-system tillgång till funktionaliteten i IT-bastjänsterna. Konsument Klientkomponent Tjänsteagent Åtkomstkontroll tjänsten Producent Tjänsteinterface Fasad ÅKT agent Loggagent Loggtjänsten Meddelande gränssnitt Programmatiskt gränssnitt Tjänstekomponent Alla meddelanden som skickas till och från BIFsäkrade tjänster passerar alltid genom fasaden och för de ITbastjänster som har agenter finns dessa i fasaden. 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 finns speciella fasader för.net och Java. 13

Tjänstegränssnitt Fasad Tjänst Signerat meddelande och biljett 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. Meddelandet förses även med insynsskydd genom kryptering med XML-Encryption enligt WS-Security. Fasaden utför dessa operationer automatiskt vilket innebär att du som utvecklare av IT-tjänster inte behöver belastas med detta. 2.6.3. Klienter 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, så kallad fet klient eller klient uppdelad på en browser och en serverdel, så kallad tunn klient. Genom en lokalt exekverande klientkomponent, kan e-id kort, certifikatshantering och biljetteknik skötas på ett uniformt sätt. Klientapplikationen kan dessutom utnyttja funktionalitet hos fasaden. Fasader hanterar signering, 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 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. 14

XACML Request context Autentisering Åtkomstkontroll XACML Response context Tjänstefråga (Signerad och krypterad biljett) Arbetsplatsklient IT-tjänst Tjänstegränssnitt Autentiseringsagent Fasadkomponent 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. 15

SAML Request(artifact) XACML Request context För att hantera inloggning i webbmiljö används SAML 2.0 Web Browser Single Sign On Profile. Autentisering Åtkomstkontroll XACML Response context SAML Response(Biljett) ssl + artifact Tjänstefråga (Signerad och krypterad biljett) Säker webbläsare Tjänstegränssnitt Klienttjänst (ex. Portlet) IT-tjänst Fasadkomponent En webbapplikation som önskar autentisera en aktör skickar aktören till autentiseringstjänstens webbgränssnitt. Efter autentisering returneras användaren till webbapplikationen tillsammans med information om hur biljett kan uthämtas. 16

2.6.4. Agenter Det är i första hand fem IT-bastjänster som du som utvecklare kommer att integrera emot i de flesta fall. Det är autentiseringstjänsten, åtkomstkontrolltjänsten, loggtjänsten, notifieringstjänsten och kontexttjänsten. Till de bastjänsterna är det framtaget hjälpklasser, så kallade agenter, som är inkorporerade i en fasad. Agentens uppgift är att effektivisera IT-bastjänstens funktion med en lokal bearbetning. Effektiviseringen kan ske med varierande grad av funktionalitet i agenten. Detaljer kring agenterna finns i respektive seminarium för varje IT-bastjänst. AuthAgent KontextAgent LoggAgent Klient Autentisering Åtkomstkontroll Samtycke Vårdrelation ÅKTAgent NotAgent LoggAgent IT-tjänst Säker kontext Logg Utlämnande Notifiering Logganalys De övriga IT-bastjänsterna har ingen agent då du som utvecklare i de flesta fall inte kommer att behöva integrera ditt IT-system direkt mot dem. Oftast är det en annan bastjänst som nyttjar de tjänsterna direkt. Skulle man vilja integrera de övriga fem bastjänsterna får man programmera mot deras webbtjänstegränssnitt. Agenterna finns för både Java och.net enligt liknande mönster och design. Tillgång till agenterna i BIF sker genom BIF-fasaden. BIF-fasaden publicerar det gränssnitt som applikationerna kan använda. Vid skapandet av en BIF-fasadinstans sker en autentisering av användaren genom att en inloggningsdialog visas där användaren kan välja certifikat och sedan inloggningsaspekt. 17

2.6.5. Certifikat Personer i hälso- och sjukvården identifierar sig med ett certifikat som bygger på Health Care Certificates (HCC) enligt SITHS-modellen. På varje SITHS-kort ska det finnas ett certifikat för varje användare. Alla webbtjänstegränssnitt får in meddelanden som är krypterade och signerade. En initial verifikation sker för att säkerställa att signaturen verkligen är gjord med den privata nyckel som certifikatet motsvarar. Gränssnittet för Web Single Sign On kräver att klienten har ett certifikat för att sätta upp tvåvägs SSL dvs Secure Socket Layer. När det är säkerställt att den som skapat meddelandet är den som certifikatet gäller så är nästa steg att säkerställa att certifikatet är pålitligt. Detta görs genom att använda PKI-komponenten. En certifikatsutgivare har alltid minst ett egenskapsvärde, vilken är det som unikt identifierar aktören. Hos certifikatutgivaren SITHS så hämtas värdet SERIALNUMBER från certifikatet och läggs in i SAML-intyget som värde till egenskapsnamnet vilket är aktörens HSA-ID. urn:carelink:bif:attrname:hsaid Det finns olika information på certifikatet, men den delmängd som man konfigurerbart kan använda som egenskapvärde är subjektets namn som för exempelvis SITHS ser ut som följande: T = Läkare, E = siths@sjukvardsradgivningen.se, SERIALNUMBER = SE165565968202-1081, G = Gunnar, SN = Gran, CN = Gunnar Gran, OU = Testavd 3, OU = Carelinks kansli, O = Carelink AB, C = se Informationen på certifikaten skall inte ses som egenskaper, utan en informationskälla för egenskapsvärden. En konfiguration för SITHS skulle kunna resultera i följande egenskaper/värden. urn:carelink:bif:attrnames:hsaid = SE165565968202-1081 urn:carelink:bif:attrnames:commonname = Gunnar Gran urn:carelink:bif:attrnames:country= SE (SERIALNUMBER) (CN) (C) 18

2.7. Webbtjänster i BIF Webbtjänster erbjuder metoder för informationssystem att samverka, utbyta information och använda varandras funktionalitet på ett enhetligt, standardiserat och säkert sätt. I grunden finns XML, med ett antal påbyggnader i form av formella standarder som SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) m fl. Det innebär ett bättre utnyttjande av befintliga system och öppnar samtidigt vägen för helt nya affärsmodeller där tjänsteutvecklare erbjuder nischkomponenter, åtkomliga via Internet och integrerbara med andra tjänster så att hela virtuella system kan byggas genom att koppla samman olika webbtjänster. Core XML XML Core Web Services SOAP MTOM WS-Addressing XML Namespace XML Infoset XML Schema Reliability WS-ReliableMessaging WS-Coordination WS-AtomicTransactions Bootstrapping WSDL WS-Policy WS-MetadataExchange Security WS-Security Policy WS-Security WS-Trust WS-SecureConversation Nu ska vi gå igenom de standarder som berör webbtjänsteutvecklingen WS-Policy används för att på ett generellt sätt beskriva vilka krav en webbtjänst ställer på en webbtjänstanvändare samt dess möjligheter. WS-Security beskriver hur signatur- och krypteringsfält läggs till i SOAP-meddelanden. Den beskriver även hur binära värden såsom X.509 certifikat och Kerbarosbiljetter läggs till i meddelandet. WS-Security garanterar end-till-end-punktsäkerhet på applikationsnivå. WS-ReliableMessaging beskriver en generisk och öppen modell för säker meddelandekommunikation. WS-Resource är en standardiserad terminologi för att beskriva samband mellan webbtjänster och resurser. I WS-Notificationstandarden ingår WS-BaseNotification, WS-BrokeredNotification och WS-Topics. Standarden specificerar ett standardiserat sätt att skicka meddelanden mellan webbtjänster. WS-Trust är en utökning till WS-Security standarden och omfattar hantering av säkerhetskreditiv samt hantering av förtroenden under en säker konversation. Alla IT-bastjänster som har ett externt gränssnitt exponeras som en eller flera webbtjänster. Webbtjänsternas gränssnitt beskrivs med WSDL och XSD då gränssnittet ska vara plattforms- och implementationsoberoende och gå att anropa från alla miljöer som har stöd för att nyttja webbtjänster. Alla webbtjänstegränssnitt som skapas exponeras via funktionalitet inom fasadkomponenten. Fasadkomponenten sköter om gemensamma operationer på ett uniformt sätt såsom Single Sign On (SSO), säkerhet och loggning. Vid ett anrop till en webbtjänst som publicerats via Fasadkomponenten säkerställs meddelandets konfidentialitet, integritet och att eventuellt SAML intyg är giltig och går att knyta till användaren. Den information om avsändaren som går att uttyda (t.ex. klientcertifikat och IP-adress) lagras temporärt kontexten för anropet medan SAML intyget lagras som ett transient gemensamt objekt. 19

2.8. Driftsättningsvy Bastjänsterna kan driftsättas både som nationella och/eller lokala instanser beroende på huvudmännens önskemål. Detta kan skilja från tjänst till tjänst. Serverdelen av BIF 1.0 går att driftsätta på Linux. Webbklient ws mysql DB BIF Server 1.0 IP: xxx.xxx.xxx.xxx OS: Linux De 9 IT-bastjänsterna BIF SDK Lokalt exekvererande klient Terracotta server TC DB Utifrån behov kan man installera flera instanser av samma IT-bastjänst på olika servrar för att t ex fördela last och öka driftsäkerheten. På varje server kommer det att finnas en gemensam del, BIF-plattform, som bl a med hjälp av Terracotta-servern används för att kommunicera mellan servrarna. Lastbärare BIF Server 1 Åtkomst Utlämnande Samtycke Vårdrelation BIF Server 2 Åtkomst Utlämnande Samtycke Vårdrelation BIF Server 3 Kontext Notifiering Autentisering Logganalys BIF Server 4 Kontext Notifiering Autentisering Logganalys BIF Server 5 Master Logg BIF Server 6 Slave Logg BIF Server 6 readonly Logg Terracotta BIF Server 7 Master Terracotta Databas BIF Server 8 Slave Terracotta Databas 20

3. BIF SDK 3.1. Inledning I detta webbseminarium kommer du att få en god kunskap kring SDK:n (Software Development Kit). För att underlätta för dem som ska skapa tjänster som nyttjar BIF funktionalitet finns en SDK i både Java och.net. Java SDK:n delas upp i tre delar: BIF SDK innehåller agenter vilka nyttjar och tillför funktionalitet ovanpå IT-bastjänsterna. BIF SDK WS tillhandahåller funktionalitet för att publicera och ansluta till webbtjänster. BIF SDK WEBAPP tillhandahåller ett skydd för webbapplikationsresurser..net SDK:n har inte samma uppdelning utan är endast en SDK. Anledningen till varför Java SDK:n är uppdelad i tre olika jar filer är att den första delen inte har några beroenden till webbtjänstespecifika 3:e parts jar:ar medan den andra delen har det. Den tredje delen tillhandahåller ett skydd för webbapplikationsresurser. För att köra BIF server och BIF SDK krävs att Java Runtime Environment 5.0 lägst uppdatering 14 finns installerad. Det gäller både Java SDK:n och.net SDK:n. 3.2. BIF SDK Java BIF SDK innehåller agenter vilka nyttjar och tillför funktionalitet ovanpå IT-bastjänsterna samt gränssnitt som används för att få tillgång till information om Aktören. Denna del finns både i Java och.net. ContextAgent NotificationAgent AuthenticationAgent BIF SDK LogAgent AuthorizationAgent Proxyfactory PublicationFactory BIF SDK WS BIF SDK WEBAPP AuthenticationFilter BIF SDK WS tillhandahåller funktionalitet för att publicera och ansluta till webbtjänster med den säkerhet BIF föreskriver. För att kunna nyttja denna del av SDK:n krävs att även jaxws-api.jar finns i användarens classpath. För publicering av bastjänstekonsumentens egna tjänster tillhandahålls ett generellt publiceringsgränssnitt (samma gränssnitt och implementation som används internt inom BIF). För att publicera Java tjänster ska gränssnittet beskrivas enligt JSR181 och JAX-WS. 21

En proxykomponentdel ingår i SDK:n och används för att skapa proxies för att ansluta mot webbtjänster med BIF säkerhet. Den proxy som skapas kan gå antingen mot en IT-bastjänst eller en egenutvecklad webbtjänst. BIF SDK WEBAPP underlättar vid utveckling av webbapplikationer mot BIF genom att den innehåller ett Autentiseringsfilter. För webbadresser som återfinns i detta filter kommer autentisering att krävas och om sessionen inte redan innehåller autentiseringsinformation sker ett SAML Artifact Resolve anrop med omdirigering till en inloggningssida för att få tag i aktörens SAML intyg. För närmare beskrivning och konfiguration av SDK:n så vill vi hänvisa till dokumentationen som följer med leveransen av BIF. BIF Server Autentiseringstjänsten genererar det SAMLintyg som måste bifogas WS anropet enligt BIFPolicy. Klientapplikation IT-bastjänst Serverapplikation Proxy IT-bastjänst IT-bastjänst BIF SDK WS BIF SDK WS WS BIFPolicyn kan t. ex. ange att anropet måste innehålla ett SAMLintyg. WS.wsdl BIF Policy WSImpl Bilden här visar befintliga applikationer som nyttjar BIF SDK. 3.3. BIF SDK.NET Gränssnittet för.net versionen av SDK:n efterliknar de API'et som finns i Java SDKn. En tredjeparts webbapplikation som ska baseras på säkerhetslösningen i BIF ska använda sig av autentiseringstillägget. Tillägget är skrivet som en ASP.NET modul och ser till att kräva en certifikatsinloggning för webbapplikationen. För.NET SDK:n finns en inkapsling av motsvarande webbtjänsttillägg för java. Det är utvecklat som en utökad bindning för anslutningspunkterna för tjänsten. Funktionaliteten bygger på att applikationen utvecklas mot ett traditionellt applikationsgränssnitt, WCF (Windows Communication Services). Gränssnittet utgör en deklarativ modell som kräver att utvecklaren måste göra en applikationskonfiguration för att använda tillägget. 22

4. Autentiseringstjänsten 4.1. Inledning I detta seminarium kommer du få goda kunskaper i hur du som utvecklare direkt kommer att integrera mot autentiseringstjänsten. Vi kommer att gå igenom tjänsten och dess agent och visa kodexempel. Vi kommer att titta närmare på inloggningsaspekter, egenskapskällor, agentens och webbtjänstegränssnittets funktioner. Dessutom kommer vi att gå igenom sekvensdiagram för feta och tunna klienter. 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. 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 Aktörer, d.v.s. Personer i hälso- och sjukvården identifierar sig med ett HCC-certifikat, Health Care Certificates enligt SITHS-modellen. På varje SITHS-kort ska det finnas ett certifikat för varje användare. De skall vara upplagda i en HSA-katalog och unikt identifierad med ett HSA-ID. Invånare autentiserar sig med en godkänd e-legitimation, ett medborgarcertifikat. Invånare behöver då inte vara registrerad eller känd sedan tidigare, men autentiseringstjänsten kan verifiera certifikatets giltighet, att certifikatet är utfärdat av betrodd instans och därmed styrka användarens identitet. Aktör 1. Logga in med SITHS-kort och certifikat Certifikat Autentiseringstjänsten 2. SAML intyget skapas med aktörens egenskaper HSA SAML Lokal DB SAML 3. SAML intyget är en förutsättning för aktörens åtkomst till information. Vårdsystem Vid autentiseringen knyts egenskaper till användaren och dennes identitet genom skapandet av ett SAML-intyg. IT-bastjänsten för autentisering försäkrar att en aktör har identifierats, autentiserats och är förknippad med vissa egenskaper genom skapandet av biljetten. 23

4.2. Applikationens ansvar Den applikation som du som utvecklare ska anpassa mot BIF har följande ansvar: Applikationen skall autentisera användaren genom att anropa authenticate() i Autentiseringsagenten. Applikationen skall logga ut användaren genom att anropa logout() i Autentiseringsagenten. 4.3. Inloggningsaspekter I BIF finns inloggningsaspekter som kan kopplas vid autentiseringen till aktören och sparas i biljetten tillsammans med aktörens egenskaper. Inloggningsaspekter är ett sätt att gruppera egenskaper för att en användare ska kunna välja olika uppsättningar av egenskaper beroende på vad syftet med inloggningen är. Det är upp till huvudmannen att bestämma om och hur man vill använda inloggningsaspekterna. Om man inte använder sig av inloggningsaspekter eller en användare saknar en aspekt hämtas användarens HSA-Id från certifikatet som enda egenskap och läggs i SAML-intyget vid inloggningen. Vid en åtkomstkontroll går åtkomstkontrolltjänsten tillbaka till autentiseringstjänsten och hämtar de ytterligare egenskaper som behövs för åtkomstkontrollen. Inloggningsaspekt 1: urn:carelink:bif:authn:1.0:aspects :businessrole Värde: Sjuksköterska Egenskaper: Egenskap 1 Egenskap 3 Egenskap 8 Egenskap 31 Egenskap 72 Egenskap 103 Autentisering HSA Egenskaper 1-100 Inloggningsaspekt 2: urn:carelink:bif:authn:1.0:aspects :businessrole Värde: Administratör Egenskaper: Egenskap 1 Egenskap 3 Egenskap 8 Egenskap 42 Egenskap 65 Egenskap 91 Egenskap 110 Lokal egenskapskälla Egenskaper 101-110 Ett sätt att använda inloggningsaspekter kan vara att man inte vill att SAML-intyget ska innehålla för många egenskaper. En aktör kan till exempel ha 100 egenskaper i HSA men vid åtkomstkontroller behöver aktören bara 10. Då kan man plocka ut dessa tio och koppla till en aspekt. Det valda aspektvärdet som används avgör, till exempel, vilken alternativ egenskapsuppsä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 egenskapsuppsättningar. En användare kan till exempel både vara 24

sjuksköterska och administratör. Användaren kan då ha olika uppsättningar av egenskaper beroende på vilken aspekt man väljer vid inloggningen. Har en användare bara en aspekt så loggas användaren automatiskt in med den uppsättning egenskaper som är kopplade till aspekten. Aspekten i sig läggs även med i SAML-intyget och kan användas som egenskap. Administration av inloggningsaspekter utförs i BIF:s webbtjänstegränssnitt. Egenskaper kopplas till aspekterna. Därefter kopplar man aktörer till aspekterna. 4.4. Egenskapskällor Autentiseringstjänsten är i sig själv en egenskapskälla där e-underskrivna användaregenskaper kan lagras. Det görs via bastjänstens administrationsgränssnitt. E-underskrifternas giltighet valideras på samma sätt som certifikat. DB Inloggningsaspekter Autentiseringstjänst Certifikat Extern egenskapskälla Lokal egenskapskälla DB HSA-katalog Administrationsgränssnitt DB Egenskaper Varje egenskapskälla har en uppsättning egenskaper som den kan tillhandahålla, i form av namn och namnrymder på dem. När ett SAML-intyg ska skapas så hämtas de egenskaper som behövs med hjälp av de egenskapskällor som då kommer i fråga. Externa egenskapskällor går att lägga till och ta bort, och det är främst en HSA-katalog som är ett krav för BIF. Det finns även egenskapskällor som tillhandahåller egenskaper utifrån information i certifikat, d.v.s. rent programmatiska egenskapskällor. Ytterligare typer av egenskapskällor går att lägga till som till exempel LDAPkatalog och databaser. Till olika typer av certifikat är det knutet vilka egenskaper som skall hämtas för dem. Därutöver så är värden för olika inloggningsaspekter knutna till uppsättningar av egenskaper. Summan av dessa är vad som sätts i en SAML-biljett vid autentisering. När autentiseringstjänsten fungerar som en egenskapskälla för åtkomstkontrolltjänsten så bifogar den i anropet vilka egenskaper som den behöver. 25

4.5. Tjänsteagenten Agenten är en hjälpklass för dig som utvecklare så applikationer enklare kan nyttja autentiseringstjänstens funktioner och hantera biljetten. Autentiseringsagenten hanterar också kommunikationen med det smarta kortet. Detta inkluderar till exempel: Val av aktuellt certifikat Initiera upplåsning av nyckel med hjälp av PIN Signera data för webservice anrop Notifiera vid uttag och insättning av det smarta kortet Vi ska nu gå igenom agentens funktioner och vad de gör: Authenticate(). Funktion för att autentisera en aktör. Logout(). Funktion för att utföra kordinerad utloggning av nuvarande aktör. Aktörens inloggningskontext raderas från agenten. isauthenticated(). Funktion för att verifiera om aktuell aktör för tillfället är autentiserad. Kontroll sker av aktörens SAML-intyg såsom giltighetstid. getassertion(). Funktion för att hämta autentiserad aktörs SAML-intyg. getidentitycertificate(). Funktion för att hämta information om aktuell autentiserad aktör i form av dess legitimeringscertifikat. getsignaturecertificate(). Funktion för att hämta information om aktuell autentiserad aktör i form av dess signeringscertifikat. setsloteventlistener(). Funktion för att registrera sig på händelser från kortläsaren, såsom insättning och uttag av kort. removesloteventlistener. Funktion för att avregistrera sig på händelser från kortläsaren. 26

Den interna hanteringen av hur inloggning hanteras kan ersättas genom att sätta en s.k. callback i BifFascadeFactory klassen. Normalt sköter BIF inloggningen genom att visa en inloggningsruta för användaren. En applikation kan välja att ersätta det befintliga användargränssnittet med ett eget gränssnitt eller t.ex. göra en automatisk inloggning som är gömd för användaren. Inloggning sker direkt när en BifFascadeFactory instans hämtas via getbiffacadeinstance(). En callback måste således sättas innan BifFacadeFactory.getBifFacadeInstance() anropas. Vi ska här titta på ett exempel i java där man kan sätta vilken dialog eller frame som är förälder till inloggningsrutorna och på så vis kunna få inloggningsrutan centrerad över angiven GUI komponent. Anropas aldrig BifFacadeFactory.setBifCallbackHandler() med någon BifCallbackHandler så kommer StandardBifCallbackHandler att användas. // Let the BifFacadeFactory create the Standard BIF Callback Handler StandardBifCallbackHandler bifcallbackhandler = BifFacadeFactory.getStandardBifCallbackHandlerInstance(); // Assign a owner bifcallbackhandler.setowner(startupframe); // Assign the callback handler, must be done before calling // BifFacadeFactory.getBifFacadeInstance BifFacadeFactory.setBifCallbackHandler(bifCallbackHandler); // Get the BifFacade final BifFacade biffacade = BifFacadeFactory.getBifFacadeInstance();... // Reassign the owner of the StandardBifCallbackHandler BifFacadeFactory.getStandardBifCallbackHandlerInstance().setOwner(subDialog); 27

4.5.1. Registrera lyssnare för kortläsare i Java Det kan underlätta att registrera en lyssnare för kortläsaren som hanterar användarens certifikat. På så sätt kan man koppla händelser till insättning och uttag av kort, t.ex. att applikationen låses när användaren tar ut sitt kort. Detta exempel är i Java. public class MyCardListener implements SlotEventListener { public void tokeninserted(collection<x509certificate> identitycertificates, Collection<X509Certificate> signaturecertificates, boolean selectedidentitycertificate) { } System.out.println("Token Inserted"); public void tokenremoved(collection<x509certificate> identitycertificates, Collection<X509Certificate> signaturecertificates, boolean selectedidentitycertificate) { } } System.out.println("Token Removed");... BifFacade biffacade = BifFacadeFactory.getBifFacadeInstance(); AuthenticationAgent authenticationagent = biffacade.getauthenticationagent(); authenticationagent.setsloteventlistener(new MyCardListener()); 4.5.2. Registrera lyssnare för kortläsare i.net Det kan underlätta att registrera en lyssnare för kortläsaren som hanterar användarens certifikat. På så sätt kan man koppla händelser till insättning och uttag av kort, t.ex. att applikationen låses när användaren tar ut sitt kort. Detta exempel är i.net. void OnTokenInserted(ICollection<X509Certificate> identitycertificates, ICollection<X509Certificate> signaturecertificates, bool selectedidentitycertificate) { Console.WriteLine("Token Inserted"); } void OnTokenRemoved(ICollection<X509Certificate> identitycertificates, ICollection<X509Certificate> signaturecertificates, bool selectedidentitycertificate) { Console.WriteLine("Token Removed"); } IAuthenticationAgent authagent = BifFacade.Instance.GetAuthenticationAgent(); // Set slot event handler authagent.tokeninserted += new SlotEventHandler(OnTokenInserted); authagent.tokenremoved += new SlotEventHandler(OnTokenRemoved); // Remove slot event handler authagent.tokeninserted -= new SlotEventHandler(OnTokenInserted); authagent.tokenremoved -= new SlotEventHandler(OnTokenRemoved); 28

4.6. Webbtjänstegränssnitt Följande funktioner tillhandahålls i webbtjänstegränssnittet. Funktionerna har olika säkerhetskrav på kommunikationskanalen. Authenticate - Funktion för att autentisera aktör med specificerade inloggningsaspekter. Funktionen kräver kommunikation över tvåvägs SSL, Secure Sockets Layer, där aktörens certifikat hämtas från SSL kopplingen. Authenticate2 - Funktion för att autentisera aktör med specificerade inloggningsaspekter. Funktionen kräver kommunikation över tvåvägs SSL, Secure Sockets Layer, där aktörens certifikat hämtas från SSL kopplingen. Denna funktion används för webbautentisering, då ett SAML-artefaktmeddelande returneras till klienten. GetAspects - Funktion för att hämta valbara inloggningsaspekter för aktuell aktör. Funktionen kräver kommunikation över tvåvägs SSL där aktörens certifikat hämtas från SSL-kopplingen. ArtifactResolve - Funktion för att hämta SAML-intyg utefter URL-kodad artefakt. Funktionen anropas endast av webbapplikationer. Funktionen kräver kommunikation över envägs SSL där aktörscertifikat inte krävs. AttributeQuery - Funktion för att hämta egenskaper för ett subjekt. Funktionen kräver kommunikation över envägs SSL (Secure Sockets Layer) där aktörscertifikat inte krävs. Logout - Funktion för att utföra kordinerad utloggning av nuvarande aktör. Aktörens inloggningskontext raderas på tjänsten och samtliga inloggningar för aktuell aktör stängs ner. Funktionen kräver kommunikation över envägs SSL (Secure Sockets Layer) där aktörscertifikat inte krävs. GetTrustedCertificates - Funktion för att hämta tjänstens samtliga betrodda certifikatsutgivare. Funktionen ställer inga säkerhetskrav på kommunikationen, då funktionen anropas före autentisering har skett. 29

4.7. Autentisering Detta är en förenklad sekvens över en autentisering. I de två nästkommande scenariona går vi mer in på djupet över autentisering från en lokalt exekverande klient och autentisering från webbklient. Förenklad autentisering Aktör Lokalt exe. klient Agenten Autentiseringstjänsten SAML Intyg Logga in () Hämta uppgifter som behövs för inloggning () Hämta förlitade certifikatsutgivare () Hämta inloggningsaspekter () Interagera med aktören för att logga in () Autentisera () Autentisera () Skapa () SAML intyg () SAML intyg () 4.7.1. Autentisering från lokalt exekverande klient Här följer ett scenario där en aktör, t ex en lokalt exekverande klient, skapar en autentiserad session för ett subjekt. Subjektet är i detta fal en fysisk person. Genom att aktören levererar subjektets identitet och signerar med ett giltigt certifikat som med säkerhet kan knytas till subjektet autentiseras denne. I detta scenario är: Aktören En applikation eller ett system Agenten Autentiseringsagenten Bastjänsten Autentiseringstjänsten 30

Aktören Agenten Bastjänsten 1 Aktören begär att autentisering ska genomföras för ett subjekt. 4 Agenten jämför listan med de betrodda certifikatsutgivarna och subjektets certifikat för legitimering. Agenten presenterar subjektets betrodda certifikat för aktören. 5 Aktören väljer 1 av de presenterade certifikaten. 8 Agenten presenterar inloggningsaspekterna för aktören. 9 Aktören väljer 0 eller flera inloggningsaspekt(er) för vidare autentiseringsbegäran. 2 Agenten begär en lista med betrodda certifikatsutgivare från bastjänsten. 3 Bastjänsten presenterar en lista med betrodda certifikatsutgivare. 6 Agenten begär en lista över aktuella inloggningsaspekter för subjektet och säkrar begäran med subjektets certifikat. Referens till agenten bifogas också. 7 Bastjänsten verifierar att certifikatet är giltigt och förlitat. Bastjänsten hämtar och presenterar valbara inloggningsaspekter för aktuellt subjekt. 10 Agenten begär referens till notifieringstjänsten via notifieringsagent. Agenten presenterar begäran om autentisering och säkrar dem med subjektets certifikat. Aktören Agenten Bastjänsten 12 Agenten mottar och lagrar autentiseringsoch egenskapsintyget. 11 Bastjänsten verifierar att certifikatet är giltigt och förlitat. Bastjänsten hämtar inloggningsaspekter. Bastjänsten validerar de valda aspekterna. Bastjänsten kontrollerar att subjektets certifikat inte redan motsvarar ett redan autentiserat subjekt. Bastjänsten sparar ner subjektets valda aspektvärden (currentvalue). Bastjänsten hämtar externa och interna egenskaper för aktuellt subjekt. Bastjänsten skapar SAML-intyget. Bastjänsten signerar autentiserings- och egenskapsintyg med bastjänstens privata nyckel. Bastjänsten lagrar autentiserings- och egenskapsintyg i databas. Bastjänsten presenterar autentiserings- och egenskapsintyget. Scenariot avslutas. 31

4.7.2. Autentisering från webbklient Det här scenariot beskriver hur en webbklient skapar en autentiserad session för ett subjekt. Genom att aktören levererar sin identitet och signerar med ett giltigt certifikat som med säkerhet kan knytas till aktören autentiseras denne. För att hantera inloggning i webbmiljö används SAML 2.0 Web Browser SSO Profile. I detta scenario är: Aktören - Fysisk person. Webb Webbläsare och/eller en webbapplikation. Bastjänsten - Autentiseringstjänsten. Aktören Webb Bastjänsten 1 Aktören initierar scenariot genom att ansluta till en skyddad webbplats och på så sätt initiera autentisering för aktören. 2 Webb kontrollerar att adressen går till skyddad resurs. 4 Webbläsaren presenterar existerande certifikat till aktören. 3 Bastjänsten svarar till Webbläsaren att klientcertifikat krävs. 5 Aktören väljer 1 av de presenterade certifikaten. 6 Aktörens webbläsare begär inloggningsaspekter för aktören och säkrar begäran med aktörens certifikat. 8 Agenten presenterar inloggningsaspekterna för aktören. 9 Aktören väljer 0 eller flera inloggningsaspekt(er) för vidare autentiseringsbegäran. 7 Bastjänsten verifierar att certifikatet är giltigt och förlitat. Bastjänsten hämtar och presenterar valbara inloggningsaspekter för aktuellt subjekt. 10 Webbapplikationen begär referens till notifieringstjänsten via notifieringsagent. Webbläsaren presenterar begäran om autentisering och säkrar dem med aktörens certifikat. Aktören Webb 11 Bastjänsten verifierar att certifikatet är giltigt och förlitat. Hämtar inloggningsaspekter för aktuellt subjekt Validerar de valda aspekterna Kontrollerar subjektets certifikat Hämtar externa och interna egenskaper för aktuell aktör. Skapar autentiserings- och egenskapsintyg Bastjänsten signerar autentiserings- och egenskapsintyg med tjänstens privata nyckel. Genererar engångsartefakt som kopplas till autentiserings- och egenskapsintyget. Bastjänsten lagrar autentiserings- och egenskapsintyget Bastjänsten omdirigerar anropet till webbapplikationens adress och bifogar engångsartefakten. Bastjänsten 14 Webbapplikationen skapar en session och associerar autentiserings- och egenskapsintyg till sessionen. Webbplatsen presenterar efterfrågad sida för aktören. 12 Webb kontrollerar att URLen går till en skyddad resurs och begär autentiserings- och egenskapsintyg baserat på engångsartefakt. 13 Bastjänsten presenterar autentiserings- och egenskapsintyg motsvarande engångsartefakt. Scenariot avslutas. 32

5. Loggtjänsten 5.1. Inledning Du kommer i detta seminarium få goda kunskaper om loggtjänsten och hur man kodar mot agenten via kodexempel. Vi kommer även att gå igenom vilka ansvar applikationer har gentemot loggtjänsten. Loggtjänsten Arbetsplatsklient Loggar paketeras via agenten. Vid ett visst antal loggpaket förs dessa över till fasaden i loggtjänsten. Paketen är seriesignerade. Logg paket Vårdtjänst Kontroll sker mot loggtyper. Loggtjänsten Tjänsten lagrar loggarna i databasen. Logg DB Tjänstegränssnitt Loggagent Fasadkomponent Loggtjänsten tar emot tidsstämplade e-underskrivna loggar från säkerhetsrelaterade händelser, exempelvis i verksamhetens system, delsystem samt BIF-tjänster. Loggtjänsten hanterar olika typer av loggar, där varje loggtyp har sitt väldefinierade innehåll. Tjänsten ger stöd för att specificera obligatoriskt och frivilligt informationsinnehåll för varje loggtyp i form av XML-schema. Loggtjänsten kontrollerar att de fält som är obligatoriska enligt XML-schemat finns med. Felaktigt innehåll utifrån specificerat XML-schema i enskild loggpost ska resultera i spårbar loggning av fel. Loggtjänsten ska fungera tillsammans med en lokal loggagent som tidstämplar och signerar logginformationen med tjänstecertifikat, för att därefter vidareförmedla loggen till loggtjänsten. Den lokala loggagenten ska under en tidsperiod ta emot loggar även om loggtjänsten är ur funktion. Detta betyder att den lokala agenten vid behov ska buffra loggar för senare överföring. Om loggtjänsten under en period inte varit tillgänglig ska överföring av buffrade loggar hanteras på ett sätt som inte överbelastar loggtjänsten. Om loggagent inte kan ta emot loggar från applikationen, till exempel om den lokala loggbuffern är full, ska felmeddelande returneras. Loggtjänstens samt loggagentens tidsangivelse ska synkroniseras mot en gemensam källa. För snabbare söktider mot databasen ska ske är det möjligt att indexera respektive loggkategori enligt hur loggmeddelandet är uppbyggt. I administrationsgränssnittet är det även möjligt att utföra validering, arkivering och gallring av hela loggpaket mellan ett datumintervall. I administrationsgränssnittet är det även möjligt att söka mot databasen med xquery. 33

Loggar skyddas mot förändring och radering genom kedjad signering. Detta innebär att loggdata som signeras ska innehålla checksumma från föregående signering. Logginformationen är ofta av känslig natur, varvid denna också måste hanteras på ett säkert sätt. Här ser vi ett xsd-schema för en loggkategori. <?xml version="1.0" encoding="utf-8"?> <xs:schema targetnamespace="urn:testns" elementformdefault="qualified" xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:t="urn:testns"> <xs:element name="phonebook"> <xs:complextype> <xs:sequence> <xs:element name="name" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="first" type="xs:string" /> <xs:element name="last" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="phone" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="type" type="xs:string" /> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Innan loggning måste en loggkategori skapas i administrationsgränssnittet och eventuellt lägga till ett schema som loggmeddelande ska valideras mot för att säkerställa strukturen på loggmeddelandet. Detta för att underlätta att söka mot en loggkategori. 5.2. Applikationens ansvar Den applikation som du som utvecklare ska anpassa mot BIF har följande ansvar: Applikationen ska använda loggtjänsten för loggning. Applikationen skall ange ett XML schema som ska användas för validering av dess loggmeddelande. Dessa läggs till genom att skapa en ny loggkategori. Applikationen skall ange en identifierare som unikt identifierar applikationen i systemet. Identifieraren sätts på loggagenten och skall ske innan loggning sker. Rekommendation: Ange klassnamnet som unik identifierare. Applikationen skall ange aktuell miljö (testindicator) till loggagenten. Miljö kan vara TEST, DEBUG eller PRODUCTION, och måste anges innan loggning sker. Applikationen skall hantera att loggagenten inte kan ta emot fler loggmeddelanden. Loggagenten slänger ett BIFLogBufferFullException i detta fall. 34

5.3. Tjänsteagenten Den lokala loggagenten tar emot loggar även om loggtjänsten är ur funktion. Detta betyder att den lokala agenten vid behov buffrar loggar för senare överföring. Om loggtjänsten under en period inte varit tillgänglig sker överföringen av buffrade loggar på ett sätt som inte överbelastar loggtjänsten. Om loggagent inte kan ta emot loggar från applikationen, till exempel om den lokala loggbuffern är full, returneras ett felmeddelande. De funktioner som loggagenten har är följande: Log Funktionen tar emot ett loggmeddelande och skickar det vidare till loggtjänsten för att sparas persistent. Då ett meddelande tas emot signeras det och läggs på en temporär kö. När ett visst konfigurerat antal meddelanden finns på temporära kön kontrolleras signaturen på dessa och paketeras ihop för att signeras och skickas till loggtjänsten. setapplicationid - Funktionen tar emot ett HSA-id som identifierar vilken applikation som agenten avser. Om HSA-id saknas, kan ett exempel vara att använda namnet på vård- eller IT-bastjänsten i fråga. ID som sätts sparas för att förenkla logganropet. settestindicator - Funktionen tar emot en flagga som anger vilken status meddelandena som loggas via agenten skall ha. Flaggan behöver inte sättas på agenten, om ingen flagga satts används statusen PRODUCTION. 5.3.1. Logga mot loggagenten i Java Nu ska vi titta på ett exempel på loggning mot loggagenten steg för steg i Java: Först skapar vi en agent genom BIF-fasaden: BifFacade biffacade = BifFacadeFactory.getBifFacadeInstance(); LogAgent logagent = biffacade.getlogagent(); Sätt applikationsid för loggande applikation och typ av miljö för aktuell loggning: logagent.setapplicationid( HSA12345 ); logagent.settestindicator(testindicator.test); Skapa loggmeddelande som valideras mot xsd-schema och logga mot agenten: DocumentBuilder db; try { db = this.documentbuilderfactory.newdocumentbuilder(); } catch (ParserConfigurationException e1) { throw new RuntimeException(e1); } Document newphonebookdocument = db.newdocument(); Element phonebook = newphonebookdocument.createelementns("urn:testns","t:phonebook"); newphonebookdocument.appendchild(phonebook); phonebook.setattributens(xmlconstants.xmlns_attribute_ns_uri, XMLConstants.XMLNS_ATTRIBUTE + ":" + "t", "urn:testns"); Element nameelement = newphonebookdocument.createelementns("urn:testns", "t:name"); phonebook.appendchild(nameelement); Element firstelement = newphonebookdocument.createelementns("urn:testns", "t:first"); nameelement.appendchild(firstelement); firstelement.appendchild(newphonebookdocument.createtextnode(string.valueof("palle" ))); Element lastelement = newphonebookdocument.createelementns("urn:testns", "t:last"); nameelement.appendchild(lastelement); lastelement.appendchild(newphonebookdocument.createtextnode(string.valueof("persson "))); 35

Element phoneelement = newphonebookdocument.createelementns("urn:testns", "t:phone"); phonebook.appendchild(phoneelement); phoneelement.appendchild(newphonebookdocument.createtextnode(string.valueof("555-555"))); Attr typeattr = newphonebookdocument.createattribute("type"); typeattr.setnodevalue("home"); phoneelement.setattributenode(typeattr); logagent.log( phonebook, Severity.ERROR, new DOMSource(phonebook)); 5.3.2. Logga mot loggagenten i.net Nu ska vi titta på ett exempel på loggning mot loggagenten steg för steg i.net: Först skapar vi en agent genom BIF-fasaden: BifFacade biffacade = BifFacade.Instance; ILogAgent logagent = biffacade.getlogagent(); Sätt applikationsid för loggande applikation och typ av miljö för aktuell loggning: logagent.applicationid = "HSA12345"; logagent.testindicator = TestIndicator.TEST; Skapa loggmeddelande som valideras mot xsd-schema och logga mot agenten: XmlDocument xml = new XmlDocument(); string phonebookxml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>" + "<t:phonebook xmlns:t=\"urn:testns\">" + "<t:name><t:first>palle</t:first>" + "<t:last>persson</t:last></t:name>" + "<t:phone type=\"home\">555-555</t:phone>" + "</t:phonebook>"; xml.loadxml(phonebookxml); logagent.log("phonebook", Severity.ERROR, xml); 5.4. Webbtjänstegränssnitt För att kommunicera med loggtjänsten via web services finns följande funktioner: Log Tar emot och lagrar en uppsättning accessloggposter (s.k. batch) där varje loggpost beskriver en loggningsvärd händelse/aktivitet. Varje batch är signerad, och signatur och batch sparas i sin helhet för att säkerställa oavvislighet. Loggbatchen är ett XML dokument samt meta data kring avsändaren. ExecuteQuery - Söker igenom loggtjänstens loggar med hjälp av en Xquery. CreateArchive - Skapar arkiv med log batchar i ett datum intervall. ValidateLog - Validerar att loggar i databasen finns och är oförändrade i ett datum intervall. RemoveLog - Tar bort loggar från databasen i ett datum intervall. RestoreArchive - Återställer loggar i databasen från det arkiv som anges som inparameter. ValidateArchive - Validerar att det arkiv som anges som inparameter är oförändrat. GetLogServiceId - Hämtar loggtjänstens Id. GetLogCategorySchema Hämtar schema för en loggkategori. 6. Åtkomstkontrolltjänsten 6.1. Inledning Åtkomstkontrolltjänsten är en av de centrala delarna av BIF. Här kommer vi att gå igenom mönster för åtkomstkontroll och resursbeskrivningar. Du kommer att få goda kunskaper i vad som krävs av dig som utvecklare vad gäller kodning mot bastjänsten genom agentens funktioner och kodexempel. Dessutom visar vi ett sekvensdiagram över en vanlig åtkomstkontrollförfrågan. 36

Åtkomstkontrolltjänsten Aktivitet Läsa Skriva Resurs Patient-ID Organisation Regelverk Aktör HSA-ID Organisation Yrkestitel Omgivningsfaktorer Aktuell tid IP-nummer Syftet med åtkomstkontrolltjänsten är att svara ja eller nej på frågor om rättigheter. Den har som uppgift att på uppdrag från andra IT-tjänster besvara frågan huruvida en aktör har rätt att komma åt en resurs och utföra en namngiven aktivitet under ett givet sammanhang. Det är alltid en IT-tjänst, till exempel ett vårdsystem som tar initiativ och anropar åtkomstkontrolltjänsten och skall tillföra bastjänsten tillräckligt med information så att tjänsten kan fullfölja sin uppgift. En åtkomstförfrågan innehåller egenskaper för den som vill utföra handlingen, för den eller de resurser som ska kontrolleras och tänkt handling som ska utföras mot resursen eller resurserna. Dessutom kan man använda sig av egenskaper för omgivningsfaktorer i åtkomstförfrågan om reglerna kräver det. För att kunna svara ja eller nej, evaluerar åtkomstkontrolltjänsten regler mot de egenskaper som gäller för aktören och efterfrågad resurs. Regelverket har sitt ursprung i de regler som gäller för den verksamhet som bedrivs. Åtkomstkontrollen bygger på XACML standarden. Gränssnittet består av ett agentgränssnitt och ett webbtjänstgränssnitt. Applikationen Axiomatics Policy Administration som ingår i BIF används för att förenkla framtagandet av regler. 37

6.2. XACML protokollens användning av BIF Regelevaluering och åtkomstkontroll kan utföras både i bastjänsten och i lokalt på klienten. Principen för hur åtkomstkontroll utförs följer dock alltid samma grundmönster. PEP Request: SAML Attribute Query Response: SAML Attribute response Autentiserings tjänsten Request: SAML Attribute Query Response: XACMLAuthz DecisionStatement PIP Response: SAML Attribute Response Request: XACMLAuthz DecisionQuery PDP Ett anrop till en åtkomstkontrollskyddad IT-tjänst passerar en grindvakt som hjälper tjänsten att avgöra om en begärd aktivitet skall utföras eller om ett resultat får returneras. Funktionen kallas PEP (Policy Enforcement Point). PEP fattar inte själv något beslut om åtkomst utan PEPs uppgift är att samla beslutsunderlag bestående av den anropande aktörens egenskaper, de begärda resursernas egenskaper samt fakta om sammanhanget i vilket anropet görs. Dessa uppgifter paketeras och överlämnas till åtkomstkontrollen som en webbtjänstfråga i formen av en XACML Request Context. Rätten till åtkomst bedöms utifrån regler som utgår ifrån aktörens egenskaper och egenskaperna för den resurs som efterfrågas. Denna funktion kallas PDP (Policy Decision Point). Åtkomstbeslutet skickas tillbaka till PEP i en XACML Response Context. Skulle PDP upptäcka att användaren saknar en egenskap som resursen kräver för åtkomst så sker en kompletterande begäran till autentiseringskontrollen. Funktionen kallas PIP (Policy Information Point). PIP skickar då en fråga till Autentiseringstjänsten som gör en kontroll i de egenskapskällor den har tillgång till efter egenskapsvärden för de tillfrågade egenskaperna för användaren. Finns kompletterande egenskapsvärden läggs de med i evalueringen av reglerna. 38

Tjänsteanrop SAML Biljett Policy Enforcement Point Policy Decision Point PEP XACML Request XACML Response PDP Åtkomstkontrolltjänst IT-Tjänst Fasaden Regler IT-tjänsten, till exempel en applikation utgör en PEP dvs. är den punkt som kommer att framtvinga ett åtkomstbeslut. Det är PEPs ansvar att samla ihop de egenskaper som behövs för att kunna göra en åtkomstkontroll. Åtkomstkontrolltjänsten verkar som en PDP som fattar åtkomstbeslutet. Alla regelsamlingar och regler finns lagrade i åtkomstkontrolltjänsten och med hjälp av dessa och egenskaperna från PEP fattas åtkomstbeslut. Tjänsteanrop SAML Biljett Policy Enforcement Point Regler PDP PEP IT-Tjänst Policy Decision Point 39

Prestandan vid regelevalueringen kan snabbas upp genom att utföras lokalt hos klienten och på så vis undvika anrop över webbtjänstegränser. Normalfallet är att endast åtkomstkontrolltjänstens agent ligger på klientsidan och att åtkomstbegäran skickas över till åtkomstkontrolltjänsten via dess webbtjänstegränssnitt för att evalueras. Om regelevalueringen sker lokalt kommer även en åtkomstkontrolltjänst att ligga på klientens sida och då hämtas den aktuella regeluppsättningen via notifiering från dess förälder på serversidan. PDP Åtkomst begäran Åtkomstkontrolltjänst Regler PDP Regler PDP Regler Åtkomstkontrolltjänst Åtkomstkontrolltjänst Flera åtkomstkontrolltjänster kan kopplas ihop i ett nätverk. Exempelvis kan flera bastjänster konfigureras till att bilda en hierarkisk struktur. En underliggande bastjänst blir notifierad av dess förälder när förälderns regeluppsättning har blivit ändrad, och hämtar förälderns regler från dess databas. Den underliggande bastjänsten evaluerar både dess egna och förälderns regeluppsättning. 40

6.3. Mönster för åtkomstkontroll Åtkomstkontrollbegäran består av ett antal egenskaper som grupperas i kategorier. Det finns fyra fördefinierade kategorier; för aktör, resurs, aktivitet och omgivningsfaktorer. Dessutom kan man lägga till eventuella applikationsspecifika egenskaper som behövs för att utföra en åtkomstkontroll. Åtkomst kan endast styras mot de egenskaper som finns med i begäran. Aktivitet Read Regel Resurs pnr=2 0000102030405 OrganizationHSAIdentity=232 1000255-023456 Organization=LandstingA SpecialityCode=ortopedi ID= 2321000255-R456 Aktör: hsatitle=läkare, sjuksköterska Organization=LandstingA SpecialityCode=ortopedi Resurs: Organization=LandstingA SpecialityCode=ortopedi Aktivitet: Read, write Begin: 20090101 Aktör hsaidentity=191112131415 hsatitle=läkare organizationhsaidentity=232 1000255-023456 Organization=landstingA SpecialityCode=Ortopedi Omgivningsfaktorer Aktören anger vem som vill utföra handlingen mot den eller de resurser som finns angivna i begäran. Egenskaperna för aktören eller subjektet hämtas från SAML intyget och sparas enklast i begäran via ett anrop till agentens gränssnitt. Resursen anger den eller de resurser som ska åtkomstkontrolleras. Exempel på resurser kan vara en patients journal, en viss del inom en patients journal, eller ett specifikt applikationssystem. Det är upp till applikationsutvecklare att definiera de resurser som skall åtkomstkontrolleras. De typer av resurser som stöds är; enskilda resurser, hierarkiska resurser och applikationsspecifika resurser. Applikationsspecifika resurser kräver att applikationen har registrerat ett XML-schema i åtkomstkontrollen. Åtkomstkontrollen verifierar att resursinnehållet följer den resursmodell vilket anges i XML-schemat. Aktivitet anger den handling som aktören vill utföra på den, eller de resurser, som finns angivna i begäran. Det kan bara finnas en aktivitet i varje begäran. Aktiviteten bestäms av varje applikation. Omgivningsfaktorer kan anges i begäran som miljöegenskaper. Det kan exempelvis vara IP-adressen på det anropande systemet och tidpunkt för begäran. Ytterligare egenskaper som kan behövas kan anges i åtkomstkontrollbegäran. Endast de egenskaper som finns med i åtkomstkontrollbegäran kan användas och kontrolleras av de regler som styr åtkomsten. Det går även att skriva åtkomstregler för egenskaper som inte finns med i åtkomstkontrollbegäran vilket leder till att Åtkomstkontrolltjänsten försöker hämta dessa egenskaper från autentiseringstjänsten och de egenskapskällor som finns definierade i där. Om en egenskap inte kan hittas i åtkomstkontrollbegäran eller hämtas från en egenskapskälla kommer resultatet alltid bli ett Nekande svar på åtkomstkontrollbegäran. 41

6.3.1. Resurser Resurser kan beskrivas på olika sätt beroende på om resursinformationen är en samling egenskaper eller innehåller en hierarkisk struktur. BIF kan hantera olika typer av resursmodeller men rekommenderat är att använda den resursmodell som SVR förespråkar för att beskriva resurser. Den stödjer en hierarkisk beskrivning av resurser. En fördel med detta förfarande är att det sker ett anrop till Agenten istället för ett per resurs vilket minskar minnesanvändningen i systemet. Det finns ingen gräns för hur många resurser som kan anges i en och samma begäran. Varje resurs i en lista anges som en separat resurs i begäran. De resurser man vill ha åtkomstkontrollerade pekas ut av ett XPath uttryck, vilket antingen kan peka ut en enskild resurs, en lista av resurser eller en hierarki av resurser. <rm:bifresource xmlns:rm="urn:carelink:bif:resource-model:0.1" schemalocation="urn:carelink:bif:resource-model:0.1 bif-model.0.1.xsd"> <rm:entitet entitettyp="und"> <rm:part agentid="se12345-1234" agenttyp="org" orgnamn="carelink AB" parttyp="aga" verksamhetskod="15"/> <rm:part agentid="19121212-1212" agenttyp="pers" parttyp="pat"/> </rm:entitet> <rm:entitet entitettyp="und"> <rm:part agentid="se12345-1234" agenttyp="org" orgnamn="carelink AB" parttyp="aga" verksamhetskod="16"/> <rm:part agentid="19121212-1212" agenttyp="pers" parttyp="pat"/> </rm:entitet> <rm:entitet entitettyp="und"> <rm:part agentid="se45678-9876" agenttyp="org" orgnamn="jll" parttyp="aga" verksamhetskod="16"/> <rm:part agentid="19121212-1212" agenttyp="pers" parttyp="pat"/> </rm:entitet> </rm:bifresource> Följande exempel kan t.ex. visa på hur en läkare försöker få tillgång till tre undersökningsresultat som gäller en viss specifik patient. Applikationen som läkaren använder för att söka efter dessa resultat kontrollerar om läkaren får tillgång till dessa resultat genom att skapa en åtkomstförfråga enligt den resursmodell som SVR förespråkar. I åtkomstförfrågan kan dessa resultat anges enligt exemplet som visas. 42

6.3.2. Resurser Java Åtkomstförfrågan innehåller det metadata som beskriver de undersökningsresultat som hittades; dess ägare samt vilken patient det handlar om. De metadata som ska med i åtkomstförfrågan kan skapas med DOM XML objekt eller t.ex. med JAXB klasser som genererats från resursschemat från SVR. Den resulterande metadata informationen läggs in i åtkomstförfrågan med metoden ResourceAttributes.setContent() Create the resource attributes ResourceAttributes resourceattributes = request.addresourceattributes(); Create the resource content from the data we want to control accesss to ResourceAttributes resourceattributes = request.addresourceattributes(); Add our resource content to the request resourceattributes.setcontent(collections.<node>singletonlist(resourceelement)); De resurser som applikationen vill ska åtkomstkontrolleras måste även anges med ett XPath uttryck i förfrågan. XPath uttrycket kan peka ut en enskild resurs, en lista, eller en hierarki av resurser. Observera att XPathuttrycket måste innehålla samma namnrymd (namespace) som finns i resursmodellen. XPath uttrycket får heller inte börja med en "/" enligt XACML standarden. Följande XPath pekar ut alla resurser: rm:bifresource/rm:entitet Följande XPath uttryck pekar ut resursen från JLL: rm:bifresource/rm:entitet[@entitettyp="und"]/rm:part[@orgnamn="jll"] I följande XPath pekas alla verksamheter med kod 15 inom Carelink AB: rm:bifresource/rm:entitet[@entitettyp="und"]/rm:part[@orgnamn="carelink AB" and @verksamhetskod="15"] XPath uttrycket tillsammans med korrekt namnrymd alias läggs in i åtkomstförfrågan med följande kod i Java: resourceattributes.addattribute("urn:oasis:names:tc:xacml:1.0:resource:scope").addstringattributevalue("xpath-expression"); resourceattributes.createresourceid().addxpathexpressionattributevalue( "rm:bifresource/rm:entitet", Collections.singletonMap("rm", "urn:carelink:bif:resource-model:0.1")); Det svar som fås från Åtkomstkontrolltjänsten kommer att bli lika många som antalet noder som XPath-uttrycket pekar ut. Varje svar innehåller ett XPath som exakt pekar ut den nod i resursen som svaret gället. Det är viktigt att använda det returnerande XPath-uttrycket för att hämta ut rätt resurs då ingen garanti ges för ordningen på åtkomstkontrollsvaren. 43

6.3.3. Resurser.NET Åtkomstförfrågan innehåller det metadata som beskriver de undersökningsresultat som hittades; dess ägare samt vilken patient det handlar om. De metadata som ska med i åtkomstförfrågan kan skapas med DOM XML objekt eller t.ex. med JAXB klasser som genererats från resursschemat från SVR. Den resulterande metadata informationen läggs in i åtkomstförfrågan med metoden ResourceAttributes.setContent() Create the resource attributes IResourceAttributes resourceattributes = request.addresourceattributes(); Create the resource content from the data we want to control accesss to XmlElement resourceelement = this.createresourcecontent(...); Add our resource content to the request resourceattributes.content = new List<XmlNode> { resourceelement }; De resurser som applikationen vill ska åtkomstkontrolleras måste även anges med ett XPath uttryck i förfrågan. XPath uttrycket kan peka ut en enskild resurs, en lista, eller en hierarki av resurser. Observera att XPath utrycket måste innehålla samma namnrymd (namespace) som finns i resursmodellen. XPath uttrycket får heller inte börja med en "/" enligt XACML standarden. Följande XPath pekar ut alla resurser: rm:bifresource/rm:entitet Följande XPath uttryck pekar ut resursen från JLL: rm:bifresource/rm:entitet[@entitettyp="und"]/rm:part[@orgnamn="jll"] I följande XPath pekas alla verksamheter med kod 15 inom Carelink AB: rm:bifresource/rm:entitet[@entitettyp="und"]/rm:part[@orgnamn="carelink AB" and @verksamhetskod="15"] XPath uttrycket tillsammans med korrekt namnrymd alias läggs in i åtkomstförfrågan med följande kod i Java: resourceattributes.addattribute("urn:oasis:names:tc:xacml:1.0:resource:scope").addstringattributevalue("xpath-expression"); resourceattributes.createresourceid().addxpathexpressionattributevalue( "rm:bifresource/rm:entitet", new Dictionary<string, string> { { "rm", "urn:carelink:bif:resource-model:0.1" } }); Det svar som fås från Åtkomstkontrolltjänsten kommer att bli lika många som antalet noder som XPath-uttrycket pekar ut. Varje svar innehåller ett XPath som exakt pekar ut den nod i resursen som svaret gället. Det är viktigt att använda det returnerande XPath-uttrycket för att hämta ut rätt resurs då ingen garanti ges för ordningen på åtkomstkontrollsvaren. 44

6.3.4. Åtaganden Ett åtkomstbeslut kan åtföljas av ett eller flera åtaganden som måste utföras av applikationen innan åtkomstbeslutet kan träda i kraft. Ett åtagande kan exempelvis vara att logga ett visst meddelande eller att skicka ett SMS till en tredje instans etc. Åtaganden skrivs in i reglerna som styr åtkomstbeslutet. Det krävs således en kommunikation mellan dig som utvecklare av applikationen och regelskrivaren vilka åtaganden som måste stödjas av applikationen. Det innebär att åtagandets identifierare (ObligationId) och dess egenskaper bestäms utanför Åtkomstkontrollen. Vad du ser är ett exempel på ett åtagande som skapas i Axiomatics Policy Administration. Ett åtagande måste utföras om dess effekt och svaret på åtkomstbeslutet överensstämmer. Skulle ett åtagande returneras som applikation inte kan hantera måste applikationen logga detta och neka åtkomst. 45

6.3.5. Hantering av åtaganden med Java Nu ska vi se ett exempel på hur ett enkelt åtagande kan hanteras med Java. final String OBLIGATION_SEND_EMAIL = "urn:carelink:bif:obligation:send-email"; final String EMAIL_ADDRESS = "urn:carelink:bif:obligation:attribute-id:emailaddress"; // Check if any obligations apply for (Obligation obligation : evalresult.getobligations()) { boolean applyobligation = false; if (Effect.PERMIT.equals(obligation.getFulfillOn()) && Decision.PERMIT.equals(evalResult.getDecision())) { applyobligation = true; } else if (Effect.DENY.equals(obligation.getFulfillOn()) && Decision.DENY.equals(evalResult.getDecision())) { } applyobligation = true; if (applyobligation) { if (OBLIGATION_SEND_EMAIL.equals(obligation.getObligationId())) { // this obligation should only have one attribute and that is // the email address assert (obligation.getattributeassignments().get(0).getattributeid().equalsignorecase(email_address)); String emailaddr = obligation.getattributeassignments().get(0).getvalueasstring(); sendemail(emailaddr, "write a subject here"); } } } else { // Unsupported obligation } Först kollar vi av om det är några åtaganden som gäller. Dessutom kollar vi vad effekten av åtagandet är. När det är gjort så kollar vi av om åtagandet innebär att skicka ett e-mail. Detta vet vi som utvecklare då detta måste regleras innan med regelskrivaren i åtkomstkontrolltjänsten. Stämmer detta så skickar vi iväg mailet. 46

6.3.6. Hantering av åtaganden med.net Nu ska vi se ett exempel på hur ett enkelt åtagande kan hanteras med.net. const string OBLIGATION_SEND_EMAIL = "urn:carelink:bif:obligation:send-email"; const string EMAIL_ADDRESS = "urn:carelink:bif:obligation:attribute-id:emailaddress"; // Check if any obligations apply foreach(iobligation obligation in evalresult.obligations) { bool applyobligation = false; if(effect.permit.equals(obligation.fulfillon) && Decision.PERMIT.Equals(evalResult.Decision)) { applyobligation = true; } else if(effect.deny.equals(obligation.fulfillon) && Decision.DENY.Equals(evalResult.Decision)) { applyobligation = true; } if(applyobligation) { if(obligation_send_email.equals(obligation.obligationid)) { // This obligation should only have one attribute and that is // the email address if(obligation.attributeassignments.count > 0 && obligation.attributeassignments[0].attributeid.equals(email_address)) { string emailaddr = obligation.attributeassignments[0].valueasstring; } SendEmail(emailAddr, "Write a subject here"); } } } else { // Unsupported obligation } Först kollar vi av om det är några åtaganden som gäller. Dessutom kollar vi vad effekten av åtagandet är. När det är gjort så kollar vi av om åtagandet innebär att skicka ett e-mail. Detta vet vi som utvecklare då detta måste regleras innan med regelskrivaren i åtkomstkontrolltjänsten. Stämmer detta så skickar vi iväg mailet. 47

6.4. Tjänsteagenten & webbtjänstegränssnitt Den enda publika funktion som åtkomstkontrollagenten tillhandahåller är evaluate(). Funktionen som utifrån inkomna egenskaper på användare och efterfrågad resurs samt regler i åtkomstkontrolltjänsten utför en regelevaluering och ett åtkomstbeslut returneras. För att utföra en åtkomstkontroll behövs ett Request objekt som innehåller de egenskaper som behövs för att kunna evaluera regeln. Request objektet byggs upp med hjälp av de metoder som återfinns i de gränssnitt som fås från Request objektet. Egenskaper för användaren (Subject), den resurs som begärs (Resurs), åtgärden som avses (Action) och sammanhanget (Environment) anges i begäran. För att kommunicera med åtkomstkontrolltjänsten via web services finns följande två funktioner: EvaluateXACML20 - Funktion som utifrån inkomna egenskaper på användare och efterfrågad resurs samt regler i åtkomstkontrolltjänsten utför en regelevaluering och ett åtkomstbeslut returneras. Inparametrar följer XACML 2.0 standarden. EvaluateXACML30 Funktionen fungerar likt ovan nämnda men som följer XACML 3.0 standarden. Vid användningen av webbtjänstgränssnittet krävs att applikationen själv lägger in egenskaperna för subjektet enligt XACML formatet. 48

6.4.1. Tjänsteagenten kodexempel med Java Nu ska vi steg för steg visa på hur en åtkomstkontroll av en enskild resurs görs i Java genom att använda oss av agentens gränssnitt. // Get a BifFascade instance BifFascade biffasacade = BifFasacadeFactory.getBifFasacadeInstance(); // Get the authorization agent AuthorizationAgent authorizationagent = biffasacade.getauthorizationagent(); // Create the request Request request = authorizationagent.createrequest(); // Add subject SubjectAttributes subjectperson = request.addaccesssubjectattributes(); // Adds the attributes from the SAML assertion subjectperson.addauthenticatedsubjectattributes(); // Add the resource final String RESOURCE_ID = "urn:com:virtual:department:patient:journal"; final String PATIENT_JOURNAL_ID = "urn:com:virtual:department:patient:journal:id"; ResourceAttributes resource = request.addresourceattributes(); resource.createresourceid().addstringattributevalue(resource_id); resource.addattribute(patient_journal_id).addstringattributevalue("journal-abc-123"); // Add requested action ActionAttributes action = request.addactionattributes(); action.createactionid().addstringattributevalue("read"); // Perform the authorization request Response response = request.evaluate(); Det första vi ska göra är att skapa en Agent genom BIF fasaden. Sedan skapar vi en åtkomstkontrollbegäran genom funktionen createrequest. Därefter måste vi ange egenskaperna för det subjekt som vill utföra handlingen. Metoden addauthenticatedsubjectattributes() lägger in alla egenskaper som finns angivna i SAML-intyget i begäran. Ytterligare egenskaper kan läggas till via andra metoder i klassen SubjectAttributes. Dessutom måste vi tala om vilken resurs vi önskar åtkomst till. I detta exempel gäller det en patientjournal. Sedan anger vi den handling som ska utföras. Nu vill vi läsa i journalen. Därefter utför vi åtkomstkontrollen genom funktionen evaluate. 49

Sist kontrollerar vi åtkomstbesluten för varje resurs och utför de åtaganden som finns innan åtkomstbeslutet utförs: // We have one resource only so we only get one result back Result evalresult = response.getresults().get(0); final String STATUS_OK = "urn:oasis:names:tc:xacml:1.0:status:ok"; // Check if the request could be evaluated if (STATUS_OK.equals(evalResult.getStatus().getStatusCode().getValue())) { // Check if any obligations apply for (Obligation obligation : evalresult.getobligations()) { boolean applyobligation = false; if (Effect.PERMIT.equals(obligation.getFulfillOn()) && Decision.PERMIT.equals(evalResult.getDecision())) { applyobligation = true; } else if (Effect.DENY.equals(obligation.getFulfillOn()) && Decision.DENY.equals(evalResult.getDecision())) { applyobligation = true; } if (applyobligation) { if (OBLIGATION_SEND_EMAIL.equals(obligation.getObligationId())) { // This obligation have one attribute only and that is the email address assert (obligation.getattributeassignments().get(0).getattributeid().equalsignorecase(attribute_id_email_address)); String emailaddr = obligation.getattributeassignments().get(0).getvalueasstring(); sendemail(emailaddr, "some information here"); } else { // Unsupported obligation. According to the recommendation this should result in DENY } } } // Evaluate if access is denied or permitted Det första som kontrolleras om en applikation ska få åtkomst om beslutet anger att statuskoden är okey. Det vill säga om det gick att göra en åtkomstkontroll i överhuvudtaget. Sedan kollar vi om det finns något åtagande att ta hand om. Nu ska vi ta hand om själva beslutet. Nu ska vi ta hand om själva beslutet. 50

Nu ska vi ta hand om själva beslutet. // We have one resource only so we only get one result back Result evalresult = response.getresults().get(0); final String STATUS_OK = "urn:oasis:names:tc:xacml:1.0:status:ok"; // Check if the request could be evaluated if (STATUS_OK.equals(evalResult.getStatus().getStatusCode().getValue())) { // Check if any obligations apply //( ) // Evaluate if access is denied or permitted if (Decision.PERMIT.equals(evalResult.getDecision())) { System.out.println("ACCESS GRANTED to " + evalresult.getresourceid()); } else if (Decision.INDETERMINATE.equals(evalResult.getDecision())) { System.out.println("ACCESS CHECK CANNOT BE DETERMINED for " + evalresult.getresourceid()); } else if (Decision.NOT_APPLICABLE.equals(evalResult.getDecision())) { System.out.println("ACCESS CHECK NOT APPLICABLE for " + evalresult.getresourceid()); } else { System.out.println("ACCESS DENIED to " + evalresult.getresourceid()); } } else { System.out.println("EVALUATION FAILED for " + evalresult.getresourceid()); } Om beslutet är PERMIT ska åtkomst ges. Är beslutet DENY ska åtkomst nekas. Är beslutet INDETERMINATE kan inte ett beslut ges utifrån den samling av egenskaper som fanns. Är beslutet NOT_APPLICABLE var begäran inte giltig för den resurstypen. 51

6.4.2. Tjänsteagenten kodexempel med.net Nu ska vi steg för steg visa på hur en åtkomstkontroll av en enskild resurs görs i.net genom att använda oss av agentens gränssnitt. // Get a BifFascade instance BifFascade biffascade = BifFascadeFactory.BifFascadeInstance; // Get the authorization agent IAuthorizationAgent authorizationagent = biffascade.getauthorizationagent(); // Create the request IRequest request = authorizationagent.createrequest(); // Add subject ISubjectAttributes subjectperson = request.addaccesssubjectattributes(); // Adds the attributes from the SAML assertion subjectperson.addauthenticatedsubjectattributes(); // Add the resource const string RESOURCE_ID = "urn:com:virtual:department:patient:journal"; const string PATIENT_JOURNAL_ID = "urn:com:virtual:department:patient:journal:id"; IResourceAttributes resource = request.addresourceattributes(); resource.createresourceid().addstringattributevalue(resource_id); resource.addattribute(patient_journal_id).addstringattributevalue("journal-abc-123"); // Add requested action IActionAttributes action = request.addactionattributes(); action.createactionid().addstringattributevalue("read"); // Perform the authorization request IResponse response = request.evaluate(); Det första vi ska göra är att skapa en Agent genom BIF fasaden. Sedan skapar vi en åtkomstkontrollbegäran genom funktionen createrequest. Därefter måste vi ange egenskaperna för det subjektet som vill utföra handlingen. Metoden addauthenticatedsubjectattributes() lägger in alla egenskaper som finns angivna i SAMLintyget i begäran. Ytterligare egenskaper kan läggas till via andra metoder i klassen SubjectAttributes. Dessutom måste vi tala om vilken resurs vi önskar åtkomst till. I detta exempel gäller det en patientjournal. Sedan anger vi den handling som ska utföras. Nu vill vi läsa i journalen. Därefter utför vi åtkomstkontrollen genom funktionen evaluate. 52

Sist kontrollerar vi åtkomstbesluten för varje resurs och utför de åtaganden som finns innan åtkomstbeslutet utförs: // Check if any obligations apply foreach (IObligation obligation in evalresult.obligations) { bool applyobligation = false; if (obligation.fulfillon == Effect.PERMIT && evalresult.decision == Decision.PERMIT) { applyobligation = true; } else if (obligation.fulfillon == Effect.DENY && evalresult.decision == Decision.DENY) { applyobligation = true; } if (applyobligation) { if (obligation.obligationid == OBLIGATION_SEND_EMAIL) { // This obligation have one attribute only and that is // the email address assert(obligation.attributeassignments[0]. AttributeId.ToLower() == ATTRIBUTE_ID_EMAIL_ADDRESS); string emailaddr = obligation.attributeassignments[0].valueasstring; sendemail(emailaddr, "some information here"); } else { // Unsupported obligation // According to the recommendation this should result in DENY } } } Det första som kontrolleras om en applikation ska få åtkomst om beslutet anger att statuskoden är okey. Det vill säga om det gick att göra en åtkomstkontroll i överhuvudtaget. Sedan kollar vi om det finns något åtagande att ta hand om. 53

Nu ska vi ta hand om själva beslutet: // Evaluate if access is denied or permitted if (evalresult.decision == Decision.PERMIT) { Console.WriteLine("ACCESS GRANTED to " + evalresult.resourceid); } else if (evalresult.decision == Decision.INDETERMINATE) { Console.WriteLine("ACCESS CHECK CANNOT BE DETERMINED for " + evalresult.resourceid); } else if (evalresult.decision == Decision.NOT_APPLICABLE) { Console.WriteLine("ACCESS CHECK NOT APPLICABLE for " + evalresult.resourceid); } else { Console.WriteLine("ACCESS DENIED to " + evalresult.resourceid); } } else { Console.WriteLine("EVALUATION FAILED for " + evalresult.resourceid); } Om beslutet är PERMIT ska åtkomst ges. Är beslutet DENY ska åtkomst nekas. Är beslutet INDETERMINATE kan inte ett beslut ges utifrån den samling av egenskaper som fanns. Är beslutet NOT_APPLICABLE var begäran inte giltig för den resurstypen. 54

6.5. Applikationens ansvar Den applikation som du som utvecklare ska anpassa mot BIF har följande ansvar: Applikationen skall använda Åtkomstkontrollen för all kontroll av åtkomst i systemet. Applikationen skall tillföra den information i åtkomstbegäran som behövs för att Åtkomstkontrollen skall kunna utföra en åtkomstkontroll. Applikationen skall utföra de åtkomstbeslut som returneras: Åtkomst skall nekas om statuskoden i åtkomstbeslutet skiljer sig från "ok". Åtkomst skall nekas om åtkomstbeslutet är Not applicable. Åtkomst skall nekas om åtkomstbeslutet är Indeterminable. Applikationen skall utföra de åtaganden som eventuellt returneras tillsammans med åtkomstbeslutet. Om applikationen inte förstår ett åtagande skall åtkomst nekas. Sedan finns några rekommendationer att ta ställning till: Applikationens egna egenskapsnamn och andra identifierare bör följa URI- eller URN-formatet för att skapa en unik identifierare i systemet. Applikationen skall tillhandahålla ett XML-schema för varje resursmodell som är specifik för applikationen. XML-schemat kan registreras i BIF via administratörsgränssnittet. BIF kommer då att verifiera inkommen begäran mot det registrerade XML-schemat och neka en begäran som inte följer XML-schemat. För att en kontroll av XML-schema ska ske måste begäran innehålla en referens till det aktuella XML-schemat genom attributet schemalocation. Applikationen ska beskriva de egenskaper och den resursmodell som används samt de åtaganden som stöds i ett dokument. Detta dokument används vid regelskrivningen och måste följas av både applikationsleverantör och regelskrivare. 55

6.6. Åtkomstkontroll Detta är en förenklad sekvens över en åtkomstkontroll. I nästa steg går vi mer in på djupet över åtkomstkontrollen. Förenklad åtkomstkontroll IT-tjänst Agenten Bastjänsten Skapa åtkomstkontrollfråga() Fyll på med uppgifter i åtkomstkontrollfrågan() Evaluera åtkomstkontrollfråga() Evaluera åtkomstkontrollfråga() Validera förfrågan() Åtkomstbeslut() Evaluera åtkomstkontrollfrågan() Åtkomstbeslut() Följ beslutet() 6.6.1. Flöde över åtkomstkontroll Detta flöde beskriver hur en Aktör, en applikation, IT-tjänst eller ett annat system, kontrollerar åtkomsten att göra en handling mot någon eller några resurser genom att skapa en åtkomstkontrollförfrågan innehållandes de egenskaper för subjekt, resurs och handling som behövs, samt hur ett åtkomstbeslut returneras av Åtkomstkontrollagenten. Subjektet i detta flöde är en fysisk person. 56

Aktören Agenten Bastjänsten 1. Aktören begär en åtkomstförfrågan från agenten. 2. Agenten presenterar en tom förfrågan till Aktören. 3. Aktören anger egenskaper för subjektet som ska utföra handlingen i åtkomstförfrågan genom att begära av agenten att den lägger till de egenskaper som ingår i det aktuella SAML-intyget, eller genom att själv ange egenskaper för subjektet. 4. Agenten hämtar de egenskaper som finns angivna i SAML-intyget för subjektet och lägger till dessa i förfrågan om Aktören begär detta. 5, Aktören anger egenskaper för eventuella mellanliggande subjekt i förfrågan. 6. Aktören anger i förfrågan den handling som subjektet önskar utföra. Aktören Agenten Bastjänsten 7. Aktören anger en eller flera informationsuppsättningar som styr vilken resurs eller vilka resurser som handlingen ska utföras på: Omfattning för denna uppsättning Identifierare för resursen eller resurserna Resursbeskrivning: Identifierare för resursnod Text Egenskaper Resursnoder Noll eller ytterligare egenskaper som bestäms av Aktören Identifierare för egenskapen Värde för egenskapen 8. Aktören begär ett åtkomstbeslut av Agenten genom att presentera förfrågan. 9. Agenten tar emot begäran och presenterar den för bastjänsten. 10. Om åtkomstförfrågan ska valideras mot ett schema kommer bastjänsten att validera förfrågan enligt det schema som angivits i förfrågan. 57

Aktören Agenten Bastjänsten 11. För varje informationsuppsättning som styr vilken resurs eller vilka resurser som efterfrågas så skapar bastjänsten en ny åtkomstförfrågan med dess specifika informationsuppsättningen och som ärver övriga förutsättningar från den ursprungliga förfrågan. Alla dessa förfrågningar har således endast en informationsuppsättning som styr vilken resurs eller vilka resurser som efterfrågas. 12. För varje sådan åtkomstförfrågan vars omfattning inte gäller en specifik resurs så identifieras noll eller flera specifika resursnoder i resursbeskrivningen. För varje resursnod skapas en ny förfrågan som specifikt pekar ut denna resursnod, och dessa nya förfrågningar ersätter den förfrågan vars omfattning inte gäller en specifik resurs som de kommer ifrån. Aktören Agenten Bastjänsten 13. För alla åtkomstförfrågningar som nu är aktuella så appliceras de på den regeluppsättning som ligger på högsta nivå, en s.k. main policy. Om inga förfrågningar är aktuella avslutas flödet med resultatet: icke applicerbart. Om refererade regler saknas avslutas flödet med resultatet: obestämbart. 15. Agenten presenterar resultat för Aktören. 14. Bastjänsten presenterar enskilda resultat till Agenten för varje förfrågan: Identifierare för resursen Resultat (Tillåt, neka, obestämt eller icke applicerbart) Utfallna Åtaganden: Identifierare för åtagandet Egenskapstilldelningar Identifierare för egenskapen Värde för egenskapen Scenariot avslutas. 58

7. Samtyckestjänsten 7.1. Inledning Samtyckestjänsten kan ses som en hjälptjänst till åtkomstkontrollen. Du kommer att få en god kunskap i bastjänsten och vad den kan göra och hur åtkomstkontrollen använder sig av bastjänsten. Samtyckestjänsten avser det samtycke som gäller direktåtkomst av vårdinformation i samband med vård och behandling och inte i exempelvis administrativa eller statistiska syften. För att en patient ska kunna samtycka krävs att organisationen har informerat patienten om hur informationen hanteras och till vem regelmässigt utlämnande sker. Patienten ska ges möjlighet att påverka till vem och vilka åtkomst/utlämnande av informationen sker. Det är hur reglerna är skrivna som styr när det behövs ett samtycke mellan patient och vårdgivare eller inte. Om det finns en vårdrelation mellan patient och vårdgivare ska ett presumtivt samtycke finnas och därför ska inte något samtycke behöva registreras. Däremot kan man alltid registrera negativa samtycken. Det kan vara begränsat till vilka som kan ta del av vårdinformationen och ha en begränsad giltighetstid samt kunna avgränsas till en vårdprocess alternativt avgränsas för vårdinformation under en angiven tidsperiod. Patienten kan endast ge samtyckesintyg till egen information. Både patienten eller dess ombud ska ges möjlighet att ge samtycke. Samtyckesintyget kan upprättas genom att tala om vad som ska omfattas eller undantas. Samtyckestjänsten hanterar samtyckesintyg av typen: Spärr - patient kan begära spärr av vårdinformation. Barn kan aldrig spärra vårdinformation. Spärren kan på begäran av patienten hävas och den kan forceras om patientens samtycke inte kan inhämtas och informationen kan antas ha betydelse för den vård som patienten oundgängligen behöver. Samtycke skede 1 innebär direktåtkomst till personuppgifter för vård och behandling, som behandlas hos annan vårdgivare genom sammanhållen journalföring mellan vårdgivare. Samtycke skede 2, innebär att tillåtelse till direktåtkomst aktivt måste ges. Samtycke skede 2 kan även ges i förväg vid remiss. Forcering av spärr (Nödöppning i två steg: vem och vad.) Spärr att ingå i regionala och nationella kvalitetsregister Samtyckesintyget skall minst innehålla: Vilka aktörer (hälso- och sjukvårdspersonal eller organisation) som ska få ta del av information eller nekas tillgång till information Vilka delar av informationen som omfattas eller undantas Giltighetstid för samtycket 59

Åtkomstkontroll 1 Samtyckestjänst E Förfrågan Samtyckestjänst D Samtyckestjänst A Domän Samtyckestjänst C Samtyckestjänst B Förfrågan Åtkomstkontroll 2 Samtyckestjänsten kan representeras av flera instanser. En samtyckestjänst kan skicka och hämta samtyckesintyg automatiskt till eller från andra samtyckestjänster. För att detta ska kunna ske måste en samtyckesnod registreras. Vid publicering hamnar noden hos den mottagande samtyckestjänsten och därefter kan tjänsterna hämta samtycken och avregistreringar hos varandra. Om någon av bastjänsterna, t ex tjänst A, känner till andra noder så meddelas tjänst B om dessa noder och tjänst B kan hämta samtycken och avregistreringar hos de tjänster som tjänst A känner till. 60

7.2. Webbtjänstegränssnitt Denna IT-bastjänst tillhandahåller inget agentgränssnitt. Anrop gör i förstahand via åtkomstkontrolltjänsten vilket innebär att i de flesta fall så kommer du som utvecklare inte koda direkt mot denna bastjänst. Vill man däremot bygga in specifika funktioner i sin applikation vad gäller samtyckesintygen får man anropa webbtjänstegränssnittets funktioner direkt. AddConsent - Funktion för att registrera samtycke. Kan endast registreras av starkt autentiserad användare som uppfyller rättighetskrav för samtyckesregistrering. En patient kan ha obegränsat många samtycken. Ett samtycke skall undertecknas av den som registrerar samtycket. Undertecknandet görs med XML enveloped signature enligt W3C Recommendation. FetchConsent - Funktionen levererar en lista på registrerade intyg. Man kan välja en lista på alla intyg, giltiga som ogiltiga eller enbart giltiga. Ett samtyckesintyg är giltigt om startdatum för intyget är mindre eller lika med dagens datum slutdatum är större än dagens datum ej återkallat Listan kan omfatta registrerade intyg för en specifik patient och eller en specifik aktör. CheckConsent - Funktionen kontrollerar om aktören har patientens samtycke för viss aktivitet. Ett samtyckesintyg är giltigt om Samtycket gäller aktören Samtycket gäller patienten Samtycket gället aktiviteten startdatum för intyget är mindre eller lika med dagens datum slutdatum är större än dagens datum samtycket ej är återkallat Kan vara negativt CancelConsent - Funktionen makulerar ett tidigare giltigt intyg. I återkallan anges vem som begärde återkallan via signatur. DeleteConsent - Funktionen tar bort ett tidigare intyg. I gallring anges vem som begärde återkallan via signatur. GetSignedConsent - Funktionen hämtar ett efterfrågat samtycke och levererar ett undertecknat samtycke komplett med sin signatur. 61

7.2.1. Registrera samtycke via webbtjänstegränssnittet i Java Vi ska nu gå igenom ett enkelt steg-för-steg exempel på hur ett anrop för att registrera ett samtycke skulle kunna göras. En applikation som vill använda Samtyckestjänsten för att t ex registrera ett samtycke, måste gå via en proxy. Proxyn hanterar de säkerhetsaspekter som BIF kräver så att applikationen inte behöver hantera dessa. Proxyn skapas genom en ProxyFactory som hämtas från BifWsFactory instansen. import com.logica.se.bif.sdk.ws.bifwsfactory; ProxyFactory proxyfactory = BifWsFactory.getInstance().getProxyFactory(); Metoden som ska anropas anges vid skapandet av proxyn genom att ange namnet på metoden samt korrekt namnrymd: WsProxy<Source> consentwsproxy; try { String wsdllocation = "consentservice-ws-0.1.wsdl"; String endpointaddress = "https://bif.test.logica.se:8443/services/bifconsentservice"; this.consentwsproxy = proxyfactory.create( new URL(wsdlLocation), QName.valueOf ("{urn:carelink:bif:consent:0.1}bifconsentservice"), QName.valueOf ("{urn:carelink:bif:consent:0.1}bifconsentserviceport"), "urn:carelink:bif:consent:0.1:addconsent", endpointaddress, 60000); } catch (MalformedURLException e) { throw new RuntimeException("Failed to create proxy, e); } När väl tjänsteproxyn är skapad behövs en begäran enligt det XML-format som, i detta fall, beskrivs av AddConsentRequest-typen i wsdl-dokumentet. //Skapa upp xml-data enligt wsdl. String requestaddconsent=... Begäran omvandlas sedan innan det skickas till Samtyckestjänsten via ett anrop till invoke()-metoden. Source request = new StreamSource(new java.io.stringreader(requestaddconsent)); Source response = null; try { response = this.consentwsproxy.invoke(request); } catch (Exception e) { throw new RuntimeException("Failed when requesting consent", e); } // Hantera svar från samtyckestjänsten Samma metodik kan användas för de övriga metoderna i samtyckestjänstens webbtjänstgränssnitt. 62

7.2.2. Registrera samtycke via webbtjänstegränssnittet i.net Vi ska nu gå igenom ett enkelt steg-för-steg exempel på hur ett anrop för att registrera ett samtycke skulle kunna göras. Lägg till en Servicereferens. Skriv in vart WSDL:en finns. Om man så önskar att göra inställningar deklarativt så fyller man i det i sin App.config <system.servicemodel> <extensions> <bindingextensions> <add name="bifbinding" type="logica.bif.ws.bifbindingcollectionelement, Logica.BIF.WS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/> </bindingextensions> </extensions> <bindings> <bifbinding> <binding name="consentserviceportbinding" wsdllocation="file:///c:\wsdl\consentservice-ws-0.1.wsdl" targetnamespace="urn:carelink:bif:consent:0.1" servicename="bifconsentservice" portname="bifconsentservicesoap12port"/> </bifbinding> </bindings> <client> <endpoint address="https://bif.test.logica.se:8443/services/bifconsentservice" binding="bifbinding" bindingconfiguration="consentserviceportbinding" contract="consentservice.bifconsentporttype" 63

name="consentserviceport" /> </client> </system.servicemodel> Eller om man vill göra det programmatiskt: Logica.BIF.WS.BIFBinding bifbinding = new Logica.BIF.WS.BIFBinding(); bifbinding.wsdllocation = "file:///c:\wsdl\consentservice-ws-0.1.wsdl"; bifbinding.targetnamespace = "urn:carelink:bif:consent:0.1"; bifbinding.servicename = "BIFConsentService"; bifbinding.portname = "BIFConsentServiceSoap12Port"; EndpointAddress address = new EndpointAddress( "https://bif.test.logica.se:8443/services/bifconsentservice"); BIFConsentPortTypeClient client = new BIFConsentPortTypeClient(bifBinding, address); Sedan använder man sig utav de autogenererade klasserna för att registrera ett samtycke. BIFConsentPortTypeClient client = new BIFConsentPortTypeClient(); SignedConsentType sct = new SignedConsentType(); sct.statedby = "191212-1212"; sct.... string result = client.addconsent(sct); Samma metodik kan användas för de övriga metoderna i samtyckestjänstens webbtjänstgränssnitt. 64

8. Vårdrelationstjänsten 8.1. Inledning I detta seminarium kommer du att få god kännedom i hur vårdrelationstjänsten fungerar. Syftet med vårdrelationstjänsten är att administrera respektive intyga att hälso- och sjukvårdspersonal har vårdrelation till patient. I vårdrelationstjänsten kan vårdrelation registreras och lagras. Registrering sker antingen manuellt i BIFs administrationsgränssnitt eller att vårdrelationstjänsten har integrerats med vård- och/eller PAS-system via webbtjänstegränssnittet. Vårdrelationstjänsten ger svar på om intygad vårdrelation föreligger mellan användare och patient. Tjänsten svarar Ja eller Nej på fråga om vårdrelation existerar. En förutsättning är att verksamheten har fastställt regler för vårdrelation. Åtkomstkontroll 1 Vårdrelationstjänst E Förfrågan Vårdrelationstjänst D Vårdrelationstjänst A Domän Vårdrelationstjänst B Vårdrelationstjänst C Förfrågan Åtkomstkontroll 2 Vårdrelationstjänsten kan representeras av flera instanser. En vårdrelationstjänst ska kunna skicka och hämta vårdrelationsintyg automatiskt till/från andra vårdrelationstjänster. För att detta ska kunna ske måste en vårdrelationsnod registreras. En användare registrerar och publicerar en vårdrelationsnod. Vid publicering hamnar noden hos den mottagande vårdrelationstjänsten och därefter kan bastjänsterna hämta vårdrelationer och avregistreringar hos varandra. Om någon av bastjänsterna, t ex tjänst A, känner till andra noder så meddelas tjänst B om dessa noder och tjänst B kan hämta vårdrelationer och avregistreringar hos de bastjänster som tjänst A känner till. 65

8.2. Webbtjänstegränssnitt Nu ska vi gå igenom webbtjänstegränssnittets funktioner: Denna IT-bastjänst tillhandahåller inget agentgränssnitt. Anrop gör i förstahand via åtkomstkontrolltjänsten. Vilket innebär att i de flesta fall kommer du som utvecklare inte att programmera direkt mot denna bastjänst. Vill man däremot bygga in specifika funktioner i sin applikation vad gäller vårdrelation får man anropa webbtjänstegränssnittets funktioner direkt. AddCarelation - Ett vårdrelationsintyg skall undertecknas av den som registrerar vårdrelationen. Undertecknandet görs med XML enveloped signature enligt W3C Recommendation. FetchCarelation - Funktionen levererar en lista på registrerade intyg. Man kan välja en lista på alla intyg, giltiga som ogiltiga eller enbart giltiga. Ett vårdrelationsintyg är giltigt om startdatum för intyget är mindre eller lika med dagens datum slutdatum är större än dagens datum ej återkallat Listan kan omfatta registrerade intyg för en specifik patient och eller en specifik aktör. CheckCarelation - Funktionen kontrollerar om hälso- och sjukvårdsperson har en registrerad vårdrelation till patient. Funktionen ska leverera ett Ja eller Nej beroende på om vårdrelation finns registrerad. CancelCarelation - Funktionen makulerar ett tidigare giltigt intyg. I återkallan anges vem som begärde återkallan via signatur. DeleteCarelation - Funktionen tar bort ett tidigare intyg. I gallring anges vem som begärde återkallan via signatur. GetSignedCarelation- Funktionen hämtar en efterfrågad vårdrelation och levererar ett undertecknat vårdrelationsintyg komplett med sin signatur. Om vårdrelationen är återkallad returneras även den signerade återkallan. 66

9. Utlämnandetjänsten 9.1. Inledning I detta seminarium ska vi titta närmare på utlämnandetjänsten. Syftet med tjänsten är att möjliggöra utlämnande av vårdinformation efter prövning av behörigt utlämnande. Tjänstens ansvar är att motta begäran om utlämnande av vårdinformation och registrera beslut om utlämnande. Autentisering HSA Klient Logg DB Notifiering Samtycke 10 Administration av utlämnande Åtkomstkontroll Vårdrelation Logg Regler Utlämnande Notifiering Begäran om utlämnande sker alltid aktivt från en aktörs sida, ingen automatiserad begäran om utlämnande skickas från ÅKT om utlämnandebeslut krävs men saknas. Denna information (krav på utlämnandebeslut) lämnas till aktör som begär tillgång till en resurs. Utlämnandetjänstens uppdrag är att motta begäran om utlämnande och att registrera resultat av menprövning/sekretessprövning. 67

Autentisering HSA Klient Logg DB Samtycke 10 Vårdtjänst Åtkomstkontroll Vårdrelation Logg Regler Utlämnande Notifiering med Notifieringstjänsten sker till aktören som begärt utlämnande från bastjänsten. Resultat av utlämnandebeslut kontrolleras av ÅKT+ vid informationsbegäran. 68

9.2. Webbtjänstegränssnitt Nu ska vi gå igenom webbtjänstegränssnittets funktioner: Denna IT-bastjänst tillhandahåller inget agentgränssnitt. Anrop gör i förstahand via åtkomstkontrolltjänsten. Vilket innebär att i de flesta fall så kommer du som utvecklare inte koda direkt mot denna bastjänst. AddApplication - Funktion för att registrera begäran om utlämnande. Tjänsten svarar med att kvittera mottaget uppdrag i form av ett ärendeid. Beslut om utlämnade (ja/nej) registreras i tjänsten, beslutet meddelas även notifieringstjänsten. GetApplicationAndHandOut - Funktion för att hämta information om en specifik begäran om utlämnande som eventuellt också håller ett beslut. Identifieras genom dess unika Id. FetchApplication - Funktion för att hämta en lista med begärda utlämnanden som återfinns i en given inkorg. Dessa begärda utlämnanden är alltid obeslutade och aktuella. CancelApplication - Funktion för att återkalla begäran om utlämnande. Återkallandet är signerat av beslutsfattarens SITHS-certifikat. AddHandout - Funktion för att registrera beslut om godkänt eller icke godkänt utlämnande. Beslutet är signerat av beslutsfattarens SITHS certifikat. FetchHandoutAndApplications - Funktion för att hämta en lista på begärda utlämnanden med eventuella, registrerade beslut. Sökningen har stöd för antingen en generell XACML Request eller sökning av beslut tagna av given aktör. CheckHandout - Funktion för att kontrollera beslut om ett specifikt utlämnande. CancelHandout - Funktion för att återkalla beslut om utlämnande. Funktionen makulerar ett tidigare beslut om utlämnande. I återkallan anges vem som begärde återkallan. Aktören skall vara starkt identifierad och autentiserad samt ha rättighet att återkalla utlämnandebeslut. DeleteHandout - Funktion för att ta bort begäran och eventuellt beslut om utlämnande. Gallring kan göras för specifikt utlämnande eller gallring baserat på när begäran om utlämnande skapades. Aktören ska vara starkt identifierad och autentiserad samt ha rättighet att återkalla utlämnandebeslut. GetApplicationLock - Funktion för att markera en begäran om utlämnande som under handläggning. Detta kan göras av en aktör för att på så sätt markera för andra aktörer att begäran är under behandling och därmed undvika oavsiktligt, parallellt arbete. GetPolicySet Denna tjänst returnerar regler för att kontrollera om beslut om utlämnande finns. Regeln består av en övergripande Policy med underliggande Rules som representerar aktuella utlämnandebesluts Targets. FetchInboxes Funktion för att hämta en lista över befintliga inkorgar. I inkorgarna återfinns begärda, obeslutade utlämnanden. 69

9.3. Beskrivning av utlämnandeflöde Här ska vi titta på ett exempel på utlämnandeflöde. En användare har på något sätt funnit ut att information kring en aktuell patient finns hos en annan huvudman. Notifieringstjänst Notifieringstjänst 6. 3. Menprövningsprocess 7. Användare begär information 1. Huvudmannagräns 5. 2. Utlämnandetjänst 4. Patientinformation Samtyckestjänst Vårdrelationstjänst Åtkomstkontrolltjänst 1. Användaren skickar en begäran om utlämnande till den aktuella huvudmannen. Detta kan t.ex. ske via någon form av portal där indikativ information funnits. Utlämnandetjänsten kan i frågeställarens SAML biljett utläsa adressen till dennes notifieringstjänst. 2. Utlämnandetjänsten skapar ett meddelande till den lokala notifieringstjänsten och returnerar OK till användaren. Utifrån den efterfrågade resursen skickas ett meddelande till avsedd beslutsfattare. 3. Beslutsfattaren genomför utlämnandeprocessen. 4. Beslutet lagras i utlämnandetjänsten. 5. Utlämnandetjänsten har tidigare läst ut adressen till frågeställarens notifieringstjänst och notifierar sin lokala notifieringstjänst. 6. Den lokala IT-bastjänsten skickar en notifiering till frågeställarens notifieringstjänst. 7. Slutligen meddelas användaren att ett beslut om utlämnande har fattats. 70

9.3.1. Sekvensdiagram över utlämnandeflöde Här ska vi titta på två sekvensdiagram över flödena med utlämnandetjänsten. Det första diagrammet visar sekvensen över begäran om utlämnande. Registrera begäran om utlämnande Aktör ÅKT Utlämnade Notifiering Handläggare addapplication doautentication Permit ApplicationID Notify Notify 71

När handläggaren har blivit notifierad om en begäran så registrerar hon ett beslut om utlämnande. Registrera beslut om utlämnande Handläggare ÅKT Utlämnade DB Notifiering/ Aktör addhandout doautentication Permit SaveHandOut Result donotify Null Det sista diagrammet visar sekvensen över hämtning av utlämnandebeslutet. Presentera begäran om utlämnande Aktör ÅKT Utlämnande DB getapplication/fetchapplication doautentication Permit getapplications Applications Applications 72

10. Säker kontexttjänsten 10.1. Inledning I detta seminarium kommer du att få goda kunskaper i vad som krävs av dig som utvecklare vad gäller kodning mot bastjänsten genom agentens funktioner. Säker kontexttjänsten Autentisering HSA DB Klient A Samtycke Åtkomstkontroll Vårdrelation Aktör Säker kontext Vårdsystem A Utlämnande Regler Läkemedels tjänst Notifiering Logg Klient B Kontexttjänstens uppgift är att lagra och förmedla förändringar av tillstånd mellan BIF-anslutna applikationer. Bastjänsten tillåter hantering av godtycklig data, men i version 1.0 av bastjänsten är det endast patienten som en aktör arbetar med som hanteras på ett standardiserat sätt. Kontexttjänsten tillhandahåller ett gränssnitt som tillåter registrering och återhämtning av kontextdata kopplat till en viss aktör. Varje kontexttyp identifieras med en sträng kallad topic. Ordet topic är valt eftersom kontexttjänsten har en enkel publish/subscribe mekanism för kontextdata. Alla meddelanden till tjänsten skall innehålla SAML-intyg för, samt vara signerat av, användaren kontexten gäller för. För webbapplikationer, då användarens nyckel inte är tillgänglig, är meddelandet i stället signerat av den betrodda tjänsten som förmedlar anropet. Kontexttjänsten implementeras med stöd för så kallad Two-phase commit, vilket innebär att kontexttjänsten fungerar som en koordinator för de resurser som är berörda i systemet av förändringen. Koordinatorn ser till att meddela resurserna att förbereda sig för förändringen, resurserna meddelar att de är redo för att genomföra eventuell förändring. Koordinatorn meddelar om de ska genomföra förändringen eller om de ska avbryta. Resurserna meddelar sedan att ordern slutfördes. 73

10.2. Tjänsteagenten & webbtjänstegränssnitt Syftet med tjänsteagenten för kontext är att förenkla användning av kontexttjänsten i applikationer/tillämpningar genom att tillhandahålla stödfunktionalitet i klienten. Detta inkluderar hantering av registrering för notifiering, vilket kan innebära att agenten till exempel måste fungera som en webservice-lyssnare. Agenten för kontexttjänsten skall inte själv hålla kontext lokalt utan endast förenkla kommunikationen med kontexttjänstservern. Kontextagenten beskriver två interface: ContextAgent beskriver operationerna som en applikation kan utföra. Dessa är i stort sett relaterade etttillett med operationerna i kontexttjänstens gränssnitt, men är något förenklade då agenten kan hjälpa till att hålla reda på viss information. ContextListener är ett callback interface som tillåter en applikation att bli notifierad när en viss typ av contextdata förändras. En klassinstans som implementerar ContextAgent är alltid kopplad mot en viss användares aktuella biljett. Detta görs exempelvis då instansen skapas. Efter detta är alla operationer implicit knutna till användaren som biljetten är utställd för. Den ContextAgent-implementerande klassen använder denna identitet då kontexttjänsten anropas. Dessa är kontextagentens funktioner: getvalue - Hämtar aktuellt kontextdata i vald topic för den aktuella aktören. setvalue - Uppdaterar kontextdata för en aktör. subscribe - Registrerar prenumeration på aktuell topic. Unsubscribe Avslutar prenumeration. Dessa är webbtjänstegränssnittets funktioner: Get - Hämtar aktuellt kontextdata i vald topic för den aktuella aktören. Set - Uppdaterar kontextdata för en aktör. Subscribe - Registrerar prenumeration på aktuell topic. Unsubscribe - Avslutar vald prenumeration. 74

10.2.1. Implementeringsexempel Detta är ett exempel på hur kontextagenten kan implementeras i en miljö där klienten inte kan nås direkt från kontexttjänsten. Arbetsplatsklient En brandvägg stoppar kommunikationen mellan kontexttjänsten och agenten i klienten. Agenten läggs både i klienten och serverdelen. Kontexttjänsten Vårdtjänstens serverdel Tjänstegränssnitt Kontextagent Fasadkomponent Vid registrering av en klient för notifiering vid kontextförändringar skickas en URL in som beskriver var klienten befinner sig. Detta förutsätter att kontexttjänsten har möjlighet att via nätverket direkt anropa klienten. I dagens nätverk, bland annat på grund av säkerhetsaspekter och den begränsade adressrymd som finns i IPv4, är det inte alltid möjligt för en nod i nätverket att fritt initiera en ny TCP/IP koppling till alla andra noder. Till exempel kan kommunikationen blockeras av en brandvägg eller så är måladressen gömd bakom en adressöversättande router. För att, trots detta, hantera notifiering till klienter skulle en implementering av kontextagenten kunna göras med en klient- och en serverdel. Klientdelen, vilken implementerar kontextagentens interface och används av vårdapplikationerna, etablerar en långlivad TCP/IP-koppling till en serverdel, som lever i närheten av kontexttjänsten. Serverdelen hanterar kommunikationen med kontexttjänsten och måste vara nåbar av kontexttjänsten för att kunna ta emot notifieringar. Då kopplingen klientdelen upprättar hålls vid liv under längre tid kan serverdelen använda denna för att vidarebefordra notifieringar till de anslutna klientdelarna. Serverdelen av kontextagenten kan i detta fall användas av ett flertal klienter på samma gång. 75

10.2.2. Tjänsteagenten kodexempel Java Kontexttjänsten hanterar värden för olika kontexttyper. Det kan finnas flera instanser av samma kontexttyp beroende på vilket attribut i SAML-biljetten som den aktuella kontexttypen är konfigurerad att använda för att separera på olika kontexter. Vi ska nu titta på lite olika exempel på integrering mot kontextagenten med Java och hur man publicerar ett kontextvärde. Vi börjar med att skapa en agent genom BIF-fasaden. BifFacade biffacade = BifFacadeFactory.getBifFacadeInstance(); ContextAgent contextagent = biffacade.getcontextagent(); Sedan sätter vi ett kontextvärde. contextagent.setvalue("patient","19121212-1212"); Nästa exempel visar hur en applikation prenumererar på förändringar av kontext. Gör en klass som implementerar gränssnittet ContextListner. public class MyContextListner implements ContextListner { public Boolean canupdate() { // The Contextservice asks us if it is okey to // switch the context. We deny the switch if we're in // the middle of some kind operation. } } public void update(string data) { // The context has changed } Skapa en prenumeration på kontexttypen patient. Instansen av ContextListner-gränssnittet kommer att meddelas om eventuella uppdateringar av kontextypens värde. Om kontexttypen är konfigurerad att använda sig av two-phase commit kommer även ContextListner- instansen att tillfrågas innan en eventuell uppdatering görs: MyContextListner mycontextlistener = new MyContextListener(); Subscription subscription = contextagent.subscribe("patient", mycontextlistner); Hämta kontextvärde: String value = signature.getvalue(); Avsluta prenumerationen subscription.unsubscribe(); 10.2.3. Tjänsteagenten kodexempel.net Kontexttjänsten hanterar värden för olika kontexttyper. Det kan finnas flera instanser av samma kontexttyp beroende på vilket attribut i SAML-biljetten som den aktuella kontexttypen är konfigurerad att använda för att separera på olika kontexter. Vi ska nu titta på lite olika exempel på integrering mot kontextagenten med.net och hur man publicerar ett kontextvärde. Vi börjar med att skapa en agent genom BIF-fasaden. BifFactory biffactory = BifFactory.Instance; IContextAgent contextagent = biffactory.getcontextagent(); Sedan sätter vi ett kontextvärde. contextagent.setvalue("patient", "121212-1212"); 76

Nästa exempel visar hur en applikation prenumererar på förändringar av kontext. Prenumerationer kan även användas för att hämta och sätta värdet på den kontexttyp som är knuten till prenumerationen. Skapa en prenumeration på kontexttypen patient. Instansen av ContextListner-interfacet kommer att meddelas om eventuella uppdateringar av kontextypens värde. Om kontexttypen är konfigurerad att använda sig av two-phase commit kommer även ContextListner-instansen att tillfrågas innan en eventuell uppdatering görs. ISubscription subscription = contextagent.subscribe("patient", contextlistener); Hämta kontextvärde för en prenumeration. string subscriptionvalue = subscription.getvalue(); Avsluta prenumerationen. subscription.unsubscribe(); 10.2.4. Sekvensdiagram Detta sekvensdiagram visar en uppdatering av kontext med konfigureringen two-phase commit. Uppdatera kontext Aktör ÅKT Kontext DB Prenumeranter settopicvalue, setsubscriptionvalue doautentication Permit isupdateallowed True setvalue Result updatevalue 77

Detta diagram visar hämtning av kontext. Hämta kontext Aktör ÅKT Kontext DB gettopicvalue, getsubscriptionvalue doautentication Permit getvalue Value Value or error message Detta diagram visar en prenumeration på kontext. Registrera prenumeration på kontext Aktör ÅKT Kontext DB subscribe doautentication Permit registersubscription Result subscriptionid 78

11. Notifieringstjänsten 11.1. Inledning Syftet med notifieringstjänsten är att ge möjlighet att notifiera avsändare och mottagare i vissa situationer. Notifieringstjänsten baseras helt och hållet på en uppsättning av standarder kallad WS-Notification. För att en notifieringstjänst skall kunna notifiera en användare via användarens egen notifieringstjänst används ett extra attribut i användarens SAML-biljett vilket beskriver adressen till webbtjänsten. Notifieringstjänsten består egentligen av två olika tjänster: Adresserad notifiering - avses de meddelanden som skickas direkt till en angiven mottagare. Icke adresserad notifiering betyder att avsändaren inte vet vem mottagaren är. Det sköter ITbastjänsten. Notifiering till annan IT-tjänst av typen web service skall ske enligt WS-BrokeredNotification. Notifiering direkt till en användare sker indirekt via mottagarens egna IT-bastjänst för Notifiering med ett därför avsett meddelande. I e-post och SMS fallet skickas meddelande till alla som finns upplagda i distributionslistan. I köfallet skickas meddelande till alla köer som gäller för aktuell notifieringstyp. 11.2. Adresserad notifiering Med adresserad notifiering avses de meddelanden som skickas direkt till en angiven mottagare. Adresserad notifiering kan ske både inom en och mellan två domäner. Adresserad notifiering är asynkron, men ett svar skickas till avsändaren med information om vilket id notifieringen tilldelats när tjänsten tagit emot meddelandet. Om avsändaren så önskar kan en kvittens skickas till avsändaren som meddelar om meddelandet gick att leverera. Adresserad notifiering Domän A Domän B Adresserad Notifieringsagent Adresserad Notifieringsagent WS 5. ForwardConfirmationok 125 WS 1. notify( ) Proxy 3. Forward 125( ) Proxy 2. ID 125 SMS Kanaler E-post SMS Kanaler E-post System X 6. Confirm ok 125 4. Till mottagaren Proxy WS 79

11.2.1. Agent- och webbtjänstegränssnitt Adresserad notifieringsagenten har följande funktioner: createmessage - Skapar ett meddelande createappendix - Skapar en bilaga getappendices().add - Lägger till en bilaga i medelandet notify - Sänder iväg ett meddelande till specificerad adressat Webbtjänstegränsnittet har följande funktioner: Notify Sänder meddelandet till angiven mottagare Forward Vidarebefodrar meddelande som ska till annan domän än den egna. ForwardConfirmation Vidarebefodrar kvittens som skall till en annan domän än den egna. 11.2.2. Adresserad notifiering i Java Innan adresserad notifiering sker måste en agent, ett meddelande och en eventuell bilaga skapas. Vi börjar med att skapa en agent genom BIF-fasaden BifFactory biffactory = BifFactory.getInstance(); AddressedNotificationAgent addressednotificationagent = biffactory.getaddressednotificationagent(); Meddelanden skapas genom createmetoden på agenten enligt exemplet. Parametrarna ämne och kanal är konfigurerbara från administratörswebbgränssnittet. SimplifiedMessage simplifiedmessage = addressednotificationagent.createmessage( "mottagandedomän", "mottagareid", "ämne", "meddelande", SecrecyLevel.NonClassified, "Kanal", 60000L); Bilagor skapas genom createmetoden på agenten. Appendix appendix = addressednotificationagent.createappendix( "Filnamn.pdf", "application/pdf", "base64string"); För att lägga till bilagor till meddelandet används följande metod på meddelandet. simplifiedmessage.getappendices().add(appendix); Meddelanden skickas genom notify-metoden på agenten. För att kunna ta emot kvittens måste en instans av confirmer interfacet skickas med. addressednotificationagent.notify(simplifiedmessage, confirmer) 80

11.2.3. Adresserad notifiering i.net Innan adresserad notifiering måste en agent, ett meddelande och en eventuell bilaga skapas. Vi börjar med att skapa en agent genom BIF-fasaden BifFactory biffactory = BifFactory.Instance; IAddressedNotificationAgent addressednotificationagent = biffactory.getaddressednotificationagent(); Meddelanden skapas genom createmetoden på agenten enligt exemplet. Parametrarna ämne och kanal är konfigurerbara från administratörswebbgränssnittet. ISimplifiedMessage simplifiedmessage = addressednotificationagent.createmessage( "mottagandedomän", "mottagareid", "ämne", "meddelande", SecrecyLevel.NonClassified, "Kanal", 60000L); Bilagor skapas genom createmetoden på agenten. IAppendix appendix = addressednotificationagent.createappendix( "Filnamn.pdf", "application/pdf", "base64string"); För att lägga till bilagor till meddelandet används följande metod på meddelandet. simplifiedmessage.appendices.add(appendix); Meddelanden skickas genom notify-metoden på agenten. För att kunna ta emot kvittens måste en instans av confirmer interfacet skickas med. addressednotificationagent.notify(simplifiedmessage, confirmer) 81

11.3. Icke adresserad notifiering Icke adresserad notifiering betyder att meddelanden publiceras och tas emot enligt publish/subscribe-modellen och att meddelanden knyts till en eller flera topics enligt WS-Topics standarden. De flesta av operationerna som beskrivs i standarden kan utföras via agenten. En avsändare som skapar ett meddelande och överlämnar det till en notifieringstjänst. Avsändaren behöver inte veta eller hålla reda på vilka som skall vara mottagare av aktuellt meddelande. Det skall notifieringstjänsten hålla reda på via interna förteckningar över vilka som är prenumeranter på aktuell notifieringstyp. Notifieringstjänsten garanterar att publicerade meddelanden skickas ut till alla som vid distributionstillfället är anslutna till aktuell notifieringstyp inom notifieringstjänst som prenumeranter. 11.3.1. Agentgränssnitt Notifieringstjänstens agent har flera olika gränssnitt som vi här kommer att gå igenom. Vill du ha en djupare genomgång av funktionerna så finns de i dokumentationen över BIF. NotificationAgent - Detta gränssnitt är ingången till notifieringsagenten Publication - Detta gränssnitt representerar en publikation AgentSubscription - Detta gränssnitt representerar en prenumeration Subscriber - Detta gränssnitt representerar en prenumerant och implementeras av klienter till notifieringsagenten TopicExpression - Detta gränssnitt representerar ett TopicExpression i WS-Topic standarden. 11.3.2. Sekvensdiagram Här ska vi titta på ett sekvensdiagram över en notifiering där ett meddelande skickas. Aktören skapar ett meddelande och överlämnar det till en notifieringstjänst. Aktören behöver inte veta eller hålla reda på vilka som skall vara mottagare av aktuellt meddelande. Notifieringstjänsten gör först en åtkomstkontroll. Därefter kontrollerar notifieringstjänsten att det är ett korrekt Topic och därefter vilka som är prenumeranter på aktuellt Topic. Notifieringstjänsten skickar ut meddelandet till alla som är anslutna till aktuellt Topic som prenumeranter. Icke adresserad Notifiering - sendmessage Aktör ÅKT Notifiering Topics Subscription Manager Subscribers Notify doautentication Permit checktopic TopicsValid getsubscribers Subscribers sendmessage 82

11.3.3. Icke adresserad notifiering i Java Icke adresserad notifiering avser asynkron hantering av meddelande enligt WS-BrokeredNotification standarden. Detta innebär att meddelanden publiceras och tas emot enligt publish/subscribe modellen och att publicister och prenumeranter knyts till en eller flera topics enligt WS-Topics standarden. De flesta av operationerna som beskrivs i standarden kan utföras via agenten. Vi börjar med att skapa en agent genom BIF-fasaden BifFactory biffactory = BifFactory.getInstance(); NotificationAgent notificationagent = biffactory.getnotificationagent(); Vi skapar ett Simple topic expression TopicExpression topicexpression = notificationagent.createsimpletopicexpression("urn:carelink:names:bif:1.0:n s:test", "topic1"); Skapa ett Concrete topic expression TopicExpression topicexpression = notificationagent.createconcretetopicexpression("urn:carelink:names:bif:1.0 :ns:test", "topic1/subtopic2"); Skapa ett XPath topic expression HashMap<String, String> uriprefixmap = new HashMap<String, String>(); uriprefixmap.put("ns1", "urn:carelink:names:bif:1.0:ns:test"); TopicExpression xpathtopicexpressionsource = notificationagent.createxpathtopicexpression(uriprefixmap, "ns1:topic1/topic2"); Skapa en prenumeration på en eller flera topics. När ett meddelande tas emot på denna prenumeration körs notify-metoden på den instans av subscriberinterfacet som skickades med när prenumerationen skapades. AgentSubscription subscription = notificationagent.subscribe(topicexpression, subscriber, System.currentTimeMillis() + 5 * 60 * 1000, true); Prenumerationen kan pausas subscription.pause(); Prenumerationen kan återupptas subscription.resume(); Prenumerationen kan förnyas subscription.renew(system.currenttimemillis() + 300000); Prenumerationen kan avslutas subscription.unsubscribe(); Här registrerar vi en publicist på en eller flera topics med hjälp av ett eller flera topic expressions. GregorianCalendar terminationtime = (GregorianCalendar) GregorianCalendar.getInstance(); terminationtime.add(calendar.millisecond, (1000 * 60 * 60)); Publication publication = notificationagent.registerpublication(topicexpressions, terminationtime); Publicera angivet meddelande på angivna topics i det topic expression som skickas in i metoden. publication.notify(topicexpression, message); Avregistrera publicist publication.unregister(); 83

11.3.4. Icke adresserad notifiering i.net Icke adresserad notifiering avser asynkron hantering av meddelande enligt WS-BrokeredNotification standarden. Detta innebär att meddelanden publiceras och tas emot enligt publish/subscribe modellen och att publicister och prenumeranter knyts till en eller flera topics enligt WS-Topics standarden. De flesta av operationerna som beskrivs i standarden kan utföras via agenten. Vi börjar med att skapa en agent genom BIF-fasaden BifFactory biffactory = BifFactory.Instance; INotificationAgent notificationagent = biffactory.getnotificationagent(); Vi skapar ett Simple topic expression ITopicExpression topicexpression = notificationagent.createsimpletopicexpression("urn:carelink:names:bif:1.0:n s:test", "topic1"); Skapa ett Concrete topic expression ITopicExpression topicexpression = notificationagent.createconcretetopicexpression("urn:carelink:names:bif:1.0 :ns:test", "topic1/subtopic2"); Skapa ett XPath topic expression IDictionary<String, String> uriprefixmap = new Dictionary<String, String>(); uriprefixmap.add("ns1", "urn:carelink:names:bif:1.0:ns:test"); ITopicExpression xpathtopicexpressionsource = notificationagent.createxpathtopicexpression(uriprefixmap, "ns1:topic1/topic2"); Skapa en prenumeration på en eller flera topics. När ett meddelande mottages på denna prenumeration körs notify-metoden på den instans av subscriberinterfacet som skickades med när prenumerationen skapades. IAgentSubscription subscription = notificationagent.subscribe(topicexpression, subscriber, 5 * 60 * 1000, true); Pausa en prenumeration subscription.pause(); Återuppta en prenumeration subscription.resume(); Förnya en prenumeration subscription.renew(system.currenttimemillis() + 300000); Avsluta en prenumeration subscription.unsubscribe(); Registrerar en publicist på en eller flera topics med hjälp av ett eller flera topic expressions. DateTime terminationtime = DateTime.Now.Add(TimeSpan.FromHours(1)); IPublication publication = notificationagent.registerpublication(topicexpressions, terminationtime); Publicerar angivet meddelande på angivna topics i det topic expression som skickas in i metoden. publication.notify(topicexpression, message); Avregistrera publicist publication.unregister(); 84

12. Logganalystjänsten 12.1. Inledning I det här seminariumet kommer vi ge en konceptuell beskrivning av logganalystjänsten. Logginformation som hämtas från loggtjänsten avseende vårdinformationstillgång skall som minimum innehålla. Aktör med egenskaper Resurs med egenskaper Aktivitet Omgivningsfaktorer Tid Logganalystjänsten används för att söka ut, bearbeta och presentera logginformation för uppföljning, vilket för vårdinformation styrs av gällande regelverk. Uppgifter hämtas från loggtjänsten och sammanställs enligt specifikation för önskad uppföljning. Rättighet att ta del av analys är regelstyrt via Åtkomstkontrolltjänsten. Logganalystjänsten kan automatisk söka ut och sammanställa uppgifter. Vid uppföljning som inte genereras av automatisk sammanställning, kan användardefinierad utsökning och bearbetning ske. Användaredefinitionen kan sparas och återanvändas, med möjlighet till justering av definitionerna. Det är drift- och förvaltarpersonal som i första hand kommer att komma i kontakt med logganalystjänsten via dess administrationsgränssnitt. Vill du ha mer information hänvisar vi till de webbseminarium som finns för drift och förvaltare. Det kan ju uppkomma situationer när du som utvecklare vill kunna köra analyser på vad dina BIF-anpassade applikationer loggar när du integrerat loggtjänsten. 85