DHO Technische Architectuur Ricky Nuyens – EDS-Telindus

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

DHO Concept en Objectieven

DHO Concept B Lees web services worden synchroon opgeroepen WS 3270 internet Q Unix B PEP Mainframe Instellingen Onderwijs & Vorming 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

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. SLA : Later te bespreken

Technische Architectuur

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

Sterke Authenticatie binnen Toepassing Instelling Bevat RRN of Bis WS 3270 internet Two-factor authentication Q Unix Toepassing PEP Mainframe Web service Consumer Instellingen Onderwijs & Vorming 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 De Web service Consumer zit ingebed in een toepassing binnen de instelling. Het gebruik van de toepassing, die op haar beurt de publieke web services aanspreekt, moet beperkt blijven tot geautoriseerde medewerkers, omdat het privacy gevoelige gegevens betreft. O&V legt aan de onderwijsinstellingen op dat een sterke authenticatie moet worden uitgevoerd voor die eindgebruikers die geautoriseerd zijn om een web service aan te roepen De authenticatie komt overeen met niveau 200 (federaal token) of 300 (eID) zoals bepaald in de veiligheidsnormen voor e-governement binnen de Vlaamse Overheid. De toepassing van de instelling dient de correcte identificatie (RRN of Bis) van de betrokken van de eindgebruiker op te nemen in elk bericht dat deze verzendt bij het oproepen van een publieke web service.

Connectie Authenticatie SSL server certificaat SSL client certificaat WS 3270 internet Cert Cert Q SSL Unix PEP Mainframe Instellingen Onderwijs & Vorming 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) De web services worden beschikbaar gemaakt via het publieke Internet. Om te vermijden dat alle Internet gebruikers toegang krijgen tot de web services (met mogelijke aanvalspogingen), wordt connectie-toegang enkel verleend tot de onderwijsinstellingen. Dit wordt geïmplementeerd door middel van SSL met client-certificate authenticatie. Hiervoor is eveneens een x.509 certificaat (cfr SSL client certificaat) nodig, maar dit certificaat staat in voor de authenticatie van de onderwijsinstelling, niet voor de specifieke applicatie, het heeft dus een ander profiel. Het is mogelijk dat dit certificaat hetzelfde is als dat voor de boodschap handtekening, indien de SSL client-authenticatie specifiek is voor deze applicatie, en niet herbruikt wordt voor andere applicaties.

Digitale Handtekening Certificaat voor digitale handtekening Bevat digitale handtekening Cert WS 3270 internet Cert Q SSL Cert Unix Toepassing PEP Mainframe Instellingen Bevat instellingsnummer en toepassingsidentificatie Onderwijs & Vorming 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 De identificatie van de onderwijsinstelling (met een instellingsnummer) is uiterst belangrijk. Het moet namelijk onmogelijk zijn dat een onderwijsinstelling een boodschap stuurt of data verkrijgt over een instellingsnummer die haar niet toebehoort. Elk bericht dient daarom het instellingsnummer te bevatten. Naast het instellingsnummer moet elk bericht ook de identifcatie van de toepassing bevatten die de web service aanroept. Elke toepassing binnen de instelling wordt voorzien van een x.509 certificaat (cfr Certificaat Digitale Handtekening). Dit certificaat laat de web service consumer toe om de web service boodschappen te voorzien van een digitale handtekening, zodat de web service provider (cfr External Web Service Provider met WS Security) kan valideren dat de boodschap komt van een geautoriseerde (en dus sterk geauthenticeerde) toepassing, alsmede de integriteit van de boodschap. Het x.509 certificaat word dus toegekend aan een specifieke toepassing, en kan niet hergebruikt worden voor andere toepassingen binnen de onderwijsinstelling.

Policy Enforcement Point (PEP) Java Proxy Internal Web service Provider Cert WS 3270 internet HTTPS Cert SSL Cert Q SOAP Unix PEP Mainframe External Web service Provider met WS Security Instellingen Onderwijs & Vorming Web Service Implementatie Internal Web service Consumer 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 De interne web services (cfr Internal Web Service Provider) binnen het netwerk van de Vlaamse Gemeenschap (“vlaanderen.be”) worden nooit rechtstreeks op Internet beschikbaar gemaakt, wel via een “security gateway” die de toegangscontrole beheert – dit is een “Policy Enforcement Point” of PEP. De PEP garandeert de eigenlijke toegangscontrole, maar gebruikt een “Policy Decision Point” (PDP) om uit te maken of een specifieke toegang al dan niet toegelaten is. Alle boodschappen van de onderwijsinstelling worden gevalideerd op de PEP. Indien de authenticatie- en autorisatie-stappen positief gevalideerd zijn, wordt de web service boodschap zonder de WS-Security informatie (handtekening, authenticatie) doorgestuurd naar de interne web service provider. Deze mag veronderstellen dat elke ontvangen boodschap van een geautoriseerde applicatie bij de onderwijsinstelling met gegeven instellingsnummer komt. De interne web service provider maakt op zijn beurt gebruik van een, met CA Gen gegenereerde, Java proxy die de “echte” business logica aanspreekt. De business logica van de web services (cfr Web Service Implementatie) wordt ontwikkeld op de backend (mainframe) van O&V zodat optimaal gebruik kan gemaakt worden van bestaande data en functionaliteit

Berichten Robuust Instelling agnostisch Toepassing agnostisch Instellingen Onderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP SOAP 3270 Verzoek Repliek 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

Gebeurtenis georiënteerd, atomair en bulk Instellingen Onderwijs & Vorming Unix Mainframe Q WS internet SSL Cert PEP SOAP 3270 Verzoek Vraag 1 Vraag 2 Repliek Antwoord 1 Antwoord 2 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 De web services die door O&V worden aangeboden hebben, naast een puur ondersteunende (lees/validatie) functie, ook een “data vergarende” functie. Wanneer een specifieke gebeurtenis zich voordoet bij de instelling (een inschrijving, een uitschrijving, slagen voor een examen) dan dient O&V daar zo snel mogelijk van op de hoogte te worden gebracht. Hoewel er eerder werd gesteld dat er een zekere loskoppeling moet zijn tussen de toepassing van de instelling en het aanroepen van de web service zou er toch naar gestreefd moeten worden om die periode zo kort mogelijk te houden. Er wordt immers gestreefd naar een zo correct, volledig en actueel mogelijk beeld van de data die bij de instellingen aanwezig is (zie business vereisten) Maar bij het doorgeven van gegevens is het soms efficiënter om deze in bulk (typisch ’s nachts) dan wel atomair door te geven. Het in bulk doorsturen van gegevens heeft als voordeel dat er minder overhead is van beveiliging (minder berichten dienen voorzien te worden van beveiliging) en doordat het transport efficiënter gebeurt (er moet niet telkens per transactie gewacht worden op de repliek). Stel dat er aan een instelling 1000 studenten zijn, die elk 15 examens afleggen. Stel dat er ook een atomaire “examenresultaat voor opleidingsonderdeel voor student”-web service wordt aangeboden. Dan zou dit betekenen dat de web service 15000 keer moet opgeroepen worden. In dit voorbeeld kan men voorzien dat het raadzamer is om een bulk web service aan te bieden. Maar in andere gevallen kan men dat niet en is het afhankelijk van het ontwerp van de toepassing bij de instelling dat men ofwel atomaire dan wel bulk web services prefereert. Om dit probleem structureel op te vangen worden alle web service berichten voorzien van een structuur zodat het mogelijk is van in 1 bericht 1 of meerdere (soortgelijke) vragen te stellen en daarop respectievelijk 1 of meerder antwoorden terug te krijgen. De structuur van het bericht wordt verder in het document in detail toegelicht. Het is belangrijk om te onderstrepen dat de gebeurtenis georiënteerde manier van werken toch dé manier van werken is die wordt aangeraden.

Structuur van de berichten

SOAP 1.1 Structuur SOAP Envelope SOAP Header SOAP Body Any internet WS Cert 3270 internet Cert SSL Cert Q SOAP Unix 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

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 WS-Security 1.0 (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf) De digest en handtekening protocols zijn SHA1 (http://www.w3.org/2000/09/xmldsig#sha1) en RSA (http://www.w3.org/2000/09/xmldsig#rsa-sha1).

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

SOAP Body : Verzoek Alle “verzoeken” volgen dezelfde structuur Informatie over de operatie: Versie & Naam Context informatie omtrent de operatie: Wie, waar, wanneer? Bevat de invoer van de operatie 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)

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

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

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)

SOAP Body : Repliek Alle “replieken” volgen dezelfde structuur Informatie over de operatie: Versie & Naam Context informatie omtrent de operatie: Wie, waar, wanneer? Bevat de uitvoer van de operatie Boodschap tgv fouten op bericht niveau 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

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

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)

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

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

SOAP Fault Enkel wanneer het bericht niet “applicatief verwerkt” wordt Uitzondering SOAP Fault SOAP Fault Uitzondering WS 3270 internet Q Unix PEP Mainframe Instellingen Onderwijs & Vorming 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.

Gegarandeerde Aflevering

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 Enkel indien geen fout optrad zal antwoord in cache opgenomen worden Voor lees acties een fouten … niet in cache

Gegarandeerde aflevering Verwerkt Niet Verwerkt Niet Gesplitst Gesplitst Als een vraag opnieuw verstuurd wordt, zal de afzender een antwoord terugkrijgen alsof het bericht voor de eerste maal werd verstuurd. Als de vraag voordien reeds werd verwerkt door het systeem (situatie 1) zal het systeem dit detecteren omdat de reeds gebruikte vraagreferte opnieuw wordt gebruikt. Als het bericht niet correct is aangekomen bij Hoger Onderwijs (situatie 2) wordt de vraag als een nieuwe vraag behandeld. Onderstaande Tabel geeft een overzicht van de hierboven opgesomde situaties.

CRUD Patronen

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

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. 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 DHO verwerkt de vraag en stuurt daarna in het antwoord de referentie (ObjectID) die werd aangemaakt voor het object terug. De instelling dient deze referentie te koppelen aan hun object zodat ze bij latere dienstaanvragen in verband met dit object de referentie kunnen gebruiken. Als er iets fout loopt bij het aanmaken wordt er binnen het antwoord geen Inhoud element voorzien. Wel wordt in dit geval een Uitzonderingen element opgenomen met daarin minimum 1 Uitzondering element.

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

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.

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.

Proof of Concept

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

CP 500

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

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

Verdere stappen

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

Vragen

DHO Technische Architectuur Ricky Nuyens – EDS-Telindus