哪些网站可以做商家,深圳市保障性住房轮候申请,新零售网站建设,开通网站流程标题中 “传统 Web 应用” 这一说法也并没有什么官方定义#xff0c;只是为了与“现代化 Web 应用”形成比较而自拟的一个概念。所谓现代化 Web 应用指的是那些基于分布式架构思想设计的#xff0c;面向多个端提供稳定可靠的高可用服务#xff0c;并且在需要时能够横向扩展的… 标题中 “传统 Web 应用” 这一说法也并没有什么官方定义只是为了与“现代化 Web 应用”形成比较而自拟的一个概念。所谓现代化 Web 应用指的是那些基于分布式架构思想设计的面向多个端提供稳定可靠的高可用服务并且在需要时能够横向扩展的 Web 应用。相对而言传统 Web 应用则主要是直接面向 PC 用户的 Web 应用程序采用单体架构较多也可能在内部采用 SOA 的分布式运算技术。 一直以来传统 Web 应用为构成互联网发挥了重要作用。因此传统 Web 应用中的身份验证技术经过了几代的发展已经解决了不少实际问题并最终沉淀了一些实践模式。 安全议题不容忽视 在讲述多种身份鉴权技术之前要强调一点在构建互联网 Web 应用过程中无论使用哪种技术在传输用户名和密码时请一定要采用安全连接。因为无论采用何种鉴权模型都无法保护用户凭据在传输过程中不被窃取。 Basic 和 Digest 鉴权 基于 HTTP 的 Web 应用离不开 HTTP 本身的安全特性中关于身份鉴权的部分。虽然 HTTP 标准定义了好几种鉴权方式但真正供 Web 应用开发者选择的并不多这里简要回顾一下曾经被广泛运用过的 Basic 和 Digest 鉴权。 不知道读者是否熟悉一种最直接向服务器提供身份的方式即在 URL 中直接写上用户名和密码 http://user:passwdwww.server.com/index.html 这就是 Basic 鉴权的一种形式。 Basic 和 Digest 是通过在 HTTP 请求头中直接包含用户名和密码或者它们的哈希值来向服务器传输用户凭据的方法。Basic 鉴权直接在每个请求请求的头部或 URL 中包含明文的用户名或密码或者经过 Base64 编码过的用户名或密码而 Digest 则会使用服务器返回的随机值对用户名和密码拼装后使用多次 MD5 哈希处理后再向服务器传输。服务器在处理每个请求之前读取收到的凭据并鉴定用户的身份。 Basic 和 Digest 鉴权有一系列的缺陷。它们需要在每个请求中提供凭据因此提供“记住登录状态”功能的网站中不得不将用户凭据缓存在浏览器中增加了用户的安全风险。Basic 鉴权基本不对用户名和密码等敏感信息进行预处理所以只适合于较安全的安全环境如通过 HTTPS 安全连接传输或者局域网。看起来更安全的 Digest 在非安全连接传输过程中也无法抵御中间人通过篡改响应来要求客户端降级为 Basic 鉴权的攻击。Digest 鉴权还有一个缺陷由于在服务器端需要核对收到的、由客户端经过多次 MD5 哈希值的合法性需要使用原始密码做相同的运算这让服务器无法在存储密码之前对其进行不可逆的加密。Basic 和 Digest 鉴权的缺陷决定了它们不可能在互联网 Web 应用中被大量采用。 简单实用的登录技术 对于互联网 Web 应用来说不采用 Basic 或 Digest 鉴权的理由主要有两个 1. 不能接受在每个请求中发送用户名和密码凭据2. 需要在服务器端对密码进行不可逆的加密 因此互联网 Web 应用开发已经形成了一个基本的实践模式能够在服务端对密码强加密之后存储并且尽量减少鉴权过程中对凭据的传输。其过程如下图所示 基于 Cookie 和 Session 的鉴权过程 这一过程的原理很简单专门发送一个鉴权请求只在这个请求中包含原始用户名和密码凭据经服务器验证合法之后由服务器发给一个会话标识Session ID客户端将会话标识存储在 Cookie 中服务器记录会话标识与经过验证的用户的对应关系后续客户端使用会话标识、而不是原始凭据去与服务器交互服务器读取到会话标识后从自身的会话存储中读取已在第一个鉴权请求中验证过的用户身份。为了保护用户的原始凭据在传输中的安全只需要为第一个鉴权请求构建安全连接支持。 服务端的代码包含首次鉴权和后续检查并授权访问的过程 IUser user;if( validateLogin( nameFromReq, pwdFromReq, out user )){ Session[CurrentUser] user;} 首次鉴权 IUser user Session[CurrentUser] as IUser;if( user null ){ Response.Redirect( /login?return_uri Request.Url.ToString() ); return;} 后续检查并拒绝未识别的用户 类似这样的技术简易方便容易操作因此大量被运用于很多互联网 Web 应用中。它在客户端和传输凭据过程中几乎没有做特殊处理所以在这两个环节尤其要注意对用户凭据的保护。不过随着我们对系统的要求越来越复杂这样简易的实现方式也有一些明显的不足。比如如果不加以封装很容易出现在服务器应用程序代码中出现大量对用户身份的重复检查、错误的重定向等不过最明显的问题可能是对服务器会话存储的依赖服务器程序的会话存储往往在服务器程序重启之后丢失因此可能会导致用户突然被登出的情况。虽然可以引入单独的会话存储程序来避免这类问题但引入一个新的中间件就会增加系统的复杂性。 传统 Web 应用中身份验证最佳实践 上文提到的简单实用的登录技术已经可以帮助建立对用户身份验证的基本图景在一些简单的应用场景中已经足够满足需求了。然而用户鉴权就是那种“你可以有很多种方法就是不怎么优雅” 的问题。 最佳实践指的是那些经过了大量验证被证明有用的方法。而用户鉴权的最佳实践就是使用自包含的、含有加密内容的 Cookie 作为替代凭据。其鉴权过程与上文所提到基于会话标识的技术没有什么区别而主要区别在于不再颁发会话标识取而代之的是一个代表身份的、经过加密的 “身份 Cookie”。 1. 只在鉴权请求中发送一次用户名和密码凭据2. 成功凭据之后由服务器生成代表用户身份的 Cookie发送给客户端3. 客户端在后续请求中携带上一步中收到的 “身份 Cookie”4. 服务器解密身份 Cookie并对需要访问的资源予以授权 这样我们消除了对服务器会话存储的依赖Cookie 本身就有有效期的概念因此顺便能够轻松提供“记住登录状态”的功能。 另外由于解密 Cookie 既而检查用户身份的操作相对繁琐迫使工程师不得不考虑对其抽取专门的服务最终采用了面向切面的模式对身份验证的过程进行了封装而开发时只需要使用一些特性标注Attribute Annotation对特定资源予以标记即可轻松完成身份验证预处理。 传统 Web 应用中的单点登录 单点登录的需求在向用户提供多种服务的企业普遍存在出发点是希望用户在一个站点中登录之后在其他兄弟站点中就不需要再次登录。 如果多个子站所在顶级域名一致基于上文所述的实践可以基于 Cookie 共享实现最简单的单点登录在多个子站中使用相同的加密、解密配置并且在用户登录成功后设置身份 Cookie 时将 domain 值设置为顶级域名即可。这样只要在其中一个网站登录其身份 Cookie 将在用户访问其他子站时也一起带上。不过实际情况中这个方案的应用场景很有限毕竟各个子站使用的用户数据模型可能不完全一致而加密密钥多处共享也增加了服务器应用程序的安全风险。 对于单点登录需求来说域名相同与否并不是最大的挑战集成登录系统对各个子站点的系统在设计上的影响才是。我们希望便利用户的同时也期待各个子系统仍拥有独立用户身份、独立管理和运维的灵活性。因此我们引入独立的鉴权子站点。当用户到达业务站点 A 时被重定向到鉴权站点登录成功之后用户被重定向回到业务站点 A、同时附加一个指示“已有用户登录”的令牌串——此时业务站点 A 使用令牌串在服务器端从鉴权子站点查询并记录当前已登录的用户。当用户到达业务站点 B 时执行相同流程。由于已有用户登录所以用户登录的过程会被自动省略。 这样的单点登录系统能够较好地解决在多个站点中共享用户登录状态的需求。不过如果在编程实践过程中略有差池就会让用户陷入巨大的安全风险中。例如在上述重定向过程中一旦鉴权系统未能验证返回 URL 的合法性就容易导致用户被钓鱼网站利用。在传统 Web 应用开发实践中被广泛部署的身份验证体系是比较重量级的 WS-Federation 和相对轻量级的 OpenID 等技术。 总结 本文简要总结了传统 Web 应用中被广泛使用的几种典型的用户登录时的鉴权处理流程。总体来说在单体 Web 应用中身份验证过程并不复杂只要稍加管理可以较轻松地解决用户鉴权的问题。但在传统 Web 应用中为了解决单点登录的需求人们也尝试了多种方式最终仍然只有使用一些较复杂的方案才能较好地解决问题。 在现代化 Web 应用中围绕登录这一需求俨然已经衍生出了一个新的工程。“登录工程” 并不简单在后续篇目中将会介绍现代化 Web 应用的典型需求及解决方法。 原文地址http://www.jianshu.com/p/6ca51a8d66bd .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
