Gemeld is dat IBM Datapower bij gebruik van MTOM (samen met ws-security) het BinarySecurityToken alleen kan verwerken als dit “in line” wordt aangeboden, Andere platformen bieden dit bij gebruik van MTOM “by reference” aan.
Vraag is of aanvullende afspraken in de standaard kunnen helpen om de interoperabiliteit op dit punt te vergroten;
Uitwerking/Analyse:
MTOM is by Design compatible met ws-security. Dit betekent dat zowel gebruik van “in line” als “by reference” is toegestaan. Een implementatie conform de standaard zou beide gevallen correct moeten kunnen afhandelen.
(dwz er wordt verwezen naar de binary data in de MIME attachment)
(Bij “In Line” wordt het token niet mtom geoptimaliseerd maar volledig in het BinarySecurityToken opgenomen)
Toelichting:Standaard plaatst Apache CXF (vanaf versie 3.1) het certificaat niet in het BinarySecurityToken element, maar in de Mime-header met een referentie in het BinarySecurityToken element.
Apache CXF gebruikt hier WSS4J, die deze optie heeft toegevoegd omdat bijv. MicroSoft .NET dit al gebruikte en Apache CXF het (nog) niet ondersteunde. De optie zit er al langer in, maar staat pas sinds versie 3.1 default op 'true'.
In tegenstelling tot MS .NET kan de optie kan in Apache CXF wel gewijzigd worden.
Dezelfde optie zorgt ervoor dat CipherData in het geval van encryptie van de inhoud van de SOAP:Body bijvoorbeeld, verhuist naar de attachment.
IBM DataPower heeft voorzover bekend, geen support voor deze optie en kan dergelijke berichten met het BinarySecurityToken en/of CipherData in de Mime header dus niet genereren of herkennen en verifiëren waar nodig.
Een mogelijke optie om interoperabiliteit te verbeteren is: aan de DK WUS standaard een regel toevoegen: “BinarySecurityToken verplicht alleen in line plaatsen”
Nadeel:
Wijziging niet backwards compatible – dus impact op bestaande implementaties;
MS WCF zal in dit geval maatwerk vragen
(wat voordeel is voor 1 leverancier is nadeel voor andere leverancier)
(Of alternatief aan de DK WUS standaard een regel toevoegen: “BinarySecurityToken alleen by reference” met vergelijkbare nadelen, in dit geval zullen IBM Datapower gebruikers aanpassingen moeten doen )
Vraag is dan ook of het wenselijk is een dergelijke aanpassing te doen in de DK WUS standaard?
Of dat de leveranciers zich in dit geval richting de standaard moeten bewegen.
In het TO DK is aangegeven dat een technische oplossing mogelijk is door een extra component op te nemen in de communicatie die wel volgens standaard werkt.
Interoperabiliteit platformen WUS bij gebruik MTOM in combinatie met WS-Security (signing)
( Zie Roadmapitem : Roadmap Digikoppeling )
Aanleiding:
Gemeld is dat IBM Datapower bij gebruik van MTOM (samen met ws-security) het BinarySecurityToken alleen kan verwerken als dit “in line” wordt aangeboden, Andere platformen bieden dit bij gebruik van MTOM “by reference” aan.
Vraag is of aanvullende afspraken in de standaard kunnen helpen om de interoperabiliteit op dit punt te vergroten;
Uitwerking/Analyse:
MTOM is by Design compatible met ws-security. Dit betekent dat zowel gebruik van “in line” als “by reference” is toegestaan. Een implementatie conform de standaard zou beide gevallen correct moeten kunnen afhandelen.
In de praktijk komen verschillen voor:
Ondersteuning bij Verzenden
*Bij CFX is dit configureerbaar
Ondersteuning bij Ontvangen
Voorbeeld BinarySecurityToken “By Reference”:
(dwz er wordt verwezen naar de binary data in de MIME attachment)
(Bij “In Line” wordt het token niet mtom geoptimaliseerd maar volledig in het BinarySecurityToken opgenomen)
Toelichting: Standaard plaatst Apache CXF (vanaf versie 3.1) het certificaat niet in het BinarySecurityToken element, maar in de Mime-header met een referentie in het BinarySecurityToken element. Apache CXF gebruikt hier WSS4J, die deze optie heeft toegevoegd omdat bijv. MicroSoft .NET dit al gebruikte en Apache CXF het (nog) niet ondersteunde. De optie zit er al langer in, maar staat pas sinds versie 3.1 default op 'true'.
In tegenstelling tot MS .NET kan de optie kan in Apache CXF wel gewijzigd worden. Dezelfde optie zorgt ervoor dat CipherData in het geval van encryptie van de inhoud van de SOAP:Body bijvoorbeeld, verhuist naar de attachment.
IBM DataPower heeft voorzover bekend, geen support voor deze optie en kan dergelijke berichten met het BinarySecurityToken en/of CipherData in de Mime header dus niet genereren of herkennen en verifiëren waar nodig.
Een mogelijke optie om interoperabiliteit te verbeteren is: aan de DK WUS standaard een regel toevoegen: “BinarySecurityToken verplicht alleen in line plaatsen”
Nadeel:
(Of alternatief aan de DK WUS standaard een regel toevoegen: “BinarySecurityToken alleen by reference” met vergelijkbare nadelen, in dit geval zullen IBM Datapower gebruikers aanpassingen moeten doen )
Vraag is dan ook of het wenselijk is een dergelijke aanpassing te doen in de DK WUS standaard? Of dat de leveranciers zich in dit geval richting de standaard moeten bewegen.