通过 Web 服务并使用 WS-Security 发送二进制数据
我们必须使用 Web 服务堆栈传输二进制数据,并且在此过程中我们必须签署 Web 服务请求/响应。
主要问题是:执行此操作的首选方法是什么?
我们应该使用 MTOM 和 WS-Security 吗? 从 ISSUE CXF-1904 我得出的结论是,使用 MTOM 时会出现问题和 WS-安全。 CXF 和 axis2 使用 WSS4J,当您使用 MTOM 时,WSS4J 似乎不能很好地处理数字签名消息。
其他 Web 服务堆栈怎么样?
We have to transfer binary data using web service stack and in the process we have to sign web service requests/responses.
The main question is: what is the prefered way to do this?
Should we use MTOM and WS-Security?
From ISSUE CXF-1904 I have concluded that there are issues when one uses MTOM and WS-Security. CXF and axis2 use WSS4J and it seems that WSS4J does not work well with digitally signed messages when you use MTOM.
What about other web service stacks?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
CXF 可以与 MTOM 一起执行 WS-Security 相关操作,但附件最终不会签名或加密。 SOAP 消息本身经过签名/加密,但由于 WSS4J 中的限制,附件并未经过签名/加密。 (如果 SpringWS 使用 WSS4J,它将具有相同的限制)
出于安全原因,默认情况下,在将 WSS4JOutInterceptor 与 CXF 一起使用时,我们关闭 MTOM 以确保它们被内联,然后进行签名/加密。 这是一个安全的选择。 WSS4JOutInterceptor 确实有一个标志 (out.setAllowMTOM(true)),该标志允许 MTOM 保留为附件,但请记住,这些附件不会受到“保护”。
CXF can do WS-Security related things along with MTOM, but the attachments do not end up signed or encrypted. The SOAP message itself is signed/encrypted, but the attachments are not due to restrictions in WSS4J. (If SpringWS uses WSS4J, it would have the same restrictions)
Be default for security reasons when using the WSS4JOutInterceptor with CXF, we turn off MTOM to make sure they get inlined and then signed/encrypted. That's a security choice. The WSS4JOutInterceptor DOES have a flag (out.setAllowMTOM(true)) which would allow the MTOM to remain as attachments, but keep in mind, those attachments would not be "secured".
只需以
byte[]
形式发送数据即可。 如果数据量很大,那么WCF确实支持MTOM。在任何情况下都不应该使用 WSE。 WSE 基于 ASMX Web 服务。 微软表示 ASMX 技术是“遗产”,他们不会修复其中的错误。 更糟糕的是,WSE 已经过时了,已经被 WCF 取代了。
Simply send the data as a
byte[]
. If there is a large amount of data, then WCF does support MTOM.Under no circumstances should you use WSE. WSE is based on top of ASMX web services. Microsoft has stated that ASMX technology is "legacy", and that they will not be fixing bugs in it. Even worse, WSE is quite obsolete, and has been replaced by WCF.
我建议使用 Spring-WS 而不是 Apache CXF API,它更轻、文档更完善且更易于使用。 然而,Spring-WS 不兼容 JAX-WS(在我看来,这并不是一件坏事,但你可能会有不同的想法)。
Spring-WS 只是一个围绕底层 SOAP 实现的轻量级、Spring 友好的包装器,并且应该在 Sun JAX-WS 或 Apache CXF 之上工作,尽管我建议使用 Sun 的实现。 它还具有完整的 MTOM 和 WS-Security 支持(通过 Apache WSS4J)。
I would recommend the use of Spring-WS over the Apache CXF API, it's considerably lighter, better-documented and easier to use. However, Spring-WS is not JAX-WS compliant (this is no bad thing, in my opinion, but you may think different).
Spring-WS is just a light, Spring-friendly wrapper around an underlying SOAP implementation, and should work on top of Sun JAX-WS or Apache CXF, although I'd recommend using Sun's implementation. It also has full MTOM and WS-Security support (via Apache WSS4J).
来自http://ws.apache.org/wss4j/attachments.html:
WSS4J 2.0 .0 通过 SOAP with Attachments (SWA) Profile 1.1 规范引入了对 SOAP 消息附件进行签名和加密的支持。 WSS4J 1.6.x 不支持对消息附件进行签名或加密。 可以通过基于“操作”的方法或通过 WS-SecurityPolicy 在 WSS4J 中对附件进行签名和加密,如以下部分所述。
From http://ws.apache.org/wss4j/attachments.html :
WSS4J 2.0.0 introduces support for signing and encrypting SOAP message attachments, via the the SOAP with Attachments (SWA) Profile 1.1 specification. There is no support in WSS4J 1.6.x for signing or encrypting message attachments. Attachments can be signed and encrypted in WSS4J via either the "action"-based approach or via WS-SecurityPolicy, as covered in the sections below.