Требовать учетные данные для некоторых методов только в веб-службе WCF

Question

У меня есть UserAccountService с различными методами, некоторые из которых требуют аутентификации пользователя (например, ChangePassword, ChangeUserData), а некоторые - нет (RegisterUser).

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

Методы, требующие аутентификации, отмечены

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]

В моем app.config указана привязка, которая использует шифрование и запрашивает учетные данные UserName:

    <binding name="authenticatedBinding">
      <security mode="TransportWithMessageCredential">
        <message clientCredentialType="UserName" />
      </security>
    </binding>

(я использую basicHttpBinding)

У меня также настроен пользовательский поставщик аутентификации:

      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="..." />
      </serviceCredentials>

При такой конфигурации я не могу вызывать какие-либо методы службы без проверки подлинности.

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

Как мне настроить свою службу, чтобы она позволяла вызывать все методы и требовала, чтобы имя пользователя и пароль устанавливались только тогда, когда это требуется через PrincipalPermission?

Я использую Silverlight в качестве своего клиента, если это важно ...

Спасибо!

Answer 1

Настройки безопасности могут быть детализированы на уровне конечной точки, но не в рамках контракта, поэтому вы не можете комбинировать безопасные и незащищенные методы желаемым способом.Я предлагаю, чтобы

1. Вы разбили свой контракт на обслуживание (интерфейс) на две части - одну для небезопасных методов.И второе, которое будет наследоваться от незащищенной части и будет содержать операции, которые необходимо защитить.
2. Реализация вашей службы не нуждается в изменении (как и реализация защищенного интерфейса) - все, что вам нужно сделать, - это представить эту реализациюкак два разных контракта (на обеспеченный и другой необеспеченный) в двух разных конечных точках.Вам необходимо заблокировать конечную точку с помощью защищенного контракта с любой необходимой конфигурацией безопасности.
3. К сожалению, с точки зрения клиента, вам приходится переключать конечную точку / URL-адрес на границе аутентификации, т.е.Вы можете использовать незащищенную конечную точку, но после аутентификации клиент может использовать любую конечную точку.