Веб-служба WCF с двухфакторной аутентификацией и BizTalk

С самого начала проекта, над которым мы работали, я предполагал, что мы сможем создать веб-службу WCF, которая будет использовать двухфакторную аутентификацию с использованием клиентских сертификатов транспортного уровня и пароля имени пользователя уровня сообщения, следующего за WS- Безопасность. Наш план состоял в том, чтобы реализовать аутентификацию на уровне сообщений, которую мы сделали, и добавить требование сертификатов клиентов, как только мы сможем реализовать собственный центр сертификации.

Некоторое время проверка подлинности на уровне сообщений работала хорошо, и теперь мы можем приступить к внедрению клиентских сертификатов. Мы сгенерировали сертификат клиента и пытаемся настроить его в BizTalk, который, похоже, позволяет нам выбрать либо сертификат клиента, либо имя пользователя. Режимы безопасности включают «Нет», «Транспорт», «Сообщение», «Транспорт с учетными данными для сообщения» и «Только учетные данные для транспорта». Я выбираю транспорт с учетными данными сообщения, так как это, кажется, наиболее точно соответствует тому, что мне нужно, но параметр безопасности транспорта отключен.

Можно ли использовать как клиентские сертификаты, так и имя пользователя / пароль?

введите описание изображения здесь


biztalk wcf wcf-security biztalk-2010
person Jeremy    schedule 13.01.2014    source источник
comment
Я думаю, вам нужно будет создать собственное поведение, чтобы добиться этого. См. Здесь статью (не BizTalk) о двухуровневой аутентификации, которая может помочь blogs.msdn.com/b/saurabs/archive/2013/05/05/10349529.aspx   -  person Dijkgraaf    schedule 14.01.2014
comment
Я все еще пытаюсь заставить это работать. В среде, отличной от Biztalk, ваш комментарий работает. В основном это сводится к настройке места приема с помощью customBinding, например: ‹customBinding› ‹имя привязки = CustomCDARequestEndpointBinding› ‹textMessageEncoding messageVersion = Soap11 /› ‹security authenticationMode = UserNameOverTransport /› ‹httpsTransport requireClientCertificate = true /› ‹›binding / customBinding ›однако конфигурация customBinding BizTalk не имеет httpsTransport расширения элемента привязки   -  person Bensonius    schedule 28.01.2014
comment
Итак, как же заставить порты BizTalk разрешить httpsTransport расширение элемента привязки, которое является ключом к тому, чтобы это работало?   -  person Bensonius    schedule 28.01.2014

Ответы (2)


arrow_upward
2
arrow_downward

Я собираюсь добавить еще один ответ, чтобы сохранить историю того, что не работает в этом вопросе.

При этом я наконец-то заставил его работать через customBinding. На этот раз я трижды проверил, что IIS требует клиентских сертификатов :)

Это включало создание настраиваемых привязок к месту приема одного приложения BizTalk и порту отправки другого. Почему? Потому что в нашем проекте одно приложение Biztalk отправляется другому.

Итак, чтобы все заработало, мне пришлось:

Место получения (приложение-получатель)

  • Используйте мастер публикации WCF в Visual Studio, чтобы повторно опубликовать приложение-получатель с помощью «WCF-CustomIsolated». Я хотел начать все сначала и позволить BizTalk / Visual Studio делать свое дело, а не гадать.

введите описание изображения здесь

  • Я пошел и отредактировал место приема в консоли администратора BizTalk.
  • Установите для атрибута textMessageEncoding messageVersion значение Soap11, потому что это то, что мы использовали
  • удалили элемент привязки httpTransport, потому что, если вы этого не сделаете, вы не сможете добавить элемент httpsTransport, который требуется
  • добавил элемент security. На данный момент это выглядело так (порядок элементов имеет значение)

введите описание изображения здесь

  • элемент security имеет атрибут с именем authenticationMode, который был переключен на UserNameOverTransport. Несмотря на название, это то, что позволило отправить UserName вместе с сообщением. Все остальное в security было оставлено со значениями по умолчанию

введите описание изображения здесь

  • httpsTransport имеет атрибут с именем requireClientCertificate, для которого установлено значение «истина», все остальное оставлено с значениями по умолчанию.

введите описание изображения здесь

  • затем добавили необходимые нам поведения, что было довольно просто, и после этого местоположение приема было выполнено.

Порт отправки (отправляющее приложение)

Это было почти то же самое, что и получение, но только на порту отправки, а не в месте приема.

  • на вкладке "Привязка" я повторяю точные шаги, описанные в разделе "Место получения".
  • Вкладка Behavior Я добавил расширение Behavior под названием clientCredentials, а в элементе ClientCertificate установил следующие значения, которые просто получают сертификат клиента, который находится в хранилище текущего пользователя для учетной записи службы, от которой ваш порт отправки работает как .
  • Вкладка «Учетные данные». Я ввел учетные данные UserName, которые ранее были введены на вкладке «Безопасность» порта отправки адаптера WCF-BasicHttp.

введите описание изображения здесь

Как только все это будет сделано, два приложения должны иметь возможность общаться друг с другом, используя как сертификаты клиента, так и аутентификацию UserName.

См. Мой ответ на этот вопрос о том, что это в основном означает в службе WCF, отличной от BizTalk. Как поставить оба Имя пользователя и сертификат клиента в клиенте WCF (почему этот пример работает)?

И не забудьте перезапустить хост-инстансы.

Редактировать - Бонус, если вы в конечном итоге экспортируете / развертываете на другой сервер, даже если вы экспортируете и импортируете / устанавливаете веб-каталог отдельно, вы, вероятно, получите IIS, в котором говорится, что он не может найти конечную точку для MyService / Myservice.svc, считая, что порт / местоположение приема отключены. Однако это потому, что теперь это WCF-CustomIsolated. Решение: откройте файл .svc для опубликованной службы и измените атрибут Factory с BasicHttpWebServiceHostFactory на CustomWebServiceHostFactory.

person Bensonius    schedule 29.01.2014

arrow_upward
0
arrow_downward

Сертификат клиента может быть применен к идентификатору конечной точки порта отправки, который использует адаптер WCF-BasicHttp, это транспортный уровень (клиентский сертификат) безопасности. Затем на вкладке безопасности, которую вы показали на включенном снимке экрана, вы обеспечиваете безопасность на уровне сообщений, которая будет представлять собой комбинацию имени пользователя и пароля.

Вот скриншот конфигурации идентификации. Вам необходимо заполнить как верхний (Service Identity), так и нижний разделы (Client Identity).

РЕДАКТИРОВАТЬ: Этот ответ неверен, у меня были неправильные настройки, и он "работал", но не по этой причине

введите описание изображения здесь

person Bensonius    schedule 17.01.2014
comment
Вы можете объяснить, почему тогда это сработало? Вы действительно достигли аутентификации по паролю и сертификату клиента? - person Dijkgraaf; 24.01.2014
comment
Вы действительно собираетесь заставить меня признать, что в IIS для сертификатов клиентов было установлено значение Игнорировать? Вот почему я заключил это в кавычки выше :( Джереми должен отозвать этот ответ. - person Bensonius; 24.01.2014