[ https://issues.apache.org/jira/browse/WSS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh moved CXF-8061 to WSS-652: ---------------------------------------------- Estimated Complexity: (was: Unknown) Affects Version/s: (was: 3.3.2) 2.2.3 Workflow: classic default workflow (was: Default workflow, editable Closed status) Key: WSS-652 (was: CXF-8061) Project: WSS4J (was: CXF) > MTOM Content-Id handling doesn't comply with RFC2392: .NET issues > ----------------------------------------------------------------- > > Key: WSS-652 > URL: https://issues.apache.org/jira/browse/WSS-652 > Project: WSS4J > Issue Type: Bug > Affects Versions: 2.2.3 > Reporter: Mike M. > Assignee: Colm O hEigeartaigh > Priority: Blocker > > We found an issue when a CXF server is being called from a .NET client with > WebService Security and MTOM in place. The relevant part of the stack trace > looks like this: > {code} > Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not > found > at > org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:215) > at > org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRef(EncryptedKeyProcessor.java:602) > at > org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRefs(EncryptedKeyProcessor.java:533) > at > org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:232) > at > org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:90) > at > org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:340) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:320) > ... 54 common frames omitted > Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not > found > at > org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(EncryptionUtils.java:376) > at > org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:207) > ... 60 common frames omitted > {code} > So at first, it looks like the incoming message has issues with Attachment > IDs. Our actual request looks like this (shortened for readability): > {code} > POST /myservice HTTP/1.1 > Host: localhost > MIME-Version:1.0 > Content-Type:multipart/related; > type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1";start-info="text/xml" > --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1 > Content-ID: <http://tempuri.org/0> > Content-Transfer-Encoding: 8bit > Content-Type: application/xop+xml;charset=utf-8;type="text/xml" > <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> > <s:Header> > [...] > <Security> > [...] > <CipherData> > <CipherValue> > <xop:Include > href="cid:http%3A%2F%2Ftempuri.org%2F1%2F636966400494014846" > xmlns:xop="http://www.w3.org/2004/08/xop/include"/> > </CipherValue> > </CipherData> > [...] > </Security> > [...] > </s:Header> > <s:Body> > <EncryptedData>[...]</EncryptedData> > </s:Body> > </s:Envelope> > --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1 > Content-ID: <http://tempuri.org/1/636966400494014846> > Content-Transfer-Encoding: binary > Content-Type: application/octet-stream > [...binary data...] > --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1-- > {code} > Now, if you compare {{<xop:Include>}}'s {{href}} value with the > {{Content-ID}} in the attachment part header, you'll see that it is the same > value, just URL-Encoded in the former. > As weird as this may seem, It's actually specified that way in those > locations: > https://www.w3.org/TR/xop10/#xop_href > {quote} > The href attribute information item has: > A [normalized value] which is a representation of a URI referencing the part > of the package containing the data logically included by the [owner element] > (i.e., the xop:Include element information item). The [normalized value] MUST > be a valid URI per the cid: URI scheme (see [RFC 2392]). In addition, the > [normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI > datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI). > {quote} > https://tools.ietf.org/html/rfc2392 > {quote} > 2. The MID and CID URL Schemes > The URLs take the form > content-id = url-addr-spec > message-id = url-addr-spec > url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec > cid-url = "cid" ":" content-id > {quote} > So the value of {{<cop:Include>}}'s {{href}} attribute must always be > URL-Encoded. > As for the attachment part header, RFC2392 specifies the following: > {quote} > A "cid" URL is converted to the corresponding Content-ID message > header [MIME] by removing the "cid:" prefix, converting the % encoded > character to their equivalent US-ASCII characters, and enclosing the > remaining parts with an angle bracket pair, "<" and ">". > Reversing the process and converting URL special characters to their > % encodings produces the original cid. > {quote} > It looks to us as if CXF didn't take that URL-Encoding from the > Specifications into account when looking up MIME Attachments. > When I tried to reproduce the issue by forcing some special characters (in > the form of a prepended "http://") into the generated Attachement-ID in > {{org.apache.xml.security.stax.impl.util.IDGenerator}}, it became apparent > that when CXF generates those Attachement-IDs, it doesn't take the URL > Encoding into account either. It generated: > {code} > <xop:Include href="cid:http://75f2d83d-026b-44bf-8825-6bd2b693d60e"/> > [...] > Content-ID: <http://75f2d83d-026b-44bf-8825-6bd2b693d60e> > {code} > ... which violates the spec imho as {{<xop:Include>}}'s {{href}} contains > non-URL-Encoded characters. > That last bit (CXF generating messages) wouldn't be too much of an issue to > me personally, but CXF failing with what appears to be Spec-Compliant > messages must be considered a bug imho. > To reiterate: this issue prevents CXF from being compatible with the .NET > SOAP / WebService Security stack and is a blocker for us. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org