Как я могу только один раз пройти аутентификацию с использованием учетных данных клиента в WCF?
Как лучше всего убедиться, что вам нужно пройти аутентификацию только один раз при использовании API, построенного на WCF?
Мои текущие привязки и поведение перечислены ниже
<bindings>
<wsHttpBinding>
<binding name = "wsHttp">
<security mode = "TransportWithMessageCredential">
<transport/>
<message clientCredentialType = "UserName" negotiateServiceCredential = "false" establishSecurityContext = "true"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name = "NorthwindBehavior">
<serviceMetadata httpGetEnabled = "true"/>
<serviceAuthorization principalPermissionMode = "UseAspNetRoles"/>
<serviceCredentials>
<userNameAuthentication userNamePasswordValidationMode = "MembershipProvider"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
Далее идет то, что я использую в своем клиентском приложении для аутентификации (в настоящее время я должен делать это каждый раз, когда хочу вызвать в WCF).
Dim client As ProductServiceClient = New ProductServiceClient("wsHttpProductService")
client.ClientCredentials.UserName.UserName = "foo"
client.ClientCredentials.UserName.Password = "bar"
Dim ProductList As List(Of Product) = client.GetProducts()
Что я хотел бы сделать, так это авторизоваться с API один раз с использованием этих учетных данных, а затем получить какой-то токен на период времени, когда мое клиентское приложение использует проект веб-службы. Я думал, что installsecuritycontext = true сделал это за меня?
Ответы 2
Хотя я ненавижу давать ответ, в котором я не уверен на 100%, отсутствие ответов на данный момент заставляет меня думать, что потенциально правильный ответ в этом случае может быть приемлемым.
Насколько мне известно, нет того механизма токенов сеанса, который вы ищете в стандартной комплектации с WCF, что означает, что вам придется проделать тяжелую работу, чтобы все работало в как хотите. Я должен прояснить, что в WCF есть механизм сеанса, но он ориентирован на обеспечение порядка сообщений и не является идеальным инструментом для создания сеанса аутентификации.
Я только что закончил работу над проектом, в котором мы реализовали наш собственный механизм сеанса для обработки всех видов устаревших стеков SOAP, но я считаю, что рекомендуемый способ реализации сеансов с аутентификацией - использовать службу токенов безопасности (STS), такую как Пабло Сибраро.
Если вам нужны подробности, пожалуйста, кричите, но я подозреваю, что в блоге Пабло будет более чем достаточно информации, чтобы вы могли двигаться дальше.
Если вы находитесь в интрасети, проверка подлинности Windows может выполняться "бесплатно" путем настройки.
Если это не подходит, службы токенов работают нормально, но в некоторых ситуациях их может быть слишком много.
Приложение, над которым я работаю, требовало простой аутентификации. Наш сервер и клиент работают внутри (очень безопасной) интрасети, поэтому нас не особо заботило требование использовать сертификат X.509 для шифрования связи, что требуется, если вы используете аутентификацию по имени пользователя.
Поэтому мы добавили нестандартное поведение к клиенту, который добавляет имя пользователя и (зашифрованный) пароль к заголовкам сообщений, а также другое настраиваемое поведение на сервере, которое их проверяет.
Все очень просто, не требуется никаких изменений в уровне доступа к сервису на стороне клиента или в реализации контракта на обслуживание. И поскольку все это делается с помощью конфигурации, если и когда нам понадобится перейти к чему-то более сильному, это будет легко выполнить.