OWSA model T version 1.0

Transkript

1 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 Godkendelsen er et resultatet af den offentlige høring der foregik i perioden fra 31/ til 3/ IT- og Telestyrelsen København, d. 5. december OWSA model T

2 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 protected] Telefon (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 Fax [email protected] 2 / 31

3 1 Introduktion Formål Målgruppe Mål OWSA model T og eksisterende services Baggrund Resume Overordnet arkitektur Elementer Egenskaber ved model T OIO WSDL OIO SERVICE WSDL og den tekniske kontrakt Kontrakt først eller kode først design OIOXML-skema OIO-WSDL OCES, SSL/TLS og Sikkerhed Retningslinier for udviklingsarbejdet Datadefinitioner XML Servicedefinitioner OIO-WSDL Service proces obligatoriske emner Etablering af OCES og SSL/TLS infrastruktur Serviceaftale Servicedokumentation Testmiljø og teststrategi Appendiks - OWSA model T og kædede sikkerhedsdomæner Appendix - Checkliste Appendix Forklaring og centrale standarder XML Web Services SOAP XML-skema Web Service Description Language (WSDL) Web Service Interoperability (WS-I) Appendix - Begrebsdefinitioner / 31

4 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

5 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/ 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 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 1 Disse to standarder er tilsammen en opdatering af WS-I Basic Profile HTTPS er ækvivalent med kombinationen af HTTP og SSLv3 / TSL 5 / 31

6 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

7 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

8 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

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

10 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

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

12 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 OCES, SSL/TLS og Sikkerhed 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

13 ! 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

14 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

15 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 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 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 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 15 / 31

16 4.3 Service proces obligatoriske emner 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å 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 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

17 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 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: 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 En kopi af skabelon til aftale grundlag OIO Web Service standardaftale samt vejledninger findes her: 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

18 ! 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 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, eller telefonnummer. 18 / 31

19 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

20 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

21 MICROSOFT CORPORATION MICROSOFT CORPORATION MICROSOFT CORPORATI ON MI CRO SO FT CO RPO RATIO N MICROSOFT CORPORATI ON M I CRO SO FT CO RPO RATI O N 5 Appendiks - OWSA model T og kædede sikkerhedsdomæner Det er ikke altid muligt at etablere en HTTPS forbindelse direkte mellem Serviceaftagers og Serviceudbyders sikkerhedsdomæner. Hvis det ikke kan lade sig gøre, er der behov for en løsning med en mellemstation. Hvis f.eks. en klientapplikation anvender en web service som igen anvender en anden web service, kan slutbrugeren ikke autentificerer sig direkte overfor den sidstnævnte web service. En variant af eksemplet er en browser som klientapplikation og dens webserver med IIS, Apache eller andet web server programmel som bruger af en Web Service. OWSA model T dækker ikke direkte en kædet løsningsmodel, men man kan gennem gensidige aftaler mellem en kæde at, sikkerhedsdomæner bruge OWSA Model T til at forbinde sikkerhedsdomænerne to og to. Der udestår så overførsel af sikkerhedsakkreditiver. Dette kan ske i en midlertidig konstruktion, hvor der mellem en start serviceaftager og en slut serviceudbyder er indskudt en serviceformidler, der optræder både som serviceudbyder og serviceaftager. Her er det ikke slutbrugerens certifikat, der anvendes til den direkte autentifikation overfor serviceudbyderen - men serviceaftagerens certifikat. Slutbrugeres certifikat eller ID overføres særskilt, hvis der er brug for det. Serviceaftager (SA) sikkerhedsdomæne Fælles offentlige standarder Serviceudbyder (SU) sikkerhedsdomæne Brugerkilent OCES CA Autencitet Borger Medarbejder Brugerkilent Virksomhed SA applikation POCES MOCES VOCES 1 OCES revocation list OIOXML xsd s ISB OWSA wsdl s OIOXML over HTTPS * Servercertifikat Autorisation SU applikation SU andre apps SU DBs OIOXML over HTTPS Serviceformidler (SF) sikkerhedsdomæne Autencitet Data Signaturforklaring Brugerinterface Funktionalitet Kommunikation Servercertifikat VOCES 1 Autorisation 1 SF applikation SF andre apps SF DBs Fig 4. OWSA model T med kæde 21 / 31

22 Ovenstående figur viser en løsning, der indeholder et formidlingsdomæne mellem en eller flere udbydere og en aftager. - Formidleren er mere og andet end blot en relæstation. - Formidleren vil overfor serviceaftager fremstå som serviceudbyder. - Formidleren vil overfor serviceudbyder fremstå som serviceaftager. Dette setup kan løses efter to forskellige design af meget forskellig kompleksitet. Forskelligheden skabes af hvilket kendskab service udbyder og aftager har til formidlerens eksistens, og hvilket ansvar der påhviler formidleren med hensyn til at understøtte det kendskab. Det enkleste design, og i alle aspekter mest rene er, at de tre domæner ikke udgør en tæt koblet kæde, men blot kender hinanden to og to på en specifik serviceudbyder-aftager snitflade. Serviceudbyder har en aftale med formidleren og identificerer denne på et virksomhedscertifikat. Autorisationer skal gælde alle informationer som virksomheden har tilgang til. Ansvaret at detailautorisationer er på plads, påhviler formidleren. Formidleren kender aftageren på medarbejdercertifikat, og kan på det grundlag sikre autorisationer specifikt. Ansvarsfordelingen fastlægges i den indgående forretningsaftale mellem myndigheder. Formidleren kan indgå tilsvarende aftaler med flere udbydere, men har det samlede sikkerhedsmæssige ansvar for legaliteten af de sammenstillinger af services (og egne systemer) som tilbydes aftageren. Det komplicerede design bygger på, at de tre domæner udgør en koblet kæde, og formidlerens rolle mest er en relæ funktion, der viderestiller aftagers forespørgsel (og medarbejder certifikat) til udbyder som autoriserer på medarbejderniveau korreleret med formidlerens virksomhedsautorisation. Det endelige sikkerhedsansvar ligger hos første led i kæden, altså udbyder. Det er ligesom i det enkle design. Blot er der i det design altid kun to led i en kæde. Da der ikke er en vedtaget brugerstyringsmodel, som kan formidle rettigheder og identifikationer, og da WS- I Basic Profile ikke giver mulighed for at dette, skal der implementeres en løsningsspecifik sikkerhedsmodel. Først og fremmest skal formidleren være trusted af udbyder, fordi udbyder er afhængig af (men kan ikke kontrollere eller viderestille ansvar) at modtage korrekte oplysninger om aftager. Formidlingen af oplysninger om aftager anbefales at ske så standardiseret og ensartet som muligt. Model-T angiver ingen standard for overførsel af brugeridentitet/certifikater, men det anbefales at bruge den kommende WS-I Basic Security Profile jf. De tekniske data og karakteristiske arkitekturegenskaber for OWSA model T i den kædede anvendelse er de samme som opgivet i afsnit / 31

23 6 Appendix - Checkliste Følgende er en oversigt over hvad man skal overholde, for at have implementeret en Web Services efter OWSA Model T. Hvert enkelt punkt er forklaret, motiveret og tilknyttet udviklingskommentarer i afsnit 4 og 5. K0xxx K1xxx K2xxx Generelt Sikkerhedsspecifikation Snitfladespecifikation XML ID Specifikation WS-I BP tilføjelse WS-I BP ændring K0015 Det påhviler serviceudbyder at tilbyde såvel test som driftsversioner. NY K0016 Mellem udbyder og enhver aftager skal der indgåes en forretningsaftale, der kan have afsæt i OIO standardaftale for webservices NY Afsnit 6 K1006 Model T skal anvende HTTPS R5000 K1007 HTTPS skal udstilles på port 443 R5000 K1008 Model T skal bruge HTTPS med mutual authentication, hvis serviceaftageren skal autentificeres. R5010 K1009 Serviceaftager skal autentificeres med OCES certifikat. R5010 K1012 For hver request skal serviceudbyderen kontrollere serviceaftagercertifikatet. Afsnit 6 K2001 Web Service en bør konstrueres ud fra kontrakt først design NY K2002 WSDL en skal være implementeret i overensstemmelse med WS-I Basic Profile 1.1 NY K2003 WSDL en skal være registreret i InfoStrukturBasen (ISB). NY 4.1 K2004 Web Services skal beskrives ved brug af OIO-WSDL. NY K2005 I OIO-WSDL skal alle anvendte skemaer være OIOXML-skemaer. NDR / 31

24 ID Specifikation WS-I BP tilføjelse WS-I BP ændring K2010 Alle skemaer skal overholde OIO Navngivnings- og Design Regler for XML-skemaer beskrevet i NDR 3.0. NY K2013 Serviceaftager skal sikre at hver request overholder struktur og formater, beskrevet i de tilhørende skemaer. NY 3.2 K2014 Serviceudbyder skal sikre at hver request overholder struktur og formater, beskrevet i de tilhørende skemaer. NY / 31

25 7 Appendix Forklaring og centrale standarder 7.1 XML Web Services XML Web Services (WS) er hjørnestenen til den migrering til Service Orienteret Arkitektur (SOA), som det anbefales fra fælles offentlig side finder sted. Åbne standarder og fokus på kommunikation og samarbejde mellem applikationer har skabt et miljø hvor web services er blevet det naturlige valg for eksponering af løst koblede systemer og integration på tværs af forskellige teknologiske platforme (det der så smukt er forkortet til EAI - Enterprise Application Integration). Den primære fordel ved brugen af Web Services er, at Web Services lader programmer skrevet i forskellige programmeringssprog og kørende på forskellige teknologiske platforme kommunikere vha. standardbaserede frameworks. Web Services muliggør interoperabilitet i miljøer hvor distribuerede applikationer skal tale sammen. Denne interoperabilitet opnås gennem ekstensiv brug af XML. OWSA model T anvender de mest stabile og mest basale dele af WS standarderne, nemlig Simple Object Acces Protocol (SOAP) og Web Service Definition Language (WSDL). Af samme grund er model T karakteriseret ved nogle begrænsninger i, hvad standarderne udretter og dermed hvad der er overladt til implementeringerne at fastlægge. Brugen af WS standarderne i model T er beskrevet i afsnit SOAP SOAP er den transport uafhængige kommunikationsprotokol for XML Web services. SOAP er en specifikation, der definerer XML beskeder. Basalt set er der tale om et XML fragment, der er indlejret i et sæt SOAP envelope tags i en SOAP besked. Det indlejerede XML fragment, som er det forretningsmæssigt værdifulde, så at sige netto, betegnes også payload i og udenfor dette dokument. <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" <soapenv:header> {Kan indeholde header elementer} </soapenv:header> <soapenv:body> {Beskeden} </soapenv:body> </soapenv:envelope> 25 / 31

26 7.3 XML-skema Indholdet af en SOAP besked er typisk beskrevet via et XML-skema. Et XML-skema er et såkaldt datatype definitions dokument. En datatype kan være alt fra et heltal til datatypen fornavn eller en komplet XML besked. I Danmark er der udstedt et sæt fælles offentlige regler for hvordan disse XML-skemaer udarbejdes. Reglerne findes på [URL]. XML instanser, der kan valideres på baggrund af disse regler og retningslinier, kaldes for OIOXML. De XML-skemaer, der udgør OIOXML, vil kunne findes i InfoStrukturBasen [URL] 7.4 Web Service Description Language (WSDL) WSDL er en forkortelse af Web Services Description Language. Man kan sige at et WSDL dokument er et XML dokument, som beskriver en eller flere SOAP beskeder og hvordan disse beskeder udveksles. WSDL er XML, det kan læses og redigeres, men i langt de fleste tilfælde, bliver WSDL en genereret og konsumeret af software. WSDL bruger XML-skema til at beskrive de XML beskeder og datatype definitioner der indgår i kommunikationen. Dette sikre en platforms og programmeringssprogs neutral base for kommunikationen mellem programmer. Ud over at beskrive de beskeder Web Servicen bruger beskriver WSDL en også hvor servicen kan tilgås og med hvilken protokol (som regel SOAP over HTTP) der skal bruges for at kommunikere med servicen. Et WSDL dokument for en Web Service indeholder 5 centrale termer Types, Messages, PortTypes, Ports og Bindings. Types Dette element indeholder datatype definitioner, som har relevans for det beskeder der bruges til kommunikation med Web Servicen. Indholdet i Types sectionen er et eller flere XML-skemaer. Messages Messages består af en eller flere logiske dele (parts). Hver del er associeret med en datatype fra Types sektionen dvs. Et XML-skema element. PortTypes En PortType er en navngivet abstraktion der indeholder en eller flere operationer. Operationerne indeholder referencer til hvilke Messages der indgår i operationerne. Ports En Port sektion definerer et individuelt endpoint en adresse med hvilken man tilknytter en såkaldt binding. Bindings En binding definerer format og protokol detaljer for operationer og beskeder, som defineret i en porttype sektion. Ved brug af ovenstående termer, kan tilgangen til en Web Service siges at foregå ved at en XML besked (Message), hvis indhold er defineret I Types sektionen sendes til en Web Service operation.. En operation kan også have et svar (Output), som det er tilfældet her: 26 / 31

27 Figure 3: Web Service Anatomy 7.5 Web Service Interoperability (WS-I) Web Services-Interoperability Organization (WS-I) er en åben, industri organisation, hvis mål er at sikre Web Service interoperabilitet på tværs af forskellige software platforme, operativ systemer og programmeringssprog. Organisationen arbejde på tværs at software industrien og standardiserings organisationer for at imødekomme kundernes krav om best practices og sikre interoperabilitet, når der skal udvikles Web Service løsninger. WS-I organisationen blev dannet i februar 2002 for at ensrette Web Service standarder med henblik på øget interoperabilitet, der skal retfærdiggøre Web Services, som den integrationsmetode, der skal erstatte eksisterende integrations former. I dag har organisationen omkring 200 medlemmer og inkluderer store Web Service software leverandører, som IBM, Microsoft, SAP og SUN. WS-I laver ikke standarder, men laver I stedet en række Profiles der indeholder en række regler, som Web Service software skal overholde for at have det bedste fundament for interoperabilitet. Den første WS-I Profile kom i april 2004 og hed - Basic Profile 1 (BP 1.0). Denne profil dækkede basale Web Service standarder, som brugen af SOAP, WSDL and XML-skema. Profilen forfiner, laver fortolkning og udspecificerer enkelte elementer af SOAP, WSDL og XML-skema specifikationerne. 27 / 31

28 8 Appendix - Begrebsdefinitioner Definition af centrale begreber for projektet Navn Teknisk definition Forretningsmæssig beskrivelse OIO OIO står for Offentlig Information Online. OIO er det fællesoffentlige brand for arkitektur og standarder, digital forvaltning og videndelingsnetstedet, Fork. OIO OIOstandard It-standarder som Kataloget over Offentlige It-standarder anbefaler eller godkender brugen af. OIO standarder giver retningslinier for hvilke standarder, der er modne og hvilke der evt. er fremtidens svar. - Der gives retningslinier for hvilke standarder (offentlige) organisationer bør skele til ved nye systemudviklinger/- anskaffelser. Åben standard En fuldstændig åben standard har følgende egenskaber: Den er tilgængelig for alle Den er gratis Den er dokumenteret i (alle) detaljer Den forbliver tilgængelig og gratis Der er tilgang til standarden for alle og alle har mulighed for at deltage i udviklingen af standarden. Dette giver typisk en bred accept af og stor tilslutning til en standard, hvilket er væsentligt for at en standard vinder stor udbredelse og er levedygtig på sigt. - XML Forkortelse for extensible Markup Language. XML er en standard for hvordan data beskrives ved brug af opmarkering (tags). XML strukturer og indhold defineres ved DTD eller XML-skema. Når it-systemer skal arbejde sammen, er der behov for en fælles forståelse af de data, som systemerne udveksler med hinanden. Ved hjælp af XML kan det f.eks. defineres, hvilke elementer, der indgår i en lønseddel eller en ordre. Selvom to systemer har hver sin måde at opbevare de konkrete lønoplysninger på, så kan de kommunikere ved hjælp af XML. XML 28 / 31

29 Navn Teknisk definition Forretningsmæssig beskrivelse OIOXML XML der overholder OIOXML Naming and Design Rules. Godkendes og publiceres via Infostructurebase. Strukturering og udveksling af information ved hjælp af XML og relaterede standarder i overensstemmelse med danske offentlige retningslinjer for brugen af standarder. Fork. OIO- XML Web Service En service baseret på standarderne SOAP og WSDL. Den underliggende transport protokol er valgfri og kan være HTTP/S, Beskedbaseret/asynkron eller synkron afhængig af de aktuelle partnere og lokationer, der udveksler services. En web service er et softwaresystem, som er designet til at understøtte interoperable maskine-til-maskine interaktioner over et åbent netværk. Web services kan indgå som et centralt element i integrationen mellem nye og gamle IT systemer. Web services kan ligeledes fungere som et centralt redskab i opbyggelsen af en serviceorienteret ITarkitektur. WS Yderligere kan web services være et værktøj til at kommunikere digitalt med samarbejdspartnere og kunder. Web Service stak De standarder, der definerer web service kommunikation og dens forskellige kvalitative egenskaber. Eksempler på standarderne er: XML, XSD, SOAP, WSDL, SAML, XML signature WS-security,WS-Reliability Anvendes som samlebegreb for de teknologier der i lag muliggør sikre, troværdige web services. Teknologierne er ikke alle nødvendige men højere lag er afhængige af de lavere for at implementere eksempelvis yderligere sikkerhed eller garanti for levering mv. WS-* WS-policy; WS-trust WS-transaction, WS-coordination, WS-addressing Og flere andre Legacy system Et eksisterende, fortsat anvendt system. Anvendes typisk om stabile eksisterende systemer baseret på en ældre teknologi i forbindelse med indførelse af nyere teknologi. Ethvert system, der er i stabil drift, og som understøtter vitale forretningsprocesser i en organisation. Typisk er der investeret betydelige midler i legacy systemer, og der må tages hensyn til disse i fremtidige projekter. - IP-domæne Et Internet addresseringsdomæne ejet af en organisation Et Internet addresseringsdomæne ejet af en organisation - 29 / 31

30 Navn Teknisk definition Forretningsmæssig beskrivelse Sikkerhedsdomæne Model Karakteristiske (arkitekturkvalitets) egenskaber Referencemodel Et afgrænset segment at et netværk, som har veldefinerede grænser til andre segmenter og kontrol med trafikken ud og ind af segmentet. Et segment kan være opbygget af undersegmenter og kan defineres til at afgrænse hvilke IT-systemer, der hører under en given juridisk enhed. En model er en beskrivelse af et komplekst system, der fremhæver det ene eller det andet sæt af egenskaber ved systemet. Modellerne består af symboler, der repræsenterer forskellige systemelementer og deres relationer til hinanden, samt prosa, der forklarer og fortolker modellerne og deres egenskaber, de problemstillinger modellerne løser. En operationalisering af Hvidbogens arkitekturprincipper i kvalitetsegenskaber, som den teknologiske løsning skal besidde. En servicekomponents varefakta. En referencemodel udpeger og fastlægger et sæt af modeller, som løser en veldefineret og afgrænset opgave. Referencemodellen fastlægger gennem modeller og beskrivelser her af konsistente mønstre, standarder eller en arkitekturstil for løsningen. En samling af IT-systemer, der tilhører en organisationsenhed og/eller en juridisk myndighed, man indgår aftaler med. ITsystemer i dette domæne er sikret mod trusler fra omgivelse som specificeret i sikkerhedspolitikken hos domæneejeren. En systemløsning kan være beskrevet ved modeller f.eks.: 1. De behov hos aktører, som en systemkomponent opfylder i en given arbejdssituation eller arbejdsproces 2. Den logiske opdeling og struktur og relationerne mellem komponenter. 3. Den procesmæssige sammenhæng mellem komponenter inklusive afhængigheder, parallelitet og timing. 4. Den fysiske topologi af det maskineri og netværk, som komponenterne afvikles på og kommunikerer over. En række karakteristika som fortæller om hvordan et IT-system opfører sig i brug, i drift og i forhold til vedligeholdelse og videreudvikling. En guide til hvordan man i praksis kan anvende en række tekniske standarder i opbygningen af en løsning. Fastlæggelsen af hvilke modeller og modellernes konkrete udseende, fortolkning og kvalitative egenskaber skal ske gennem en høringsproces, der involverer ITarkitektur komite og forum og XML komite og forum. Formålet er at sikre opbakning blandt parthavere og interessenter inden for det område, løsningen har betydning, for en fælles løsning, således at alle implementeringer følger modellen. Fork / 31

31 Navn Teknisk definition Forretningsmæssig beskrivelse Implementering Referenceimplementation Implementering er den praktiske realisering af et system og idriftsættelse heraf. En referenceimplementation er et eksempel på med udgangspunkt i referencemodellen hvordan,: a) serviceudbyder (provider), given en konkret teknologi, realiserer modellen og bygger et it-værktøj eller it-system til en organisation b) serviceaftager (consumer,) given denne konkrete organisation, indarbejder it-værktøjet. Implementering af en model betyder a) Ved hjælp af en given teknologi at realisere modellen som kørende og kommunikerende CPU-processer, dvs. som et brugsklart it-værktøj, således at den får de beskrevne kvalitetsegenskaber. b) Foretager den nødvendige organisatoriske tilpasning og ved hjælp af en vidensoverførsel gennem medvirken og uddannelse integrerer det udviklede itværktøj i den organisation som skal bruge det. Referenceimplementeringen skal demonstrere i praksis, at den kan levere kvaliteterne, der er beskrevet af modellen og kvalitetsegenskaberne. Referenceimplementeringen kræver ikke en høringsproces i digital forvaltningsregi på tværs af det offentlige. Men parter inden for samme teknologi eller samme branche kan organisere en standardiseringsproces. Fork / 31