用户的请求首先到达IIS服务器，在服务器允许访问的条件下，IIS将首先检查当前请求服务的用户，将请求映射到Windows用户，然后，根据这个Windows用户的身份继续后继的请求处理，在IIS中提供了多种验证请求用户身份的方式
- Anonymous Authentication
在启用匿名访问的情况下，IIS将不会从用户的请求中检查用户的安全信息，在http头中也不需要包含验证信息。IIS直接将当前请求的用户映射到系统的 IIS APPPOOL\DefaultAppPool 用户
HttpContext.Current.User.Identity.Name: [empty]
WindowsIdentity.GetCurrent().Name: IIS APPPOOL\DefaultAppPool
-
Basic Authentication
如果服务器关闭了AnonymousAuthentication而启用了BasicAuthentication，用户在向服务器提交请求以后，如果请求中没有需要的验证信息，服务器将返回一个质询（challenge），这个质询以回应头的形式发送到浏览器，格式如下：
WWW-Authenticate： Basic realm=“XXXXXXXX”
realm用于对请求URI所指定的受保护资源进行标识。
浏览器将弹出一个对话框来要求用户输入自己的账号。对于IIS来说，这个账号必须是IIS服务器上的一个账号
Paste_Image.png
用户输入的账号信息会连接为一个通过冒号分隔的字符串，然后通过base64编码之后，由浏览器发送到服务器。
HttpContext.Current.User.Identity.Name: Richard-PC-01\winauth
WindowsIdentity.GetCurrent().Name: IIS APPPOOL\DefaultAppPool
但这里需要提到一个笔者在Windows docker container 里面发现的一个问题，
在container enable了IIS BasicAuthentication以后， 客户端的浏览器提交请求了以后， 并不会弹出弹出对话框要求用户输入账号
- Windows Authentication
在用户具有Windows域帐户的内部网环境中，这种验证方式就能发挥作用。在Windows Authentication中，浏览器尝试使用当前用户在域登录过程中使用的凭据，如果此尝试失败， 就会弹出一个提示框来提示该用户输入用户名和密码。
当浏览器访问设为WinAuthticaiton的IIS资源时，IIS发送两个WWW身份验证头： Negotiate和NTLM
客户端认识Negotiate 头，将选择使用Negotiate 头,之后浏览器可以选择NTLM 或Kerberos两种验证方式。
如果客户端不认识Negotiate头，只能选择NTLM头，就只能使用NTLM验证方式. NTLM验证的主要过程如下：
1）客户端首先在本地加密自己的密码成为密码散列
2）客户端向服务器发送自己的账号，这个账号是没有经过加密的，明文直接传输
3）服务器产生一个16位的随机数字发送给客户端，作为一个challenge
4 ) 客户端再用加密后的密码散列来加密这个challenge，然后把这个返回给服务器，作为response。
5）服务器把用户名、给客户端的challenge、客户端返回的response这三个东西，发送给域控制器
6）域控制器用这个用户名在SAM密码管理库中找到这个用户的密码散列，然后使用这个密码散列来加密challenge
7）域控制器比较两次加密的challenge，如果一样，那么认证成功
IIS 的authentication 会在ASP.NET的authentication之前发生，如果认证不通过，直接会返回如401 Unauthorized此类response， 当IIS 的验证通过，那么下面将进入ASP.NET 的Authentication
ASP.NET的authentication主要有下面几种方式：
Windows Authentication
这里的Windows Authentication 虽然与上文提到的IIS Windows Authentication 名称完全一样， 但意义是截然不用的。
在Asp.net 中的Windows Authentication发生的时候，仅仅是从请求中获取Windows 用户的信息，并表示为.NET用户对象， 注意， 这个过程并不会和域控制器产生通信Forms Authentication
