JBoss Web Services
  1. JBoss Web Services
  2. JBWS-3214

MTOM attachment decoding for digest does not respect "XML Schema Part 2: Datatypes Second Edition" standard

    Details

    • Steps to Reproduce:
      Hide

      deploy a webservice expecting attachments, we used this bit of definition in the wsdl :
      <xsd:complexType name="GenericAttachmentType" xmime:expectedContentTypes="application/pdf">
      <xsd:annotation>
      <xsd:documentation>An MTOM/XOP capable framework can serialize this field to binary data in another SOAP part. It will then need to use an XOP Include element with cid reference.</xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
      <xsd:extension base="xsd:base64Binary">
      <xsd:attribute ref="xmime:contentType" use="required"/>
      </xsd:extension>
      </xsd:simpleContent>
      </xsd:complexType>

      and expecting a signed request, we used this in the META-INF/jboss-wsse-server.xml file :
      <config>
      <timestamp ttl="3000" />
      <sign type="x509v3" alias="$

      {wsse.keystore.alias}

      " />
      <requires>
      <timestamp maxAge="3000" />
      <signature />
      </requires>
      </config>

      send a request message with an attachment, if the request's body's digest was calculated using a multi-line base64 encoded version of the attachment it will be accepted.

      If it was calculated using a single-line base64 encoded version of the attachement the signature won't match.

      Show
      deploy a webservice expecting attachments, we used this bit of definition in the wsdl : <xsd:complexType name="GenericAttachmentType" xmime:expectedContentTypes="application/pdf"> <xsd:annotation> <xsd:documentation>An MTOM/XOP capable framework can serialize this field to binary data in another SOAP part. It will then need to use an XOP Include element with cid reference.</xsd:documentation> </xsd:annotation> <xsd:simpleContent> <xsd:extension base="xsd:base64Binary"> <xsd:attribute ref="xmime:contentType" use="required"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> and expecting a signed request, we used this in the META-INF/jboss-wsse-server.xml file : <config> <timestamp ttl="3000" /> <sign type="x509v3" alias="$ {wsse.keystore.alias} " /> <requires> <timestamp maxAge="3000" /> <signature /> </requires> </config> send a request message with an attachment, if the request's body's digest was calculated using a multi-line base64 encoded version of the attachment it will be accepted. If it was calculated using a single-line base64 encoded version of the attachement the signature won't match.
    • Similar Issues:
      Show 10 results 

      Description

      While setting up a communication between a jboss 5.1.0GA using the standard web-services stack (I get "X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1" in my HTTP headers) and a datapower appliance we came to an issue regarding the MTOM messages we exchange.

      The messages are transferred with binary attachements using MTOM, they are also signed.
      The signature is applied on the message with the binary attachement encoded in base64.

      The signatures do not match since the digest of the body do not match since the base64 encoded version of the attachement used to calculate the digest is different :

      • jboss enforces a limit on line length of base 64-encoded data to 76 characters
      • datapower do not and use a base64 form on one line.

      After checking the documentations describing this standard I think the way datapower does it is the correct one.

      http://www.w3.org/TR/soap12-mtom/#mime-serialization points to http://www.w3.org/TR/2005/REC-xop10-20050125/#introduction which in turns points to http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#base64Binary which states that :
      "For compatibility with older mail gateways, [RFC 2045] suggests that base64 data should have lines limited to at most 76 characters in length. This line-length limitation is not mandated in the lexical forms of base64Binary data and must not be enforced by XML Schema processors."
      "Note: For some values the canonical form defined above does not conform to [RFC 2045], which requires breaking with linefeeds at appropriate intervals."

      Am I correct in my assumption?
      Is this behaviour configurable on the Jboss side of things?

      Antoine

        Activity

        Hide
        Richard Opalka
        added a comment -

        JBoss Native SOAP stack doesn't support JAXWS any more

        Show
        Richard Opalka
        added a comment - JBoss Native SOAP stack doesn't support JAXWS any more

          People

          • Assignee:
            Unassigned
            Reporter:
            rouadec
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: