De discussie van 28 januari 2013: "RFC: In vrije berichten toestaan om geen stuurgegevens te gebruiken. Bij foutafhandelingen de WS-* standaarden volgen" bestaat uit 2 delen. RFC0134 voor Vrije berichten is inmiddels doorgevoerd. Deze discussie gaat over het gebruik van WS-* standaarden of eigenlijk het weghalen van routeringsinformatie uit de payload.
Uitgangspunt in de discussie was: "Het gebruik van stuurgegevens in de “payload” van berichten is in strijd met de geest van de wereldwijde standaarden. Het zelf implementeren van routering informatie in een bericht, maakt de implementatie van een webservice of consument onnodig ingewikkeld. Het uitgangspunt van de service orientatie is dat een dienst wordt afgenomen op een bepaald adres en het routeren is strikt verborgen in de infrastructuur."
Dit is in tegenspraak met "Wel is gesteld dat een StUF bericht zelf moet vertellen wat er met hem moet gebeuren zonder dat er tussen de end-to-end points gerommeld wordt met de stuurgegevens. Je zou dus WS-* toe kunnen passen zonder wijzigingen aan te brengen op de stuurgegevens."
De laatste stelling is niet wat je wilt. Als stuurgegevens blijven bestaan is het nutteloos om WS-* standaarden zoals wsa:To, wsa:From te verplichten. Uitgangspunt is om service oriëntatie toe te passen en routeringsinformatie uit de playload te krijgen, niet om verplicht gebruik te maken van wereldwijde standaarden. Gebruik maken van deze standaarden moeten je helpen, niet extra werk bezorgen. Zolang stuurgegevens niet verdwijnen hoef je ook niet a la SuwiML bv wsaw="http://www.w3.org/2006/05/addressing/wsdl" te verplichten in de definities. Kan natuurlijk wel, hier zouden we dan een andere discussie over kunnen voeren.
De standaarden maken voor WS-Security, WS-Adressing etc. gebruik van de SOAP header. Stuurgegevens zitten nu in de SOAP body. Om de StUF standaard hierin te verbeteren en beide stellingen hierboven iets naar elkaar toe te brengen stel ik voor in de huidige standaard alle berichten de stuurgegevens te verplaatsen van de SOAP body naar de SOAP header. De stuurgegevens blijven in het bericht, zitten niet meer in de payload maar daar waar ze eerder thuishoren: in de header. Alle intermediair systemen kan je configureren om het bericht inclusief de header door te sturen. In Den Haag hebben we voor oa bevragingen de security stricter en willen we niet dat "stuurgegevens" onderweg te manipuleren zijn. Om dit te bereiken moet onze intermediair zelf bij de stuurgegevens kunnen komen. Nu zijn we verplicht de payload aan te passen. Dit is niet wat je wilt. Vanuit de standaarden zou het al een verbetering zijn als het voldoende is om niet de payload maar de header aan te passen. De Payload is voor de doelapplicatie. Met een aanpassing zoals
<message name="Stuurgegevens">
<part name="parameters" element="BG:Stuurgegevens"/>
</message>
en bv
<operation name="npsLv01">
<soap:operation soapAction="http://www.egem.nl/StUF/sector/bg/0310/npsLv01"/>
<input>
<soap:header message="tns:Stuurgegevens" part="parameters" use="literal"/>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
<fault name="fout">
<soap:fault name="fout" use="literal"/>
</fault>
</operation>
is dit vrij snel te doen.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0470.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
@Andre:
Wat bedoel je met deze passage: "In Den Haag hebben we voor oa bevragingen de security stricter en willen we niet dat stuurgegevens onderweg te manipuleren zijn. Om dit te bereiken moet onze intermediair zelf bij de stuurgegevens kunnen komen. Nu zijn we verplicht de payload aan te passen. Dit is niet wat je wilt. Vanuit de standaarden zou het al een verbetering zijn als het voldoende is om niet de payload maar de header aan te passen."
Vanuit securityoverwegingen zou ik niet zo goed weten waarom je de stuurgegevens zou willen aanpassen?
Stuurgegevens zijn in vele gevallen zelf een onderdeel van het securityprobleem. Denk aan de gebruikersnaam of wijzigen van de zender.
Ik zou er ook voor willen pleiten rekening te houden met meer protocolbindingen dan alleen WS-*.
Tijdens de StUF Expertgroep van 15 februari 2017 is dit RFC goedgekeurd voor uitwerking. Tijdens de discussie kwamen er nog wel twee opties bovendrijven. Een waarbij de stuurgegevens naar de soap-header worden verplaatst en een waarbij de stuurgegevens zowel in de payload als in de soap-header wordt geplaatst. Bij de laatste vorm loop je de kans dat beide stuurgegevens uit elkaar gaan lopen.
Hierbij de uitwerking van RFC0470
Bijlage
Bij het doornemen van de uitwerking kreeg ik de volgende foutmelding tijdens het openen van de WSDL met behulp van XML Spy:
File C:\dev\SEG\RFC0470\wsdl\bg0310_verstrekSynchronisatieBericht_mutatie.wsdl is not valid.
File C:\dev\SEG\RFC0470\wsdl\0301\stuf0301.xsd is not valid.
Invalid XML schema: ''StUF:verwerkingssoort' is already declared in schema document 'C:\dev\SEG\RFC0470\wsdl\bg0310_msg_stuf_mutatie_resolved.xsd'.'
Error location: schema / attribute
Het probleem heb ik opgelost door in 0301\stuf0301_types.wsdl in plaats van stuf0301.xsd het schema uit de bovengelegen map bg0310_msg_stuf_mutatie_resolved.xsd te importeren.
Vervolgens kan ik de voorbeeldberichten niet valideren met de schema's. Het schema van de SOAP envelope laat weliswaar alles toe in de header maar nu wordt de structuur van de stuurgegevens niet meer afgedwongen.
Dat lijkt me in de praktijk lastig. Het invullen en gebruik van de SOAP header moet door (aanvullende) afspraken afgedwongen worden maar een bericht wat hier niet aan voldoet kan wel valide zijn volgens het StUF schema.
Bovendien zijn de voorbeelschema's de stuurgegevens verwijderd. Dit is in strijd met wat boven in pagina 2 wordt gesteld: Laat implementaties van koppelvlakken vrij in de keuze van stuurgegevens routering.
Het idee van de RFC vind ik interessant maar er moet nog nagedacht worden hoe de stuurgegevens valideerbaar in de SOAP header geplaatst kunnen worden en hoe eventueel stuurgegevens wel (ook) in de payload opgenomen kunnen worden, mocht het nodig zijn.
Die import fout is mijn fout. Sorry daarvoor.
De voorbeeld schemas zijn een voorbeeld implementatie voor een koppelvlak die kiest voor deze wijze van stuurgegevens routering.
Waarom zou je schema validatie willen op authenticatie, autorisatie en routeringsgegevens ? In mijn optiek is schema validatie hiervoor niet bedoeld. Als je de routering of authenticatie fout doet werkt het niet. WS-* standaarden zitten ook niet in schema validatie. Evenzo het meegeven van een security token of SAML. Wel zijn dit internationale standaarden die beschreven zijn. Een ESB kan aanvullend, indien ingesteld, simpel een SAML of token valideren. Een applicatie kan die validatie ook toepassen. Het lijkt me juist dat als je in een koppelvlak implementatie kiest voor een eigen SOAP header dat je dan hiervoor aanvullende afspraken moet maken. En ook hier kan de applicatie, net als bij de SAML of token, de header valideren
Toch vindt er wel enige vorm van validatie van de soapheader plaats.
Zo wordt in zowel XML-Spy als Oxygen het element <request_header> afgekeurd en worden, na verwijdering van dat element, ook de andere elementen afgekeurd zodra ik de prefix 'stuf' verwijder.
Wijzig ik de naam '<stuf:berichtcode>' in '<stuf:berichtcode1>' dan is er weer geen vuiltje aan de lucht en valideert het bericht gewoon.
Tijdens de StUF Expertgroep van 19 april 2017 heeft een aantal leden zijn bezwaren geuit tegen het voorstel van Andre. Zo zijn er bezwaren tegen het feit dat je de stuurgegevens niet meer kunt valideren maar tevens dat het er niet simpeler op wordt terwijl men geen behoefte bij de gemeenten ziet.
Toch vinden een aantal leden het voorstel dermate interessant dat het zeker verder onderzoek verdiend. Zo zou er een inhoudelijke analyse plaats moeten vinden waarin o.a. aandacht wordt besteedt aan het probleem dat aan het voorstel ten grondslag ligt en waarin staat hoe het voorstel bijdraagt aan het oplossen van dat probleem. Aangezien het voorstel pas op de dinsdag voor de bijeenkomst is gepost wordt uiteindelijk besloten het punt weer op de agenda van de volgende StUF Expertgroep te plaatsen zodat de leden meer tijd hebben het te bestuderen.
Hierbij vaststellen probleem, onderzoek, analyse en voorstel voor 4 verbeterpunten door mij uitgewerkt met hulp van KING expertise.
Bijlage
Tijdens de StUF Expertgroep van 17 mei 2017 is over het voorstel van Andre gesproken.
Daarbij is gesteld dat de gegevens in de stuurgegevens natuurlijk voor de logistiek van belang zijn maar dat je deze deels ook functioneel nodig hebt. Met name om die reden is het geen optie om de stuurgegevens te verplaatsen naar het ws:addressing deel van de soap-header omdat het ws:addressing deel bij het doorlopen van de verschillende hubs steeds aangepast kan worden.
Tijdens de discussie kwam de optie van het gebruik van SAML naar boven drijven. Een SAML fragment mag onderweg niet aangepast worden. Besloten is dat we gaan kijken of we het voorstel kunnen uitbreiden met SAML.
In dit kader zou ik voor willen stellen naast SAML ook te kijken naar OAuth en OpenID. Met name ook vanwege de mogelijkheden voor andere formaten van XML (JSON etc.).
Binnen de documentcreatieservices is al een onderhoudsverzoek ingediend om te kijken naar gebruik van onder andere OAuth binnen dit koppelvlak. Natuurlijk moet zoiets niet binnen één enkel koppelvlak afzonderlijk geregeld worden maar zou het juist goed zijn om dit overkoepelend voor alle koppelvlakken en mogelijk ook gewoon StUF breed op dezelfde manier aan te pakken.
Tijdens de StUF Expertgroep van 21 juni 2017 is dit RFC weer besproken.
Er werd nogmaals duidelijk gesteld dat sommige stuurgegevens ook nodig zijn voor de verwerking van de berichten.
Daarnaast konden enkele leden zich er niet in vinden de stuurgegevens optioneel te maken in de generieke berichten aangezien daarmee ook zender en ontvanger optioneel zouden worden. dat was niet acceptabel.
Wel was er bereidheid de discussieren over de vormgeving van het optioneel maken van de stuurgegevens.
Een van de richtingen waarin werd gedacht was het zo herschrijven van de standaard dat deze los komt te staan van XML. E.e.a. zou dan moeten verhuizen naar de protocolbindingen.
Het tijdens de voorgaande vergadering besproken idee om gebruik te maken van SAML werd ter discussie gesteld. In plaats daarvan zou je ook gebruik kunnen maken van OAuth en OpenID.
In de werkgroep van de Zaak- Documentservices zal volgende week een voorstel worden besproken. Indien dat voorstel goed wordt ontvangen dan zullen Michiel Verhoef en Andre van de Nouweland dat samen verder oppakken en zal bekeken worden of dit kan worden opgenomen in de StUF onderlaag.
SAML uitleg
Bijlage
SAML uitleg als PDF
Bijlage
Ik zit niet zo diep in de materie als de meesten hier maar even 2 kleine kanttekeningen
1. Vallen de headers niet binnen het domein van de 'digikoppeling standaard'? In de digikoppeling standaard WUS staat namelijk:
DigiKoppeling richt zich dus uitsluitend op de logistieke laag.(..) In het geval van WUS en ebMS komt de logistieke laag overeen met de ‘header’ van het bericht en gaat de ‘body’ uitsluitend over de inhoud.
2. Zo op het oog is wat in de protocolbindingen geschreven staat over versleuteling/signing certificaten e.d. geërfd van de digikoppeling standaard. Met de voorstellen hier om SAML / openID te gebruiken trek je een heel nieuw domein, namelijk versleuteling/signing binnen de StUF standaard. Verder kun je nog discussieren over de use-case. Ik vraag mij af hoe breed de vraag is en SSL wordt al binnengemeentelijk afgedwongen dus als je unieke identificatie wilt valt daar een oplossing te vinden (en ook gratis en out-of-the-box beschikbaar, bijvoorbeeld met apache ingangen definiëren en daar een certificaat afdwingen)
Je kan logistiek maar ook authenticatie/autorisatie in Soap headers plaatsen. Die afspraken wil je op zijn vroegst op koppelvlak niveau maken. Of misschien pas bij implementatie (aansluitvoorwaarden aanbieder). De Digikoppeling -ebMS en -WUS koppelvlakken zijn voorbeelden waar afspraken gemaakt zijn voor het bericht inclusief header.
De aanzet van deze discussie was om stuurgegevens in ieder geval uit de payload van het bericht te halen in de StUF onderlaag zodat je bij koppelvlakken bovenstaande vrijheid krijgt en dubbelingen van logistiek en/of authenticatie/autorisatie gegevens vermijdt. Als dit geen optie blijkt te zijn dan is optioneel maken the next best thing. Feit is dat bij oa WS-* standaarden delen van de logistiek in de Soap header zit en niet in de payload vandaar de poging. In feite zeg je bij 1) precies hetzelfde.
In de Digikoppeling-WUS koppelvlak standaard wordt gebruik gemaakt van/verwezen naar WS-* standaarden. Evenzo zou je bij andere koppelvlakken naar SAML/OpenID/OAuth kunnen verwijzen. Het maken van handvatten en leveren/gebruik van voorbeelden hoe je dat dan doet is essentieel.
Met je opmerking over versleuteling/signing ben ik het niet eens. Het gaat om authenticatie/autorisatie binnen je koppelvlak. Dit zit er al van oudsher in. Er moet gekeken worden naar andere vormen van authenticatie/autorisatie vanwege modernisering (bv gebruik REST) en het gebruik van Gemma 2 referentiecomponenten voor Authenticatie en Autorisatie. Dat je daarbij signing en encryptie certificaten gebruikt vanwege security is meer de 'hoe' vraag.
Hierbij wat SAML voorbeelden
Bijlage