De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

DHO Technische Architectuur Ricky Nuyens – EDS-Telindus.

Verwante presentaties


Presentatie over: "DHO Technische Architectuur Ricky Nuyens – EDS-Telindus."— Transcript van de presentatie:

1 DHO Technische Architectuur Ricky Nuyens – EDS-Telindus

2 AHOVOS p. 2 Agenda DHO Concept en Objectieven Technische Architectuur Structuur van de berichten Gegarandeerde aflevering CRUD Patronen Proof of Concept – bevindingen Volgende stappen

3 DHO Concept en Objectieven

4 AHOVOS p. 4 DHO Concept Lees web services worden synchroon opgeroepen Aanmaak, wijzig en verwijder web services worden uitgesteld synchroon opgeroepen Instelling beheert data, O&V leest data Biedt Webservice aan Roept Webservice op Unix Mainframe Instellingen Q WS internet Onderwijs & Vorming PEP B 3270

5 AHOVOS p. 5 DHO Objectieven Maximale Gegevenskwaliteit : –De gegevens die O&V aggregeert van alle instellingen zijn correct, volledig en actueel. Gegarandeerde Confidentialiteit : –De confidentialiteit van de gegevensuitwisseling tussen de instellingen en het beleidsdomein O&V moet gegarandeerd worden Authenticiteit, integriteit en niet weerlegbaarheid : –De oplossing garandeert dat de data aangereikt vanuit de instelling niet kan gewijzigd worden. Verder moet er op een onweerlegbare manier kunnen aangetoond worden dat data aangeleverd door een instelling, enkel van die instelling afkomstig kan zijn. Losse koppeling : –De dagdagelijkse werking van de instelling mag niet verhinderd worden door de oplossing. Er wordt gestreefd naar een zo los mogelijke koppeling tussen de systemen van de instelling en die van O&V Interoperabiliteit : –De oplossing is (zoveel mogelijk) gebaseerd op industrie standaarden om een maximale interoperabiliteit met de instellingen te kunnen garanderen.

6 Technische Architectuur

7 AHOVOS p. 7 Technische Architectuur Biedt Webservice aan Roept Webservice op InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Certificaat voor digitale handtekening Cert PEP 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 3270 Java Proxy Web Service Implementatie Toepassing Two-factor authentication

8 AHOVOS p. 8 Sterke Authenticatie binnen Toepassing Instelling 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 InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet PEP Web service Consumer 3270 Toepassing Bevat RRN of Bis Two-factor authentication

9 AHOVOS p. 9 Connectie Authenticatie 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) InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP SSL client certificaat SSL server certificaat 3270

10 AHOVOS p. 10 Digitale Handtekening 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, een identificatie van de toepassing Elk bericht wordt voorzien van een digitale handtekening InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP Cert 3270 Bevat instellingsnummer en toepassingsidentificatie Certificaat voor digitale handtekening Toepassing Bevat digitale handtekening

11 AHOVOS p. 11 Policy Enforcement Point (PEP) Interne web services worden beschikbaar gemaakt via een beveiligde toegangspoort die de toegangscontrole beheert : PEP Authenticatie en autorisatie stappen : –SSL Client Certificate –Digitale handtekening : instellingsnummer EN toepassingsidentificatie InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP Cert External Web service Provider met WS Security Internal Web service Provider HTTPS SOAP 3270 Java Proxy Web Service Implementatie Internal Web service Consumer

12 AHOVOS p. 12 Berichten 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 InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP Cert SOAP 3270 Repliek Verzoek

13 AHOVOS p. 13 Gebeurtenis georiënteerd, atomair en bulk 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” Correcte, volledige en actuele data aangereikt door de instellingen is noodzakelijk voor een correcte stand van het leerkrediet Gebeurtenis georiënteerd is DÉ manier InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP Cert SOAP 3270 Verzoek Vraag 1 Vraag 2 Repliek Antwoord 1 Antwoord 2

14 Structuur van de berichten

15 AHOVOS p. 15 SOAP 1.1 Structuur InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP Cert SOAP 3270 SOAP Envelope SOAP Header Digitale Handtekening (verzoek) SOAP Body Instellingsnummer Identificatie van de toepassing Gebruikers identificatie Bericht referte Vraag/Antwoord referte Any

16 AHOVOS p. 16 SOAP Header 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 de 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 “http://www.w3.org/2001/10/xml-exc-c14n#”. –Dit is de standaard methode binnen WS-Security. De originele 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

17 AHOVOS p. 17 SOAP Body : Verzoek of Repliek / OperatieMetaData 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

18 AHOVOS p. 18 SOAP Body : Verzoek 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

19 AHOVOS p. 19 SOAP Body : Verzoek / Context (Afzender) 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

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

21 AHOVOS p. 21 SOAP Body : Verzoek / Vragen 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)

22 AHOVOS p. 22 SOAP Body : Repliek 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

23 AHOVOS p. 23 SOAP Body : Repliek / Context (Afzender) Tijdstip waarop bericht werd aangemaakt Vb: dho.vlaanderen.be Identificatie van de toepassing binnen een DHO 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

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

25 AHOVOS p. 25 SOAP Body : Repliek / Antwoorden 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

26 AHOVOS p. 26 SOAP Body : Repliek / Uitzonderingen 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

27 AHOVOS p. 27 SOAP Fault 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. Unix Mainframe Instellingen Q WS internet Onderwijs & Vorming PEP 3270 SOAP Fault Uitzondering

28 Gegarandeerde Aflevering

29 AHOVOS p. 29 Gegarandeerde Aflevering Referte : unieke identificatie van berichten, vragen en antwoorden –Vraag / Antwoord : De afzender dient voor elke vraag een unieke referte te versturen. Deze wordt bij het antwoord terug gegeven opdat het mogelijk is vraag en antwoord te correleren. HTTP(S) is geen gegarandeerd protocol dus … –Het bericht werd verwerkt, de gevraagde acties werden uitgevoerd, maar er loopt iets mis bij het versturen van het antwoord –Het bericht is niet correct aangekomen bij de ontvanger en werd niet verwerkt … voor de afzender is er geen zekerheid of de berichten werden verwerkt –Vraagrefertes die bij de originele vragen werden gebruikt, MOETEN opnieuw als vraagreferte opgegeven worden –Het is niet noodzakelijk om de vragen in een identiek bericht te sturen

30 AHOVOS p. 30 Niet Gesplitst Gegarandeerde aflevering Gesplitst VerwerktNiet Verwerkt

31 CRUD Patronen

32 AHOVOS p. 32 CRUD Terminologie Object: Een object bestaat steeds uit volgende elementen. –ObjectID: Deze referentie is uniek voor elk object en wordt aangemaakt door DHO. –Objectelementen: Dit zijn de elementen die een bepaald object beschrijven. –Referenties: Referenties die naar andere objecten verwijzen

33 AHOVOS p. 33 CRUD Patronen : Aanmaak Het aanmaken van een object bij DHO vereist steeds het versturen van het aan te maken object: –Verplicht op te nemen: Objectelementen, Referenties –Mag niet opgenomen worden: ObjectID Het antwoord bevat de referentie (ObjectID) die werd aangemaakt voor het object. De instelling dient deze referentie te bewaren zodat bij latere vragen in verband met dit object deze referentie kunnen gebruiken. Indien de aanmaak niet kon verwerkt worden, wordt dit aangegeven door een Uitzondering en zal er geen Inhoudelement zijn.

34 AHOVOS p. 34 CRUD Patronen : Raadpleeg Als een instelling een object, dat eerder werd aangemaakt, wil raadplegen, dient het de door DHO aangemaakte referentie (ObjectID) te versturen via het vraagelement. DHO stuurt de volledige inhoud van het object via het antwoord terug. Indien het object niet gevonden wordt, zal enkel een uitzondering worden meegegeven

35 AHOVOS p. 35 CRUD Patronen : Wijzig Bijna identiek met Aanmaken, op ObjectID na Voor het wijzigen van een object dient men het object dat men wil wijzigen in zijn volledigheid te versturen: de ObjectID, alle objectelementen (zowel de gewijzigde als de niet gewijzigde) en alle referenties. In het antwoord staat het ObjectID, puur ter bevestiging van de succesvolle verwerking. Indien de wijziging niet kon verwerkt worden, wordt dit aangegeven door een Uitzondering en zal er geen Inhoudelement zijn.

36 AHOVOS p. 36 CRUD Patronen : Verwijder Voor het verwijderen dient enkel het ObjectID meegegeven te worden. Het antwoord bevat het ObjectID ter bevestiging van de verwerking terug. Ook hier zal bij een fout een uitzondering verstuurd worden in plaats van de inhoud.

37 Proof of Concept

38 AHOVOS p. 38 POC 2 : CA Gen Oplossing Biedt Webservice aan Roept Webservice op InstellingenOnderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP Cert SSL server certificaat External Web service Provider met WS Security Internal Web service Consumer Internal Web service Provider HTTPS SOAP 3270 Java Proxy Web Service Implementatie 32K Limiet Codepage 37/500

39 AHOVOS p. 39 CP 500

40 AHOVOS p. 40 page 40 DHO Architectuur Mainframe Biedt Webservice aan Roept Webservice op Instellingen Q WS internet Onderwijs & Vorming Cert PEP Cert Studie Toelagen Unix VIP B B B T Business Web Service Technische Web Service T T

41 AHOVOS p. 41 page 41 DHO Architectuur - Toekomst Mainframe Instellingen Q WS internet Onderwijs & Vorming Cert Studie Toelagen Unix VIP Java CAPS Biedt Webservice aan Roept Webservice op B T Business Web Service Technische Web Service B B T T T WSM

42 Verdere stappen

43 AHOVOS p. 43 Verdere stappen O&V en ET zijn verantwoordelijk voor de WSDL’s –O&V en ET zorgen voor eerste voorstel : 15 Januari 2007 –Instellingen geven opmerkingen op voorstel –WSDL’s gefinaliseerd : einde Januari 2008 Procedure “sterke authenticatie” uitwerken Procedure “aanvraag certificaat (SSL of Digitale Handtekening) uitwerken SLA beheer

44 Vragen

45 DHO Technische Architectuur Ricky Nuyens – EDS-Telindus


Download ppt "DHO Technische Architectuur Ricky Nuyens – EDS-Telindus."

Verwante presentaties


Ads door Google