Блог

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

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

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

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

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

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

(Я использую BasicHttpBinding)

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

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

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

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

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

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

Спасибо!

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

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