Sammanfattning och specifikationer för POT

Transkript

1 0.2 Sammanfattning och specifikationer för POT Kornhamnstorg 61 SE Stockholm Sweden Telefon: +46 (0) Telefax: +46 (0)

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

3 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= xmlns:wsse= 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

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

5 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_SE C 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_SE H Obehörig användare: T_SERVICES_SE J Certezza AB Sid 5/8

6 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

7 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

8 -----END CERTIFICATE 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: Utan SAML-validering aktiverat: Certezza AB Sid 8/8