在Asp.net上，微软的membershop框架经历了Asp.net membership到Asp.net simple membership，再到现在的Asp.net Identity. 每一次改变，都使得验证框架更加的适应变化和可定制。这篇文章是Asp.net Identity系列的开篇，主要就membership的历史以及Asp.net Identity中的中的一些新的特性和设计思想分享一下自己的理解。后续将会对Asp.net Identity的实际使用以及实现方式等进行进一步展开。
一， Asp.net membership
Asp.net membership是在2005年的Asp.net 2.0引入的。微软首次为Web Form提供了一套membership解决方案，包含了表的结构，基础的操作User, Role等的类，甚至还有一套控件(用户登录login, 用户注册createuserwizard等这些控件)和一套现成的管理页面用来配置。(如下图)
微软一直的优势，就是非常的傻瓜化，什么都是现成的，直接拿来就用，但是也带来了一个负面的影响，就是适应性差，缺乏弹性，无法应对实际应用中的差别需求, 这主要体现在:
- 1. 无法改变表结构，Asp.net membership为你定义好了User，Role等表，但是实际的开发中，你的User表可能需要更多的字段，这个时候往往只能在创建一个存储User附属信息的表。
- 2. 提供的控件看似方便，但是其实鸡肋。由于自带的login控件和membership类，只提供了简单的用户信息录入，不能满足我们项目的需要。例如：我们要用户注册的时候同时输入QQ号码，电话号码，家庭地址。那么使用默认的方式是没有办法解决的。
- 3. 默认只能是存储在Full Sql Server中，对于SQL Server CE, SQL Azure都不支持。通过自定义的Provider可以将membership中的数据存储到其它的关系数据库中，但是对于NoSQL数据库，实现起来非常麻烦。
二， Asp.net simple membership
Asp.net simple membership是再一次的改进，目标是让你更容易地将membership集成到现有的系统中。更容易体现在，它的外部依赖少，对于原有系统的侵入少。
可以定义自己的User表，然后通过下面代码, 生成membership工作所依赖的表，你就能将你系统中的User表和simple membership无缝对接起来。SimpleMembership没有强制的表结构, 所以你可以用任何你觉得舒服的定义自己的User表来存储User信息。这里实际中就是有2个User表，一个是你定义的User表；另一个是simple membership中的User表，只包含和membership相关的信息。
WebSecurity.InitializeDatabaseConnection("DefaultConnection", "UserProfile", "UserId", "UserName", true); 下图是simple membership在数据库中生成的表
但是simple membership本质上也只是上一代membership的改良而已。从下面的图中能够看出来，simple membership是membership的另外一种实现，提供了一种方便使用的MembershipProvider。
由于这种原因, simple membership仍然摆脱不了一些弊病:
- 仍然无法应用到NoSql数据库中.
- 无法集成到OWIN中
- 无法方便的扩展
三，Asp.net Identity简单介绍
Identity是微软设计的全新的独立的membership系统，是为所有的Asp.net应用提供服务的
Identity有下面优点:
- Asp.net全境适用: Asp.net, MVC, web api, SignalR
- User信息自定义
- 存储易于扩展: 默认使用EF Code First存储到数据库中，但是也非常容易扩展到SharePoint, Windows Azure Storage Table Service, NoSQL databases
- 可单元测试
- 角色: 有Role Provider，非常容易创建和管理角色
- Claims权限信息: 相比简单的Role权限控制，Claims提供了更加丰富的内容
- 社交化登录: 比如Facebook等
- 支持Windows Azure Active Directory
- 支持OWIN
- Nuget发布和安装
Identity的原理以及基本设计思想
要完整的理解Identity，需要先了解OWIN。OWIN可以参考文章 下一代Asp.net开发规范OWIN（1）
基于OWIN的设计，使得Identity把membership抽象成了两块大的部分。一块是membership所依赖的数据的存储，一块是Identity的authentication部分。
下一篇，将通过一个实际的例子，来分析Identity的具体使用以及背后的设计。
