search

Logius-standaarden / Digikoppeling-Algemeen

1 stars 0 forks source link

Interoperabiliteit platformen WUS bij gebruik MTOM in combinatie met WS-Security (signing) #6

Closed logius-standaardenbeheer closed 2 years ago

logius-standaardenbeheer commented 2 years ago

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

BinarySecurityToken In Line By Reference
Apache CFX* V V (Default)
MS WCF V
IBM Datapower V

*Bij CFX is dit configureerbaar

Ondersteuning bij Ontvangen

BinarySecurityToken In Line By Reference
Apache CFX V V
MS WCF V V
IBM Datapower V

Voorbeeld BinarySecurityToken “By Reference”:

<?xml version="1.0"?>
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" 
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="X509-13452f65-dd79-423e-b101-a0f8461af63f"> 
<xop:Include xmlns:xop=http://www.w3.org/2004/08/xop/include
href="cid:7cdc7574-4a82-4d9c-9757-8b5a328b42d5-268@http%3A%2F%2Ftest%2Fxsd%2F2009%2F02%2Ftest"/>
</wsse:BinarySecurityToken>

(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.

PHaasnoot commented 2 years ago

Besproken in TO DK

logius-standaardenbeheer commented 2 years ago

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.