Webbseminarium BIF-Utbildning för utvecklare Version 1.0.0

Transkript

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

2 Innehållsförteckning 1. Introduktion Inledning Implementering BIF Arkitektur Inledning Tjänstebaserad arkitektur Flexibel plattform Säkerhet Egenskapsbaserad åtkomstkontroll BIF Beståndsdelar Biljett (SAML-intyg) Fasadkomponent Klienter Agenter Certifikat Webbtjänster i BIF Driftsättningsvy BIF SDK Inledning BIF SDK Java BIF SDK.NET Autentiseringstjänsten Inledning Applikationens ansvar Inloggningsaspekter Egenskapskällor Tjänsteagenten Registrera lyssnare för kortläsare i Java Registrera lyssnare för kortläsare i.net Webbtjänstegränssnitt Autentisering Autentisering från lokalt exekverande klient Autentisering från webbklient Loggtjänsten Inledning Applikationens ansvar Tjänsteagenten Logga mot loggagenten i Java Logga mot loggagenten i.net Webbtjänstegränssnitt Åtkomstkontrolltjänsten Inledning XACML protokollens användning av BIF Mönster för åtkomstkontroll Resurser Resurser Java Resurser.NET Åtaganden Hantering av åtaganden med Java Hantering av åtaganden med.net Tjänsteagenten & webbtjänstegränssnitt Tjänsteagenten kodexempel med Java Tjänsteagenten kodexempel med.net Applikationens ansvar Åtkomstkontroll Flöde över åtkomstkontroll

3 7. Samtyckestjänsten Inledning Webbtjänstegränssnitt Registrera samtycke via webbtjänstegränssnittet i Java Registrera samtycke via webbtjänstegränssnittet i.net Vårdrelationstjänsten Inledning Webbtjänstegränssnitt Utlämnandetjänsten Inledning Webbtjänstegränssnitt Beskrivning av utlämnandeflöde Sekvensdiagram över utlämnandeflöde Säker kontexttjänsten Inledning Tjänsteagenten & webbtjänstegränssnitt Implementeringsexempel Tjänsteagenten kodexempel Java Tjänsteagenten kodexempel.net Sekvensdiagram Notifieringstjänsten Inledning Adresserad notifiering Agent- och webbtjänstegränssnitt Adresserad notifiering i Java Adresserad notifiering i.net Icke adresserad notifiering Agentgränssnitt Sekvensdiagram Icke adresserad notifiering i Java Icke adresserad notifiering i.net Logganalystjänsten Inledning

4 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

5 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

6 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 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

7 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

8 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

9 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 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

10 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

11 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 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

12 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

13 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

14 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 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

15 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

16 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

17 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

18 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 = SE , 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 = SE urn:carelink:bif:attrnames:commonname = Gunnar Gran urn:carelink:bif:attrnames:country= SE (SERIALNUMBER) (CN) (C) 18

19 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

20 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

21 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 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

22 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 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

23 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

24 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 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 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 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

25 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 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

26 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

27 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

28 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()); 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

29 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

30 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 () 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

31 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

32 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

33 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

34 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=" 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 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

35 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 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

36 Element phoneelement = newphonebookdocument.createelementns("urn:testns", "t:phone"); phonebook.appendchild(phoneelement); phoneelement.appendchild(newphonebookdocument.createtextnode(string.valueof(" "))); Attr typeattr = newphonebookdocument.createattribute("type"); typeattr.setnodevalue("home"); phoneelement.setattributenode(typeattr); logagent.log( phonebook, Severity.ERROR, new DOMSource(phonebook)); 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\"> </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

37 Å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

38 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

39 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

40 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

41 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= OrganizationHSAIdentity= Organization=LandstingA SpecialityCode=ortopedi ID= R456 Aktör: hsatitle=läkare, sjuksköterska Organization=LandstingA SpecialityCode=ortopedi Resurs: Organization=LandstingA SpecialityCode=ortopedi Aktivitet: Read, write Begin: Aktör hsaidentity= hsatitle=läkare organizationhsaidentity= 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

42 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="se " agenttyp="org" orgnamn="carelink AB" parttyp="aga" verksamhetskod="15"/> <rm:part agentid=" " agenttyp="pers" parttyp="pat"/> </rm:entitet> <rm:entitet entitettyp="und"> <rm:part agentid="se " agenttyp="org" orgnamn="carelink AB" parttyp="aga" verksamhetskod="16"/> <rm:part agentid=" " agenttyp="pers" parttyp="pat"/> </rm:entitet> <rm:entitet entitettyp="und"> <rm:part agentid="se " agenttyp="org" orgnamn="jll" parttyp="aga" verksamhetskod="16"/> <rm:part agentid=" " 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

43 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" 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

44 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" 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

45 Å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

46 Hantering av åtaganden med Java Nu ska vi se ett exempel på hur ett enkelt åtagande kan hanteras med Java. final String OBLIGATION_SEND_ = "urn:carelink:bif:obligation:send- "; final String _ADDRESS = "urn:carelink:bif:obligation:attribute-id: address"; // 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_ .equals(obligation.getObligationId())) { // this obligation should only have one attribute and that is // the address assert (obligation.getattributeassignments().get(0).getattributeid().equalsignorecase( _address)); String addr = obligation.getattributeassignments().get(0).getvalueasstring(); send ( addr, "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 . 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

47 Hantering av åtaganden med.net Nu ska vi se ett exempel på hur ett enkelt åtagande kan hanteras med.net. const string OBLIGATION_SEND_ = "urn:carelink:bif:obligation:send- "; const string _ADDRESS = "urn:carelink:bif:obligation:attribute-id: address"; // 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_ .equals(obligation.obligationid)) { // This obligation should only have one attribute and that is // the address if(obligation.attributeassignments.count > 0 && obligation.attributeassignments[0].attributeid.equals( _address)) { string addr = obligation.attributeassignments[0].valueasstring; } Send ( Addr, "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 . 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

48 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

49 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

50 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_ .equals(obligation.getObligationId())) { // This obligation have one attribute only and that is the address assert (obligation.getattributeassignments().get(0).getattributeid().equalsignorecase(attribute_id_ _address)); String addr = obligation.getattributeassignments().get(0).getvalueasstring(); send ( addr, "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

51 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

52 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

53 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_ ) { // This obligation have one attribute only and that is // the address assert(obligation.attributeassignments[0]. AttributeId.ToLower() == ATTRIBUTE_ID_ _ADDRESS); string addr = obligation.attributeassignments[0].valueasstring; send ( addr, "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

54 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

55 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

56 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() 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

57 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

58 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

59 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

60 Å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

61 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

62 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 = " 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

63 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= , 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=" binding="bifbinding" bindingconfiguration="consentserviceportbinding" contract="consentservice.bifconsentporttype" 63

64 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( " 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 = " "; sct.... string result = client.addconsent(sct); Samma metodik kan användas för de övriga metoderna i samtyckestjänstens webbtjänstgränssnitt. 64

65 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