Поставщик членства в WCF и менеджер авторизации пользовательских сервисов w.пользовательский валидатор имени пользователя - PullRequest
Новая
       5

Поставщик членства в WCF и менеджер авторизации пользовательских сервисов w.пользовательский валидатор имени пользователя

3 голосов
/ 18 января 2010

Я новичок в WCF, пытаюсь настроить службы и получил два разных совета:

  1. Использование встроенной службы аутентификации с поставщиком членства (http://msdn.microsoft.com/en-us/library/bb398990(VS.100).aspx) ( Пользовательский UserNamePasswordValidator с Silverlight 3.0 ).
  2. Использование диспетчера авторизации службы с настраиваемым средством проверки имени пользователя и «TransportWithMessageCredential» (http://msdn.microsoft.com/en-us/library/ms729794(VS.100).aspx) ( Архитектура приложения службы в WCF )

Разница, которую я вижу, заключается во втором методе: учетные данные пользователей проверяются при каждом обращении к службам, и мне не нужно сохранять состояние сеанса на сервере, что мне нравится.

Я неправильно понимаю концепции и эти две проблемы решают разные проблемы?

Может кто-нибудь, пожалуйста, помогите мне понять эти два и когда использовать каждый?

Ответы [ 2 ]

6 голосов
/ 18 января 2010

Встроенные в ASP.NET поставщики членства и ролей просто предоставляют вам готовые таблицы и хранимые процедуры в базе данных SQL Server (и графический интерфейс администратора) для управления созданием пользователей, определения ролей, назначения пользователей ролям и т. Д. .

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

Для начала я бы определенно воспользовался этой опцией - гораздо проще и быстрее начать работу.

Пользовательский валидатор проверки подлинности - это более сложная тема, на которую вы, возможно, захотите взглянуть, если у вас есть особые и специализированные потребности, выходящие за рамки поставщика членства ASP.NET. Это дает вам больше возможностей - вы в основном получаете имя пользователя и пароль от WCF, и вам решать, аутентифицировать ли этого абонента или нет, но на самом деле это также немного больше работы.

Нет никакой разницы в том, как выполняется аутентификация. Лучшей практикой WCF является использование услуг для каждого звонка, и в этом случае вы будете всегда проверять подлинность вызывающего абонента для каждого звонка. - независимо от того, какой механизм аутентификации вы используете в фоновом режиме (Active Directory, членство в ASP.NET, пользовательские).

Так что я бы определенно рекомендовал использовать встроенные поставщики членства и ролей ASP.NET, если этого достаточно для вас - и я уверен, что они будут в порядке в течение длительного времени!

3 голосов
/ 19 января 2010

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

TransportWithMessageCredential является средством шифрования на транспортном уровне, где, например, вы шифруете транспортный уровень с помощью SSL и встраиваете в него учетные данные пользователя.

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

 <serviceBehaviors>
       <behavior name="myCustomBehavior">
          <serviceCredentials>
             <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"
                 membershipProviderName="MembershipProvider" />
          </serviceCredentials>
       </behavior>
    </servicebehaviors>

 <system.web>
  <membership defaultProvider="MembershipProvider" userIsOnlineTimeWindow="15">
   <providers>
    <clear />
     <add name="MembershipProvider" type="MyApp.AP.SimpleSqlMembershipProvider, MyApp.AP" connectionStringName="APServer" applicationName="/MyApp" />
   </providers>
  </membership>
 </system.web>

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

<userNameAuthentication
   userNamePasswordValidationMode="Custom"
   customUserNamePasswordValidatorType=
   "MyApp.SL.CustomUserNameValidator, MyApp.SL"/>

Поэтому использование имени пользователя / пароля на уровне сообщений в качестве учетных данных отличается (и отличается) от использования имени пользователя / пароля в качестве механизма аутентификации. Надеюсь, что это поможет вам понять концепции

...