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

Presentatie over: "Technische Architectuur. p. 2 Instellingen Q WS SSL Certificaat voor digitale handtekening Cert SSL client certificaat Web service Consumer SSL server."— Transcript van de presentatie:

1 Technische Architectuur

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 Structuur van de berichten

10 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

11 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-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 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

12 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

13 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

14 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

15 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)

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

17 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

18 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

19 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)

20 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)

21 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

22 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

23 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