Взаимодействие WCF с Axis2 с использованием WS-Trust - PullRequest
Новая
       32

Взаимодействие WCF с Axis2 с использованием WS-Trust

7 голосов
/ 24 апреля 2009

Мы пытаемся заставить WCF и Java общаться друг с другом с помощью токенов SAML, выданных STS. Несмотря на то, что обе стороны соответствуют стандартам WS-Security, WS-Trust, WS-Policy и т. Д., Они, похоже, не общаются друг с другом, и одна или другая будут создавать загадочные исключения или игнорировать заголовки безопасности .

Мы используем .NET 3.5, привязку федерации WCF на стороне MS и Axis2 / Rampart / Rahas на стороне java.

Кто-нибудь когда-нибудь был в состоянии сделать эту работу?

Ответы [ 5 ]

6 голосов
/ 11 июня 2009

Axis2 является неполной с точки зрения соответствия стандартам WS.

Я недавно (в прошлом месяце) прошел фазу POC, когда Axis2 провалил мои тесты на соответствие WS- * (в частности, WS-AT, WS-Coordination).

Взгляните на «Проект Метро». Sun и Microsoft совместно работали над обеспечением правильного взаимодействия WCF и JAX-WS.
https://metro.dev.java.net/

3 голосов
/ 15 июня 2009

Я бы также не рекомендовал переходить на Axis2 на стороне Java, если вы можете. Было бы легче с Glassfish или JAX-WS, очевидно, хотя я никогда не проверял это.

Я столкнулся и с такими проблемами, когда пытался заставить WCF и Axis2 сотрудничать. Проверьте версию стандарта, используемую в файле WSDL, в нашем случае они не совпадали.

2 голосов
/ 09 июня 2009

Я предполагаю, что сторона сервера - это ось, это не ясно, но это более распространено.

Если вы программируете совместимые веб-сервисы на Java, вам следует подумать о переходе на JAX-WS, не только потому, что модель программирования axis2 немного странна, но часто код неполон. Я определенно сталкивался с функциями, частично реализованными ранее, и мне было трудно определить, какое тестирование на совместимость было выполнено с помощью стека Microsoft.

Я бы сказал, что у вас гораздо больше шансов в будущем при использовании стека JAX-WS. Одной из основных причин является то, что инженеры Sun проводят довольно много времени, общаясь с инженерами Microsoft, чтобы убедиться, что их стеки совместимы, и они интерпретировали спецификации таким же образом. Кроме того, модель программирования проще и может управляться с аннотациями. Это также несколько упрощает развертывание и обслуживание. Дополнительный контейнер для обслуживания файлов .AAR и необходимость удаления axis2 из конечной точки службы можно просто игнорировать: конечную точку можно просто рассматривать как сервлет.

Есть документация людей, которые заставляют SAML работать с JAX-WS: http://www.jroller.com/gmazza/entry/using_the_opensaml_library_in

Если вы не можете отойти от оси2, я думаю, что аналогичная стратегия должна быть применена. Где вы могли бы перехватить токен и выполнить аутентификацию до того, как он вызовет конечную точку службы.

См .: http://www.omg.org/news/meetings/workshops/Web_Services_USA_Manual/02-3_K_Smith.pdf

http://www.mail-archive.com/axis-user@xml.apache.org/msg10292.html

http://www2.sys -con.com / ITSG / virtualcd / WebServices / архив / 0303 / secrist / index.html

2 голосов
/ 21 мая 2009
1 голос
/ 30 ноября 2011

Мы успешно протестировали Rampart для сценариев WS-Trust с WCF на стороне клиента и сервера.

BTW Rampart пока не поддерживает сценарии WS-Federation, и ваша политика безопасности может быть связана с ней. [К вашему сведению - WS-Federation будет доступна с Rampart в середине следующего года].

Если вы можете приложить политики безопасности, мы можем внимательно посмотреть ..

...