注意 如果没有启用 IIS“匿名访问”设置，不符合 IIS 身份验证标准的请求将被拒绝而且永远不会到达 ASP.NET 应用程序。

该方案中的数据流如下图所示。

该插图显示了以下的事件顺序：

1. 客户端生成一个对受保护资源的请求。
2. IIS 接收到该请求，如果该请求者经过 IIS 身份验证，或启用了 IIS“匿名访问”，则请求将传递到 ASP.NET 应用程序。在这种情况下，因为 ASP.NET 应用程序中的身份验证模式设置为 Forms，所以没有使用 IIS 身份验证。
3. 如果没有 Cookie 附加到该请求，ASP.NET 将该请求重定向到登录页面，其页面路径保存在应用程序的配置文件中。在登录页面上，客户端输入必需的凭据（通常是名称和密码）。
4. 应用程序代码检查凭据以确认其可靠性，通常在事件处理程序中。如果凭据通过了身份验证，则应用程序代码将附加上包含用户名称（但没有密码）的票据，例如 Cookie。如果没有通过身份验证，该请求通常返回“访问拒绝”信息或再次显示登录页面。
5. 应用程序发出票据以后，ASP.NET 会使用消息身份验证检查来检查票据的有效性。应用程序不需要 *.config 文件中的凭据。实际上，ASP.NET 在发出 Cookie 后并不检查凭据，即使它们存在。
6. 如果用户通过了身份验证，ASP.NET 会检查授权，然后允许访问最初所请求的、受保护的资源，或将请求重定向到其他页面上，这取决于应用程序的设计。它也可以将请求定向到自定义的授权模块上，在该模块中将检查凭据，以用于对所访问的受保护资源进行授权。如果没有通过授权，ASP.NET 会始终重定向到登录页面。
7. 如果用户已被授权，则允许对受保护资源的访问；或应用程序在对受保护资源授权以前可能要求附加的凭据验证，这取决于应用程序的设计。