使用 WS-Trust 与 Axis2 进行 WCF 互操作
我们正在尝试使用 STS 颁发的 SAML 令牌让 WCF 和 Java 相互通信。 尽管双方都遵守 WS-Security、WS-Trust、WS-Policy 等标准，但它们似乎并没有相互交谈，并且其中一方会抛出神秘的异常或忽略安全标头。
我们在 MS 端使用 .NET 3.5、WCF Federation 绑定，在 java 端使用 Axis2/Rampart/Rahas。
有没有人能够做到这一点？
We are trying to get WCF and Java talking to each other using SAML tokens issued from an STS. Despite the fact that both sides are compliant with the standards, WS-Security, WS-Trust, WS-Policy, etc., they don't seem to talk to each other and one or the other will throw cryptic exceptions or ignore security headers.
We are using .NET 3.5, WCF Federation binding on the MS side, and Axis2/Rampart/Rahas on the java side.
Has anyone ever been able to make this work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Axis2 在 WS 标准合规性方面并不完整。
我最近（上个月）经历了一个 POC 阶段，Axis2 未能通过我的 WS-* 合规性测试（特别是 WS-AT、WS-Coordination）。
看看“地铁计划”。 Sun 和 Microsoft 合作，让 WCF 和 JAX-WS 互操作“正确”。
https://metro.dev.java.net/
Axis2 is incomplete in terms of WS standards compliance.
I recently (in the last month) went through a POC phase where Axis2 failed my WS-* compliance tests (specifically WS-AT, WS-Coordination).
Have a look at "Project Metro". Sun and Microsoft collaborated on getting WCF and JAX-WS interop "right".
https://metro.dev.java.net/
如果可以的话，我也不建议在 Java 方面使用 Axis2。 显然，使用 Glassfish 或 JAX-WS 会更容易，尽管我从未测试过它。
当我试图让 WCF 和 Axis2 合作时，我也遇到了这类问题。 检查 WSDL 文件中使用的标准版本，这些版本与我们的案例不匹配。
I would also not recommand going for Axis2 on the Java side, if you can. Would be easier with Glassfish or JAX-WS apparently, althoug I never tested it.
I ran into those kind of issues as well when trying to make WCF and Axis2 cooperate. Check the version of the standard used in the WSDL file, those were not matching in our case.
您是否正在处理文档文字与 rpc 编码的问题？ （抱歉，必须问一下。）
http://www.ibm.com /developerworks/webservices/library/ws-whichwsdl/
http://www.developerfusion.com/article/4694/web-services-interoperability- Between-j2ee-and-net-part-1/3/
http://msdn.microsoft.com/en-us/library/ms996466。 ASPX
Are you handling the doc literal vs. rpc-encoded issue? (Sorry, have to ask.)
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
http://www.developerfusion.com/article/4694/web-services-interoperability-between-j2ee-and-net-part-1/3/
http://msdn.microsoft.com/en-us/library/ms996466.aspx
我假设服务器端是轴，尚不清楚，但这是更常见的。
如果您正在使用 Java 编写可互操作的 Web 服务，则应该考虑切换到 JAX-WS，不仅因为 axis2 编程模型有点奇怪，而且代码通常不完整。 我之前确实遇到过部分实现的功能，而且我发现很难确定使用 Microsoft 堆栈执行了哪些互操作性测试。
我想说您将来使用 JAX-WS 堆栈会有更好的机会。 一个主要原因是 Sun 工程师花了相当多的时间与 Microsoft 工程师坐在一起，以确保他们的堆栈具有互操作性，并且他们以相同的方式解释规范。 除此之外，编程模型更容易并且可以通过注释来驱动。 它还在一定程度上简化了部署和维护。 用于服务 .AAR 文件的附加容器以及从服务端点删除 axis2 的操作可以被忽略：端点可以被视为 Servlet。
有文档说明人们如何使用 SAML 来使用 JAX-WS：http://www.jroller。 com/gmazza/entry/using_the_opensaml_library_in
如果您无法摆脱 axis2，我认为需要采用类似的策略。 您将在其中拦截令牌并在调用服务端点之前进行身份验证。
请参阅：http://www.omg.org/news/会议/workshops/Web_Services_USA_Manual/02-3_K_Smith.pdf
http://www.mail-archive.com/[电子邮件受保护]/msg10292.html
http://www2.sys-con.com/ITSG /virtualcd/WebServices/archives/0303/secrist/index.html
I'm assuming that the server side is axis, it's not clear but that is more common.
If you are programming interoperable webservices you in Java you should consider switching to JAX-WS, not only because the axis2 programing model is a little bizarre, but often the code is incomplete. I've certainly come across features partially implemented before, also it's I found it difficult to determine what testing for interoperability had been performed with the Microsoft stack.
I would say you have much better chances in the future using a JAX-WS stack. One major reason is Sun Engineers spend quite some time sitting with Microsoft engineers to make sure their stacks were interoperable and they'd interpreted the specs in the same way. Besides this the programming model is easier and can be driven with annotations. It also somewhat simplifies deployment and maintenance. The additional container for servicing .AAR files and the fiddling to remove axis2 from the service endpoint can just be ignored: the endpoint can just be treated as a Servlet.
There is documentation of people getting SAML to work with JAX-WS: http://www.jroller.com/gmazza/entry/using_the_opensaml_library_in
If you cannot move away from axis2 I think a similar strategy needs to be employed. Where you would intercept the token and do the authentication before it gets to call the service endpoint.
See: http://www.omg.org/news/meetings/workshops/Web_Services_USA_Manual/02-3_K_Smith.pdf
http://www.mail-archive.com/[email protected]/msg10292.html
http://www2.sys-con.com/ITSG/virtualcd/WebServices/archives/0303/secrist/index.html
我们已经在客户端和服务器端使用 WCF 成功测试了 Rampart 的 WS-Trust 场景。
BTW Rampart 尚不支持 WS-Federation 方案，您的安全策略可能与其相关。 [仅供参考 - WS-Federation 将于明年年中随 Rampart 一起提供]。
如果可以的话，请附上安全策略，我们可以仔细查看。
We have successfully tested Rampart for WS-Trust scenarios with WCF both at the client and server ends.
BTW Rampart doesn't have WS-Federation scenarios supported yet and your security policy could be related to it. [FYI - WS-Federation will be available with Rampart mid next year].
If you can please attach the security policies we can have a close look..