OWSA model T version 1.0

OWSA model T version 1.0 OIO Web Service Arkitektur model Transportbaseret sikkerhed Anbefaling Denne anbefaling er godkendt af den fællesoffentlige IT-Arkitekturkomité den 22.12.2005. Godkendelsen er et resultatet af den offentlige høring der foregik i perioden fra 31/8 2005 til 3/10 2005. IT- og Telestyrelsen København, d. 5. december 2005. OWSA model T

Kolofon: OIO Web Service Arkitektur model Transportbaseret sikkerhed Denne referencemodel kan frit anvendes af alle. Citeres fra referencemodellen i andre publikationer til offentligheden skal angives korrekt kildehenvisning. OWSA referencemodeller anbefales af den fællesoffetlige IT-Arkitekturkomite og udarbejdes af ITog Telestyrelsen, IT-strategisk kontor, som sekretariat for IT-Arkitekturkomiteen. For model T s vedkommende er forslag til udkastet udarbejdet i et partnerskab med KMD. Partnerskabet leverer foruden forslaget til referencemodel også en referenceimplementering af model T på en konkret teknologisk platform. Denne implementering rapporteres i et særskilt dokument, se oio.dk Kontaktperson: It-Arkitekt René Løhde, email: rel@itst.dk Telefon 33379205 (direkte) Forfattere: It-Arkitekt René Løhde, IT strategisk kontor It-Arkitekt Nils Bundgaard, Rambøll Management It-Arkitekt Ivan Overgaard, KMD Ministeriet for Videnskab, Teknologi og Udvikling IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 DK-2100 København Ø Telf. +45 35 45 00 00 Fax. +45 35 45 00 10 http://www.itst.dk itst@itst.dk 2 / 31

1 Introduktion... 4 1.1 Formål... 4 1.2 Målgruppe... 4 1.3 Mål... 4 1.4 OWSA model T og eksisterende services... 5 1.5 Baggrund... 5 1.6 Resume... 6 2 Overordnet arkitektur...7 2.1 Elementer... 7 2.2 Egenskaber ved model T... 8 3 OIO WSDL OIO SERVICE... 10 3.1 WSDL og den tekniske kontrakt... 10 3.2 Kontrakt først eller kode først design... 10 3.3 OIOXML-skema... 11 3.4 OIO-WSDL... 12 3.5 OCES, SSL/TLS og Sikkerhed... 12 4 Retningslinier for udviklingsarbejdet... 15 4.1 Datadefinitioner XML... 15 4.2 Servicedefinitioner OIO-WSDL... 15 4.3 Service proces obligatoriske emner... 16 4.4 Etablering af OCES og SSL/TLS infrastruktur... 17 4.5 Serviceaftale... 17 4.6 Servicedokumentation... 18 4.7 Testmiljø og teststrategi... 19 5 Appendiks - OWSA model T og kædede sikkerhedsdomæner... 21 6 Appendix - Checkliste... 23 7 Appendix Forklaring og centrale standarder... 25 7.1 XML Web Services... 25 7.2 SOAP... 25 7.3 XML-skema... 26 7.4 Web Service Description Language (WSDL)... 26 7.5 Web Service Interoperability (WS-I)... 27 8 Appendix - Begrebsdefinitioner... 28 3 / 31

1 Introduktion Nærværende dokument beskriver OIO Web Service Arkitektur model Transportbaseret sikkerhed forkortet OSWA model T. Denne referencemodel repræsenterer et operationelt skridt i at muliggøre en serviceorienteret arkitektur. Det er den første model i en serie af referencemodeller, som Ministeriet for Videnskab, Teknologi og Udvikling (MTVU) vil udarbejde i samarbejde med myndigheder og branchen. Hver model løser en række kvalitetsbehov, som myndighederne stiller til interoperabilitet, og hver model efterprøves i en konkret implementering. Modellerne udarbejdes for at: sikre en ensartethed i realisering af principperne i OIO Hvidbog om it-arkitektur om interoperabilitet, sikkerhed, åbenhed, fleksibilitet og skalerbarhed ved anvendelse af Web Service standarderne gøre det enkelt for leverandørerne at udarbejde Web Services, der i praksis spiller sammen på tværs af myndigheder og it-platforme. 1.1 Formål Det skal være let at gøre det rigtigt. At give en arkitekturbeskrivelse for OWSA model T, dvs. beskrive rammerne for model T og de elementer der indgår i model T, samt de muligheder og begrænsninger model T tilbyder. Denne arkitekturbeskrivelse giver retningslinier for udvikling og eksponering af Web Services med de karakteristiske arkitekturkvalitetsegenskaber, som er beskrevet i dette dokument. 1.2 Målgruppe Løsningsdesignere som f.eks. o IT Arkitekter o Systemkonsulenter o Udviklere med designansvar (referencemodellen indeholder ikke platformsspecifikke implementeringsvejledninger) Projektledere 1.3 Mål Motivationen for udformningen af OWSA model T er følgende: At opstille en model der realiseres med eksisterende etablerede teknologier og godkendte standarder fra OIO-kataloget (referenceprofil). At skabe et fælles fundament for sikkerhed, transport og datatyper. At brugen ikke skal forudsætte store ændringer i eksisterende systemer. Modellen skal kunne stilles som krav i kravspecifikationer og aftaler. Simplificere udviklingsarbejdet for både Service Udbyder og Service Aftager. At skabe teknologisk konsensus. Dvs. at give en fælles forståelse af hvilke teknologier, for transport, sikkerhed og datatyper, der benyttes og hvordan de benyttes. At genbruge eksisterende standarder maksimalt. 4 / 31

Byggestene i OWSA model T er etablerede komponenter, der har vist sig reelt interoperable i praksis og som sikrer ens implementeringer. Overordnet set er OWSA model T en tilpasning af WS-I s Basic Profile 1.1 til danske forhold. Model T hviler på følgende byggesten: WS-I s Basic Profile 1.1 og simple SOAP Binding Profile 1.0, som blev godkendt 24/8 2004 1. HTTPS 2 benyttes til transport og sikkerhed. Transportlaget krypterer data og overfører certifikat mellem Service Udbyder og Service Aftager til autentifikation. OCES certifikater benyttes som identifikation af Service Aftager. En Service Udbyder identificeres med et Servercertifikat. OIOXML skal benyttes for at skabe størst mulig fælles kontekst på datatyper. En konkret implementering af Model T kræver en aftale mellem serviceaftager og serviceudbyder om service levels og de specifikke kvalitative egenskaber og gensidige forpligtigelser. Denne aftale kan formuleres som en forretningsaftale og tage udgangspunkt i OIO standardkontrakten for Web Services mellem myndigheder. En af forudsætningerne for at etablere og anvende en Web Service mellem myndigheder er, at der tilgodeses forpligtigelser i henhold til datatilsynets retningslinier for videregivelse af oplysninger i portaler og itløsninger. 1.4 OWSA model T og eksisterende services OWSA model T skal først bringes i anvendelse overfor eksisterende services, når der er en forretningsmæssig begrundelse for at modernisere dem. En af disse forretningsmæssige grunde kan være at serviceudbyderen ved at overholde model T afskaffer interoperabillitetsproblemer og sikrer, at serviceudbyderens services er implementeret som alle andre services i det offentlige. OWSA model T er således tiltænkt anvendt ved nye services eller ved moderniseringer. Anbefalingen af en OWSA model T påvirker ikke lovligheden af eksisterende Web Services eller ændrer ansvaret og kravene for eksisterende løsningers anvendelse. Anbefalingen har ikke generel tilbagevirkende kraft.. 1.5 Baggrund For at gøre det muligt at frembringe anvendelige systemer til en offentlig administration opbygget af web services fra forskellige offentlige instanser og leverandører, er det vigtigt at interfacet til disse web services implementeres på en ensartet måde. Hvis f.eks. autentifikation ikke foretages på samme måde overfor alle web services, vil det i praksis være uoverkommeligt komplekst at anvende flere forskellige Web Services fra flere leverandører. På basis af Hvidbog om IT-arkitektur og Håndbog for Arkitektur for Digital Forvaltning ønsker MVTU at udvikle referencemodeller for de forskellige arkitekturelementer beskrevet i håndbogen. Et af de prioriterede områder er, at angive operationelle anvisninger til at muliggøre en serviceorienteret arkitektur. OIO Web Service Arkitektur modellerne giver anvisninger på hvordan man skal integrere servicekomponenter baseret på Web Service standarderne. MVTU vil i samarbejde med myndighederne og branchen løbende definere forslag til modeller og gennemføre høringer i de kommende år, således at der løbende produceres konkrete, operationelle anvisninger på at udvikle OIO Web Services. Planen for dette arbejde publiceres på OIO.dk i form af en roadmap http://www.oio.dk/arkitektur/soa/webservices/owsa/roadmap. 1 Disse to standarder er tilsammen en opdatering af WS-I Basic Profile 1.0 2 HTTPS er ækvivalent med kombinationen af HTTP og SSLv3 / TSL 5 / 31

Baggrunden for denne specifikation af en løsningsmodel er således, at den er begyndelsen i en løbende proces som lancerer løsningsmodeller udvalgt med modenhed og realisering som et vigtigt kriterium. Teknologierne udvikles løbende og kontinuerligt, og det følger naturligt heraf, at nye modeller vil følge den aktuelt frigivne model, og frigivne modeller vil blive release opdateret eller udfaset. Det er et afgørende krav til løsningsmodellerne formuleret i ovennævnte roadmap, at de skal understøtte en vækst i udbuddet af realiseringer. Modellerne skal derfor være lette at bruge og lette at implementere på forskellige platforme og hos forskellige brancheleverandører. Til hver model tilhører en eller flere referenceimplementeringer, der fungerer som praktiske eksempler på implementering af modellen på en teknologisk platform. MVTU vil til hver af modellerne initiere mindst en referenceimplementering i samarbejde med branchevirksomheder. Referenceimplementeringen er samtidig en afprøvning af modellen, som viser at der findes en driftsplatform hvorpå modellen kan realiseres, men er ikke i sig selv et bevis for at den kan realiseres på alle platforme. 1.6 Resume Dette dokument beskriver en fælles offentlig dansk OIO profile af WS-I Basic Profile 1.1. I denne proces introduceres en række nye begreber: OIO Web Service Arkitektur Model Transport (OWSA model T) nærværende normative dokument for den danske profil og udvidelse af WS-I Basic Profile 1.1. Modellen fastlægger at Web Service i fælles offentlige implementeringer overholder WS-I Basic Profile 1.1, simple SOAP Binding Profile 1.0 og gør brug af OIOXML til definition af datatyper. Derudover fastlægger modellen at sikkerheden brugt i denne model er kendt internet teknologi HTTPS, samt benytter OCES certifikater til autentifikation. OIOWSDL dokumentet introducerer begrebet OIO-WSDL. Dette er en WSDL, som overholder WS-I Basic Profile 1.1 og som gør brug af OIOXML i de beskeder WSDL en beskriver OIOWSA-Service dokumentet introducerer begrebet OWSA-Service, som er en applikation-tilapplikation implementeret efter en fælles offentlig OWSA model. Model T refererer til to applikationers direkte kommunikation uden formidling gennem 3. part. Begrebet er interessant fordi det har betydning i forhold til autorisation og autentifikation mellem to applikationer. OWSA Model T er den danske version af WS-I Basic Profile 1.1 og simple SOAP Binding Profile 1.0 udvidet med krav om brug af OCES, OIOXML og HTTPS. 6 / 31

MICROSOFT CORPORATION MICROSOFT CORPORATION MICROSOFT CORPORATI ON M I CRO SO FT CO RPO RATI O N 2 Overordnet arkitektur 2.1 Elementer OIO Web Service arkitekturen, model T, angiver en punkt-til-punkt forbindelse mellem 2 sikkerhedsdomæner, hvor der er én serviceaftager og én serviceudbyder. Indenfor disse sikkerhedsdomæner skal sikkerhedspolitikkerne hos henholdsvis serviceaftager og serviceudbyder varetage sikkerheden i kommunikationen. Eksistensen og soliditeten i disse sikkerhedsdomæner samt en gensidig anerkendelse heraf mellem serviceaftager og serviceudbyder i en aftale, er en afgørende præmis for model T. Set i forhold til Datatilsynets redegørelse om videregivelse af data mellem IT-systemer er det sikkerhedsdomænet der afgrænser og identificerer myndighederne i aftaler om dataudvekslingen. Serviceaftager (SA) sikkerhedsdomæne Fælles offentlige standarder Serviceudbyder (SU) sikkerhedsdomæne Brugerkilent OCES CA Autencitet Borger POCES OCES revocation list Autorisation Medarbejder Brugerkilent MOCES OIOXML over HTTPS Servercertifikat SU applikation Virksomhed SA applikation VOCES OIOXML xsd s OWSA wsdl s SU andre apps ISB SU DBs Signaturforklaring Data Funktionalitet Brugerinterface Kommunikation Fig 1: OWSA model T grundelementer OIO Web Service arkitekturen er sammensat af tre hovedelementer: En serviceaftager, de fælles offentlige standarder og en serviceudbyder. Serviceaftager kommunikerer med Serviceudbyder. De fælles offentlige standarder definerer rammerne for kommunikationen. De fælles offentlige standarder specificerer transport, autentifikation, snitflader og datatyper. HTTPS håndterer kryptering af dataudvekslingen, yderligere benyttes HTTPS s mulighed for overførsel af certifikater. En Web Service der overholder Model T: Skal implementere to-sidet autentifikation, hvis serviceaftageren skal autentificeres. Dvs. Serviceaftager autentificerer Serviceudbyder på Serviceudbyders servercertifikat og Serviceudbyder autentificerer Serviceaftager på Serviceaftagers OCES certifikat. Skal implementere en-sidet HTTPS, hvis forretningsscenariet ikke kræver autentificering af serviceaftageren. 7 / 31

Persondatalovens og forvaltningslovens krav indgår i forretningsscenariet og specielt udeladelse af aftagers autentifikation (anonym bruger) skal specifikt vurderes i forhold hertil. De fælles offentlige standarder implementerer en central database (ISB), der udstiller datatyper som XML- Skemaer (OIOXML) og snitflader som WSDL. Yderligere benyttes OCES infrastruktur for certifikater, der håndterer distribution af certifikater, samt vedligeholder og distribuerer listen af udgåede certifikater. Der eksisterer tre typer af Serviceaftagere: Borger. Identificeres af Serviceudbyder med et OCES personcertifikat (POCES). En borger benytter typisk en tynd klient, f.eks. en Browser. Dette er et U2B scenario. Medarbejder, f.eks. en sagsbehandler. Identificeres af Serviceudbyder med et OCES medarbejdercertifikat (MOCES). En medarbejder sidder typisk ved en tung klient. En medarbejder skal have et ansættelsesforhold til en virksomhed. Dette er et U2B scenario. Virksomhed. Identificeres af Serviceudbyder med et OCES virksomhedscertifikat (VOCES). Her foregår kommunikationen mellem to servere. Dette er et B2B scenario. En serviceudbyder udstiller snitflader til applikationer. En snitflade (WSDL) og alle de datatyper (XSD) der indgår i snitfladen, skal være registreret i ISB og overholde OIO s retningslinier for OIOXML. Det påhviler Serviceudbyder at kontrollere om et OCES-certifikat er nedlagt. Derfor skal Serviceudbyder validere indkomne certifikater mod listen af certifikater som skal afvises. En serviceudbyder behandler forespørgselen og danner svaret i en serviceudbyder applikation. såfremt denne applikation kommunikerer med andre applikationer (SU andre apps) og datakilder (SU DBs), er det serviceudbyderens ansvar, at disse applikationer ligger indenfor det sikkerhedsdomæne, som aftalen om dataudvekslingen specificerer. 2.2 Egenskaber ved model T Tekniske data for OWSA model T - direkte Web Service WS-I Basic Profile version 1.1 og Simple SOAP Binding Profile version 1.0 Transportlag Certifikat Serviceaftager HTTPS SSL 3.0 med mindst 1024 bit nøgler til overførsel af certifikater og mindst 128 bit i øvrigt. OCES person, medarbejder eller virksomhedscertifikat Servercertifikat Karakteristiske arkitekturkvalitetsegenskaber for OWSA model T, og hvordan de implementerer principper fra Hvidbogen om IT-arkitektur: Interoperabilitet Certifikat Serviceudbyder Hvidbogsprincip Kvalitetsegenskaber Model Ts arkitekturkvalitetsegenskaber Integration, Punkt til punkt integration baseret på HTTPS, SOAP Kommunikation herunder troværdighed Troværdighed Skal implementeres derudover, hvis det og WSDL kræves Information, semantik og data SOAP payload skematyper skal være defineret i OIOXML 8 / 31

Åbenhed Sikkerhed Der anvendes åbne standarder fra OIO kataloget (referenceprofilen) til at realisere kvalitetsegenskaberne, hvor det er muligt Sikkerhed og brugerstyring Autentifikation Integritet Fortrolighed. Autorisation til at udføre servicen Uafviselighed om at servicen er udført Tilgængelighed Loginkald til Serviceudbyder (Serviceaftager) Etablering af HTTPS (Serviceudbyder) HTTPS og OCES. Hvis forretningsscenariet ikke kræver autentificering af serviceaftageren kan OCES undlades. Skal implementeres derudover, hvis det kræves Kvaliteten i sikkerhedsdomænet skal være beskyttet mod uønskede angreb, der kan degradere den aftalte åbningstid og oppetid Kald af Web Service specificeret i WSDL (Serviceaftager) Web Service producerer og returnerer svar (Serviceudbyder) Fleksibilitet Komponentstruktur. Forandringsparathed. Flytbarhed mellem teknologiske platforme Bestemmes af strukturen af de komponenter, procedurer og funktioner, som danner svaret, som web servicen leverer tilbage til serviceaftager Kan anvendes alle steder, hvor SOAP og WSDL baserede services kan håndteres. Variationshåndtering Åbningstid og oppetid Skalerbarhed Stabilitet og kapacitet Svartid Bestemmes af SOAP-serverne hos Serviceaftager og Serviceudbyder, samt kompleksiteten i at danne svaret på servicen hos Serviceudbyder og Serviceudbyders evne til at håndtere dette. Genopretningstid 9 / 31

3 OIO WSDL OIO SERVICE 3.1 WSDL og den tekniske kontrakt En Web Service er beskrevet ved dens WSDL, som derfor bliver det umiddelbare indbegreb af den tekniske kontrakt. Der er to basale måder en WSDL for en Web Service kan frembringes: Kontrakt først Her udarbejdes WSDL en, som det første i udviklingsprocessen. Herefter laves implementeringen af servicen kode etc. på baggrund af WSDL en. Kode først Her implementeres service først hvorefter WSDL en genereres på baggrund af koden dette foregår som regel automatisk. 3.2 Kontrakt først eller kode først design I kontrakt først udvikling er fokus lagt på det konceptuelle design af den eller de beskeder den bliver sendt mellem applikationer og ikke API erne for de forskellige applikationer. I praksis betyder dette at WSDL en laves i hånden enten gennem en teksteditor eller et dertil indrettet værktøj. En vigtig detalje er, at de XMLskema konstruktioner der indgår i WSDL bliver lavet som noget af det første i arbejdsgangen. Når skemaerne og derefter WSDL en er fabrikeret kan en række værktøjer lave kodeskabeloner der kommer til at danne ramme for implementeringen af Web Servicen. Når man laver kontrakt først udvikling, bliver det første design lavet ved datalaget dvs de XML-skemaer der kommer til at indgå i Types sektionen i WSDL en. På den måde bliver XML-skemaerne grundlaget for implementering hos både serviceaftager (consumer) og serviceudbyder (provider). Hvert system, der ønsker at integrere, må derfor sørge for at kunne implementerer de XML-skema typer der er fremkommet af dette arbejde. Analyse og design fase for udarbejdelsen af XML-skemaer og WSDL kan være en omkostningskrævende omgang. Dette er den pris der betales for at gøre XML-skema og WSDL udviklingen til førsteklasses medlemmer af udviklingsprocessen og ikke blot et biprodukt af implementeringen. Hvis kontrakt først er mere besværligt at implementere, er mere ressource krævende og kræver specialviden eller specialværktøjer hvorfor så vælge dette? Svaret er - igen som med så meget andet med Web Services interoperabilitet! I den serviceorienterede arkitektur udveksler de løst koblede services meddelelser. Derfor bliver det afgørende, at der mellem serviceaftager og serviceudbyder er enighed om meddelelsens struktur og typer, dvs om meddelelsens XML-skema. Dermed bliver den fælles meddelelse til omdrejningspunktet for at forskellige systemer kan tale sammen. For det offentlige er de fælles XML-skemaer specificeret i Infostrukturdatabasen og betegnes OIOXML Derfor skal en interoperabel Web Service konstrueres ud fra aftalen om den fælles meddelelse, hvilket populært betegnes som kontrakt først (contract first) design. Dette i modsætning til kode først design, hvor man tager udgangspunkt i eksisterende forretningskomponenter i én organisation, og eksponerer dem gennem en WSDL. Dermed tager man den forudsætning, at det er denne organisations struktur, semantik, typer og operationer, der gælder for alle. Dette fører til Web Services, der ikke bliver interoperable. 10 / 31

Hvis man lader analysen, der er forudsætning for at specificere den rette tekniske kontrakt, være retningsgivende for hvordan kode og dermed Web Servicen implementeres og ikke omvendt, har man skabt det bedste fundament for interoperabilitet. Gennem analysen sikrer man, snitfladebeskrivelsen er gennemarbejdet i forhold til fælles offentlige standarder og platformsuafhængig. Dermed sikres at WSDL en er en reel og operationel fællesnævner for alle serviceudbydere og alle serviceaftagere, som hver skal implementere snitfladen i individuelle platforme, Eller med andre ord hvis WSDL en er indikator for servicens implementering er der størst sandsynlighed for en fornuftigt mapning mellem XML-skema typerne i WSDL en og de typer det underliggende programmeringsmiljø skal bruge ved implementering. En anden fordel ved kontrakt først udviklingen er den sikkerhed man får for at beskederne der bruges i WSDL en er så præcist defineret så muligt ydermere får man den ekstra fordel det er at hvis der sker ændringer i datatyperne vil dette hurtigt kunne afspejles i WSDL en og dermed også i datavalideringen. Tilgangen forhindrer ikke at man benytter legacy-komponenter gennem en wrapning med Web Services, men stiller krav om at denne wrapning foretages intelligent, så de nødvendige transformationer til fællesoffetlig standard lægges ind i komponenten.! K2001: Web Service en bør konstrueres ud fra kontrakt først design! K2004: Web Services skal beskrives ved brug af OIO-WSDL. InfoStrukturBasen stiller et værktøj til rådighed som genererer WSDL med indlejrede XMLSkemaer udfra en kontrakt først filosofi. http://isb.oio.dk/ 3.3 OIOXML-skema OIOXML skema er byggesten i den tekniske kontrakt. At lave WSDL først (kontrakt først) og sende XML beskeder fra service til service, betyder i realiteten at det er W3C XML-skema der definerer Web Servicens datatyper.! K2005: I OIO-WSDL skal alle anvendte skemaer være OIOXML-skemaer.. 11 / 31

At det er et OIOXML betyder at det er godkendt af OIOXML komiteen (eller godkendt domænekomite) og overholdende NDR eller et adopteret internationalt skema. Proceduren for godkendelse fremgår af OIOXML-komiteens infostrukturelle instrukser og er ikke en del af OWSA modellen. 3.4 OIO-WSDL Hvad skal der til for at lave en OIO-WSDL? Som det er med OIOXML er man underlagt et sæt regler hvis man laver WSDL er der kan udarbejdes i en OIO kontekst. Indledningsvis er det hensigtsmæssigt at fastslå, hvad der ikke er underlagt nogen form for fælles offentlig regulering. Grundlæggende stilles der ikke fælles krav til granularitet af operationer og beskeder der indgår i servicen og til navngivning af operationer. Den konkrete forvaltning eller fagsektor kan have sådanne krav, og de og serviceudbyderne kender bedst selv den mest hensigtsmæssige granularitet af de operationer og beskeder der indgår i servicen. Snitfladekravene (dvs krav der relaterer sig til OIOXML og WSDL) har en række afledte eller underforståede egenskaber der ikke specificeres som egentlige krav. Eksempelvis at beskederne i operationerne skal gøre brug af XML-skemaer der er i overensstemmelse med NDR.! K2002: WSDL en skal være implementeret i overensstemmelse med WS-I Basic Profile 1.1 3.5 OCES, SSL/TLS og Sikkerhed 3.5.1 Transportbaseret sikkerhed De basale WS standarder SOAP og WSDL håndterer ikke sikkerhed. Dette sikres i model T af Internet protokollen HTTPS, der hviler på sikkerhedstandarden SSL/TLS. Model T baseres på to-sidet autentificering efter public-key metoden og kræver således den sikkerhedsløsning der blot er anført som en mulighed i WS-I Basic Profile 1.1! K1006: Model T skal anvende HTTPS. Kravet er den del, der leverer sikker krypteret transport, og afgrænser til http som eneste understøttede protokol (altså ikke noget FTP, SMTP osv.). Kravet om HTTPS er ultimativt som hindring af man in the midle attack der bryder fortroligheden af payload. Kravet er det samme som gælder ved al HTTP transport og er ikke specielt webservice relateret. Det er serverens servercertifikat der bruges til kryptering af data under transport. Model T indeholder ingen signering. Skal data signeres må det gøres i lagene over, altså implementeres af Serviceudbyder og Serviceaftager applikationerne, ved brug af f.eks. XML-dsig eller andre signeringsframework. 12 / 31

! K1007: HTTPS skal udstilles på port 443 SSL kommunikerer gennem port 443. Det er kun fra data sendes til port 443 og til det hentes igen, på hhv. klient og server, at data er krypteret. Dette medfører, at det ikke er muligt at sende data over flere HTTPS forbindelser uden at data dekrypteres på de mellemliggende servere. Det medfører også at serviceaftager og serviceudbyder er ansvarlige for at komponenter involveret i dataudvekslingen ligger i de aftalte sikkerhedsdomæner Vær opmærsom på, at det kan rejse en sikkerhedsproblemstilling, hvis SSL-punktet er placeret i en denimitariseret zine (DMZ). Det skal da kontrolleres at sikkerhedspolitikken for den transporterede meddelelse ikke kompromitteres heraf, og at der i givet fald tages hånd om sikkerhedspolitikkens krav herfra og ind til applikationen. K1008: Model T skal bruge HTTPS med mutual authentication, hvis serviceaftageren skal! autentificeres. Forholdet mellem krav K1006 og K1007 og dette krav er, at krav K1006-K1007 vedrører sikker transport (krypteret linie SSL på HTTP) og krav K1008 vedrører klient identifikation, som i OWSA model-t kun er tilladt på HTTPS. Vær som serviceudbyder opmærsom på, at hvis serviceaftageren må være anonym, så kan det flytte angrebspunktet for denial-of-service (DOS) angreb væk fra det punkt, hvor en identitet normalt kontrolleres, og ind til det punkt, hvor servicerequesten modtages og omsættes i servicefunktioner.! K1009: Serviceaftager autentificeres med OCES certifikat. Dermed skal serveren (Serviceudbyder) være opsat til at kræve klientcertifikat og serveren skal autentificeres med et servercertifikat. Det kræves derfor at rodcertifikatet til servercertifikatet skal være installeret både på klient og server. Både klient og server skal have OCES rodcertifikat installeret, og serviceudbyder skal kontrollere server certifikatet for gyldighed. Model T kræver eksistensen og soliditeten af sikkerhedsdomæner hos hhv. serviceaftager og serviceudbyder, samt en gensidig anerkendelse heraf mellem serviceaftager og serviceudbyder. Dette nedfældes og håndteres formelt i en forretningsaftale, som beskrevet i krav K0016 Kravet om OCES certifikat er et minimumskrav, som ikke udelukker muligheden for at udvide med andre og flere certifikater. Det anbefales, at support for andre certifikattyper afgrænses til andre nationale myndigheders certifikat (svarende til OCES for danske serviceudbydere og aftagere). Mulige og accepterede certifikatpraksis i en specifik webservice skal fremgå af forretningsaftalen i K0016. Vedtagne nationale certifikatpraksis kan registreres i OIO-kataloget via den OIO-brugerstyring, som udarbejdes under referancemodellen for brugerstyring. 13 / 31

3.5.2 OCES og SSL/TLS infrastruktur Sikkerhedsmodellen for OWSA model T er baseret på en punkt til punkt kommunikationsforbindelse mellem serviceaftager og serviceudbyder. Kommunikationsforbindelsen etableres vha. https (http over SSL 3.0). Serviceaftageren anvender et OCES certifikat og serviceudbyderen anvender et (X509) SSL server certifikat ved etableringen af https forbindelsen. Servercertifikatet skal være udstedt til serviceudbyderen eller dennes hostingcenter. Det skal identificere en server, der tilhører serviceudbyderen og indgår i det af serviceudbyderen garanterede sikkerhedsdomæne, således som dette er beskrevet i aftalen mellem serviceaftager og serviceudbyder. Sikkerhed i en sådan web service kontekst betyder, at det er muligt at foretage en eller flere af følgende aktiviteter: Verificerer integriteten af en besked, det vil sige at den ikke er modificeret under transporten mellem applikationer. Https etablerer integritet, fortrolighed samt autentifikation af end points. Integriteten er en egenskab ved https protokollen. Kommunikere en besked fortroligt, så andre ikke kan se den. Fortroligheden opnås ved at kommunikationen i en https krypteres. Afgøre identiteten af de kommunikerende parter autentificerer dem. Den gensidige autentifikation opnås ved at serviceaftageren anvender et OCES certifikat og serviceudbyderen anvender et SSL server certifikat til at etablere https forbindelsen. Afgøre hvorvidt en serviceaftager er autoriseret til at udføre den aktuelle operation. Https etablerer ikke autorisationen af serviceaftageren overfor serviceudbyderen. Det er serviceudbyderens ansvar ud fra serviceaftagerens identitet at afgøre hvorvidt serviceaftageren er autoriseret til at udføre den aktuelle operation. Https er i de fleste tilfælde tilstrækkelig til at etablere sikkerhed i en punkt til punkt forbindelse mellem serviceaftager og serviceudbyder. Https har været anvendt i en årrække til f.eks. borgerservice- og netbanksløsninger, og er derfor kendt blandt mange udviklings- og driftshuse. Den har vist sig at være interoperabel mellem forskellige implementeringer. Hvis serviceaftageren og serviceudbyderen ikke er direkte forbundet med en HTTPS forbindelse som illustreret i figur 1, så kan integritet, fortrolighed og autentifikation ikke etableres udelukkende teknisk vha. HTTPS forbindelser. Hvis der er indsat en mellemliggende serviceudbyder mellem den endelige serviceaftager og endelige serviceudbyder, kan den endelige serviceudbyder ikke teknisk sikre den endelige serviceaftagerens identitet, samt sikre at de data som serviceaftageren har sendt ikke bliver ændret og læst. På samme måde kan serviceaftageren ikke teknisk sikre den endelige serviceudbyders identitet samt sikre at de data som den endelige serviceudbyder har sendt ikke er blevet ændret og læst. Det betyder at teknisk kan modellen ved forbindelser, der ikke er punkt til punkt, ikke etablere integritet, fortrolighed, autentifikation og autorisation. For at anvende modellen til løsninger der ligger udover en punkt til punkt forbindelse mellem serviceaftager og serviceudbyder kræves: En analyse af løsningens krav til integritet, fortrolighed, autentifikation og autorisation. Det er f.eks. ikke altid tilfældet at en serviceudbyder har behov for/kræver at vide hvem den endelige serviceaftager/slutbruger er. At der etableres et tillidsforhold mellem de kommunikerende parter, som beskrives i den juridiske kontrakt mellem parterne. Det krævede tillidsforhold som implementeres både teknisk og kontraktligt. I appendiks kan man læse om en speciel anvendelse af model T, hvor der mellem en serviceaftager og en serviceudbyder er indskudt en serviceformidler. 14 / 31

4 Retningslinier for udviklingsarbejdet 4.1 Datadefinitioner XML! K2010: Alle skemaer skal overholde OIO Navngivnings- og Design Regler for XML-skemaer beskrevet i NDR 3.0. Skal overholde http://www.oio.dk/index.php?o=0f3120e8e51a0bf4c8247743abb6659c 4.2 Servicedefinitioner OIO-WSDL! K2003: WSDL en skal være registreret i InfoStrukturBasen (ISB). Valget af den tekniske implementering af repository (UDDI eller andet) er ikke en del af OWSA modellen, men er overgivet til Infostruktur Basen som den relevante OIO WS infostrukturelle komponent. OIO værktøjsstøtten afgør graden af inddragelse af UDDI. 4.2.1 Web Service-Interoperabillity Basic Profile 1.1 WSDL en skal overholde retningslinier fra WS-I Basic Profile 1.1. For at service og servicebeskrivelse kan overholde WS-I Basic Profile 1.1 (BP 1.1) vil det være en uoverkommelig opgave for udviklere at skulle læse hele BP 1.1 og forholde dette til egne services. Derfor foretrækker langt de fleste at kontrollere BP 1.1 overensstemmelse ved hjælp af et værktøj et stykke software. Leverandørerne af udviklingsplatforme er allerede nu ved at implementere komponenter i deres software, som sikrer at udviklere laver programmer, der overholder BP 11. Indtil disse initiativer rammer markedet, vil man kunne bruge 3.parts software til kontrol af BP 1.1 i Web Services. 4.2.2 XSD-WSDL Der er to måder at beskrive skema-datatyperne i en WSDL: indlejret og importeret. Model-T services kan anvende begge beskrivelser. I den indlejrede metode kopieres alle skemaer ind i WSDL en, så WSDL en indeholder alle typedefinitioner. Alle typer fra samme namespace samles i et namespace og alle import-referencer ændres til lokale referencer. I den importerede metode angives en URI for, hvor skemaerne findes. WSDL en er mere overskuelig, mere enkel og ikke så disponeret for fejl, når den opbygges som import, og det giver mulighed for dynamisk generering af URIs, når dette er hensigsmæssigt. Man skal dog være opmærksom på, om de værktøjer man anvender, kan håndtere skemaer på denne måde. InfoStrukturBasen stiller et værktøj til rådighed som genererer WSDL enten med importerede eller indlejrede XML-skemaer http://isb.oio.dk/ 15 / 31

4.3 Service proces obligatoriske emner 4.3.1 Tjek sikkerhed! K1012: For hver request skal serviceudbyderen kontrollere serviceaftagercertifikatet. TDC har udgivet vejlidninger for, hvordan dette i praksis gøres. Bl.a. skal man sikre - At certifikatet er et OCES Certifikat - At certifikatets udløbsdato ikke er overskredet. - At certifikatet ikke er med på listen over spærrede certifikater. Tjek den fuldstændige vejledning på http://isb.oio.dk/ eller hos TDC Perioden hvor certifikatet er gyldigt kan læses i certifikats data. En liste af spærrede certifikater han hentes ved TDC som også angiver retningslinier for certfikat-håndtering Såfremt servicen understøtter andre nationale certifiktpraksis, skal der udføres tilsvarende kontrol. 4.3.2 Datavalidering For hver Request skal data valideres med det skema som WSDL en indeholder. Hver Response skal skemavalideres før afsendelse. Denne valideringskontrol sikrer, at det data der sendes over nettet overholder de XML skemaer, som servicen angiver. I Basic Profile påhviler det modtager at generere en fault hvis der modtages en uforståelig header blok. Modtageren skal også være opmærksom på, at der ikke kan næres blind tillid til, at alt der modtages er som forventet. Modtageren skal og vil i egen interesse vælge at validere det modtagne, men der er pålagt afsender en pligt til at validere.! K2013: Serviceaftager skal sikre at hver request overholder struktur og formater, beskrevet i de tilhørende skemaer. Princippet der lægges op til er, at man har ansvar for at levere noget godt og rigtigt ind i infra struktruren (OWSA model T) som så til gengæld står inde for at det når uændret frem. Modtageren ved at det er valideret, og at valideringsfejl fundet hos modtager, er fejl opstået under transport, eller et forsøg på indtrængning..! K2014: Serviceudbyder skal sikre at hver request overholder struktur og formater, beskrevet i de tilhørende skemaer. Princippet er at kravet kun påføres den anden part og man bestemmer selv hvad der gøres på egen side. Dette krav vil normalt suppleres af beskrivelser i forretningsaftalen. 16 / 31

4.3.3 Fejlhåndtering Basic Profile (BP) 1.1 angiver retningslinier for fejlhåndtering. Disse retningslinier skal overholdes i Model T. Ifølge Basic Profile 1.1 skal serviceudbyder ( message reciever i BP) returnere en SOAP-fejlbesked - der overholder BP 1.1 - i alle tilfælde, hvor serviceaftager forventer et SOAP response. Det er serviceaftager der modtager og fortolker fejlbeskeden og om muligt giver brugeren en fornuftig besked om den opståede fejl. En fejl returneres således at soap:body kun har et child-element nemlig soap:fault. Serviceaftager skal tolke en SOAP konvolut med et fault element som værende en fejl uanset, hvad http status koden måtte være. Strukturen er at soap:fault ikke kan have andre underlæggende elementer (children) end faultcode, faultstring, faultactor og detail. Kort fortalt er det hhv. (se i øvrigt afsnit 3.3 i BP 1.1): faultcode: faultstring: faultactor: detail: Værdierne VersionMismatch, MustUnderstand, Client eller Server. Betegnelse/kort forklaring. Hvad der gik galt? Aktøren. Hvor gik det galt? (Kan være en mellemstation der skulle behandle dele af SOAP beskeden. En detaljering af hvad der er gået galt (her kan man placere applikationsspecifikke exceptions/error descriptions og lignende evt. med angivelse af modtaget input, der ikke kunne forstås) Tilsvarende bør serviceudbyder sikre sig, at der i den indgåede aftale er taget højde for de processer, der træder i kraft ved fejl, og at disse processer er indskrevet i serviceaftalen. 4.4 Etablering af OCES og SSL/TLS infrastruktur I forbindelse med etablering af sikkerhedsinfrastruktur omkring en Web Service er der en række ting som kan være essentielt at kende til herunder SSL Server konfiguration og installation, X.509 herunder OCES - installering på tykke- og tyndeklienter, hentning af OCES revocationlist (dvs. Liste med ugyldige certifikater) og meget andet. På denne side er en række papirer, som beskriver, hvordan man kan etablere infrastruktur til sikring af Web Servicen: http://www.oio.dk/aktiviteter/soa/webservices/sikkerhed 4.5 Serviceaftale I forbindelse med udviklingen vil der, som ved traditionel IT-system integration, typisk være visse krav, der skal overholdes i forholdet mellem service udbyder og aftager. Denne bilaterale aftale kan nedfælles i det juridiske aftale grundlag, der er udarbejdet i MVTU i første halvdel af 2005. En kopi af skabelon til aftale grundlag OIO Web Service standardaftale samt vejledninger findes her: http://www.oio.dk/styring/standardkontrakter, nederst på siden. I forbindelse med udvikling og implementering bør udvikleren naturligvis være bekendt med, at denne er underlagt de rammer, som aftalegrundlaget har udstukket. Er OIO Web Service standardaftalen grundlaget, så er følgende bilag særligt centrale for en løsningsdesigner: Bilag 3 teknisk beskrivelse, specifikationer og versionering Bilag 4 - sikkerhedsproblemstillinger Bilag 5 servicemål for driftseffektivitet, svartider og recovery Bilag 7 afprøvning i testmiljø 17 / 31

! K0016: Mellem udbyder og enhver aftager skal der indgåes en forretningsaftale, der kan have afsæt i OIO standardaftale for webservices 4.6 Servicedokumentation I forbindelse med idriftsættelsen af Web Servicen skal den dokumenteres. Dokumentationen er primært rettet mod serviceaftager(e), da det jo er denne som er klient til servicen. Der arbejdes under ISB med, hvordan registreringer af servicedokumentation kan understøttes baseret på UDDI. Dette arbejde bør tage stilling til, hvordan nedestående dokumentationsbehov kan understøttes: Beskrivelse Kort prosabeskrivelse af snitfladen Teknisk kontrakt XML-skemaer for servicen og/eller WSDL dokument man kan i forbindelse med offenligørelse af service over serviceaftager redegøre for XML-skemaer og WSDL er. Dette kan og vil for det meste fremstå som links til disse f.eks i InfostrukturBasen http://isb.oio.dk/info NB! I forbindelse med offentligørelse af servicens WSDL kan det være hensigtsmæssigt ikke at frigive den del af WSDL en, som binder dets funktionalitet til et bestemt endpoint. OWSA Model Betegnelse For at tilbyde så mange metadata til (potentielle) servicetagere i dennes første møde med dokumentationen kan det være hensigtsmæssigt at vise hvilken OWSA model serviceudbyder mener servicen falder ind under. Autentifikation Specifikation af om serviceaftager skal autentificeres eller ikke Version Version, versionshistorik og versionskompabilitet angives for hhv testversion og produktionsversion Service aftale Det bør fremgå af dokumentationen, hvor eventuelle nye serviceaftagere kan finde et eksempel på de juridiske kriterier serviceaftager/udbyder skal overholde. Dette kan konkret være i form af et link til allerede indgåede aftaler eller link til en generisk aftale for netop denne service. Kontakt information / Support Uanset hvor meget dokumentation der skrives til en given service vil der i disse år de første år af den service orienterede arkitektur være et behov for at serviceaftager får kontakt til serviceudbyder i forbindelse med yderligere afklaringer ved integration til servicen. Derfor skal kontakt information til personer/aliaser hos service udbyder fremstå af den samlede dokumentation for service. F.eks som URL til supportside, email eller telefonnummer. 18 / 31

4.7 Testmiljø og teststrategi Testmiljø og teststrategi fastlægges suverænt af den enkelte serviceudbyder og serviceaftager indenfor de kvalitetskrav og egenskaber som hver part selv har. Den samlede kvalitet af en løsning, der indeholder en Web Service, vil maksimalt nå det laveste niveau hos hver enkelt part. Kvalitetsegenskaberne, herunder garanterede kvalitetsniveauer, vil fremgå af den forretningsmæssige aftale. Mulighederne for at gennemføre test er med til at bestemme det opnåelige kvalitetsniveau. Testmiljø og teststrategi er underlagt nogle strukturelle krav, som skal opfyldes af en implementering. Der indgår fire kerneelementer eller operatører/funktioner i den styrede OWSA løsning, og disse har alle en livscyklus, som skal understøttes af implementeringen. Service udbyder Service aftager - fremstiller af service med autorisationskontrol - forbruger af service og authentifikationskilde InfoStrukturBase - udleverer service kontrakt WSDL (udpeger udbyder) Certifikat - Udsteder og kontrollerer certifikat Stadier i livscyklus, som hver især begrunder et teknologisk miljø, er DESIGN TEST DRIFT - elementer fastlægges principielt - elementet udvikles og testes - elementet er funktionelt og bruges produktivt En Web Service starter med at en udbydende myndighed fastlægger et indhold, og i den fase skabes WSDL og den indtastes og lægges i udbyderens kopi af ISB oplysninger. Den kan først placeres i ISBen, når WSDLen ligger fast, idet enhver henvisning, andre måtte lave til WSDLer i ISB, vil låse versionen for ændringer. Derpå afprøves den efter udvikling, og det skal ske af udbyderen selv med autoriserede certifikater mod testdata. Sluttelig sættes den i drift, hvilket betyder at den endelige WSDL placeres i ISB og henviser til driftsdata. Når aftageren starter med at bruge servicen, skal det i første omgang være mod testdata og med et certifikat autoriseret til test. Web Services er et samspil mellem tre uafhængige og selvstændige organisationer. Dette gælder i alle faser og altså også i testfasen. Hvis Web Servicen følger OWSA er organisationerne myndigheder, som illustreret i figur 2, som alle skal være indrettet på, at de andre myndigheder kan være i en testfase og have behov for testfunktionalitet. OIO OCES AFTAGER myndighed OWSA UDBYDER myndighed ISB 19 / 31

Figur 2: Myndigheder, der spiller sammen i model T Den udbydende myndighed skal, også for en Web Service der er i drift, tilbyde faciliteter for at en anden myndighed kan aftage servicen i en testsituation hvor kvalitet og autorisationskrav er ganske anderledes. Specielt gælder det også for den infrastrukturelle myndighed OIO, og de fælles funktioner der benyttes, nemlig OWSA model-t, Infostrukturbasen ISB med OIO-XML og OIO-WSDL samt certifikater fra OCES CA. UDBYDER OCES ISB AFTAGER DESIGN Lokalt, internt N.A. N.A. N.A TEST Lokalt, internt Læser fra OCES-CA DRIFT Server ekstern Test og drift Læser fra OCES-CA Skriver I ISB Læser i ISB N.A Lokal klient Ekstern service Drift klient Ekstern service! K0015: Det påhviler serviceudbyder at tilbyde såvel test som driftsversioner. En udbyder skal i designfasen kunne oprette nye WSDL i en kontinuerlig proces over længere tidsrum, på en måde så tredjepart ved at disse er ustabile og ikke frigivet. En udbyder skal i testfasen kunne afprøve en ny service uden at andre aftagere får tilgang til den, også selvom man ikke kan være sikker på at autorisationsmekanismer er på plads endnu. En udbyder skal i produktionsfasen tilbyde testfaciliteter til nye aftagere af servicen. InfoStrukturBasen er en kontrakt først registrant, og er ikke aktiv i driftsfasen. 20 / 31