WCF Security之IIS的验证方式

WCF service可以host在任何形式的应用程序中，但是一般来讲，还是以宿主在IIS上为主。WCF的验证更多是与IIS的验证相一致的。如何将WCF的复杂验证方式一一理清，有必要从IIS的验证方式及其使用场景谈起。

IIS的几种验证方式
1.匿名验证(Anonymous)，就是不做客户端验证，在服务端直接模拟匿名用户来访问指定的资源。
2.基本验证(Basic)，就是客户端在对话框中输入用户名、密码，明文传输至服务端进行验证，这是HTTP支持的，比较原始的认证方式。
3.集成Windows验证(Integrated)，包括NTLM和Kerberos两种方式，集成验证的方式下，客户端不用传输密码给服务端，而通过hash等暗号交换的方式来验证。这种验证方式非常安全，但是缺点是客户端和服务端都必须是windows环境，而且不能通过HTTP代理工作。
4.证书(Certificate)验证，证书分为服务端证书和客户端证书，服务端证书是为了验证服务端的身份，客户端证书是为了验证客户端的身份，服务端证书理论上应该由公开的证书机构来发放，其公钥用于客户端信息的加密，服务端接收到后使用私钥解密。对于客户端证书，可以是由服务端发放的内部证书。

这些验证方式使用的场景
Anonymous验证，一般用于website，任何用户都可以访问一个站点所有公开的资源。
Basic验证，这种验证方式不清楚还有什么场景下会使用它。
Integrated Windows验证，这对于服务端和客户端同在一个域中的情况下，这中验证既安全又不需要额外的工作。
Certificate验证，主要用于跨越应用边界，域，甚至网络的应用安全。如果使用服务端证书，那么公布的服务将以https方式向外提供。大多数安全主要停留在服务端证书加密。如果需要对客户端做限定，那么可以使用客户端证书。

常见的一些WCF验证方案

1.匿名验证

其实除了website需要匿名验证之外，对于内部的基于SOA的Service也有可能使用匿名验证，只要在对外公布的Service进行验证，而在intranet内部的Service可以直接绕开验证。

2.匿名验证+custom authentication/authorization

就是不用IIS的验证机制，而自己基于数据库实现验证及授权。这种WCF服务的安全依赖于用户名和密码，用户名和密码通过参数或者放在message header中，密码做一些加密。

3.Integrated Windows验证(AD)

这种验证主要用于intranet内部的验证，一般可能有两种情况，一种是客户端在域内，还有一种是内部的不直接对外公布的Service，由其他的对外公布的Service调用，由于在内网，所以只需要做集成windows验证即已足够。

4.服务端证书验证+custom authentication/authorization

这是在方案2的基础上的改进方案，就是在IIS中使用服务端证书，对传输的数据进行加密。

5.服务端证书+客户端证书验证

这可以看做方案4的另一种调整方案，当客户端有限，而且不想维护基于数据库的用户管理模块，那么可以使用客户端证书来识别客户端身份，基于不同权限可以使用不同的证书。

其实服务端验证方案有很多，我之前公司的做法是自己实现验证和授权，而在验证用户的时候使用服务端证书提高安全系数，然后在服务端维护一个session，并随机生成一个token返回给客户端，客户端在后续的访问中直接通过token与服务端交互。估计这种服务端的验证方案每个公司都有自己的特色实现。就我个人感觉，国内的习惯是喜欢自己实现验证和授权而绕开windows集成的方案，随着.net的发展，基于IIS/webservice/WCF的验证也在不断改进，在.net 4.0中提出了Windows Identity Foundation，我觉得我们有必要综合考虑具体的系统安全需求，尽可能的使用“体制内”的方案，呵呵。