摘要
通过本文你将了解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)。
初次看到这两个概念。或许大家非常easy犯迷糊。
由于,Authentication和Authorization确实长得非常像。
事实上。它们只外表非常像而已,内在却大不同样。
验证(Authentication)
验证就是鉴定应用程序訪问者身份的过程。
验证回答了下面问题:当前訪问的用户是谁?这个用户是否有效?在日常生活中。身份验证并不罕见。比方,通过检查对方的证件。我们一般能够确信对方的身份。
授权(Authorization)
授权是决定验证通过的用户应该拥有何种级别的訪问安全资源的权限。资源能够是IIS上的页面文件、媒体文件(.jpeg)、压缩文件(.zip)等等。
以下我们简单的描写叙述验证和授权的过程。
ASP.NET身份验证方式
安全问题一直是ASP.NET的关注点。当中,Windows验证和表单验证(Forms Authentication)就是ASP.NET两种基本的安全机制。
Windows验证:一般用于局域网应用。使用Windows验证时,用户的Windows安全令牌在用户訪问整个站点期间使用HTTP请求。进行消息发送。
应用程序会使用这个令牌在本地(或者域)里验证用户账号的有效性。也会评估用户所在角色所具备的权限。
当用户验证失败或者未授权时,浏览器就会定向到特定的页面让用户输入自己的安全凭证(username和password)。
Forms验证:Windows验证的局限性非常明显,一旦用户有超出本地域控制器范围的外网用户訪问站点。就会出现故障。
ASP.NET表单验证(Forms Authentication)非常好的弥补了这一缺陷。
使用表单验证。ASP.NET须要验证加密的HTTP cookie或者查询字符串来识别用户的全部请求。
cookie与ASP.NET会话机制(session)的关系密切。在会话超时或者用户关闭浏览器之后,会话和cookie就会失效,用户须要又一次登录站点建立新的会话。
理解表单认证流程
第一步 在页面登录框输入账号和password。
第二步 检查用户是否有效。能够从配置文件、SQL Server数据库或者其它外部数据源中查找。
第三步 假设用户有效。则在client生成一个cookie文件。cookie文件标识用户已经验证通过,当你訪问站点其它资源时。不须要又一次验证。
认识ASP.NET Membership
使用表单认证能解决主要的身份验证问题。可是。大部分应用程序还包括角色和用户管理以及权限信息的存储问题。
因此。我们不得不做以下这些事情:
- 创建用户和角色表。
- 编写訪问数据表的代码。
- 提供用户和password验证的方法。
差点儿每个应用程序,我们都反复着做上面类似的事情。当微软发现这一问题后。在ASP.NET 2.0引入了Membership的重磅级技术方案。ASP.NET Membership非常好的攻克了WEB应用程序在成员资格方面的常见需求,这些需求包含表单身份验证,存储username、password和用户资料信息 (profile)等。
在非常长的一段时间内。Membership极大地简化了应用程序的编写。
然而。我们的需求越来越多,ASP.NET Membership自身设计的缺陷,难以适应这样的变化。
-
数据库架构受限于SQL Server。对其它数据库非常难兼容。
-
生硬的表存储结构。
假设须要加入额外的用户资料信息,须要存储在其它表,使得这些信息难以訪问(除非通过 Profile Provider API)。
-
系统仅根据关系数据库设计。
当然,你也能够写一个面向非关系型数据库的Provider(比如 Windows Azure 存储表),可是不得不写大量的代码,来解决兼容问题。
-
不能使用OWIN。因为登录、注销功能基于表单认证。第三方账号的接入显得比較困难。
OWIN (Open Web Interface for .NET):
OWIN 是一种定义 Web server和应用程序组件之间的交互的规范 。这一规范的目的是发展一个广阔且充满活力的、基于 Microsoft .NET Framework 的 Web server和应用程序组件生态系统。
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 中的角色提供程序让你能够基于角色来限制相应用程序某个部分的訪问。
你能够非常easy地创建诸如 “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。实现自己的用户和角色管理。
来源:https://www.cnblogs.com/jhcelue/p/6991165.html