Sammanfattning och specifikationer för POT



Relevanta dokument
Säker åtkomst för vård- och apoteksaktörer. David Skullered

Apotekens Service. federationsmodell

Guide till Inera IdP. Information angående anslutning av Nationella e-tjänster

Version: 2.0 NBS / / AS

Tjänstebeskrivning Extern Åtkomst COSMIC LINK. Version 1.0

Beställningsstöd för anslutning till NTJP

Version: 2.0 NBS / / AS

ehälsomyndighetens nya säkerhetslösning

Lä s mer om SLL:s Regionälä Tjä nsteplättform (RTP)

Läs mer om SLL:s Regionala Tjänsteplattform (RTP)

XML-produkter. -Registret över verkliga huvudmän (RVH) Teknisk handledning för webbtjänst mot RVH (Web Services) Datum: Version: 1.

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.0.1

Datum: Version: Författare: Christina Danielsson Senast ändrad:

Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation.

Anslutningsvägledning. Nationell patientöversikt 2.0

RIV TA Basic Profile 2.1 med intygspropagering RIV Tekniska Anvisningar

Underlag för godkännande av tjänsteproducent

till Säkerhetstjänster x

LAT Lathund anslutning och test

Avtal om Kundens mottagande av intyg från Mina intyg Bilaga 1 - Specifikation av tjänsten mottagande av intyg från Mina Intyg

Pascal tillämpningsanvisning Anrop av Pascal via uthopp från annan applikation

MVK SSO 2.0 Mina vårdkontakter

Inom SITHS e-id finns det certifikat för olika syften som grupperas enligt:

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 3.0

Nationell Tjänsteplattform och säkerhetsarkitektur. Per Brantberg, område arkitektur/infrastruktur

TjänsteID+ Teknisk översiktsdokument etjänstekort, Privata vårdgivare

Mobilt Efos och ny metod för stark autentisering

Anvisning Tjänsteplattformen Driftsättning av Virtualiseringsplattformen

Tjänsteavtal för ehälsotjänst

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.3

Systemadministration. Webcert Fråga/Svar

Beställning av samverkan över flera tjänsteplattformar

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 1.0

Krav på säker autentisering över öppna nät

Godkännande av kundapplikationer

Checklista. Konsumentinförande via Agent, Nationell Patientöversikt (NPÖ)

Beslutsunderlag. Rekommendation för beslut om lösning för hantering av invånarens tidbokning gällande mottagningar som använder flera tidböcker

Tjänsteavtal för ehälsotjänst

PhenixID & Inera referensarkitektur. Product Manager

Att bygga VPN. Agenda. Kenneth Löfstrand, IP-Solutions AB. Olika VPN scenarios. IPsec LAN - LAN. IPsec host - host SSH

Certifikat - Ett av en CA elektroniskt signerat intyg som knyter en publik nyckel till en specifik nyckelinnehavare. Källa: Inera (BIF)

Mobilt Efos och ny metod för stark autentisering

Filleveranser till VINN och KRITA

Felsökningsunderlag. för Nationell patientöversikt, NPÖ. Dokumentationsversion 3.0 Datum

Mobilt Efos och ny metod för stark autentisering

Version Datum Kommentar Etablering av dokumentet Efter första genomgång av Cygate och SITHS PA

Anvisningar för klientdator vid inloggning med certifikat på smarta kort

Hur passar SITHS in i verkligheten? Svensk e-legitimation i förhållande till SITHS?

Anvisningar för användare vid användning av e- Tjänster. Anvisningar och rekommendationer för användare av e-tjänster i samverkan SAML & SSO

Agenda Bakgrunden till Sambi Vad Sambi är Krav som ställs på medlemmarna Erfarenheter från pågående arbeten

RIV Tekniska Anvisningar Kryptografi. Version ARK_

Instruktion. Datum (12) Coverage Dokument id Rev Status? Godkänd. Tillhör objekt -

Topologi. Utförande: I exemplet så kommer vi att utgå från att man gör laborationen i en Virtuell miljö (Virtualbox).

Tillitsramverket. Detta är Inera-federationens tillitsramverk.

ehälsomyndighetens nya säkerhetskrav

Utförande: I exemplet så kommer vi att utgå från att man gör laborationen i en Virtuell miljö (Virtualbox).

Elektronisk tullräkning Sid 1(9) Samverkansspecifikation. Version: 1.0 SAMVERKANSSPECIFIKATION. för. e-tullräkning

<Skriv in datum> <Skriv in ditt namn> <Skriv in ort>

Villkor för anslutning till Nationella tjänsteplattformen

Tjänstespecifik teststrategi. För anslutning till tjänsteplattform för vård- och omsorgsutbud

Instruktioner för inloggning med e-tjänstekort till 3C/Comporto samt installation av kortläsare till e- tjänstekort

RIV Tekniska Anvisningar Basic Profile Valfria tillägg

Certifikatbaserad inloggning via SITHS, tillämpningsexempel

3. Steg för steg. Kör IPv6 på riktigt med FortiGate! Principen är enkel:

Varför Sambi, för vad och vem, samexistens med andra lösningar, svensk e-leg, SITHS, HSA, Skolfederation et cetera (Ulf Palmgren, SKL, CeSam)

Checklista för införande av webbokning ProSang JAVA

RF Kalmar SYSTEMDOKUMENTATION IDP HULTSFRED. Beställare: RF Kalmar. Version:

Manual inloggning Svevac

Avtal om Kundens användning av Identifieringstjänst SITHS

Tjänstespecifik Teststrategi Utomlänsfakturering

BILAGA 2 Tekniska krav Version 0.81

Tekniskt ramverk för Svensk e- legitimation

1 Infrastruktur för RTJP RTJP är placerad i en virtuell miljö som i brist på bättre namn går under benämningen MVK-molnet

Modul 3 Föreläsningsinnehåll

Avtal om Kundens användning av E-identitet för offentlig sektor

Att sätta upp en IPsec-förbindelse med RADIUS-autentisering (med SIP) Lisa Hallingström Paul Donald Bogdan Musat Adnan Khalid

Practical WLAN Security

Testning av Sambi. Testplan. Version PA5. Fil namn: SAMBI_TP.docx Senast sparad: Copyright (c) 2014 IIS

Instruktion för integration mot CAS

Portförändringar. Säkerhetstjänster 2.1 och framåt

Avtal 1 om Agentens. användning av Ineras Tjänster

PDL medarbetaruppdrag vårdgivare vårdenhet Organisation verksamhetschef. NetID drivrutiner kortläsare operativ browser

Instruktion för att kunna använda Säkerhetstjänsternas administrationsgränssnitt

Digital inlämning av årsredovisningar

Avisering av förändringar i tjänstekontrakt för Mina Meddelanden

Felmeddelande - inloggning till Pascal

SITHS Thomas Näsberg Inera

RDT Externt Webbtjänst Gränssnitt

Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1.

Begränsning av patientval vid sammanhållen journalföring (Tillgänglig patient TGP) Funktionsbeskrivning

Kravunderlag inom området Identitet och Åtkomst

ÄR KVALITETSREGISTREN EN GIVEN KÄLLA? Tveksamt

Införande av Skolfederation. Erfarenheter i Sundsvalls kommun

Att sätta upp en IPsec-förbindelse med mobil klient. Lisa Hallingström Paul Donald

Användarhandbok Test. NKRR Utgåva 0.4 Sida: 1 (19) NKRR

Att använda kryptering. Nyckelhantering och protokoll som bygger på kryptering

HSA Anslutningsavtal. HSA-policy

RDT Externt Webbtjänst Gränssnitt

Lathund Beställningsblankett AddSecure Control

Transkript:

0.2 Sammanfattning och specifikationer för POT Kornhamnstorg 61 SE-111 27 Stockholm Sweden 00 00 Telefon: +46 (0)8 791 92 Telefax: +46 (0)8 791 95 www.certezza.net

Innehållsförteckning 1 SAMMANFATTNING... 3 2 SPECIFIKATIONER OCH FÖRTYDLIGANDEN... 3 2.1 GRÄNSSNITT MELLAN RIK KLIENT OCH WS- KLIENT... 3 2.2 CERTIFIKAT FÖR AUTENTISERING AV SLUTANVÄNDARE... 4 2.3 NYTTJANDE AV AUDIENCERESTRICTION INOM POT... 4 2.4 SESSIONSHANTERING UNDER POT... 5 2.5 BEHÖRIGHETSTILLDELNING INOM POT... 5 2.6 NÄTVERKSKOMMUNIKATION MOT WSP UNDER POT... 6 2.7 TJÄNSTEKONTRAKT FÖR POT... 6 2.8 DATOR OCH MILJÖ SOM SKA ANVÄNDAS FÖR RIK KLIENT UNDER POT... 6 2.9 CERTIFIKAT MED TILLHÖRANDE PUBLIKA NYCKLAR FÖR IDP/STS... 7 2.10 ANROP MED OCH UTAN SAML- VALIDERING HOS WSP... 8 Certezza AB Sid 2/8

1 Sammanfattning Detta dokument sammanfattar och specificerar de detaljer som POT-projektet har beslutat ska gälla för ingående komponenter i relation till det POT-scenario som projektet utvärderar. För övergripande information om POT-scenariot hänvisas läsaren till POT:ens flödesschema. 2 Specifikationer och förtydliganden 2.1 Gränssnitt mellan Rik klient och WS-klient Gränssnittet mellan rik klient och WS-klient i POT-scenariot skall implementeras i form av RIV TA-meddelanden (SOAP-meddelanden kompatibla med RIV TA-specifikationerna). Dock krävs ett tillägg i form av den SOAP-header som POT-projektet beslutat skall användas som SAML-intygsbärare. Vid sidan om detta tillägg skall rik klient utföra anrop mot WS-klient helt i enlighet med de specifikationer som RIV TA 2.1 dikterar. Den SOAP-header som används inom POT:en ser ut som följer: <soapenv:envelope xmlns:soapenv= http://schemas.xmlsoap.org/soap/envelope/ xmlns:wsse= http://docs.oasis-open.org/wss/v1.1/oasis-wss-wssecurity-secext- 1.1.xsd xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion"> <soapenv:header> <wsse:security> <saml2:assertion.. </saml2:assertion> </wsse:security> </soapenv:header> Rik klient skall konstruera RIV TA-meddelandet inklusive POT-headern och skicka denna till WS-klienten. Den rika klienten behöver även utrustas med följande interaktiva funktioner: - Initiera autentisering och utkvittens av SAML-intyg från STS. Detta skall ske med WS- Trust 1.3 i enlighet med SSO-lösningen som är byggd för rika klienter av CGI. Certezza AB Sid 3/8

- Initiering av SOAP-request till WS-klient samt uppvisande av anropets resultat samt tidsåtgång. Detta anrop skall specificeras av ansvarig för WS-klient (Ineras tjänsteplattformsförvaltning). Implementation och utveckling av Rik klient för POT:en genomförs av CGI. WS-klient skall konsumera RIV TA-meddelandet från rik klient som bl.a. innehåller SOAPheader med slutanvändarens SAML-intyg, i enlighet med specifikationen som beslutats inom POT-projektet. Vidare skall WS-klienten via tjänsteplattformen utföra ett anrop mot Apotekens Service POT-WSP, vilken svarar olika beroende på om användaren är behörig eller ej, samt redovisa resultatet av anropet för rik klient som ett respons på klientens SOAPrequest. Utformning, implementation och utveckling av WS-klient ansvarar Ineras tjänsteplattformsförvaltning för. 2.2 Certifikat för autentisering av slutanvändare De certifikat som slutanvändaren på rik klient använder mot STS:en för att autentisera sig är av typen SITHS HCC-Funktion men använder sig inte av smart cards som nyckelbärare (de används som mjuka certifikat). Den enda part som i praktiken behöver etablera tillit till dessa slutanvändarcertifikat är den STS som kommer autentisera slutanvändare innan utfärdning av SAML-intyg. 2.3 Nyttjande av AudienceRestriction inom POT AudienceRestriction används inom SAML2-standarden för att uttrycka den tilltänkta mottagaren av ett SAML-intyg, i form av en Service Provider registrad inom ramarna för exempelvis en SAML2-federation såsom Sambi. POT-scenariots specifikationer när det gäller validering av SAML-intyg hos tjänsteproducenter vilka ju ligger bakom en Service Provider dikterar att AudienceRestriction antingen bortses ifrån av bakomliggande WSP eller matchas mot subjektet för det certifikat som aktuell WS-klient använder sig av för att antingen: Etablera MTLS-sessionen mot WSP:n (i fallet direktkontakt mellan WSP och WS-klient) Etablera MTLS-sessionen mot närmast liggande ESB (eller annan form av tjänsteväxel) I det andra fallet ovan krävs att WS-klienten propagerar sitt certifikat som används vid etableringen av dess MTLS-session. WSP:n skall vid sådan validering, vid sidan om själva SAML-intygsvalideringen, matcha den uttryckta mottagaren (FQDN-delen) inom ramarna för AudienceRestriction med värdet i certifikatets subject eller SubjAltName. Tilliten hålls samman på dessa tre nivåer: - Transportnivå - SOAP-nivå - SAML-nivå Certezza AB Sid 4/8

För att förenkla arbetet med validering under POT:en togs följande beslut: - WS-klienten utför ingen SAML-validering i enlighet med POT-scenariot eftersom stöd för detta i så fall behöver implementeras i form av kod. Eftersom POT:ens syfte är att utvärdera intygspropagering påverkar detta beslut inte POT:ens resultat. - WS-klienten propagerar sitt HSAID med hjälp av det certifikat som används för att etablera MTLS-sessionen mot NtJP. NtJP använder sig av befintlig HTTP-header för att propagera HSAID för det certifikat som WS-klienten använder sig av vid anslutning till NtJP (x-rivta-original-serviceconsumer-hsaid). - I SAML-intygen som utfärdas av STS:en skall AudienceRestriction endast innehålla HSAID för WS-klienten i följande format: hsaid:<hsaid> WS-klienten kommer att identifieras med följande HSAID under POT:en: T_SERVICES_SE165565594230-102C och SAML-intyg som ställs ut åt WS-klienten skall alltså reflektera detta HSAID i AudienceRestriction-elementet. Under POT:en kommer inte WSP:n att matcha HSAID för aktörssystemet mot AudienceRestriction i SAML-intyg. Denna typ av extra validering måste ses över innan en framtida produktionssättning av intygspropagering efter slutförd POT, samt belysas i form av rekommendationer i POT:ens slutrapport. 2.4 Sessionshantering under POT Under POT:en kommer endast lösa sessioner att användas gentemot WSP:n, d.v.s. varje SOAP-request/reply är separata anrop som inte går under någon gemensam session (vid sidan om den underliggande TLS-sessionen). Även mellan rik klient och WS-klient skall lösa sessioner användas för att minimera arbetsinsatsen i relation till POT:ens syfte. Innan en framtida produktionssättning av intygspropagering efter genomförd POT måste dock olika former av sessionshantering diskuteras och utvärderas för att integrationseffektiviteten skall bli optimal samt passa de användningsmönster som finns för aktuella tjänster. 2.5 Behörighetstilldelning inom POT För att minimera komplexitet och arbetsinsats kommer behörigheter på WSP-sidan att tilldelas på HSAID för subjektet som beskriv av SAML-intyg. Ett HSAID kommer att ha behörighet och ett annat kommer ej att ha behörighet. Dessa två HSAID ser ut som följer: Behörig användare: T_SERVICES_SE165565594230-107H Obehörig användare: T_SERVICES_SE165565594230-107J Certezza AB Sid 5/8

Apotekens Service ansvarar för att tillämpa behörighetstilldelningen i sin WSP för respektive HSAID under POT:en. 2.6 Nätverkskommunikation mot WSP under POT Under POT:en kommer all trafik till/från Apotekens Service WSP att gå över Internet över TCP port 443 (MTLS-session). Apotekens Service får använda valfritt certifikat på sin WSP för att etablera MTLS-sessionen mot tjänsteplattformen (tjänsteplattformens testmiljö). Följande IP-adresser är involverade i kommunikationen (endast IPv4 används under POT): Tjänsteplattformens externt interface: X.X.X.X Apotekens Service WSP externt interface: X.X.X.X Följande ciphersuite skall användas mellan tjänteplattformen och Apotekens Service WSP: TLS_RSA_WITH_RC4_128_SHA 2.7 Tjänstekontrakt för POT Tjänstekontrakt för POT:en ska vara det som ingår i ref-appen för RIV-TA 2.1. Ref-app hittas under: rivta.se/source och tjänstekontraktet finns under RefApp/rivta-bp- 21/java/cxf/trunk/rivta-bp21-refapp-schemas/src/main/resources/schemas Ineras tjänsteplattformsförvaltning ansvarar under POT:en för att hantera WSDL:er, XSD:er och andra element som berör RIV TA. Ineras tjänsteplattformsförvaltning bistår även Apotekens Service med anslutning av WSP till NtJP samt åtföljande av RIV TA configstyrning (Konfigurationsstyrning tjänstedomäner) under POT:en. 2.8 Dator och miljö som ska användas för rik klient under POT Under POT:en kommer den dator som kommer användas som rik klient att placeras hos Inera på ett nätverkssegment där erfordelig åtkomst till STS och WS-klient finns tillgänglig. CGI specificerar krav på denna dator i relation till den applikation som kommer utvecklas för rik klient. Applikationen för rik klient kommer att utvecklas i.net-miljö. Applikationen skall ha i sitt gränssnitt implementera två interaktiva funktioner som utför ett behörigt, respektive ett obehörigt anrop i enlighet med den behörighetsstyrning som WSP:n hos Apotekens Service tillämpar. Applikationen skall vidare ha stöd för att logga samtliga anrop med tillhörande anropssvar till en lokal loggfil i filsystemet. Denna logg skall kunna användas för felsökning under POT:ens testfas. Vidare skall applikationen redovisa svarstider från STS respektive WSklient, vilket bl.a kommer användas för grundläggande prestandamätning under testfasen. Certezza AB Sid 6/8

2.9 Certifikat med tillhörande publika nycklar för IdP/STS Nedan finns Base64-kodad sträng för certifikat och tillhörande publik nyckel för den IdP/STS som används inom POT:en. -----BEGIN CERTIFICATE----- MIIDwTCCAqmgAwIBAgICWZ8wDQYJKoZIhvcNAQEFBQAwXjELMAkGA1UEBhMCU0Ux ETAPBgNVBAgTCEphbXRsYW5kMQ8wDQYDVQQKEwZMb2dpY2ExDTALBgNVBAsTBFRl c3qxhdaabgnvbamte0xvz2ljysbuzxn0ifjvb3qgq0ewhhcnmtiwoti3mtmznjm4 WhcNMzIwOTIyMTMzNjM4WjCBpjELMAkGA1UEBhMCU0UxGDAWBgoJkiaJk/IsZAEZ FghTZXJ2aWNlczERMA8GA1UECBMISmFtdGxhbmQxEjAQBgNVBAcTCU9zdGVyc3Vu ZDEPMA0GA1UEChMGTG9naWNhMQ0wCwYDVQQLEwRUZXN0MR4wHAYDVQQDExVsb2N0 b3qudxr2lmjpzi5vc3quc2uxfjaubgnvbautdvnfmtm0odc1mjk5nzewgz8wdqyj KoZIhvcNAQEBBQADgY0AMIGJAoGBAOn3BvfDmlU8sjsRcsAi2N6cWd27NKI53r6g RY1ttDAhPZ7upbg85vgFH3+BY+BMvDVkwU8/PUmiMBpvV219izSII3cPYrfX2qZc Xq6aBlYcTG0VBRieIJ+AoCZ9JNnyNqjGBcZeIa0vAGQi5zfug4TBO8VhXczkQkUX jsez9r5lagmbaagjgcmwgcawoayikwybbquhaqeeldaqmcggccsgaqufbzabhhxo dhrwoi8vb2nzcc5iawyub3n0lnnlojg4odgvmakga1udewqcmaawcwydvr0pbaqd AgWgMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0 ZTAdBgNVHQ4EFgQUe3tK34SeMKy2F5sHg9baFKNWVdUwHwYDVR0jBBgwFoAUHI0W +7uLYp1bdV8Ukqdn6MQzHtEwDQYJKoZIhvcNAQEFBQADggEBALIxbKRyIvi7o3nq kq6gt8ept7smxvfcqoabaxo0l0p34axtgvd2zgf9eki+otv5zwkphjakem8syhub lrmaitp7eblwev4rh+6wplzxiloflmxzdhctg71dhlzwyyw36pxja2da9xspx4kv TjYBkW957hy6P01G8pHy08eGhKOFr6wBEc54zdPTm9kdvacbffqopy46QtGyw8Rn Wx/7afEpZ8JOlDklEFw9ArfxX6Rw7wMzGhjx6fJvl7BPD9OxxJm+e/FypP2DWZPj ktdblpaafqcn8uuotkzp3qrn3r9kc2y61wb7up5wtkpygt96kakmxqtge1bfl7xm 8oWFZoo= Certezza AB Sid 7/8

-----END CERTIFICATE----- 2.10 Anrop med och utan SAML-validering hos WSP Under POT:en kommer Apotekens Service WSP att etableras som två instanser med separata URL:er där den ena URL:en har SAML-validering aktiverat och den andra URL:en har SAMLvalidering avaktiverat. Följande URL:er används för att nå respektive instans: Med SAML-validering aktiverat: https://... Utan SAML-validering aktiverat: https://... Certezza AB Sid 8/8