Каков наилучший способ аутентификации через WCF?

Аутентификация на основе сообщений, которая основана на WS-Security, - это то, что вы ищете, и определенно поддерживается basicHttpBinding и netTcpBinding. Я думаю, что вы делаете ошибочное предположение, что только WsHttpBinding будет поддерживать WS-Security, что является неточным.

Привязки WS предназначены для WS-* элементов, отличных от WS-Security, таких как WS-ReliableMessaging. Настройка независимой от транспорта безопасности сообщений по-прежнему будет сложно, если вы хотите, чтобы он оставался безопасным. Для транспортов, которые не являются дуплексными, вам нужно будет иметь по крайней мере один сертификат, обмененный заранее.

Это может быть еще одной причиной, по которой вы считаете, что безопасность сообщений не поддерживается basicHttpBinding. basicHttpBinding не позволит вам использовать аутентификацию UserName без транспортной безопасности (по уважительной причине я тоже добавлю). И поскольку транспортная безопасность по своей сути зависит от транспорта, я предполагаю, что вы пытаетесь ее избежать.

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

Если вы предоставляете внешнюю службу, которая требует аутентификации / авторизации на уровне пользователя, я бы рекомендовал использовать поставщика ASP.NET.

Здесь есть полезная утилита, которая позволяет удаленно администрировать поставщика ASP.NET. Решение ASP.NET требует SQL...

Почему WS-* должен зависеть от транспорта?

Вся суть спецификаций WS-* заключается в том, что они являются частью сообщения и, следовательно, не зависят от транспорта.

WS-* является независимым от транспорта. В этом-то все и дело.

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

Для внешнего APIs мы пошли с WS-* аутентификации с использованием сертификатов, а затем простой механизм аутентификации (имя пользователя и пароль предоставляется, GUID токен аутентификации возвращается, токен поставляется со всеми запросами после факта).

Спасибо за ваши ответы.

Я не имел в виду транспортную зависимость, моя ошибка. Я имел в виду, что я хотел бы, чтобы потребитель мог выбрать, к какой конечной точке привязываться. И поскольку basicHttpBinding и netTcpBinding, среди прочего, не поддерживают WS-*, мне нужно использовать что-то на уровне обслуживания.

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