WCF membership provider versus custom service authorization manager w. custom username validator

I am quite new to WCF and I am trying to setup services and have received two different advice:

1. Use a the built in authentication service with a membership provider (http://msdn.microsoft.com/en-us/library/bb398990(VS.100).aspx) (Custom UserNamePasswordValidator with Silverlight 3.0).
2. Use a custom service authorization manager with a custom username validator and ”TransportWithMessageCredential” (http://msdn.microsoft.com/en-us/library/ms729794(VS.100).aspx开发者_Go百科) (Architechture of service application in WCF)

The difference I can see is in method two, the users credentials is verified at every call to the services and I don't have to keep a session state on the server, which I like.

Am I misunderstanding the concepts and the two solve different problems?

Can someone please help me understand these two and when to use each?

The ASP.NET built-in membership and role providers just give you ready-made tables and stored procedures in your SQL Server database (and an admin GUI) to handle creating users, defining roles, assigning users to roles and so forth.

They come with a predefined membership authentication provider for WCF - so basically, you're just getting more or less everything for free and don't have to worry about all the nitty-gritty details of creating users, managing their passwords and so forth.

For starters, I would definitely use this option - much easier and much quicker to get up and running.

The custom authentication validator is more of an advanced topic, that you might want to look into if you have specific and specialized needs that go beyond the ASP.NET membership provider. It gives you more power - you basically get the username and password from WCF and it's up to you whether or not to authenticate that caller - but it's also quite a bit more work, really.

There is no difference in the way the authentication is made - WCF's best practice is to use per-call services, and in this case, you'll always authenticate your caller on a per-call basis - no matter what kind of authentication mechanism you use in the background (Active Directory, ASP.NET Membership, custom).

So I'd definitely recommend using the ASP.NET built-in membership and role providers, as long as those suffice for you - and I'm pretty sure they'll be just fine for a long time!

The 2 options you have provided are not mutually exclusive, Username/Password validation is a Message validation mechanism. Its purpose is to provide credentials for the user sending the message.

TransportWithMessageCredential is a transport level means of encryption, where for example you encrypt the transport level using SSL and embed the user credentials within this with the message.

Membership & Role providers are a means for authenticating the credentials passed by the user, it looks like this.

 <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>

Right now you're probably using a custom username password validator that looks like this

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

Therefore using Username/Password at the message layer as a credential is different (and seperate) from using Username/Password as an authentication mechanism. Hope this helps you understand the concepts