OWSA model T version 1.0

Størrelse: px
Starte visningen fra side:

Download "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, 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 / 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 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 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: 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 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

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel Indhold > Indledning 3 Standarder 5 OIOUBL 5 OIO RASP 6 OIO SMI 7 Biblioteker 8 Web applikationer 9 Fakturablanket 9 NemHandel Registrering 9 NemHandel.dk 10 Web services

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Præcisering af transportbaseret sikkerhed i Den Gode Webservice

Præcisering af transportbaseret sikkerhed i Den Gode Webservice Præcisering af transportbaseret sikkerhed i Den Gode Webservice 1. Historik...2 2. Indledning...3 3. SSL/TLS baseret netværk...3 4. Sundhedsdatanettet (VPN)...5 5. Opsummering...6 6. Referencer...6 Side

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

BBR OIOXML. Vejledning til OIOXML-snitflade. InputBox.wsdl

BBR OIOXML. Vejledning til OIOXML-snitflade. InputBox.wsdl OIOXML Vejledning til OIOXML-snitflade En vejledning rettet mod 3. part. Ændringer i forhold til forrige versioner Første version, 19.11.2010 Snitfladebeskrivelser Side 2 af 10 Indholdsfortegnelse 1. Introduktion...

Læs mere

Certifikatpolitik for NemLog-in

Certifikatpolitik for NemLog-in Side 1 af 9 7. november 2012 Certifikatpolitik for NemLog-in Version 1.2 Dette dokument beskriver certifikatpolitikken for NemLog-in løsningen. Politikken definerer hvilke typer certifikater, der må anvendes

Læs mere

BILAG 1 GENERELLE BETINGELSER INTERN (VERSION 1.0 AF 31. MAJ 2005) (I DET FØLGENDE KALDET GENERELLE BETINGELSER) OIO STANDARDAFTALE FOR WEB SERVICES

BILAG 1 GENERELLE BETINGELSER INTERN (VERSION 1.0 AF 31. MAJ 2005) (I DET FØLGENDE KALDET GENERELLE BETINGELSER) OIO STANDARDAFTALE FOR WEB SERVICES BILAG 1 GENERELLE BETINGELSER INTERN (VERSION 1.0 AF 31. MAJ 2005) (I DET FØLGENDE KALDET GENERELLE BETINGELSER) OIO STANDARDAFTALE FOR WEB SERVICES INDHOLDSFORTEGNELSE 1. Anvendelsesområde... 3 2. Definitioner...

Læs mere

UDSNIT 8. februar 2008

UDSNIT 8. februar 2008 UDSNIT 8. februar 2008 Dette udsnit indeholder indeholder en introduktion til hvad begrebet brugerstyring dækker over Kolofon: OIO Referencemodel for tværgående brugerstyring Dette baggrundsdokument kan

Læs mere

Affaldsdatasystem Vejledning supplement i system-til-system integration for.net brugere

Affaldsdatasystem Vejledning supplement i system-til-system integration for.net brugere Affaldsdatasystem Vejledning supplement i system-til-system integration for.net brugere Dokument version: 2.0 ADS version: 1.0 Henvendelse vedrørende affald: Miljøstyrelsen Roskilde, Affaldssekretariatet

Læs mere

Ibrugtagning af Fødselsindberetningsservicen på NSP

Ibrugtagning af Fødselsindberetningsservicen på NSP Ibrugtagning af Fødselsindberetningsservicen på NSP Udarbejdet af: NSI Version: 1.0 Dato: 09.07.2013 Indholdsfortegnelse 1 Vejledning til ibrugtagning af Fødselsindberetningsservicen... 3 1.1 Læsevejledning

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Valg af webservice standard

Valg af webservice standard Valg af webservice standard Agenda Valg til en serviceorienteret infrastruktur Identitetsbaserede Services, Kåre Kjelstrøm Teknologiske trends og udfordringer Debat, spørgsmål og kritik Skal du lave en

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

Teknisk Dokumentation

Teknisk Dokumentation Sundhedsstyrelsens E2B Bivirkningswebservice Teknisk Dokumentation Side 1 af 8 Indhold Indledning... 3 Terminologi... 3 Arkitektur... 4 Web Service Snitflade... 4 Valideringsfejl... 5 Success... 5 E2B...

Læs mere

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus 4. oktober 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y DEVOTEAM i Danmark og i Europa 2 Devoteam

Læs mere

Affaldsdatasystem Vejledning i system-til-system integration

Affaldsdatasystem Vejledning i system-til-system integration Affaldsdatasystem Vejledning i system-til-system integration Dokument version: 2.0 ADS version: 1.0 Henvendelse vedrørende affald: Miljøstyrelsen Roskilde, Affaldssekretariatet Ny Østergade 7-11 4000 Roskilde

Læs mere

Sikker udstilling af data

Sikker udstilling af data Sikker udstilling af data Digitaliseringsstyrelsen 8. oktober 2012 Thomas Gundel Agenda Baggrund hvorfor udstille data? OWSA Model T Identitetsbaserede Web Services NemLog-in s fuldmagtsløsning OAuth 2.0

Læs mere

Webservice til upload af produktionstilladelser

Webservice til upload af produktionstilladelser BILAG 1 Webservice til upload af produktionstilladelser Indhold og anvendelse Denne web-service gør det muligt for 3. parts programmer i kommuner og amter at Uploade og registrere kommunale produktionstilladelser

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

2. Systemarkitektur... 2

2. Systemarkitektur... 2 Indholdsfortegnelse 2. Systemarkitektur... 2 2.1 Præsentationsserverarkitektur... 3 2.2 Applikationsserverarkitektur... 7 Version 7.0 Side 1 af 7 5. Systemarkitektur Arkitekturen for Nyt BBR bygger på

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Sundhedsdatanettets Anatomi UNI-C Router Organisation A Router Router Organisation B Firewall Firewall Linjesikkerhed

Læs mere

Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22

Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22 Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen...

Læs mere

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning.

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning. 1 af 6 30-01-2009 12:42 Vejledning Brugervejledning for OIO-katalog over offentlige it-standarder Version 2.0 - April 2008 INDHOLDSFORTEGNELSE Indledning OIO på nettet Standarder og standardisering Offentlig

Læs mere

Sikkerhed i Stamdatamodulet KOMBIT

Sikkerhed i Stamdatamodulet KOMBIT Sikkerhed i Stamdatamodulet KOMBIT 1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Oversigt... 4 3.1 Relevante OCES-detaljer... 4 4 Overholdelse af persondatalov mv.... 5 5 Importer...

Læs mere

VEJLEDNING TIL CERTIFIKATBRUG FOR A- KASSERNES WEBSERVICEINTEGRATION MOD ARBEJDSMARKEDSSTYRELSENS DFDG.

VEJLEDNING TIL CERTIFIKATBRUG FOR A- KASSERNES WEBSERVICEINTEGRATION MOD ARBEJDSMARKEDSSTYRELSENS DFDG. ARBEJDSMARKEDSSTYRELSEN VEJLEDNING TIL CERTIFIKATBRUG FOR A- KASSERNES WEBSERVICEINTEGRATION MOD ARBEJDSMARKEDSSTYRELSENS DFDG. VERSION RC1 DATO 10. januar 2012 REFERENCE FORFATTER Tøger Nørgaard KONTRAKTNUMMER

Læs mere

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen... 3 2 Formål

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 SOSI (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 Indhold Hvad og hvem er SOSI Visionen og Missionen Begreber, arkitektur og teknik Hvad er SOSI Projekt initieret og drevet af Ribe- og

Læs mere

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22.

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. AUGUST 2013 Fil: DIADEM - Kom godt igang - Ver 1.7.0.docx Indhold 1.

Læs mere

Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice

Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice Dato: Ref.: Mellem og KOMBIT A/S Formål Formålet med denne aftale er at fastlægge de tekniske krav til kommunikationen mellem

Læs mere

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

Læs mere

Understøttelse af LSS til NemID i organisationen

Understøttelse af LSS til NemID i organisationen Understøttelse af LSS til NemID i organisationen Table of contents 1 Dette dokuments formål og målgruppe... 3 2 Introduktion til LSS til NemID... 4 2.1 Forudsætninger hos organisationen... 5 2.1.1 SSL

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

Arkitekturprincipper for Sundhedsområdet

Arkitekturprincipper for Sundhedsområdet Arkitekturprincipper for Sundhedsområdet - Ved anskaffelse af nye systemer Version 0.91 DIGITAL SUNDHED SAMMENHÆNGENDE DIGITAL SUNDHED I DANMARK Nationale principper ved anskaffelse af it-systemer At indføre

Læs mere

Webservices. hvad er det og hvad kan det bruges til? Rikke Lose (rlo@dbc.dk) Databasekonsulent, DBC

Webservices. hvad er det og hvad kan det bruges til? Rikke Lose (rlo@dbc.dk) Databasekonsulent, DBC Webservices hvad er det og hvad kan det bruges til? Rikke Lose (rlo@dbc.dk) Databasekonsulent, DBC Forvirret? Web-baserede services services på hjemmesider XML Webservices Teknologi 2 Web-baseret service

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

Vilkår for Dialogintegration

Vilkår for Dialogintegration Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer

Læs mere

Udkast til REST-ressourcer for Dokumentboks (DKAL) (uddrag fra kravspecifikation og E-boks løsningsbeskrivelse)

Udkast til REST-ressourcer for Dokumentboks (DKAL) (uddrag fra kravspecifikation og E-boks løsningsbeskrivelse) Udkast til REST-ressourcer for Dokumentboks (DKAL) (uddrag fra kravspecifikation og E-boks løsningsbeskrivelse) IT- og Telestyrelsen anbefaler at anvende webservice-standarderne til udarbejdelse af services,

Læs mere

Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0

Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0 Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-10-

Læs mere

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT

Læs mere

Introduktion. Jan Brown Maj, 2010

Introduktion. Jan Brown Maj, 2010 Jan Brown Maj, 2010 Introduktion OIOXML har eksisteret som det centrale datastandardiseringsparadigme siden 2002. Til OIOXML-konceptet er der et regelsæt betegnet OIO Navngivnings- og Deignregler (NDR),

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

Læs mere

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

Kald af PingService via SOAPUI

Kald af PingService via SOAPUI Kald af PingService via SOAPUI Author: Integration Expert Team (IET) Owner: Integration Expert Team (IET) Page 1 of 24 1. Dokumenthistorik Kald af PingService via SOAPUI Revisioner Dato for denne version:

Læs mere

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Bilag 1 Vurdering af økonomiske konsekvenser af beslutningsforslag B 103 1. Indhold i beslutningsforslag B 103 Det overordnede

Læs mere

Kulturministeriets it-arkitekturpolitik

Kulturministeriets it-arkitekturpolitik Kulturministeriets Kulturministeriets Januar 2012 Udgivet af Kulturministeriet Udarbejdet af Kulturstyrelsen H.C. Andersens Boulevard 2 1553 København V www.kulturstyrelsen.dk post@kulturstyrelsen.dk Kulturministeriets

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27.

Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27. Høringsparter vedr. certifikatpolitikker Se vedlagte liste Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27. februar

Læs mere

WHITEPAPER DokumentBroker

WHITEPAPER DokumentBroker WHITEPAPER DokumentBroker Copyright 2013 DokumentBrokeren er en selvstændig arkitekturkomponent, som uafhængigt af forretningsapplikation og kontorpakke, genererer dokumenter af forskellige typer og formater,

Læs mere

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09 LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,

Læs mere

Indholdsfortegnelse. Systembeskrivelse - Sikkerhed

Indholdsfortegnelse. Systembeskrivelse - Sikkerhed Indholdsfortegnelse 9. Sikkerhed i BBR... 2 9.1 Autentifikation i Nyt BBR...2 9.1.1 Grundelementer...3 9.1.2 Log på-funktionalitet...4 9.2 Autorisation i Nyt BBR...5 9.2.1 Security Application Block design...5

Læs mere

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7 OIO Serviceprincipper Version: 1.1 Status: i høring i PF for GD1 og GD2 Oprettet: 4. juni 2014 Dato: 4. juni 2014 Dokument historie Version Dato Beskrivelse

Læs mere

SOSI STS Testscenarier

SOSI STS Testscenarier SOSI STS Testscenarier Version 1.0.1 Status: Offentliggjort Indholdsfortegnelse 1 Introduktion... 2 1.1 Baggrund...2 1.2...2 1.3 Baggrundsmateriale... 2 1.4 Adgang...2 2 Test af STS Webservice... 4 2.1

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne

Læs mere

Snitfladebeskrivelse for Service UdbetalendeEnheder. KMD Udbetaling. GF411001Q Version 1.1, 02.02.2015

Snitfladebeskrivelse for Service UdbetalendeEnheder. KMD Udbetaling. GF411001Q Version 1.1, 02.02.2015 Snitfladebeskrivelse for Service UdbetalendeEnheder KMD Udbetaling GF411001Q Version 1.1, 02.02.2015 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold til forrige version... 3 1 Brug af snitfladebeskrivelsen...

Læs mere

Introduktion til NemID og Tjenesteudbyderpakken

Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S 11. april

Læs mere

IT-sikkerhedspanelets anbefalinger vedrørende privacy

IT-sikkerhedspanelets anbefalinger vedrørende privacy Anbefalinger vedr. privacy IT-sikkerhedspanelet under Ministeriet for Videnskab, Teknologi og Udvikling har i løbet af de seneste møder drøftet nødvendigheden af at forbedre borgere og virksomheders privacy

Læs mere

Digital signatur og XML. Karsten Munk, Videnskabsministeriet

Digital signatur og XML. Karsten Munk, Videnskabsministeriet Digital signatur og XML Karsten Munk, Videnskabsministeriet Indledning Ministeriet for Videnskab, Teknologi og Udvikling tidligere IT- og Forskningsministeriet + universiteterne + innovationspolitikken

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur FAQ Version 1.0 Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag

Læs mere

Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3

Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 1 Indholdsfortegnelse INDHOLDSFORTEGNELSE 2 A5.1 INTRODUKTION 4 A5.2 HTTP RETURKODER 4 A5.3 DIGITAL POST FEJLKODER 7 A5.3.1 DIGITAL POST

Læs mere

Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/) Creative Commons NY-NC (http://creativecommons.org/licenses/bync/2.0/deed.

Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/) Creative Commons NY-NC (http://creativecommons.org/licenses/bync/2.0/deed. Sikkerhedsmodeller for OIOREST Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø Telefon: 3545 0000 Fax: 3545 0010 Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/)

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

Civilstyrelsen. Lovtidende. Generisk webservice til søgning af afgørelser - Vejledning. Version: 0.4 2013-09-03

Civilstyrelsen. Lovtidende. Generisk webservice til søgning af afgørelser - Vejledning. Version: 0.4 2013-09-03 Generisk webservice til søgning af Version: 0.4 2013-09-03 Indhold 1 INTRODUKTION... 3 1.1 BAGGRUND... 3 1.2 REQUEST - SØGEKRITERIA... 3 1.2.1 Understøttelse af operatorer i søgekriteria... 4 1.3 RESPONS...

Læs mere

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Servicebeskrivelse Økonomistyrelsen Marts 2011 Side 1 af

Læs mere

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Miljøportalsekretariatet Ref.: jejnb Den 22. november 2007 Baggrund I forbindelse med strukturreformen

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

DESIGNDOKUMENT (Teknisk dokumentation)

DESIGNDOKUMENT (Teknisk dokumentation) 29. feb.2016 version 1.2 Lægemiddelstyrelsens E2B Bivirkningsservice DESIGNDOKUMENT (Teknisk dokumentation) Dokument historik Version Dato Ændring 1.0 19-06-2014 Final version ifm. idriftsættelse 1.1 29-06-2015

Læs mere

Snitfladebeskrivelse for WEBService IndkomstEnkeltForespoergsel. KMD Indkomst, P13-5. Version 13.0, 24.09.2015

Snitfladebeskrivelse for WEBService IndkomstEnkeltForespoergsel. KMD Indkomst, P13-5. Version 13.0, 24.09.2015 Snitfladebeskrivelse for WEBService IndkomstEnkeltForespoergsel KD Indkomst, P13-5 Version 13.0, 24.09.2015 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen...

Læs mere

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4

Læs mere

Præsentation af BSK regionens identity and access management platform

Præsentation af BSK regionens identity and access management platform Regionshuset It digital forvaltning BSK programmet Olof Palmens alle 17 Kontakt@regionmidtjylland.dk www.regionmidtjylland.dk Præsentation af BSK regionens identity and access management platform BrugerStamdataKataloget

Læs mere

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat. Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012

Læs mere

Web services i brug. Anvendelse uden for biblioteksverdenen

Web services i brug. Anvendelse uden for biblioteksverdenen Web services i brug Anvendelse uden for biblioteksverdenen Agenda Visionen bag webservices Tre cases Et kig fremad Nordija Etableret i marts 1998 Udviklingsprojekter Forretningskritiske applikationer Komponenter

Læs mere

Administration af brugere vha. sammenhængende log-in

Administration af brugere vha. sammenhængende log-in Hvad er sammenhængende log-in? Danmarks Miljøportal Ref.: jejnb 21. august 2012 Formål Formålet med beskrivelsen er at skabe et overblik over sammenhængende log-in, som en nem og enkel måde at administrere

Læs mere

SOSI Gateway Komponenten (SOSI GW)

SOSI Gateway Komponenten (SOSI GW) SOSI Gateway Komponenten (SOSI GW) - en security domain gateway Version 1.2 1/8 Indledning Region Syddanmark er udvalgt som pilotregion for projektet Det Fælles Medicingrundlag, og i den forbindelse arbejdes

Læs mere

Fælles Bibliotekssystem

Fælles Bibliotekssystem Fælles Bibliotekssystem Møder med leverandører af 3. partssystemer, der integrerer til FBS Afholdt d. 22. og 23. oktober 2014 Spørgsmål til organisation, rammeplan og tilslutningsforløb: 1. Hvem leverer

Læs mere

Strategi 2013-2017 Danmarks Miljøportal

Strategi 2013-2017 Danmarks Miljøportal Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang

Læs mere

Digital Signatur Infrastrukturen til digital signatur

Digital Signatur Infrastrukturen til digital signatur Digital Signatur Infrastrukturen til digital signatur IT- og Telestyrelsen December 2002 Resumé: I fremtiden vil borgere og myndigheder ofte have brug for at kunne kommunikere nemt og sikkert med hinanden

Læs mere

Produktbeskrivelse for

Produktbeskrivelse for Produktbeskrivelse for Service til opfølgning på behandlingsrelationer NSP Opsamling Tjenesteudbyder Opfølgning Notifikation Side 1 af 7 Version Dato Ansvarlig Kommentarer 1.0 22-12-2011 JRI Final review

Læs mere

Kravspecifikation. for. Indholdskanalen 2.0

Kravspecifikation. for. Indholdskanalen 2.0 Kravspecifikation for Indholdskanalen 2.0 August 2011 2 Indhold 1. Kort projektbeskrivelse... 3 2. Erfaringer fra Indholdskanalen... 3 Konsekvenser... 3 3. Tekniske krav... 4 Redaktionsværktøjet og indholdsproduktion...

Læs mere

Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning

Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning Indholdsfortegnelse Indledning... 3 Systemkrav... 4 Installation af Citrix-klient... 5 Tilpasning

Læs mere

Termer og begreber i NemID

Termer og begreber i NemID Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Termer og begreber i NemID DanID A/S 26. maj 2014 Side 1-11 Indholdsfortegnelse

Læs mere

Anbefalede testprocedurer

Anbefalede testprocedurer Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Anbefalede testprocedurer Nets DanID A/S Marts 2014 Side 1-34 Indholdsfortegnelse

Læs mere

Integrationsmanual. Anvendelse af webservice til kursusoversigt i Campus. Brugervejledning til udviklere

Integrationsmanual. Anvendelse af webservice til kursusoversigt i Campus. Brugervejledning til udviklere Integrationsmanual Anvendelse af webservice til kursusoversigt i Campus Brugervejledning til udviklere Moderniseringsstyrelsen Webservice manual til udviklere 2016 1 1. Indholdsfortegnelse Nyt kapitel

Læs mere

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær.

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær. EfterUddannelse.dk FraværService - systemdokumentation BRUGERDOKUMENTATION: WEB-SERVICE Af: Logica Indhold 1. Indledning... 1 1.1 Formål... 1 1.2 Webservice version... 1 1.3 Historik... 1 2. Absence Webservice...

Læs mere

PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER

PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER cuneco en del af bips Dato 20. marts 2012 Projektnr. 14 021 Sign. SSP 1 Indledning cuneco gennemfører et projekt, der skal udvikle en standardiseret struktur og

Læs mere

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12 Oktober 2013 HLG/XIGA Opstartsvejledning ATS Engros 1/12 1. ATS Engros vejledning for aktører Formålet med dette dokument er at beskrive, hvordan du kommer i gang med at anvende ATS til test af certifikat

Læs mere

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365 NemID DataHub adgang morten@signaturgruppen.dk & jakob@signaturgruppen.dk Agenda Funktionaliteten og brugeroplevelsen Arkitekturen og komponenterne bag NemID og digital signatur Datahub token Pause Udvikling

Læs mere

TDCs Signaturserver. 11/05 - Version 1.0 2005 TDC Erhverv Sikkerhed og certifikater

TDCs Signaturserver. 11/05 - Version 1.0 2005 TDC Erhverv Sikkerhed og certifikater TDCs Signaturserver Side 2 Indhold Indledning...3 Teknisk projekt... 3 Tekniske forudsætninger... 3 Installation af klienten... 4 Udstedelse af signatur... 4 Anvendelse af signaturen... 6 Eksport af signaturen...

Læs mere

Service Orienteret Arkitektur

Service Orienteret Arkitektur Service Orienteret Arkitektur Datalogisk Institut 22. november 2004 v/ Vidensleverandør Henrik Hvid Jensen, SOA Network henrikhvid@soanetwork.dk (c) SOA Network, 2004 1 Indførelse af et servicelag (c)

Læs mere

Anbefaling til unik Id-nøgle

Anbefaling til unik Id-nøgle Anbefaling til unik Id-nøgle 1 / 15 Kolofon: OIO Referencemodel for tværgående brugerstyring Denne anbefaling kan frit anvendes af alle. Citeres fra anbefalingen i andre publikationer til offentligheden

Læs mere

Struktur på privatlivsimplikationsrapporten

Struktur på privatlivsimplikationsrapporten Struktur på privatlivsimplikationsrapporten Appendiks 6 Håndbog i: Privatlivsimplikationsanalyse IT og Telestyrelsen INDHOLDSFORTEGNELSE Struktur på rapport over privatlivsimplikationsanalysen... 3 Introduktion...

Læs mere

LUDUS Web Installations- og konfigurationsvejledning

LUDUS Web Installations- og konfigurationsvejledning LUDUS Web Installations- og konfigurationsvejledning Indhold LUDUS Web Installations- og konfigurationsvejledning... 1 1. Forudsætninger... 2 2. Installation... 3 3. Konfiguration... 9 3.1 LUDUS Databasekonfiguration...

Læs mere

Vejledning til Retsinformation web services test stubs

Vejledning til Retsinformation web services test stubs Civilstyrelsen Vejledning til Retsinformation Version:2 2010.02.08 Indholdsfortegnelse 1. Introduktion... 3 2. Installation... 3 3. Web Service beskrivelse og testdata... 3 2010.02.08 2 Side 2 af 5 1.

Læs mere