Каков наилучший способ реализации аутентификации через WCF?Каков наилучший способ аутентификации через WCF?
Я бы предпочел не использовать WS- *, поскольку он должен быть независимым от транспорта.
Должен ли я «сворачивать свои собственные»? Есть ли какие-либо рекомендации для этого (статьи/сообщения в блогах)?
Или есть какой-то способ: (и должен ли я) использовать встроенные ASP.NET-провайдеры членства и профиля на стороне сервера?
Почему WS- * зависит от транспорта?
Весь смысл спецификаций WS- * заключается в том, что они являются частью сообщения и, следовательно, независимы от транспорта.
WS- * - транспорт независимо. В этом весь смысл.
Аутентификация действительно зависит от того, кто из желающих потребителей вашего сервиса. Не взвешивайте внутренние службы с безопасностью, которая не требуется, а также полезно добавлять дополнительные уровни безопасности, если вам нужно знать конкретные вещи о сторонних пользователях.
Для внешних API мы прошли аутентификацию WS- * с использованием сертификатов, а затем простой механизм аутентификации (имя пользователя и пароль включены, маркер аутентификации GUID возвращается, токен предоставляется со всеми запросами после факта).
Спасибо за ваши ответы.
Я не имел в виду транспорт, зависимый, моя ошибка. Я имел в виду, что я бы хотел, чтобы потребитель мог выбрать, к какой конечной точке привязать. И поскольку basicHttpBinding и netTcpBinding, среди прочих, не поддерживают WS- * Мне нужно что-то использовать на уровне сервиса.
Давид простой аутентификации - это то, чего я пытался избежать. В идеале я бы хотел сделать одно и то же, не добавляя аргумент токена ко всем моим контрактам на работу.
Проверка подлинности на основе сообщений, основанная на WS-Security, является тем, что вы ищете, и определенно поддерживается basicHttpBinding и netTcpBinding. Я думаю, вы ошибочно полагаете, что только WsHttpBinding будет поддерживать WS-Security, что является неточным.
WS-привязки предназначены для WS- * элементов, отличных от WS-Security, таких как WS-ReliableMessaging. Настройка безопасности транспорта, независимой от сообщений, по-прежнему будет сложной, если вы хотите, чтобы она оставалась безопасной. Для транспортов, которые не являются дуплексными, вам необходимо иметь как минимум один сертификат, обменянный заранее.
Возможно, это другая причина, по которой вы полагаете, что безопасность сообщений не поддерживается basicHttpBinding. basicHttpBinding не позволит вам использовать аутентификацию UserName без обеспечения безопасности на транспорте (по какой-то причине я тоже добавлю). И поскольку транспортная безопасность по своей сути зависит от транспорта, я предполагаю, что вы пытаетесь ее избежать.
Так или иначе, если вы хотите быть полностью независимым от транспортировки, первое, что вам нужно решить, это получить сертификаты в порядке и выяснить, как вы собираетесь распространять первый (корневой) сертификат (ы) или безопасно обменные сертификаты. Если у вас есть роскошь приложения, в котором вы можете распространять главный сертификат, то возьмите этот маршрут. Если у вас более сложный сценарий, вам нужно отступить и подумать о том, насколько сильно эта проблема на самом деле.
Если вы нарушаете внешнюю службу, требующую аутентификации/авторизации на уровне пользователя, я бы рекомендовал использовать поставщика ASP.NET.
Есть полезная утилита here, которая позволяет удаленно администрировать поставщика ASP.NET. Решение ASP.NET требует SQL ...