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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DAR OIO vejledning Version 1.2

DAR OIO vejledning Version 1.2 DAR OIO vejledning Version 1.2 Indhold 1 Ændringer i forhold til forrige version... 2 2 Introduktion... 3 2.1 Formål... 3 2.2 Læsevejledning... 3 3 Beskrivelse... 3 3.1 Fælles elementer og strukturer...

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

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

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

Identitetsbaserede webservices og personlige data

Identitetsbaserede webservices og personlige data > Identitetsbaserede webservices og personlige data Version 0.8 IT- & Telestyrelsen juni 2009 Indhold > Indledning 3 Målgruppe 3 Afgrænsning 4 Definitioner og begreber 5 Scenarier 7 Scenarie med browser

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

NemHandel registreringsvejledning. Navision Stat, INDFAK og Nemkonto. Introduktion. Overblik. Side 1 af 15. ØS/ØSY/CPS 7.

NemHandel registreringsvejledning. Navision Stat, INDFAK og Nemkonto. Introduktion. Overblik. Side 1 af 15. ØS/ØSY/CPS 7. Side 1 af 15 NemHandel registreringsvejledning ØS/ØSY/CPS 7. januar 2015 Navision Stat, INDFAK og Nemkonto Dette dokument beskriver den nødvendig EAN registrering på Nemhandelsregistret via NS NHR WEB

Læs mere

Den Gode Webservice. version 1.1, 1-7-2008 W 1

Den Gode Webservice. version 1.1, 1-7-2008 W 1 Den Gode Webservice version 1.1, 1-7-2008 W 1 Indhold Introduktion...3 Anvendte standarder...4 Internationale standarder...5 Nationale standarder...6 Namespaces...6 Grundlæggende arkitektur...6 Kommunikationsmodel...7

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

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

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering OI OXML som obligatorisk, åben standard - uddybende vejledning 1 Om dette dokument Dette dokument beskriver anbefalet praksis for at anvende OIOXML som åben, obligatorisk standard. IT- og Telestyrelsen

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

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

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

Rapport om snitflader til publiceringsagent i Gentofte Kommune

Rapport om snitflader til publiceringsagent i Gentofte Kommune Rapport om snitflader til publiceringsagent i Gentofte Kommune Connecting Business & Technology Devoteam Fischer & Lorenz A/S 2004 Dette dokument er udarbejdet for af Devoteam Fischer & Lorenz A/S. har

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

Indstilling Master i IT-sikkerhed. Jette Lundin it-vest leder på Handelshøjskolen Lektor på IFI

Indstilling Master i IT-sikkerhed. Jette Lundin it-vest leder på Handelshøjskolen Lektor på IFI Indstilling Master i IT-sikkerhed Jette Lundin it-vest leder på Handelshøjskolen Lektor på IFI Baggrund Med it i alting, Supply Change Management, netværksorganisationer og med systemer sammensat af kommunikerende

Læs mere

ATP WS Provider Profile

ATP WS Provider Profile ATP WS Provider Profile Author: Integration Expert Team (IET) (IET) Subject: ATP WS provider profile Page 1 of 16 1. Dokumenthistorik ATP WS Provider Profile Revisioner Dato for denne version: 13.11.2014

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

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

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

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

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber HØRINGSDOKUMENT Fra: Til: Resumé: David Rosendahl Høringsparter Arbejdsgruppen har identificeret de overordnede og tværgående begreber i sagsbehandlingsprocessen og struktureret og defineret disse generiske

Læs mere

Digital Signatur Sikker brug af digital signatur

Digital Signatur Sikker brug af digital signatur Digital Signatur IT- og Telestyrelsen December 2002 Resumé Myndigheder, der ønsker at indføre digital signatur, må ikke overse de vigtige interne sikkerhedsspørgsmål, som teknologien rejser. Det er vigtigt,

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

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

Projekt: VAX NemHandel 4.0

Projekt: VAX NemHandel 4.0 Ejer: mysupply ApS Projekt: VAX NemHandel 4.0 Emne: Dette dokument beskriver de tekniske specifikationer for VAX NemHandel 4.0 samt krav til miljøet, herunder hardware og software, hvori VAX NemHandel

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

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Microsoft IIS 6 Certifikat administration Følgende vejledning beskriver hvordan man installere et certifikat på en IIS 6 For support og hjælp til anvendelsen af denne vejledning kan du kontakte FairSSL

Læs mere

STS Anvenderdokument i. STS Anvenderdokument

STS Anvenderdokument i. STS Anvenderdokument i STS Anvenderdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.4 2014-07 N iii Indhold 1 Introduktion 1 1.1 Målgruppen...................................................... 1 2 STS 1 2.1 Snitflade........................................................

Læs mere

Ungebasen. Løsningsbeskrivelse. Åbne interfaces mellem Datacontaineren/Tilbagemelding.dk og kommunale vejledningssystemer

Ungebasen. Løsningsbeskrivelse. Åbne interfaces mellem Datacontaineren/Tilbagemelding.dk og kommunale vejledningssystemer PUBLICPUBLICX Ungebasen Løsningsbeskrivelse Åbne interfaces mellem Datacontaineren/Tilbagemelding.dk og kommunale vejledningssystemer 14.09.2012 A414.44.4 [Status] Side 1 af 9 Indhold 1. Formål... 3 2.

Læs mere

Kontraktbilag 4 Kundens IT-miljø

Kontraktbilag 4 Kundens IT-miljø Kontraktbilag 4 Kundens IT-miljø [Vejledning til Leverandøren i forbindelse med afgivelse af tilbud Dette bilag indeholder Kundens krav til at systemet skal kunne afvikles i nedenstående IT-miljø. Leverandøren

Læs mere

Teknologi vurderingsmodel

Teknologi vurderingsmodel Teknologi vurderingsmodel Version 1.1 Dato 14. januar 2010 Status Færdigvurderet Produkt Borger.dk/Min side Udarbejdet af Kurt Hansen Indhold 1. Forside Dette faneblad 2. Vurderingsguide Kort vejledning

Læs mere

Professionel Udvælgelse i byggeriet Skabeloner

Professionel Udvælgelse i byggeriet Skabeloner Professionel Udvælgelse i byggeriet Skabeloner Vejledning i anvendelsen af skabeloner til brug for udvælgelse, herunder prækvalifikation i byggeriet Marts 2013 Byggeriets Evaluerings Center SOLIDARISK

Læs mere

e-tl System til System kommunikationstest

e-tl System til System kommunikationstest e-tl System til System kommunikationstest Version Dato Forfatter Kommentarer Distribueret til 0.5 22/10-07 Anders Bohn Jespersen Udgave til workshop 24/10. 0.6 24/10-07 HGK Opdateret med beskeder. 0.9

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

Januar 2012. Version 2.0. OTP-politik - 1 -

Januar 2012. Version 2.0. OTP-politik - 1 - OTP-politik Januar 2012 Version 2.0 OTP-politik - 1 - Indholdsfortegnelse Indholdsfortegnelse... 2 1. Indledning... 3 1.1. Baggrund og formål... 3 1.2. Kildehenvisninger... 3 1.3. Forkortelser... 3 1.4.

Læs mere

GeoEnviron Web-løsninger

GeoEnviron Web-løsninger 2012 Troels Kreipke 01-01-2012 Indhold Generelt... 3 Web-løsninger... 3 XML-firewall... 4 GeoEnviron_WebService... 4 Installation af web-løsninger uden brug af GeoEnviron_WebService... 5 GeoEnviron_WebService...

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

Testservice med anvendelse af Microsoft software.

Testservice med anvendelse af Microsoft software. Testservice med anvendelse af Microsoft software. Få offentlig nøgle fra installeret signeringscertifikat 1. Klik Start Kør på den pc eller server hvor signeringscertifikatet er installeret. 2. Skriv MMC

Læs mere

E-BUSINESS SOLUTIONS FROM CSC. 4 Systemgrænseflader. 4 Systemgrænseflader

E-BUSINESS SOLUTIONS FROM CSC. 4 Systemgrænseflader. 4 Systemgrænseflader E-BUSINESS SOLUTIONS FROM CSC 4 Systemgrænseflader 4 Systemgrænseflader E-BUSINESS SOLUTIONS FROM CSC 4 Systemgrænseflader Dokumentoplysninger Titel: Projekt: e-tl Løsningsspecifikation, Systemgrænseflader

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note Version 2.4 Der er over det sidste år lavet en lang række forbedringer, tiltag og fejlrettelser. Ændringer til forudsætningerne: o Klienten skal ved førstegangs login

Læs mere

1 INTRODUKTION TIL DKAL SNITFLADER 3

1 INTRODUKTION TIL DKAL SNITFLADER 3 DKAL Snitflader 1 Indholdsfortegnelse 1 INTRODUKTION TIL DKAL SNITFLADER 3 1.1 ANVENDELSE AF OIOXML 3 2 SNITFLADEOVERSIGT 3 2.1 REST 5 2.1.1 HTTP RETURKODER OG FEJLKODER 6 2.1.2 WEBSERVICE 6 2.2 AFSENDELSE

Læs mere

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen Nets Denmark A/S Lautrupbjerg 10 P.O. 500 DK 2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 www.nets.eu Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Læs mere

LaserNet v6.6 Release Nyhedsbrev

LaserNet v6.6 Release Nyhedsbrev LaserNet v6.6 Release Nyhedsbrev NY Input Management-Løsning! Indhold: LaserNet v6.6 LaserNet Webinars NY LaserNet Input Management-løsning Nyt Produkt: LaserNet Client Nye Features & Functions Ny medarbejder

Læs mere

DBC Strategi 2017. DBC har nye udfordringer i de kommende år

DBC Strategi 2017. DBC har nye udfordringer i de kommende år DBC Strategi 2017 DBC har nye udfordringer i de kommende år Digital transition er stadig det grundvilkår, der bestemmer DBC s strategi. Også i de kommende år. Med alt hvad det indebærer med teknologi,

Læs mere

Generelt deler vi visionen om elektronisk handel, også til offentlige virksomheder.

Generelt deler vi visionen om elektronisk handel, også til offentlige virksomheder. Helle Schade-Sørensen IT - og Telestyrelsen Holsteinsgade 63 2100 København Ø hss@itst.dk Hellerup, den 12. september 2007 Høringssvar til Høring af Revisions- og opdateringsstrategi for OIOUBL Med økonomistyringssystemerne

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 Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Version 1.10 Versionshistorik Version Dato Opsummerende beskrivelse af ændringer 1.00 2010-10-5

Læs mere

Sikkerhedsmodeller for Pervasive Computing

Sikkerhedsmodeller for Pervasive Computing Sikkerhedsmodeller for Pervasive Computing Christian Damsgaard Jensen Safe & Secure IT-Systems Research Group Informatik & Matematisk Modellering Danmarks Tekniske Universitet Email: Christian.Jensen@imm.dtu.dk

Læs mere

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense CPR Broker version 2.0 Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense Steen Deth, Chefarkitekt sde@gentofte.dk CPR data hvor svært (og interessant) kan det være? Kommune Borgerservice

Læs mere

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR EG Copyright Infrastruktur er mere end nogle servere... Den Mentale Infrastruktur Den Fysiske Infrastruktur Den Mentale Infrastruktur Vi vil jo gerne have vores

Læs mere

Bilag 1 Kundens opgavebeskrivelse

Bilag 1 Kundens opgavebeskrivelse Bilag 1 Kundens opgavebeskrivelse Side 2 af 12 Indhold 1. Indledning... 3 1.1. Baggrund og formål... 3 1.2. Vision og mål... 3 1.3. Målgruppe... 3 2. Begreber... 4 2.1. Begrebsliste... 4 3. Opgavebeskrivelse...

Læs mere

FORSLAG TIL MASSEAFSENDELSE

FORSLAG TIL MASSEAFSENDELSE FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11 Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding Nuværende OIO-REST løsning Digital post De nuværende Digital Post

Læs mere

NemHandel i cloud - sikkerhedsmæssige overvejelser. Helle Schade-Sørensen IT og Telestyrelsen

NemHandel i cloud - sikkerhedsmæssige overvejelser. Helle Schade-Sørensen IT og Telestyrelsen NemHandel i cloud - sikkerhedsmæssige overvejelser Helle Schade-Sørensen IT og Telestyrelsen Agenda Lidt om NemHandel Rationalet for valg af cloud Overvejelser vedr. sikkerhed Løsning og erfaringer indtil

Læs mere

Vejledning til Retsinformation web services

Vejledning til Retsinformation web services Civilstyrelsen Vejledning til Retsinformation Version:3 2011.03.21 Indholdsfortegnelse 1. Introduktion... 3 2. Baggrund... 3 2.1 Lex Dania... 4 3. Adgang... 4 4. Lex Dania høste web service... 5 4.1 Servicebeskrivelse...

Læs mere

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 1 Indholdsfortegnelse G.1 INTRODUKTION 4 G.1.1 OVERBLIK OVER HVORDAN DIGITAL POST KAN TILGÅS 4 G.1.2 FLOW SOM EN DIGITAL

Læs mere

Smartair 6.0. Installations guide

Smartair 6.0. Installations guide Smartair 6.0 Installations guide Indholdsfortegnelse 1 Indledning... 4 2 System Oversigt... 4 3 Installation... 5 3.1 System Krav... 5 3.2 Klargøring af installationen... 5 3.3 Afinstallere tidligere TS1000

Læs mere

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering

Læs mere

HOSTINGPLANER DDB CMS HOS DBC

HOSTINGPLANER DDB CMS HOS DBC HOSTINGPLANER DDB CMS HOS DBC Indhold Hostingplaner DDB CMS hos DBC... 1 1 Hostingplaner... 3 2 Definitioner... 4 2.1 Miljøer... 4 2.2 Support... 4 2.2.1 DDB CMS - 1. line support... 4 2.2.2 DDB CMS -

Læs mere

Connect Integration. MS Exchange Integration. Administratorvejledning

Connect Integration. MS Exchange Integration. Administratorvejledning Connect Integration MS Exchange Integration Administratorvejledning Version 1.0 Dansk Januar 2014 Velkommen! Denne manual beskriver opsætningen af Integration mellem Connect og MS Exchange server. Hvis

Læs mere

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. 1 2 KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. Det er frivilligt for kommuner at aftage systemet. Iht. den fælleskommunale

Læs mere

Cloud Computing De juridiske aspekter

Cloud Computing De juridiske aspekter Cloud Computing De juridiske aspekter Forskningsnet Konference 2010 Middelfart Advokat Nis Peter Dall Hvad er Cloud? IaaS (Infrastructure as a Service) - Computerkraft, lagerplads mv. stilles til rådighed

Læs mere

Mindstekrav til udstyr (fase 1) Løsningsbeskrivelse

Mindstekrav til udstyr (fase 1) Løsningsbeskrivelse Mindstekrav til udstyr (fase 1) Løsningsbeskrivelse Indholdsfortegnelse 3.1 INDLEDNING 2 3.2 MINDSTEKRAV TIL SLUTBRUGERNES KLIENTER MV 2 3.2.1 Mindstekrav til hardware for PC-klienter 2 3.2.2 Mindstekrav

Læs mere

Forord. Versioner. Version Date Description 1.0.0 05/06/2013 Initial version 2.0.0 24/07/2013 URI er ændret

Forord. Versioner. Version Date Description 1.0.0 05/06/2013 Initial version 2.0.0 24/07/2013 URI er ændret APOS2 OIO Services 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

Nemhandel infrastruktur. Morten Hougesen Christian Uldall Pedersen 8. April 2010

Nemhandel infrastruktur. Morten Hougesen Christian Uldall Pedersen 8. April 2010 Nemhandel infrastruktur Morten Hougesen Christian Uldall Pedersen 8. April 2010 Agenda NemHandelsprogrammet Gennemgang af funktionalitet RASP biblioteker RASP.NET og Java Brug af OCES certifikater Pause

Læs mere

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England.

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England. Cookievejledningens Tekniske Guide Den tekniske guide beskriver fem skridt til overholdelse af cookiereglerne: 1. Fastlæggelse af webejendom 2. Undersøgelse af om der sættes cookies på hjemmesiden 3. Afgivelse

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring)

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring) Sektorstandardiseringsudvalget for ehandel Til interessenter i ehandel (udsendes i bred offentlig høring) UDKAST v.2. Høring over vision, pejlemærker og forretningskrav til ehandel mellem den offentlige

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Small Business Server 2008 SSL certifikat administration Følgende vejledning beskriver hvordan man installere et certifikat på en SBS 2008 server. Ved bestilling af certifikater til Small Business Server

Læs mere

KRAVSPECIFIKATION for underretningsstatistik

KRAVSPECIFIKATION for underretningsstatistik Ankestyrelsen Data og Analyse Den 4. marts 2014 KRAVSPECIFIKATION for underretningsstatistik Kontakt: Jesper Nyholm, Statistiksektionen, jny@ast.dk, tlf. 61 89 75 07 1 af 12 1. Indledning I denne kravspecifikation

Læs mere

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur Cloud i brug Migrering af Digitalisér.dk til cloud computing infrastruktur 02 Indhold > Executive Summary............................................................... 03 Digitaliser.dk.....................................................................

Læs mere

Standardvilkår for modtagelse af OCES-certifikater fra Nets DanID. (NemID tjenesteudbyderaftale [NAVN på NemID tjenesteudbyder indsættes])

Standardvilkår for modtagelse af OCES-certifikater fra Nets DanID. (NemID tjenesteudbyderaftale [NAVN på NemID tjenesteudbyder indsættes]) Lautrupbjerg 10 DK-2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 www.nets.eu CVR-nr. 30808460 P. 1-11 Standardvilkår for modtagelse af OCES-certifikater fra Nets DanID (NemID tjenesteudbyderaftale

Læs mere

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem Arkitekturrapport: Kommunernes Ydelsessystem 1 Indholdsfortegnelse Baggrund for projekt... 3 Resultat af gennemført arkitekturanalyse... 5 Anvendelse af forretningsservices... 9 Baggrund for projekt Baggrund

Læs mere