Technische Architectuur. p. 2 Instellingen Q WS SSL Certificaat voor digitale handtekening Cert SSL client certificaat Web service Consumer SSL server.

Slides:



Advertisements
Verwante presentaties
BLOGGEN met GOOGLE Een onderdeel van het “Goochel” avontuur… BLOGGEN met Google presentatie van Seniornet Vlaanderen VZW Lesgever: ……………….
Advertisements

Carenet End of Life => Migratie Ziekenhuizen
MAGDA standaarden & richtlijnen
E-RADEN Roadmap. AGENDA • Overzicht van nieuwe ontwikkelingen 2009 • Interfaces • Document Types : Meta-data • E-raden gratis ? • Perspectieven.
Metadata proces april 2009 train de trainers. Waar in het werkproces metadata Binnen de organisatie zal afgesproken moeten worden van welke data er metadata.
DHO Technische Architectuur
Easy Bis Bestuursdienst Informatie Systeem Van agendapunt tot besluit Met automatische internet publicatie.
voor financiële rapportages
17 april 2008 WAB*info De digitale bron van de Nederlandse waterbodems Gaston Lamaitre Data-ICT-Dienst, Delft Uitvoerders: Atlis (hoofdaannemer), CSO (functioneel.
HALLO OPLETTEN : Waarom sql DOEN : Introductie opdracht
Hoogwaardig internet voor hoger onderwijs en onderzoek Utrecht, 29 maart 2006 nieuwe technische ontwikkelingen m.b.t. eduroam eduroam voorwaarts! Paul.
Eenduidig en verantwoord elektronisch bestuurlijk verkeer
Hoe een aanvraag voor het bekomen van een certificaat voor de export van producten bestemd voor diervoeding indienen via internet? 1. Het geschikte certificaat.
PLDA – Connectiviteit Rudolf de Schipper Geoffroy Fauveaux 09/11/2004.
Basic Web Services Technology Matthijs Smith & Roel Arents tbv ISS 2005/2006.
Databank Hoger Onderwijs: Technische architectuur 23 november 2007.
SOA, Webservices en EDISON
DISCIMUS. DISCIMUS 1.0  De doelstelling van Discimus 1.0 is : de bouw van een centraal systeem :  dat in- en uitschrijvingen registreert vanaf inschrijvingsperiode.
DOV binnenstebuiten (deel 1) Praktische tips bij het gebruik van de geografische zoekfunctie Linsey Vanthournout Departement Leefmilieu, Natuur en Energie.
Besturings- systeem A Computer A Besturings- systeem B Computer B Netwerk Handmatige taak I Applicatie 2Applicatie 1 Handmatige taak II Applicatie 3 Gebruiker.
DHO – Web Services Resultaten
Databank Hoger Onderwijs : functionaliteiten 10 oktober 2007.
Coördinatiecel Vlaams e-government 1 van 18 april 2006 CORVE / EDS-T VKBO Web Services Mark Draeck, VICC
Waarom nieuwe privacy richtlijnen?
Digipoort Eerste bijeenkomst SBR en Digipoort Datum:
Eduroam BELnet bezoek, 18 juli 2005
Hoogwaardig internet voor hoger onderwijs en onderzoek Federatieve netwerk toegang: eduroam Federatiedagen, Utrecht, 29 Maart 2006
Hoogwaardig internet voor hoger onderwijs en onderzoek eduroam BELNET, Brussel, 29 September 2005
EduRoam SEC seminar, 22 februari 2005
Hoogwaardig internet voor hoger onderwijs en onderzoek Utrecht, 27 oktober 2005 Wireless LAN beveiliging Paul Dekkers.
Service Oriented Architecture
Minicollege Service Oriented Architecture
Waarom een standaard Een norm of standaard is een procedure of een maat waarvan een groep mensen met elkaar heeft afgesproken dat ze hem zullen gebruiken.
hcc!pc Werkgroep netwerken
Het gebruik van het eHealth Platform door UZ Leuven
Edukoppeling certificering
De juridische context van de digitale factuur.
2014 EVALUATIES N+1.
1.Klik in het hoofdvenster van Lync op het tabblad Chatruimten. 2.Typ in het zoekvak de naam van een ruimte of een of meer trefwoorden. De overeenkomende.
Web service Lucinda Barendse Dennis Kanters Sjoerd Ouweneel
Federated Authentication Benchmarking Framework
21 oktober 2015 Gebruikerscomité Servercertificaten Problemen en oplossingen Eric Roelandt.
Enterprise Service Bus IBK3ESB01
Java & het Web Programma: Beveiliging Filters. Security.....wat is dat(1)? Beveiliging draait om 4 belangrijke steunpilaren: 1.Authenticatie: is de persoon.
Java & het Web Programma: Contexts Listeners Scope/Attributes Thread safety.
©2016 Avanade Inc. All Rights Reserved. RAI Community Technische Implementatie Rob Bakkers
DigEplan
RDA Toelichting op Remote Document Authentication
INFOSESSIE voor SOFTWARELEVERAN CIERS 6 juni 2016.
Netwerken 4 Enigma Netwerken paragraaf 7. Het internet  netwerk van netwerken Hosts (computers) Netwerken (met oa. switches) Verbindingen Hosts (routers)
Ervaringen Edukoppeling Lessons learned uit BPV Optimalisatie en implementatie nummervoorziening.
Netwerken 6 Enigma Netwerken paragraaf 9. Applicatielaag End-to-end principe De infrastructuur (het internet) staat los van de toepassingen Makkelijk.
Gegarandeerde Aflevering. p. 2  Referte : unieke identificatie van berichten, vragen en antwoorden Vraag / Antwoord : De afzender dient voor elke vraag.
Gids door Doccle Doccle. De Cloud 2 1.Wat is de Cloud? 2.Voordelen van de Cloud 3.Nadelen van de Cloud 4.Doccle is geen cloudapplicatie.
Edukoppeling Implementatie aanpak Edustandaard Architectuurraad 23 juni 2016.
Universiteit Utrecht Managementinformatie via het web met behulp van Business Objects Angela Wolffenbuttel Afdeling Informatievoorziening, Bureau Controller.
in de bouw Beveiligde uitwisseling van data.
SharePoint Alles over metadata In de Private en Public cloud.
Wat is het Hoe stel ik het in Hoe kan ik het gebruiken
MAGDA in een notendop.
Hoe werkt bibliografische software?
Het eHealth-platform ICT InfoDay 2 maart 2011
Identication & Authentication
End-to-end vercijfering
Kennis delen Actualisering register kwalificatiestructuur SBB.
Technische Architectuur & Discimus
Een volgende stap voor het succesvolle EDISON verhaal
FINELTS Wijzigingen 2018 nieuwe XSD-schema's & schermen
WIBON levering (producten)
DCAT-AP Vlaanderen voorlegging als standaard
Transcript van de presentatie:

Technische Architectuur

p. 2 Instellingen Q WS SSL Certificaat voor digitale handtekening Cert SSL client certificaat Web service Consumer SSL server certificaat External Web service Provider met WS Security Internal Web service Consumer Internal Web service Provider HTTPS SOAP Web service en business logica in Java Web Service Implementatie Toepassing Two-factor authentication Unix Onderwijs & Vorming PEP Internet Technische Architectuur Biedt Webservice aan Roept Webservice op

p. 3  Web service Consumer zit ingebed in een toepassing binnen de instelling  Gebruik van web services moet beperkt blijven tot geautoriseerde medewerkers omdat het privacy gevoelige gegevens betreft  two-factor authentication  Elk bericht dat de instelling verstuurt bevat de correcte identificatie (RRN of Bis of …) van de betrokken eindgebruiker Sterke Authenticatie binnen Toepassing Instelling Instellingen Q WS Toepassing Unix Onderwijs & Vorming PEP Internet Bevat RRN of Bis Web service Consumer Two-factor authentication Biedt Webservice aan Roept Webservice op

p. 4  Publieke web services maar enkel instellingen mogen deze aanroepen  Implementatie op basis van X.509 SSL client-certificate authenticatie  1 SSL certificaat per instelling (of per ICT provider) SSL client certificaat SSL server certificaat Connectie Authenticatie Instellingen Q WS SSL Cert Unix Onderwijs & Vorming PEP Internet Biedt Webservice aan Roept Webservice op

p. 5  Elke instelling mag enkel toegang hebben tot eigen gegevens  Implementatie op basis van X.509 Certificaat voor digitale handtekening  1 X.509 certificaat per toepassing binnen instelling  Elk bericht bevat het instellingsnummer en een identificatie van de toepassing  Elk bericht wordt voorzien van een digitale handtekening Toepassing Digitale Handtekening Instellingen Q WS SSL Cert HTTPS SOAP Unix Onderwijs & Vorming PEP Internet Bevat instellingsnummer en toepassingsidentificatie Certificaat voor digitale handtekening Bevat digitale handtekening Toepassing Biedt Webservice aan Roept Webservice op

p. 6  Interne web services worden beschikbaar gemaakt via een beveiligde toegangspoort die de toegangscontrole beheert : PEP of Policy Enforcement Point  Authenticatie en autorisatie stappen : SSL Client Certificate Digitale handtekening : instellingsnummer EN toepassingsidentificatie Policy Enforcement Point (PEP) Instellingen Q WS SSL Cert HTTPS SOAP Unix Onderwijs & Vorming PEP Internet External Web service Provider met WS Security Web Service Implementatie Internal Web service Consumer Biedt Webservice aan Roept Webservice op

p. 7  Robuust Het veranderen van een web service vergt heel wat inspanning. Daarom wordt verwacht dat de berichten minstens even robuust zullen zijn als de EDISON record layouts  Instelling agnostisch Er worden geen berichten gespecificeerd per instelling of voor een bepaalde set van instellingen. Alle web services kunnen door alle instellingen aangeroepen worden  Toepassing agnostisch In de berichten wordt niet aangegeven voor welke toepassing ze bestemd zijn.  Gestandaardiseerd SOAP 1.1 & Uniforme structuur Berichten Instellingen Q WS SSL Cert SOAP Unix Onderwijs & Vorming PEP Internet Repliek Verzoek Biedt Webservice aan Roept Webservice op

p. 8  Web services hebben zowel ondersteunende (lees) functie als “data vergarende” functie.  Bij doorgeven van veel gegevens is bulk efficiënter (digitale handtekening, netwerk, …)  structurele oplossing in structuur van de berichten  Bulk is niet hetzelfde als “’s nachts in batch- of stapelverwerking”  Correcte, volledige en actuele data aangereikt door de instellingen is noodzakelijk  Gebeurtenis georiënteerd is DÉ manier Repliek Antwoord 1 Antwoord 2 Gebeurtenis georiënteerd, atomair en bulk Instellingen Q WS SSL Cert SOAP Unix Onderwijs & Vorming PEP Internet Biedt Webservice aan Roept Webservice op Verzoek Vraag 1 Vraag 2

Structuur van de berichten

p. 10 SOAP Envelope SOAP Header Digitale Handtekening (verzoek) SOAP Body Instellingsnummer Identificatie van de toepassing Gebruikers identificatie Bericht referte Vraag/Antwoord referte Any SOAP 1.1 Structuur Instellingen Q WS SSL Cert HTTPS SOAP Unix Onderwijs & Vorming PEP Internet

p. 11  Identiek aan DHO berichten  WS-Security 1.0  Boodschap-encryptie is niet noodzakelijk wegens connectie-encryptie (SSL)  De digitale handtekening omvat de hele SOAP body.  Het certificaat gebruikt om te tekenen wordt meegegeven in elke boodschap, met formaat “oasis wss-x509-token-profile- 1.0#X509v3”  De canonicalization method die gebruikt moet worden is Exclusive Canonicalization “ Dit is de standaard methode binnen WS-Security. De methode zonder “exclusive” bleek validatieproblemen te veroorzaken in situaties waarbij gehandtekende XML documenten bijgesloten werden in andere XML documenten.  De digest en handtekening protocols zijn SHA1 en RSA SOAP Header

p. 12  Momenteel onder review Afstemming met MAGDA voor ganse Vlaamse overheid Verwacht wordt dat er kleine wijzigingen zijn t.o.v. DHO Bv. Datum formaat  Volgende slides zijn voorlopig nog niet bindend, maar dienen als voorbeeld SOAP Body

p. 13  Het OperatieMetaData element bevat de Versie en de Naam van de operatie  De inhoud van deze elementen staat vast door de beschrijving van het XML Schema en kan NIET veranderd worden  Zowel in Verzoek als Repliek  Operationele Ondersteuning SOAP Body : Verzoek of Repliek / OperatieMetaData Onder voorbehoud

p. 14  Alle “verzoeken” volgen dezelfde structuur OperatieMetaData: Informatie over de operatie (dezelfde structuur voor alle operaties) Context: Informatie voor autorisatiedoeleinden (dezelfde structuur voor alle operaties) Vragen: Informatie over de invoer van de operatie (specifieke structuur voor iedere operatie) Bevat de invoer van de operatie Context informatie omtrent de operatie: Wie, waar, wanneer? Informatie over de operatie: Versie & Naam Onder voorbehoud SOAP Body : Verzoek

p. 15 Tijdstip waarop bericht werd aangemaakt Unieke identificatie van het verzoek bericht Instellingsnummer Verplicht voor de instelling Security op basis van rollen (Optioneel) Naam van de gebruiker Naam van de organisatie-eenheid (Optioneel) INSZ-nummer van de gebruiker Type van het verzoek bericht = VRAAG Onder voorbehoud SOAP Body : Verzoek / Context (Afzender)

p. 16 Optionele elementen voor verzoek Vb: dho.vlaanderen.be Optioneel voor de instelling Onder voorbehoud SOAP Body : Verzoek / Context (Ontvanger)

p. 17  Referte is verplicht en uniek voor een instelling  VraagInhoud is specifiek voor elke operatie  Meerdere vragen binnen een verzoek mogelijk, maar gelimiteerd in aantal (1..99) Onder voorbehoud SOAP Body : Verzoek / Vragen

p. 18  Alle “replieken” volgen dezelfde structuur OperatieMetaData: Informatie over de operatie (dezelfde structuur voor alle operaties) RepliekContext: Informatie omtrent de afzender van het verzoek en de ontvanger van het verzoek (= degene die het verzoek beantwoordt) Antwoorden: Informatie omtrent het antwoord op de gestelde vraag (specifieke structuur voor iedere operatie) Uitzonderingen: Voor fouten op bericht-niveau Bevat de uitvoer van de operatie Context informatie omtrent de operatie: Wie, waar, wanneer? Informatie over de operatie: Versie & Naam Boodschap tgv fouten op bericht niveau Onder voorbehoud SOAP Body : Repliek

p. 19 Tijdstip waarop bericht werd aangemaakt Vb: dho.vlaanderen.be Identificatie van de toepassing binnen Security op basis van rollen (optioneel) Naam van de gebruiker Naam van de organisatie-eenheid (optioneel) INSZ-nummer van de gebruiker (optioneel) Unieke identificatie van het repliek bericht Type van het repliek bericht = ANTWOORD Onder voorbehoud SOAP Body : Repliek / Context (Afzender)

p. 20 De context informatie van de afzender van het verzoek bericht wordt hierin gekopieerd (hierbij ook de referte van het verzoek bericht) Onder voorbehoud SOAP Body : Repliek / Context (Ontvanger)

p. 21  Referte komt overeen met de Referte van de overeenstemmende Vraag  AntwoordInhoud is specifiek voor elke operatie  Als er een fout wordt opgemerkt in de vraag, wordt er minstens 1 uitzondering teruggestuurd Onder voorbehoud SOAP Body : Repliek / Antwoorden

p. 22  Identificatie: Unieke identificatie van de uitzondering  Type: 3 uitzonderingstypes (Fout, Waarschuwing & Informatie)  Tijdstip: wanneer de uitzondering zich heeft voorgedaan  Diagnose: beschrijving van de uitzondering (boodschap)  Omstandigheid: bijkomende informatie omtrent de uitzondering Onder voorbehoud SOAP Body : Repliek / Uitzonderingen

p. 23  Enkel wanneer het bericht niet “applicatief verwerkt” wordt Foute XML structuur, niet conform het schema Foute Digitale Handtekening Encoding Version Mismatch  Een SOAP fault bevat de elementen faultcode voor het type fout, faultstring met een beschrijving van de fout, faultactor voor de bron van de fout detail met de detailuitleg van de foutmelding. Onder voorbehoud Instellingen Q WS SSL Cert HTTPS SOAP Unix Onderwijs & Vorming PEP Internet SOAP Fault Uitzondering SOAP Fault