当你没有花钱去买SSL证书（安全套接层，你可以简单的理解为：正常http请求都是明文传送，使用SSL后可以帮你把http报文自动加密，就算有人在互联网上截获了也无法解密。我们偶尔访问有些网站的时候，看到的“https://www.xxx.com”,就极可能是基于SSL证书的形式）。至于“通过电缆以明文的方式...”，其实这句话说的很不对，首先，电缆只是一种传输介质，里面传送的只是电脉冲、光信号等等，而不是网络协议报文（学过计算机网络的都知道）。至于说“采用明文的形式”，也不对，其实“基本身份验证”中，是将用户名和密码采用了Base64编码的，感兴趣的读者，可以用httpwatch或者Fiddler之类的工具去监视一下http请求，我这里就不做演示了 。只是由于Base 64编码很容易反编码，所以和明文没啥区别。这样一来，你会发现“基本身份验证”方式，确实存在很多不安全因素。
在IIS 7上测试一下windows 身份验证：
和之前的基本身份验证差不多，我就不再截图演示了。如果用户输入正确的windows用户名和密码，则能够正常访问网站。如果输入错误的，则返回的401.1（前面基本身份验证是401.2）。值得一提的就是，记得之前有位asp.net MVP 曾告诉过我，使用windows身份验证的时候，只能用户在使用IE浏览器时候才能够正常访问。因为这种情况下，不是使用http报文传输的形式，而是浏览器端直接与操作系统内部交互，进行用户名和密码的验证。经过证实，发现这话的后半句是对的，确实监视不到http实体内容。但不仅仅局限于IE浏览器，我在firefox中也能够正常的访问和使用。
匿名身份验证：
所谓匿名身份验证，其实就可以理解为“不验证”。就是匿名用户都可以访问资源，没有任何限制。通常我们的网站，都要启用匿名方式验证，集成windows身份验证。不难发现，其实匿名身份验证，也是通过windows用户组里面的一个特定的用户来通过验证的，如图所示：
最后一种，Form身份验证：
前面所讲的那些身份验证方式，其实都和asp.net没有直接的联系，都是IIS 和操作系统级别的验证方式。而Form 身份验证，则需要asp.net提供支持。因为通常网站的身份验证和成员管理都非常复杂，而不是通过单纯的某一种验证方式能够实现的。对于大部分互联网的网站而言，用户可以访问部分页面，但部分页面必须登录后才能访问和操作，而且不同用户角色登录，操作权限也不一样。这又会涉及到很多方面的知识，而且实现方式也有很多种。
由于篇幅和时间有限，今天就先到此。后期我再详细地去整理关于Form身份验证的详细及成员管理，权限管理方面的文章，敬请期待。