摘要
通过本文你将了解ASP.NET身份验证机制，表单认证的基本流程，ASP.NET Membership的一些弊端以及ASP.NET Identity的主要优势。
目录
- 身份验证（Authentication）和授权（Authorization）
- ASP.NET身份验证方式
- 理解表单验证流程
- 认识ASP.NET Membership
- 拥抱ASP.NET Identity
- ASP.NET Identity主要组成部分
- 总结
身份验证（Authentication）和授权（Authorization）
我们先来思考一个问题：如何构建安全的WEB应用？
一直以来，这都是比较热门的话题。不幸的是，目前还没有一种万能方法，来保证您的WEB应用是绝对安全的。不管是系统本身的漏洞，还是其他外来的攻击，我们每天都饱受着安全问题的煎熬。
其实，我们也无需沮丧和纠结。既然，我们不能阻止攻击，但是可以提前预防，尽量将损失减到最小，不是吗？
目前，有许多适用于ASP.NET应用的安全原则，比如深度防御、不信任任何输入数据、关闭不必要的功能等等。但是，最基本的、最重要的原则还是身份验证（Authentication）和授权（Authorization）。
初次看到这两个概念，也许大家很容易犯迷糊。因为，Authentication和Authorization确实长得很像。其实，它们仅仅外表很像而已，内在却大不相同。
验证（Authentication）
验证就是鉴定应用程序访问者身份的过程。验证回答了以下问题：当前访问的用户是谁？这个用户是否有效？在日常生活中，身份验证并不罕见。比如，通过检查对方的证件，我们一般可以确信对方的身份。
授权（Authorization）
授权是决定验证通过的用户应该拥有何种级别的访问安全资源的权限。资源可以是IIS上的页面文件、媒体文件（.jpeg）、压缩文件（.zip）等等。
下面我们简单的描述验证和授权的过程。
ASP.NET身份验证方式
安全问题一直是ASP.NET的关注点。其中，Windows验证和表单验证（Forms Authentication）就是ASP.NET两种主要的安全机制。
Windows验证：一般用于局域网应用。使用Windows验证时，用户的Windows安全令牌在用户访问整个网站期间使用HTTP请求，进行消息发送。应用程序会使用这个令牌在本地（或者域）里验证用户账号的有效性，也会评估用户所在角色所具备的权限。当用户验证失败或者未授权时，浏览器就会定向到特定的页面让用户输入自己的安全凭证（用户名和密码）。
Forms验证：Windows验证的局限性非常明显，一旦用户有超出本地域控制器范围的外网用户访问网站，就会出现问题。ASP.NET表单验证（Forms Authentication）很好的弥补了这一缺陷。使用表单验证，ASP.NET需要验证加密的HTTP cookie或者查询字符串来识别用户的所有请求。cookie与ASP.NET会话机制（session）的关系密切，在会话超时或者用户关闭浏览器之后，会话和cookie就会失效，用户需要重新登录网站建立新的会话。
理解表单认证流程
第一步 在页面登录框输入账号和密码。
第二步 检查用户是否有效。可以从配置文件、SQL Server数据库或者其他外部数据源中查找。
第三步 如果用户有效，则在客户端生成一个cookie文件。cookie文件标识用户已经验证通过，当你访问网站其他资源时，不需要重新验证。
认识ASP.NET Membership
使用表单认证能解决基本的身份验证问题。但是，大部分应用程序还包含角色和用户管理以及权限信息的存储问题。因此，我们不得不做下面这些事情：
- 创建用户和角色表。
- 编写访问数据表的代码。
- 提供用户和密码验证的方法。
几乎每一个应用程序，我们都重复着做上面类似的事情。当微软发现这一问题后，在ASP.NET 2.0引入了Membership的重磅级技术方案。ASP.NET Membership很好的解决了WEB应用程序在成员资格方面的常见需求，这些需求包括表单身份验证，存储用户名、密码和用户资料信息 （profile）等。
在很长的一段时间内，Membership极大地简化了应用程序的编写。然而，我们的需求越来越多，ASP.NET Membership自身设计的缺陷，难以适应这种变化。
数据库架构受限于SQL Server。对其他数据库很难兼容。
生硬的表存储结构。如果需要添加额外的用户资料信息，需要存储在其他表，使得这些信息难以访问（除非通过 Profile Provider API）。
系统仅依据关系数据库设计。当然，你也可以写一个面向非关系型数据库的Provider（例如 Windows Azure 存储表），但是不得不写大量的代码，来解决兼容问题。
不能使用OWIN。由于登录、注销功能基于表单认证，第三方账号的接入显得比较困难。
OWIN （Open Web Interface for .NET）:
OWIN 是一种定义 Web 服务器和应用程序组件之间的交互的规范 。这一规范的目的是发展一个广阔且充满活力的、基于 Microsoft .NET Framework 的 Web 服务器和应用程序组件生态系统。
Katana 是开源的的OWIN框架，主要用于微软.NET应用程序。Katana 2.0 将随 Visual Studio 2013 一起发布。 新版本有两个值得关注的方面：
- 为自托管提供核心基础结构组件。
- 提供了一套丰富的验证中间件（包括 Facebook、Google、Twitter 和 Microsoft Account 这样的社交提供商）以及适用于 Windows Azure Active Directory、cookie 和联合身份验证的提供程序。
更多信息参考 http://owin.org/
拥抱ASP.NET Identity
鉴于ASP.NET Membership的弊端，微软又开发一套新的安全框架ASP.NET Identity。ASP.NET Identity具有以下优势：
图 ASP.NET Identity基本功能
统一的框架
可以轻松地整合到 ASP.NET 各种框架以及程序上。例如，ASP.NET MVC, Web Forms, Web Pages, Web API 和 SignalR等。
自定义用户信息
可以很方便的扩展用户信息。比如，添加用户的生日，年龄等。
灵活的角色管理
ASP.NET Identity 中的角色提供程序让你可以基于角色来限制对应用程序某个部分的访问。你可以很容易地创建诸如 “Admin” 之类的角色，并将用户加入其中。
数据持久性以及兼容性
默认情况下，ASP.NET Identity 系统将所有的数据存储在SQL Server数据库中，并且使用 Entity Framework Code First 实现数据库的管理。
当然，对其他存储介质也有很好的支持。例如 SharePoint, Windows Azure 存储表服务, NoSQL 数据库等等。
单元测试能力
ASP.NET Identity 使得 Web 应用程序能够更好地进行单元测试。
OWIN 集成
ASP.NET 验证（Authentication）基于 OWIN 中间件，可以在任何 OWIN 的宿主上使用。ASP.NET Identity 不依赖于System.Web，完全兼容 OWIN 框架，可以被用在任何由OWIN 承载的应用程序。
NuGet 包
ASP.NET Identity 作为一个 NuGet 包进行发布，并且在 Visual Studio 2013 中作为 ASP.NET MVC, Web Forms 和 Web API 项目模板的一部分提供。你也可以从 NuGet 库中下载到该 NuGet 包。
这种发布方式使得 ASP.NET 团队能够为了添加新功能或者进行 BUG 修复更好的进行迭代，更加敏捷的进行发布给开发人员。
ASP.NET Identity主要组成部分
图 ASP.NET Identity基本组成部分
ASP.NET Identity主要包括核心功能模块、EntityFramework模块以及OWIN模块。具体如下：
Microsoft.AspNet.Identity.Core
核心库，包含Identity的主要功能。
Microsoft.AspNet.Identity.EntityFramework
主要包括ASP.NET Identity 的EF 部分的实现。
Microsoft.AspNet.Identity.OWIN
ASP.NET Identity对OWIN 的支持。
总结
本文首先介绍了一些安全机制，然后引申到ASP.NET Membership，最后强调了ASP.NET Identity的优势。相信本文让大家对ASP.NET Identity有一个基本的了解，后续我将介绍如何扩展ASP.NET Identity，实现自己的用户和角色管理。