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