WCF - Configuring Client/server authentication in headers?

Question

I've got a WCF service that will need to receive client credentials, and maintain some kind of role-based data, based on my auth method.

The clients will reside on many different systems, and as such, each client will have a unique userID and pw.

I'm using basicHttpBinding and have read a few articles, such as this one, http://nirajrules.wordpress.com/2009/05/22/username-over-https-custombinding-with-wcf%E2%80%99s-channelfactory-interface/, that describe the process.

So what I'm looking for is if someone has a full client/server configured like this to take a look at so I can derive my own solution from this.

What I'd like to do is have the username and password passed in the headers for each request, passing back some kind of SecurityTokenValidationException on fail, or continuing if passing.

Thanks.

UPDATE

I'm using the wsHttpbinding with the following config on both the client and server:

  <wsHttpBinding>
    <binding name="wsHttpEndpointBinding" >
      <security mode="TransportWithMessageCredential">
        <transport clientCredentialType="Basic" />
        <message clientCredentialType="UserName" />
      </security>
    </binding>
  </wsHttpBinding>

And the call out to the server from the client as follows:

ServiceReference1.ServiceClient myClient = new ServiceReference1.ServiceClient();

myClient.ClientCredentials.UserName.UserName = "billuser";
myClient.ClientCredentials.UserName.Password = "mypassword";

Response.Write("Data from WCF Service: " + myClient.GetData(1));

I think I need a bit of a hand with linking up the CustomUsernamePasswordValidator on the server as I'm still getting the '...could not be activated.' error.

Answer 1

Are you required to use the basicHttpBinding? That binding is really only there to provide support for legacy WS-BasicProfile implementations (i.e. ASMX). If your clients are also .NET/WCF, I would highly recommend using wsHttpBinding, which provides a plethora of security options out of the box. You could use certificates, username/password, etc. with transport and/or message security and not need to write any of the security stuff yourself. Just configure-and-go (CAG).

Security credential information is available to the service itself via the OperationContext, in case you need to access it directly from your code. If your code does need to access it, however, I would recommend writing a behavior to extract the pertinent information from the OperationContext and place it in something more application specific so that you don't have to reference System.ServiceModel everywhere you need to access information on OperationContext.