Just a note to remind myself to dig into this next week: this very nice article shows how to do user authentication using BasicHttpBinding and OperationContext: http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2. One can stuff the username/password in the message headers, so you can actually access them from within your service method from the OperationContext.Current. The approach I tried before using a custom UserNamePasswordValidator has an important disadvantage: you can't easily get to the username from within your service method. And in the UserNamePasswordValidator one has no access to OperationContext.Current. There are complex workarounds for this (see e.g. here), but still then you'd end up accessing your database once for authentication, and once to do the real work, which is inefficient. And it's not like huge amounts of code are needed to do your own authentication. It is somewhat less "elegant", but this really becomes relevant mostly when needing to refactor because of a change of the method of authentication to something else than username.

The end goal is to identify the user, i.e. get the user row id from the database during authentication, and then use the user row id to relate e.g. a database modification to the user using a foreign key. Typically in a business app you want to trace who has done what and when (audit), so you don't just want to authenticate the user and let him execute a service method, but you want to use his user id, and perhaps more (authorization) to perform an action.