我的问题与这个非常相关
我已经花了数周的时间来尝试与之抗争,但似乎没有值得一提的解决方案,除了上述问题的解决方案,这是一个糟糕的解决方法,但周围似乎真的没有其他东西.
我们正在尝试与具有已建立并正在运行的 Web 服务的遗留系统进行通信,并在其 WSDL 中声明了某些 WS-Security 约束。我们不能改变服务器上的任何东西,我们只需要按照它的出价去做。我们还有一个第三方客户端实现,它实际工作并与服务器通信,所以我们知道通信是有效的——使用那个特定的客户端。现在,我们想做我们自己的。
上述 WS-Security 策略包括加密和签名。有以下几种情况:
- 编写我们自己的代码来加密/解密和签名/验证
- 使用现成的 JAX-WS 实现之一为我们完成上述操作
第二种选择当然是我们试图做的。然后我们分为以下几部分:
- 地铁/WSIT
- 阿帕奇 CXF
网络上的每个人都建议后一种选择(我也尝试过)-但目前我选择了第一种(特别是因为我们没有与 Spring 进行任何集成以利用 CXF 与它的良好集成)
在处理了一些模棱两可的文档和各种向导 (NetBeans) 之后,我们找到了一个解决方案,其中包含很少的自定义代码、带有一些密钥库的配置文件以及 wsimport 实用程序通常生成的代码。
一段时间过去了,它包括转储 XML SOAP 请求和响应,比较我们生成的失败请求和来自第 3 方客户端的成功请求。很多痛苦,没有结果 - 消息各不相同,但核心逻辑和结构还可以 - 然后 - 你实际上无法比较加密的部分。一段时间后,我得到了一个客户端,它发送了一些东西,实际上收到了一些东西,但未能解密响应。
其实解密好了,但是签名摘要验证失败了。值得一提的是,原始 XML 消息包含一个“&”字符,以及多个换行符。即 SOAP 消息的负载在语法上不是正确的 XML。反正。
似乎这种摘要验证深深植根于 Metro/WSIT 堆栈中,我绝对无法找到实际拦截和更正该摘要 - 或者实际上是计算此摘要的内容 - 显然 - 问题是一些特殊的字符在摘要计算之后或之前被翻译或规范化,我们(而是我试图用来保持双手清洁的底层实现)做了一些与 Web 服务的服务器端所做的不同的事情。
即使是 Metro 管(名字不错,但文档非常稀缺——这些天似乎没有人使用 Metro/WSIT——或者,我应该说,没有人使用 SOAP 或具有这种安全级别的 SOAP?——当我尝试 Apache CXF 时,生成的 SOAP 消息看似相似)并且它们拦截消息的方式似乎没有帮助 - 当试图获取消息的原始内容时,没有提供方法(Packet.getMessage().writeTo... - 和其他变体)实际上可以绕过摘要验证的事情——因为他们都试图以 StAX 方式、流媒体等方式读取内容(调用 StreamingPayLoadDigester.accept 总是失败)
但是希望会最后死去,我会一次又一次地尝试找到一些晦涩难懂的无证魔法来让我的东西发挥作用。好的,我正准备收工并深入研究 java 加密 - 直到我发现上述问题。实际上,在抛出摘要不匹配异常之前,它“利用”了一条从 Metro 代码深处打印的日志消息(实际上我认为是来自 wssx-impl )和规范化的解密消息。值得庆幸的是,这条消息是使用 java.util.logging 打印出来的,并且可以通过各种方式截获它——例如,将它发送到某种同步队列中,以供我的客户端使用。啊。如果有人有更好的想法,请写下你的想法。
谢谢你们。