在昨天的博文Silverlight3+wcf+在不使用证书的情况下自定义用户名密码验证 中提到了，我想实现的安全效果，就是客户端访问的时候不需要https，也不需要安装证书（商业证书客户端会自动信任），但是暴露的wcf接口不是每个人可以调用的，因为sl+wcf只支持basicHttpBinding一种绑定，在这种绑定下面其实是可以不适用传输安全，然后消息安全选择 username，就是我想要的效果，但是到目前为止我都没有试验成功，有哪位成功了，可以给我一些提示，在此先谢谢了！
昨天我也有想，要是实验不成功，我就自己在参数中加上用户名密码，在wcf端进行自己的验证（根据数据库信息)，当然了，传输的用户名和密码要加密，然后在wcf端解密，算法使用.NET类库（这方面可以参看：加密技术、密钥和证书 ）中的就可以了，如果自己有兴趣或者又需要加入自己的算法也可以。
今天我又在google上面搜索，MSDN论坛中找帖子，中文的，英文的，都看看，有没有我想要的效果，目前没有结果。但是找到了下面的一篇文章，可惜打不开，只能看看快照，给了我更多的提醒，同时感觉自己的联想性真是还不行啊，想的就那么一点点，联系性也不行，相关知识无法联系使用。他里面也提到了我的上面一段的想法。
总结起来，他提到的验证有四种：
1、无验证
2、通过参数验证，就是在wcf方法的参数中添加两个参数，username和password
3、通过信息头部验证，将验证的用户信息存储在信息的header中，然后再wcf端取出来进行验证
4、还是通过信息头部验证，但是，是在方法上添加attibute，利用特性进行验证，否则每次的方法中都要进行验证，加载特性中，只需要针对特性进行编码，在特性中进行验证。
我就说一句总结的吧：思路需要扩展。
原文内容摘抄：
When talking about security for service calls, there are actually a few things to consider. First of all, how do you make sure the data sent over the wire is encrypted? That's your first level of security: always make sure the data that's being sent over the wire is encrypted. After all, unless we're working in an intranet environment, anyone could potentially look at the packets that are being sent.
Luckily, securing this is easy to do: use SSL/https. As far as SL/WCF is concerned, this comes down to setting your security mode to "Transport" in your binding. That's really all there is to it.
On to the next level, what this is all about: securing your calls (for reference, I've made a Visual Studio solution documenting different ways of doing this - you can download that at the bottom of this post). Lots of projects have some kind of requirement stating only certain people can call certain service operations - for example, you might only want people with a valid username/pw-combination to be able to call your operations, instead of letting everyone call them. Seeing your servicehost will probably be publicly available (again, unless you're working in an intranet-environment), anyone could potentially write a client to communicate with your services. This obviously poses some serious risks.
So, on to username authentication on your service operations. The idea is that you will require every service call to provide you with a username/pw-combination. In the service operation, this combination will be validated and the call will only continue if the combination is valid. Thus blocking off everyone who hasn't got a valid combination from using your services! Since we're using SSL/https to encrypt our message, we can safely send the username/pw over the wire. A comparable method already exists out of the box with WsHttpBinding, but in Silverlight, we're limited to basicHttpBinding, so we can't use that one.
This project shows different ways of implementing this:
* No authentication. This is a regular service call, everyone will be able to call the service, no username/pw is passed or sent over the wire, no authentication is done. This is, obviously, not secure, and shouldn't be done outside of a controlled environment.
* Authentication through method parameters. Username/pw are provided via parameters to the service method. Authentication is done in the service method. This will work, but it isn't exactly a beautiful solution: all your service method signatures will have to have 2 additional parameters: username & pw.
* Authentication through message headers. Instead of passing the username/pw to the method via parameters, they are passed by adding them to the message header of the message which is sent over the wire. Once in the service method, they are extracted and authentication is done. This is already a lot better than the previous method: no additional parameters are required.
* Authentication through message headers by implementing an operation behavior. Same as the previous method, but instead of writing code in every method to check username/pw, we write this code once in a custom operation behavior. Every method decorated with this attribute will automatically perform username/pw authentication. This is the preferred way to implement username/pw authentication.
Conclusion: nice code, not too much clutter, encrypted messages & safe calls! :-)
For those of you who want to read more about this (and then some), I got A LOT of help from the reference made by David Betz - give it a read if you find the time.
As usual, full source code is included. You can download that here. Enjoy!