2013-03-21 3 views
1

Помощь! :) У меня нет никаких проблем с попытками получить следующие рабочие (извинения заранее, если я не использую точную правильную терминологию) :)Использование токенов SAML2 с помощью WCF channelelfactory и веб-служб

Мне нужно получить доступное веб-приложение .NET (клиент) с веб-службами Weblogic, защищенными политиками SAML 2. Существуют ограничения в том, что мне нужно использовать .NET 3.5/4, и как таковой я использую WIF (с расширениями) для работы с ADFS2, настроенным для генерации токенов SAML2.

Веб-сайт -> adfs2 -> бит токена SAML2 работает до сих пор - я определенно получаю токены.

Дополнительные (1) - службы Weblogic должны использовать политики SAML2, которые реализуют метод подтверждения отправителей-ваучей, и хотя ADFS 2 поставляет носитель по умолчанию, я могу манипулировать утверждением SAML, прежде чем отправлять токен по проводам к услуге (-ам).

Дополнительные (2) - По многочисленным причинам веб-службы не достигаются через SSL, а basicHTTPBinding - мой единственный вариант.

Теперь проблема .. Я просто не могу общаться с Weblogic таким образом, чтобы послать маркер в запросе (любая попытка авторизовались возвращает оракул «Ошибка Общие веб-службы безопасности» из-за там быть нет действительный заголовок безопасности в запросе). Предпочтительный подход был бы через WCF, используя фабрику каналов - приведенный ниже код является приблизительным примером того, что я пробовал, - материал идентификационных данных/токенов был взят из примера кода, который поставляется с материалами расширения WIF:

ответ на следующем посте (и везде я смог найти): WCF and WebLogic SAML interop

..is именно то, что я делаю - но стоит ли просматривать трафик или wireshark'ом путем внедрения клиента MessageInspector и глядя на запрос в «BeforeSendRequest», я не вижу любой знак токена (и запрос отклоняется как следствие).

Также не имеет значения, могу ли я манипулировать маркером, чтобы включить отправители-поручители или просто оставить его как есть изначально.

Дополнительный (3): Мне удалось успешно связаться с сервисом Weblogic, если я не использую ADFS2/SAML/WIF/WCF и т. Д., Но вместо этого перейдите по более базовым веб-ссылкам WSE2.0/3.0 (т. е. создание SoapRequest, токена UserName и т. д.)

Проблема с этим заключается в предоставлении правильного имени пользователя и пароля без взаимодействия с пользователем. Другими словами, соблюдение «подхода SSO», и не нужно выполнять аутентификацию форм (или эквивалент), чтобы каждый раз получать учетные данные пользователя. Не существует очевидного способа использования SecurityToken, сгенерированного ADFS с WSE либо ..

Может ли кто-нибудь помочь пролить свет? Почему подход фабрики каналов WCF с поставленным токеном просто не работает, то есть нет признака действительного токена при отладке и, конечно же, недействительный токен SAML, полученный Weblogic.

Я также посмотрел на маршрут CustomMessageEncoder и добавил SAML Assertion в заголовок SOAP таким образом .. но из того, что я смог узнать, это действительно не должно быть так сложно. Есть что-то в WCF?

+0

Hello Mac. Что касается вашего третьего пункта (дополнительно (3)), возможно, я мог бы предложить вам это обходное решение: если вы можете получить учетные данные пользователя в своем .NET-клиенте, включите их в свой HTTP-запрос через заголовок «Авторизация: основные кодированные символы». Я знаю, что это не лучший подход, но ... – Gaucho

+0

Привет, спасибо за ответ. Дополнительное (3) действительно является последним средством из-за необходимости избегать того, чтобы пользователь вводил свои учетные данные при входе на сайт. Настоящая головная боль заключается в том, что подход SAML2/Channelfactory работает * предположительно *, но это не так :(Возможно, есть дополнительные настройки привязки basicHTTP или пользовательские поведения, которые я мог бы использовать, но я просто не уверен, что они будут –

+0

Хорошо, это похоже на комбинацию факторов, которые способствовали моим проблемам. Не последним из которых были ограничения, налагаемые конфигурацией целевых веб-сервисов, которые в настоящее время не могут быть изменены - вернуться к чертежной доске;) –

ответ

0

Ограничения на привязку к конечной точке (basicHTTP) не поддерживают SAML2 afaik, также ADFS2.0, похоже, подает токены-носители и модифицирует токен после того, как факт также не является стартером (предлагаемые переопределения в WIF для этого не работают должным образом), и, наконец, потому, что веб-службы не отстают от https, имея режим безопасности ни один (который является единственным, который может быть использован) означает, что никакой токен не отправляется в любом случае. ahh хорошо, вернемся к чертежной доске!

Смежные вопросы