在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的具体使用以及背后的设计。