DHO Technische Architectuur

1. DHO Technische Architectuur Ricky Nuyens – EDS-Telindus

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

3. DHO Concept en Objectieven

4. Q Biedt Webservice aan Roept Webservice op Unix 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 WS 3270 internet B PEP Mainframe Instellingen Onderwijs & Vorming

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. Cert Cert Cert Q Biedt Webservice aan Roept Webservice op Unix Technische Architectuur SSL server certificaat Certificaat voor digitale handtekening Java Proxy SSL client certificaat Internal Web service Provider WS 3270 internet HTTPS SSL Two-factor authentication SOAP PEP Toepassing Mainframe External Web service Provider met WS Security Web service Consumer Instellingen Onderwijs & Vorming Web Service Implementatie Internal Web service Consumer

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

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

10. Cert Cert Cert Q Unix Digitale Handtekening Certificaat voor digitale handtekening Bevat 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 WS 3270 internet SSL PEP Toepassing Mainframe Instellingen Onderwijs & Vorming Bevat instellingsnummer en toepassingsidentificatie

11. Cert Cert Cert Q Unix Policy Enforcement Point (PEP) Java Proxy Internal Web service Provider • 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 WS 3270 internet HTTPS SSL SOAP PEP Mainframe External Web service Provider met WS Security Instellingen Onderwijs & Vorming Web Service Implementatie Internal Web service Consumer

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

13. Verzoek Vraag 1 Vraag 2 Cert Cert Cert WS 3270 internet SSL SOAP Repliek PEP Antwoord 1 Mainframe Antwoord 2 Instellingen Onderwijs & Vorming Q Unix 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

14. Structuur van de berichten

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

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-200401-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. 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. SOAP Body : Verzoek Informatie over de operatie: Versie & Naam Context informatie omtrent de operatie: Wie, waar, wanneer? • 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

19. SOAP Body : Verzoek / Context (Afzender) Type van het verzoek bericht = VRAAG Tijdstip waarop bericht werd aangemaakt 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 Unieke identificatie van het verzoek bericht

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

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. SOAP Body : Repliek Informatie over de operatie: Versie & Naam Context informatie omtrent de operatie: Wie, waar, wanneer? • 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 Boodschap tgv fouten op bericht niveau

23. SOAP Body : Repliek / Context (Afzender) Type van het repliek bericht = ANTWOORD 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 INSZ-nummer van de gebruiker (optioneel) Naam van de organisatie-eenheid (optioneel) Unieke identificatie van het repliek bericht

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

28. Gegarandeerde Aflevering

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. Gegarandeerde aflevering Verwerkt Niet Verwerkt Niet Gesplitst Gesplitst

31. CRUD Patronen

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. 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. 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. 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. 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. Cert Cert Cert Q Biedt Webservice aan Roept Webservice op Unix POC 2 : CA Gen Oplossing SSL server certificaat Java Proxy Internal Web service Provider WS 3270 internet HTTPS SSL SOAP PEP Mainframe External Web service Provider met WS Security Instellingen Onderwijs & Vorming Web Service Implementatie Internal Web service Consumer • 32K Limiet • Codepage 37/500

39. CP 500

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

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

42. Verdere stappen

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