Regionförbundet i Kalmar Län Barnhälsodatapiloten - Slutrapport Bilaga 1-15 2010-03-01
Innehållsförteckning 1. Bilaga 1 Avtal...5 2. Bilaga 2 - Testprotokoll BHDP Hultsfred SSK mot edos...8 2.1 Inloggning med SITHS-certifikat mot Apotekets edos...8 2.1.1 Förutsättningar:...8 2.1.1.1 Vår testmiljö...8 2.1.1.2 Förberedelser inför test...8 2.1.2 Testgenomförande och resultat...8 2.1.2.1 Test 1, 2010-02-17 kl 13.30...8 2.1.2.2 Test 2 2010-02-18...12 2.1.3 Slutsatser...13 3. Bilaga 3 Testprotokoll Teknik...14 3.1 Inloggning med SITHS-certifikat...14 3.2 SAML...14 3.3 Loggning...15 4. Bilaga 4 Testprotokoll Teknik Vimmerby IDP...16 Testprotokoll från Vimmerby med PortWise som IDP...16 4.1 Inloggning med SITHS-certifikat...16 4.2 SAML...17 4.3 Loggning...17 4.4 Följande innebär testsituationer som inte skall fungera...17 4.4.1 SITHS...18 4.4.2 SAML...18 5. Bilaga 5 Testprotokoll Emmaboda KalmarLT UR...19 5.1 Uppkoppling mot Landstinget...19 6. Bilaga 6 - Testprotokoll Emmaboda KalmarLT SP...24 6.1 Uppkoppling mot Landstinget...24 7. Bilaga 7 Testprotokoll teknik KalmarLT SP...28 7.1 Inloggning med SITHS-certifikat...28 2
7.2 SAML...28 7.3 Loggning...29 8. Bilaga 8 Testprotokoll teknik Hultsfred IdP...30 8.1 Inloggning med SITHS-certifikat...30 8.2 SAML...30 8.3 Loggning...31 9. Bilaga 9 - Testprotokoll Hultsfred mot Landstinget...32 9.1 Uppkoppling mot Landstingets SP...32 9.2 Slutsatser tester...35 10. Bilaga 10 Testprotokoll Hultsfred mot Emmaboda...36 10.1 Steg 3: Uppkoppling mot skolhälsovårdssystemet...36 10.2 Slutsatser förberedande tester...39 10.3 Test av behörig sköterskas inloggning till Profdoc från lånad dator (ej egen arbetsplats)...40 11. Bilaga 11 Testprotokoll teknik 100220 EmmabodaIDP KalmarLtSP.41 11.1 Inloggning med SITHS-certifikat...41 11.2 SAML...41 11.3 Loggning...42 12. Bilaga 12 Testprotokoll teknik 100220 HultsfredIDP EmmabodaSP..43 12.1 Inloggning med SITHS-certifikat...43 12.2 SAML...43 12.3 Loggning...44 13. Bilaga 13 Testprotokoll teknik 100220 VimmerbyIDP EmmabodaSP 45 13.1 Loggning...46 14. Bilaga 14 Teknisk dokumentation Emmaboda...47 14.1 BHDP MobilityGuard SP/IDP i Emmaboda...47 14.1.1 Server...47 14.1.2 Nätverk...47 14.1.3 SAML-funktioner...47 14.1.4 Målsystem...47 15. Bilaga 15 Teknisk dokumentation Vimmerby...48 3
15.1 Installationen i Vimmerby...48 15.1.1 Nod 1...48 15.1.2 Nod 2...48 15.1.3 Federation...49 15.1.4 Autentisering...49 16. Bilaga 16 Teknisk dokumentation Hultsfred...50 4
1. Bilaga 1 Avtal Serviceavtal för medlemmar Definition av ingående parter i avtalet 1. Avtalets tillämpningsområde Syftet med detta avtal är att enas om en gemensam uppsättning riktlinjer och regler för att säkerställa flexibel och väl fungerande autentiserings samt efterlevnad av rättsliga skyldigheter. Omfattningen av detta avtal är begränsat enbart för inter-organisatoriska nätverk med anknytning till sådan autentisering och villkoren för deras användning. Avtalet påverkar inte eventuella avtal mellan federationen ledamöter och tjänsteleverantörer om innehållet i de tjänster, priser, nyttjanderätt eller eventuella skulder skadeersättning på grund av dem. Avtalet kompletteras med följande åtta bilagor: 2. Omfattningen av operatörernas skyldigheter Verksamhetsutövaren skall tillhandahålla alla federationen medlemmarna med tjänster inom autentisering. Operatören sträva efter maximal tillgänglighet och tillgång till användning. Under normala omständigheter skall autentiseringstjänster vara tillgängliga under dygnets alla timmar. Detta skall dock regleras i SLA för tjänsten. Operatören ska informera Federation ledamöter namn och kontaktuppgift, till vilka frågeställningar som rör detta avtal kan ställas. Operatören kan också skriva avtal med externa tjänsteleverantörer (Federation Partners), samt med utländska samarbetspartners som tillhandahåller autentisering. Operatören är skyldig att genomföra säkerhetsanalyser på regelbunden basis och presentera resultaten för federationsmedlemmarna för att säkerställa kontinuerlig drift samt tjänstens integritet. 3. Skyldigheter för Federationsmedlem Federationsmedlem - Skall åta sig ansvaret för lämplig användning av tjänsten och - Skall meddela operatören dess tekniska och administrativa kontaktpersoner som rör detta avtal. Innan tjänsten kan inledas skall medlemmen presentera hur dess användaradministration skall genomföras. Om Federationsmedlemen skall agera som autentiseringsorganisation förbinder den sig att - Se till att slutanvändaren har förbundit sig att följa de regler och riktlinjer för användning som anges i annat avtal. 5
- Om autentisering kräver utlämnande av personuppgifter, skall giltigt tillstånd inhämtas av slutanvändarna. - Tillse att de alla personuppgifter är korrekta och hålls aktuella När Federationsmedlemen agerar som tjänsteleverantör - Skall denne ansvara för alla tjänster som levereras till federationen av institut och andra enheter under tjänsteleverantörens ledning. 4. Begränsning av ersättning om andra federationens medlemmar, externa tjänsteleverantörer eller slutanvändare Verksamhetsutövaren skall inte hållas ansvarig för skador på förbundets medlemmar eller dess slutanvändare och Federationsmedlem skall inte hållas ansvarig för skador för operatören på grund av användningen av autentiseringstjänsterna, driftstopp eller andra frågor som rör användningen av tjänsterna. Federationsmedlem är skyldig att genomföra säkerhetsanalyser på regelbunden basis och presentera resultaten för operatören för att säkerställa kontinuerlig drift samt tjänstens integritet. 5. Reglering av driftsavbrott av tjänsten (a) Avbrott för tillhandahållandet av tjänsten Utan separat ansvar för ersättning, ska operatören ha rätt att avbryta tillhandahållandet av tjänster till förbundets medlemar antingen helt eller delvis i följande situationer: (a) Om Federationsmedlem begår ett väsentligt avtalsbrott, skall verksamhetsutövaren ha rätt att avbryta tillhandahållandet av tjänster tills federationsmedlemen fullgör sina skyldigheter igen; (b) Om mindre överträdelser som begåtts av federationsmedlems är återkommande och fortsätter trots operatörens skriftliga påminnelser ska operatören ha rätt att avbryta tillhandahållandet av tjänster tills federationsmedlemen fullgör sina skyldigheter igen; (c) Om federationsmedlemen genom sitt handlande eller försummelse orsakat försämrad kvalitet eller andra negativa effekter på funktionalitet i operatörens servrar, utan åtgärd vidtages (d) Om det blir nödvändigt att avbryta tjänsten på grund av reparation, förbättring och förebyggande verksamhet underhåll. Operatören skall ha rätt att säga upp avtalet omedelbart, om tjänsten har avbrutits i minst 60 dagar. En rimlig tid skall reserveras för operatören att rätta till eventuella brister och defekter som upptäckts i innehåll och kvalitet på tjänsterna. 6. Personuppgifter och datasäkerhet Båda parter har åtagit sig att uppfylla de skyldigheter som följer av gällande lagstiftning om skydd av personuppgifter samt behandling och utlämnande av personuppgifter, skyldigheter avseende icke-spridning och sekretess, samt en tillräcklig nivå av datasäkerhet för tjänsterna. 6
7. Samarbete Båda parter är överens om att informera den andra parten om förändringar i sina kontaktuppgifter. 10. Giltighetstid, ändring och uppsägning av avtalet Avtalet skall gälla tills vidare. Uppsägningstiden för uppsägning av avtalet skall vara sex månader. 11. Tvister Tvister rörande detta avtal skall lösas i första hand genom förhandlingar. Om frågan inte kan lösas genom förhandlingar, skall eventuella tvister lämnas till ordinarie domstol vid operatören. 7
2. Bilaga 2 - Testprotokoll BHDP Hultsfred SSK mot edos Kommun: Hultsfreds kommun 2.1 Inloggning med SITHS-certifikat mot Apotekets edos. 2.1.1 Förutsättningar: 2.1.1.1 Vår testmiljö Våra sjuksköterskor jobbar nästan uteslutande via tunna klienter, kopplade med RDP mot ett MS Terminal Server-kluster bestående av fyra virtualiserade 1 Windows 2003 TS-servrar. De terminaler som används i Hultsfreds kommun varierar i ålder och de äldsta (HP t5300) är ca sex år gamla. OS-versionerna är Windows CE, Linux eller Windows XPe. För att på enklaste sätt utrusta dessa arbetsplatser med smartcardläsare är planen att byta ut tangentborden mot tangentbord med inbyggd kortläsare, i vårt fall HP ED707AA, som kostar ca 315 kr. 2.1.1.2 Förberedelser inför test På varje terminalserver installerades Net-ID 5.3.0.28 T0002. Sedan tidigare låg Nexus Personal på servrarna för de användare som använder mjuka bankid-certifikat i olika sammanhang, och vi visste inte hur detta skulle påverka korthanteringen. Det nya tangentbordet kopplades först in på en modern, nyinköpt terminal HP t5540 med Windows CE. Kortläsaren fungerade utan några inställningar eller uppdateringar av terminalprogramvara. Vi testade med mitt RA-kort och testkort och upplevde att kortläsaren fungerade bra i TS-miljön. Vi bytte ut terminalen mot en mycket äldre modell, HP t5300, också den med Windows CE, och nu krävdes uppdatering av Windows CE för att det nya tangentbordet skulle fungera. Vi upplevde dock störningar som yttrade sig i att kortläsaren fungerade men inte alltid tangentbordet. Man var tvungen att slita ut och sätta in USB-kontakten titt som tätt. En annan stor komplikation var att uppdateringen av OS inte fanns kvar vid omstart av terminalen. Vi kommer att fortsätta försöken med att få även dessa gamla terminaler att fungera med det nya tangentbordet. 2.1.2 Testgenomförande och resultat 2.1.2.1 Test 1, 2010-02-17 kl 13.30 Två sjuksköterskor hade utsetts för att testa, men vi valde att endast låta den ena, Erika, aktivera sin kortinloggning hos Apoteket. Anledningen var att deras arbetsplatser ännu inte anpassats för att hantera kortläsare och vi ville inte riskera att störa bådas möjligheter att komma åt edos, i den händelse något skulle gå snett. 1 VMware 3 8
Testmiljön bestod av en gammal HP t5300 med uppdaterat OS (som inte startats om!). Först testade jag att logga in mot edos från terminalen. På så sätt fick de båda sjuksköterskorna se förloppet. Jag surfade till edos.apoteket.se och valde SITHS som inloggningsmetod: Om man inte satt i kortet i kortläsaren får man en uppmaning: Apoteket hämtar endast ut Telias d-legitimation från kortet och ber mig bekräfta att det är detta jag vill använda: 9
Rutan för pinkodsinmatning dyker upp, och nu har Nexus Personal blandat sig i leken(!): Varför det är Nexus Personal som frågar efter min pinkod vet jag inte, men det fungerar lika bra som när NetID frågar. Eftersom mitt personnummer inte är en godkänd användare i edos-systemet släpps jag inte in. 10
Nu är det Erikas tur. Jag stänger webbläsaren och loggar ut ur domänen. Erika loggar in och eftersom det är första gången hon loggar in i TS-miljön sedan NetID installerades, får hon en fråga om hon vill installera certifikatet, som av någon anledning inte kan kontrolleras mot SITHS CA v3. Vi har inte hunnit undersöka varför denna varning dyker upp och hur vi kan få bort den, men det är inte bra att få en säkerhetsvarning när man testar ett nytt, säkrare system! 11
Hon lugnades emellertid och klickade på Ja-knappen. Därefter startade hon webbläsaren, som är MS Internet Explorer 7.0, och proceduren ovan upprepades på samma sätt, med den skillnaden att hon accepterades vid inloggningen till edos, och kunde testa att hon hade tillgång till samma funktionalitet som tidigare. Vi avslutade testet genom att Erika loggade ut från edos, och gick till den gamla sidan för inloggning: och kontrollerade om hon fortfarande kunde logga in med användarnamn och lösenord, men det var tvärstopp. Ett meddelande talade om att hon skulle använda den nya inloggningsmetoden i fortsättningen. 2.1.2.2 Test 2 2010-02-18 Dagen efter den första testen som ägde rum i IT-kontorets lokaler, åkte en tekniker ut till Erikas ordinarie arbetsplats, med en ny terminal (HP t5540) och ett nytt tangentbord. Arbetsplatsen ligger i en fiberansluten fastighet ca 3 km från kommunhuset. Inloggning med kort testades återigen och allt fungerade perfekt. Därefter åkte tekniker och sköterska till hennes andra arbetsplats, ett särskilt boende i Vena, och bytte även här ut terminal och tangentbord. Den här fastigheten är uppkopplad med en hyrd förbindelse på 2 Mbit/s, men även här fungerade inloggning till edos utan problem. 12
2.1.3 Slutsatser Vi hade inte räknat med att det skulle vara några problem med själva inloggningen till edos, så de här testerna kom mer att handla om hur väl tangentboden med inbyggd kortläsare och programvaran på terminalservrarna skulle fungera. I stort är vi mycket nöjda med hur pass enkelt det varit att aktivera kortläsarfunktionalitet i TS-miljön. Innan vi breddar införandet av SITHS-kort bland sköterskorna bör vi dock lösa problemen med de gamla terminalerna. Annars måste vi räkna med högre kostnader för utbyte av arbetsplatsutrustning. Fortsatt utredning om säkerhetsvarningen som helst ska leda fram till att vi kan slippa den är också angelägen. Vi bör identifiera alla som använder sig av Nexus Personal på terminalservrarna och uppgradera dem med SITHS-kort, så att vi kan avinstallera Nexus från servrarna. 13
3. Bilaga 3 Testprotokoll Teknik 3.1 Inloggning med SITHS-certifikat - Klient sidan, Kolla att NetID klienten få upp valet av certifikat, och att bara SITHS certifikat är med. - Klient sidan, kolla att inloggning sker över en SSL kanal med minst 128 bitars kryptering, helst 256-bitars. - Server sidan, verifiera att bara SSLv3 eller TLSv1 används som protokoll. - Server sidan, verifiera att inga "osäkra" eller "svaga" SSL eller TLS cipher suites tillåts (t.ex. null, <128bitars, anonyma DH, o.s.v.) - Server sidan, kolla att certifikatet är från en godkänt SITHS CA. - Server sidan, kolla att CRL eller OCSP uppslag görs på rätt sätt. T.ex. att CRL hämtas vid rätt intervall, att OCSP svaret är rätt signerat av utgivare o.s.v. - Server sidan, (om OCSP används) kolla att det är mojligt att tar fram OCSP svaret från utgivaren för eventuella uppföljning. 3.2 SAML - IdP sidan, Kolla att eventuella signatur på inkomna AuthnRequests stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den SP som skickade anropet. - IdP sidan, Kolla att den genererade SAML Response innehåller rätt användare från inloggade SITHS certifikat. 14
- IdP sidan, Kontrollera SAML innehåll att följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. - SP sidan, Kolla att eventuella signaturer på inkomna Response stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den IdP som skickade anropet. - SP sidan, Kontrollera SAML innehåll att den följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. T.ex. Om detta är en SP- Initiated ska InResponseTo stämmer, om det är en Unsolicited Response ska inte InResponseTo finnas, o.s.v. 3.3 Loggning - IdP Sidan, En inloggning ska kunna följas i log från första autenticering fram till skapandet av SAML Response. - SP Sidan, En inloggning ska kunna följas från mottagandet av SAML Response till godkänt inloggning i applikationen. 15
4. Bilaga 4 Testprotokoll Teknik Vimmerby IDP Testprotokoll från Vimmerby med PortWise som IDP. 4.1 Inloggning med SITHS-certifikat - Klient sidan, Kolla att NetID klienten få upp valet av certifikat, och att bara SITHS certifikat är med. OK Vi tillåter kort med följande CA: SITHS CA TEST v3 och SITHS CA v3 - Klient sidan, kolla att inloggning sker över en SSL kanal med minst 128 bitars kryptering, helst 256-bitars. OK - Server sidan, verifiera att bara SSLv3 eller TLSv1 används som protokoll. OK Vi tillåter inga andra protokoll än TLS v1.0 och SSL v3.0 - Server sidan, verifiera att inga "osäkra" eller "svaga" SSL eller TLS cipher suites tillåts (t.ex. null, <128bitars, anonyma DH, o.s.v.) OK Vi tillåter följande Cipher suites RSA_AES_256_CBC_SHA RSA_3DES_EDE_CBC_SHA RSA_AES_128_SHA RSA_RC4_128_SHA RSA_RC4_128-MD5 - Server sidan, kolla att certifikatet är från en godkänt SITHS CA. OK Vi tillåter kort med följande CA: SITHS CA TEST v3 och SITHS CA v3 - Server sidan, kolla att CRL eller OCSP uppslag görs på rätt sätt. T.ex. att CRL hämtas vid rätt intervall, att OCSP svaret är rätt signerat av utgivare o.s.v. OK vi använder oss av CRL under testen och hämtar idag med ett intervall på 10 min. (För SITHS Test kort använder vi oss av http://www.carelink.se/sithsca/test-crl0003.crl) - Server sidan, (om OCSP används) kolla att det är mojligt att tar fram OCSP svaret från utgivaren för eventuella uppföljning. Använder oss av CRL under testen 16
4.2 SAML - IdP sidan, Kolla att eventuella signatur på inkomna AuthnRequests stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den SP som skickade anropet. OK Vi validerar signaturen med konfigurerat Cert. - IdP sidan, Kolla att den genererade SAML Response innehåller rätt användare från inloggade SITHS certifikat. OK - IdP sidan, Kontrollera SAML innehåll att följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. OK - SP sidan, Kolla att eventuella signaturer på inkomna Response stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den IdP som skickade anropet. N/A - SP sidan, Kontrollera SAML innehåll att den följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. T.ex. Om detta är en SP- Initiated ska InResponseTo stämmer, om det är en Unsolicited Response ska inte InResponseTo finnas, o.s.v. N/A 4.3 Loggning - IdP Sidan, En inloggning ska kunna följas i log från första autenticering fram till skapandet av SAML Response. OK - SP Sidan, En inloggning ska kunna följas från mottagandet av SAML Response till godkänt inloggning i applikationen. N/A 4.4 Följande innebär testsituationer som inte skall fungera 17
4.4.1 SITHS - Om CRL/OCSP är otillgängligt eller svara med unknown/revoked ska inloggning misslyckas. OK 4.4.2 SAML - SP Sidan, kolla att servern avslå en SAML Response med ingen eller en felaktigt signatur. N/A - SP Sidan, kolla att servern avslå en SAML Response signerat med en annan certifikat än den som är konfigurerat för den IdP i frågan. N/A - IdP Sidan, kolla att servern avslå en SAML Request med ingen eller en felaktigt signatur. OK - IdP Sidan, kolla att servern avslå en SAML Request signerat med en annan certifikat än den som är konfigurerat för den SP i frågan. OK 18
5. Bilaga 5 Testprotokoll Emmaboda KalmarLT UR Kommun: Emmaboda kommun 5.1 Uppkoppling mot Landstinget Med Unsolicited Response Handhavande: Surfa mot pd.emmaboda.se Ange SITHS som legitimationssätt Ange din sexsiffriga kod Förutom Emmabodas egna testsida och inloggning mot ProfDoc kan man nu klicka på länk mot Landstingets tjänst (testsida) och via Unsolicited Response komma åt den. Har testat på PC med XP och de senaste uppdateringarna installerade. Eftersom vi inte har Landstingets och Mobilityguards testserver med i vår ordinarie DNS så var vi tvungna att lägga med dem i host-filen. 193.235.216.42 sp001.ltkalmar.se 195.67.95.107 login.emmaboda.se 195.67.95.107 pd.emmaboda.se 195.67.95.107 m01-mg-local.login.emmaboda.se 195.67.95.107 m01-bhdp-test.login.emmaboda.se 195.67.95.107 m01-rdp-profdoc.login.emmaboda.se 195.67.95.117 m01-mg-ident-0.login.emmaboda.se Allt fungerade som det var tänkt och inga frågetecken dök upp. De inklistrade skärmbilderna säger ganska mycket hur enkelt det var. 19
Starta med att gå mot adressen pd.emmaboda.se 20
21
22
23
6. Bilaga 6 - Testprotokoll Emmaboda KalmarLT SP Kommun: Emmaboda kommun 6.1 Uppkoppling mot Landstinget Man börjar initieringen genom att gå mot denna adress: https://sp001.ltkalmar.se/necs/samlserviceprovider?res=/csexamplewebapp/index.jsp&idp=https://m01-mg-local.login.emmaboda.se/samlv2/idp/metadata/7 Handhavande: Välj länk mot sp Ange SITHS som legitimationssätt Ange din sexsiffriga kod Man ser nu testsidan Har testat på PC med XP och de senaste uppdateringarna installerade. Eftersom vi inte har Landstingets och Mobilityguards testserver med i vår ordinarie DNS så var vi tvungna att lägga med dem i host-filen. 193.235.216.42 sp001.ltkalmar.se 195.67.95.107 login.emmaboda.se 195.67.95.107 pd.emmaboda.se 195.67.95.107 m01-mg-local.login.emmaboda.se 195.67.95.107 m01-bhdp-test.login.emmaboda.se 195.67.95.107 m01-rdp-profdoc.login.emmaboda.se 195.67.95.117 m01-mg-ident-0.login.emmaboda.se Allt fungerade som det var tänkt och inga frågetecken dök upp. De inklistrade skärmbilderna säger ganska mycket hur enkelt det var. 24
Starta med att gå mot adressen (i ett skarpt läge hade denna adress givetvis varit en ikon som användaren bara hade dubbelklickat på): https://sp001.ltkalmar.se/necs/samlserviceprovider?res=/csexamplewebapp/index.jsp&idp=https://m01-mg-local.login.emmaboda.se/samlv2/idp/metadata/7 25
26
27
7. Bilaga 7 Testprotokoll teknik KalmarLT SP 7.1 Inloggning med SITHS-certifikat - Klient sidan, Kolla att NetID klienten få upp valet av certifikat, och att bara SITHS certifikat är med. Ingen inloggning hos SP - Klient sidan, kolla att inloggning sker över en SSL kanal med minst 128 bitars kryptering, helst 256-bitars. Ingen inloggning hos SP - Server sidan, verifiera att bara SSLv3 eller TLSv1 används som protokoll. Ingen inloggning hos SP - Server sidan, verifiera att inga "osäkra" eller "svaga" SSL eller TLS cipher suites tillåts (t.ex. null, <128bitars, anonyma DH, o.s.v.) Ingen inloggning hos SP - Server sidan, kolla att certifikatet är från en godkänt SITHS CA. Ingen inloggning hos SP - Server sidan, kolla att CRL eller OCSP uppslag görs på rätt sätt. T.ex. att CRL hämtas vid rätt intervall, att OCSP svaret är rätt signerat av utgivare o.s.v. Ingen inloggning hos SP - Server sidan, (om OCSP används) kolla att det är mojligt att tar fram OCSP svaret från utgivaren för eventuella uppföljning. Ingen inloggning hos SP 7.2 SAML - IdP sidan, Kolla att eventuella signatur på inkomna AuthnRequests stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den SP som skickade anropet. Ingen IdP hos Lanstinget - IdP sidan, Kolla att den genererade SAML Response innehåller rätt användare från inloggade SITHS certifikat. Ingen IdP hos Lanstinget 28
- IdP sidan, Kontrollera SAML innehåll att följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. Ingen IdP hos Lanstinget - SP sidan, Kolla att eventuella signaturer på inkomna Response stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den IdP som skickade anropet. OK från alla IdP:er - SP sidan, Kontrollera SAML innehåll att den följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. T.ex. Om detta är en SP- Initiated ska InResponseTo stämmer, om det är en Unsolicited Response ska inte InResponseTo finnas, o.s.v. OK från Hultsfred och Emmaboda, Vimmerby stödja inte Unsolicited Response metoder. 7.3 Loggning - IdP Sidan, En inloggning ska kunna följas i log från första autenticering fram till skapandet av SAML Response. Ingen IdP hos Lanstinget - SP Sidan, En inloggning ska kunna följas från mottagandet av SAML Response till godkänt inloggning i applikationen. OK, inkommande SAML meddelandet loggas med unik ID. 29
8. Bilaga 8 Testprotokoll teknik Hultsfred IdP 8.1 Inloggning med SITHS-certifikat - Klient sidan, Kolla att NetID klienten få upp valet av certifikat, och att bara SITHS certifikat är med. OK - Klient sidan, kolla att inloggning sker över en SSL kanal med minst 128 bitars kryptering, helst 256-bitars. OK (128bitar med IE, 256bitar med FF) - Server sidan, verifiera att bara SSLv3 eller TLSv1 används som protokoll. OK (Inga SSLv2 tillåts) - Server sidan, verifiera att inga "osäkra" eller "svaga" SSL eller TLS cipher suites tillåts (t.ex. null, <128bitars, anonyma DH, o.s.v.) OK - Server sidan, kolla att certifikatet är från en godkänt SITHS CA. OK - Server sidan, kolla att CRL eller OCSP uppslag görs på rätt sätt. T.ex. att CRL hämtas vid rätt intervall, att OCSP svaret är rätt signerat av utgivare o.s.v. OK (Kontroll med CRL hämtade med HTTP) - Server sidan, (om OCSP används) kolla att det är mojligt att tar fram OCSP svaret från utgivaren för eventuella uppföljning. Ej testat, CRL används. Produkten loggar hela OCSP svaret när det finns dock. 8.2 SAML - IdP sidan, Kolla att eventuella signatur på inkomna AuthnRequests stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den SP som skickade anropet. OK, detajler finns i logg. - IdP sidan, Kolla att den genererade SAML Response innehåller rätt användare från inloggade SITHS certifikat. 30
OK, subjekt innehåller bara HSA-ID - IdP sidan, Kontrollera SAML innehåll att följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. OK - SP sidan, Kolla att eventuella signaturer på inkomna Response stämmer och är signerade med en certifikat som är registrerade (konfig eller Metadata) för den IdP som skickade anropet. Ingen SP hos Hultsfred - SP sidan, Kontrollera SAML innehåll att den följa de principer och standarder som finns inom BHDP projektet och SAML 2.0 i allmänhet. T.ex. Om detta är en SP- Initiated ska InResponseTo stämmer, om det är en Unsolicited Response ska inte InResponseTo finnas, o.s.v. Ingen SP hos Hultsfred 8.3 Loggning - IdP Sidan, En inloggning ska kunna följas i log från första autenticering fram till skapandet av SAML Response. OK, alla loggrader innehåller samma unik transaktionsid för sessioner. - SP Sidan, En inloggning ska kunna följas från mottagandet av SAML Response till godkänt inloggning i applikationen. Ingen SP hos Hultsfred 31
9. Bilaga 9 - Testprotokoll Hultsfred mot Landstinget Kommun: Hultsfreds kommun 9.1 Uppkoppling mot Landstingets SP Inloggning mot Landstingets SP-funktion. När användaren kopplas upp kommer hon till en dummysida som rapporterar vilken information SP noterat om klienten. Handhavande: Välj länk till Kalmar Landsting Test Gå förbi certifikatvarningen Ange SITHS som legitimationssätt Ange din sexsiffriga kod Kontrollera vilken information SP redovisar i vänsterspalten Fyll i förutsättningar och resultat här. Vi testar med en bärbar dator (den som använts för de flesta tester med SAML och SITHS): Compaq nc8430, Intel Core2 T7200 2GHz, 2 GB RAM Win XP Professional SP3, Internet Explorer 8 Eftersom vi inte lagt upp de externa resurserna i våra DNS:er har vi lagt till dem i /etc/hosts: 193.235.216.42 sp001.ltkalmar.se 195.67.95.107 login.emmaboda.se 195.67.95.107 pd.emmaboda.se 195.67.95.107 m01-mg-local.login.emmaboda.se 195.67.95.107 m01-bhdp-test.login.emmaboda.se 195.67.95.107 m01-rdp-profdoc.login.emmaboda.se 195.67.95.117 m01-mg-ident-0.login.emmaboda.se OBS! I vår nuvarande konfiguration måste kortet sitta i redan från start. Jag börjar med länken till SP-initierad session https://sp001.ltkalmar.se/necs/samlserviceprovider?res=/csexamplewebapp/ index.jsp&idp=https://idp.hultsfred.se/neidp/md Den känner inte automatiskt av att jag måste använda SITHS-certifikatet. Därför får jag en fråga om vilket certifikat jag vill använda. 32
Jag väljer SITHS-certifikatet och fyller i min sexsiffriga kod. Nu visas den publicerade tjänsten som består av en informationssida hos Landstinget. 33
IP-adressen är den som vi går ut med från vårt administrativa nät och uppgifterna om certifikatet (UserID) överensstämmer med dem som ligger på mitt kort: Därefter testar jag att använda Telia e-id istället för SITHS-certifikatet och det går också bra: 34
Jag testar också med uppkoppling via Unsolicited Response: https://idp.hultsfred.se/neidp/samlresponder?samlrequest=unsolicited&entityid= sp001.ltkalmar.se och får exakt samma resultat. 9.2 Slutsatser tester Inga kommentarer. Allt verkar fungera enligt intentionerna. 35
10. Bilaga 10 Testprotokoll Hultsfred mot Emmaboda Kommun: Hultsfreds kommun 10.1 Steg 3: Uppkoppling mot skolhälsovårdssystemet Inloggning mot Emmabodas SP-funktion och vidare inloggning mot Profdoc. När användaren kopplas upp kommer hon till inloggningssidan på PD_EBODA, där manuell inloggning sker med separat ID och lösenord. Handhavande: Välj länk till Skolhälsovård Emmaboda Ange SITHS som legitimationssätt Ange din sexsiffriga kod Logga in i Profdoc och testa att köra applikationen Fyll i förutsättningar och resultat här. Vi testar först med en bärbar dator (den som använts för de flesta tester med SAML och SITHS): Compaq nc8430, Intel Core2 T7200 2GHz, 2 GB RAM Win XP Professional SP3, Internet Explorer 8 Eftersom vi inte lagt upp de externa resurserna i våra DNS:er har vi lagt till dem i /etc/hosts: 193.235.216.42 sp001.ltkalmar.se 195.67.95.107 login.emmaboda.se 195.67.95.107 pd.emmaboda.se 195.67.95.107 m01-mg-local.login.emmaboda.se 195.67.95.107 m01-bhdp-test.login.emmaboda.se 195.67.95.107 m01-rdp-profdoc.login.emmaboda.se 195.67.95.117 m01-mg-ident-0.login.emmaboda.se Vi har även lagt upp Emmabodas webbplatser i zonen Tillförlitliga platser i IE:s Internetinställningar/Säkerhet och tagit bort Begär serververifiering för alla platser i den här zonen. m01-rdp-profdoc.login.emmaboda.se lades till i Lokalt intranät för att vi skulle slippa varningen om hämtning av rdp-fil. Allt för att slippa extra knapptryckningar och varningar om osäkra platser och okända certifikat när skolsköterskan ska testa. 36
Länken till Emmabodas tjänst kommer att finnas tillgänglig för användaren antingen via ikon på skrivbordet, eller i intranätmeny. OBS! I vår nuvarande konfiguration måste kortet sitta i redan från start. Länken http://login.emmaboda.se/samlv2/sp/req?idpid=3 känner inte automatiskt av att jag måste använda SITHS-certifikatet. Därför får jag en fråga om vilket certifikat jag vill använda. 37
Jag väljer SITHS-certifikatet och fyller i min sexsiffriga kod. Nu öppnas sessionen mot terminalservern. 38
Här slutar de förberedande testerna där jag använt mitt SITHS-kort. Eftersom jag inte är behörig i Profdoc-systemet kan jag inte logga in i applikationen. 10.2 Slutsatser förberedande tester Eftersom vi sitter i en testmiljö så finns det fortfarande för mycket handpåläggning för att man ska få till en smidig inloggning för sköterskan. Planen var att idag också testa inloggningen från en skolsköterskas arbetsplats, med hennes eget kort. Skolsköterskan sitter på skolnätet, som mot Internet aviserar en annan IP-adress (source adress) än våra användare på tjänstemannanätet, och sitter dessutom bakom en extra proxybrandvägg (ISA server). Vid våra tidspressade försök att få till stånd en liknande miljö på IT-kontoret kom vi fram till att det inte var tid att t ex anpassa vilka IP som får accessa Emmabodas SP, eller byta hennes source adress via individuella regler i vår brandväggsrouting. Vägen framåt bör istället vara att flytta användaren till vårt administrativa nät, för att längre fram se till att vi etablerar en autentiseringsportal så att man kan sitta var som helst och logga in till olika SP via den. 39
10.3 Test av behörig sköterskas inloggning till Profdoc från lånad dator (ej egen arbetsplats) 2010-02-24 kl 15.15 I samband med utlämning av SITHS-kort testade en av sköterskorna uppkoppling med kortet. Hon använde precis samma dator som jag använt igår, och fick exakt samma funktionalitet. Dock upptäckte vi att man kan klicka på fel ställe i rutan för val av certifikat. Om man klickar till höger om namnet avaktiveras förvalt värde utan att nytt värde väljs och man får ett felmeddelande när man försöker gå vidare. Man måste börja om från början. Man kan alltså inte klicka på Utfärdaren, se pil. Dessvärre hade hon inte sin inloggning till PMO-systemet i huvudet, varför denna test också stannade vid inloggningen till PD_EBODA. 40