建设网站要服务器,阿里云注册域名,如何做团购网站中的美食地处地图功能,汉中今天确诊名单一、预备知识
本文讨论基于微服务架构下的身份认证和用户授权的技术方案#xff0c;在阅读之前#xff0c;最好先熟悉并理解以下几个知识点#xff1a;
微服务架构相关概念#xff1a;服务注册、服务发现、API 网关身份认证和用户授权#xff1a;SSO、CAS、OAuth2.0、JW…一、预备知识
本文讨论基于微服务架构下的身份认证和用户授权的技术方案在阅读之前最好先熟悉并理解以下几个知识点
微服务架构相关概念服务注册、服务发现、API 网关身份认证和用户授权SSO、CAS、OAuth2.0、JWT
文章在涉及到上述知识内容时会附上参考链接。此外还有以下几个基础概念在身份治理领域容易混淆
认证授权鉴权权限控制
建议参考 pphh 的博文《认证、授权、鉴权和权限控制》
http://www.hyhblog.cn/2018/04/25/user_login_auth_terms
二、背景
当企业的应用系统逐渐增多后每个系统单独管理各自的用户数据容易行成信息孤岛分散的用户管理模式阻碍了企业应用向平台化演进。当企业的互联网业务发展到一定规模构建统一的标准化账户管理体系将是必不可少的因为它是企业互联网云平台的重要基础设施能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力为企业带来诸如跨系统单点登录、第三方授权登录等基础能力为构建开放平台和业务生态提供了必要条件。
三、需求分析
在微服务架构下必须对企业的平台生态进行合理的业务划分每个业务板块将自成系统例如负责宣发的企业官网、主打文体的 B2B2C 商城、面向社区的物业服务系统等这些系统业务比较独立应当独立拆分。每个系统又可根据各自的业务模型进行切分将业务模型和用户需求统筹分析后建立恰当的领域模型形成独立的服务。
另外企业平台的客户范围比较复杂有 2B 的业务也有 2C 的还有 2Ggoverment的因此平台级的统一身份管理必须涉及组织实体和个人实体两类其中组织实体包括政府机关G、企业单位B、团体组织B等这类似于多租户架构的概念但又比传统多租户架构复杂。
一统一身份管理Unified Identity Manager
统一身份管理UIM是整个平台帐号和权限管控的基础由此构建的系统称为UIMSUnified Identity Management System平台下所有系统的账户管理、身份认证、用户授权、权限控制等行为都经由 UIMS 处理提供帐号密码管理、基本资料管理、角色权限管理等功能。UIMS 基于『统一身份治理』的概念可划分为两级账户体系、基础权限模块和基础信息模块三大模块。其中两级账户体系将账户分为组织实体帐号和个人实体账户两大类个人实体从属于组织实体也可以不从属任何组织实体且个人实体可同时从属于多个组织实体基础权限模块将各业务系统的资源权限进行统一管理和授权基础信息模块用于描述组织实体和个人实体的基本信息如组织实体名称、地址、法人个人实体姓名、电话号码、性别等基础信息。UIMS 提供统一的 API 与各子系统连接。
可以看到众多系统和众多服务都将依赖于 UIMS 。本文仅涉及 UIMS 下的两级账户体系和基础权限模块这两个模块据此可以独立出账户管理服务和权限管理服务也可以合并成一个账户权限管理服务。其中账户管理服务包括业务系统实体、组织实体和个人实体管理、权限管理服务包含认证、授权和鉴权三个部分。 关于统一身份管理系统的介绍请参考 https://mtide.net/平台级SaaS架构的基础-统一身份管理系统.html 二软件即服务SaaS
企业提供对外的 IT 服务有两种部署模式一是私有云部署二是公有化服务。公有云服务即 SaaS提供系统级的应用服务包括企业服务如企业邮箱、办公 OA、人力资源系统等个人服务如个人邮箱、云笔记、云网盘等。平台级的 SaaS 应用架构实际上可以理解为多租户架构的升级版加大了统一身份治理的难度。而基于 UIMS 系统的两级账户体系可以很容易做到这一点。值得注意的是有些系统仅提供个人账户服务有些系统仅提供组织账户服务有的则两者都提供必须处理好个人实体和组织实体之间的关系。 关于 SaaS 的介绍请参考 http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html 三组织实体Orginization Entity
在 UIMS 中组织机构应当是一种实体与之对应的另一种实体是个人实体。注意实体Entity不是账户Account因此要设计一种用于组织实体登入受控系统的方法这里有两种可选方案一是增加组织实体账户组织实体自身拥有账户可直接进行认证登录二是将从属于组织实体的个人账户作为组织实体的登入凭证。无论何种方法在认证和授权时都应当向 UIMS 提供统一的标准的账户凭证凭证的规格由 UIMS 定义因此组织实体的认证授权与个人实体的认证授权并无二致。
四单点登录SSO
企业平台涉及众多子系统为简化各子系统的用户管理提升用户体验因此实现 SSO 是统一身份认证的重要目标一次登录全部访问。对于企业内部应用来说SSO 是必须的选项例如企业 OA、HR、CRM 等内部系统对于外部应用来说SSO 是可选项具体哪个应用应当加入 SSO 系统由该业务系统决定例如外部商城、物业系统等对外服务系统。无论何种应用是否采用 SSOUIMS 在技术上应当具备 SSO 的能力。 关于SSO的介绍请参考 https://www.cnblogs.com/EzrealLiu/p/5559255.html 五授权登录
随着平台业务的逐渐增长依托于平台的和平台依托的厂商和客户等资源将极大的丰富平台因此必须构筑开放的生态系统以支撑业务的进一步发展。可以开放平台级的授权登录功能以允许第三方应用接入。通过三方授权登录将平台的服务各能力开发给第三方并将第三方的服务和能力接入平台繁荣共生共同发展。
六服务间鉴权
业务系统切分出不同的服务根据粒度粗细和业务需求不同服务的数量和权限要求都不同。微服务架构下的身份认证和授权可分为两种
内部服务的认证和授权外部服务的认证和授权。
通常内部服务处于安全的内网环境之下例如 BFF 层Backend For Frontend Layer的商品服务、订单服务等在对安全需求不高的情况下可不执行认证过程服务与服务之间是相互信任的。
而外部服务的认证和授权通常由外部应用发起通过反向代理或网关向安全边界内的服务发起请求因此必须执行严格的认证过程。无线端APP、Web端、桌面客户端等外部应用下的各类服务都属于外部服务。 服务间鉴权示意图
七帐号登出和销毁
与 SSO 相对应UIMS 应该支持一次登出全部登出即 SSOffSingle Sign-Off非标准术语或者一次登出部分登出而是否全部登出或部分登出取决于用户的选择例如用户在 Web 端登出后是否无线端 APP 也登出这取决于用户偏好但系统应当提供这种能力。
此外必须提供统一的销毁功能以支持用户删除其账户一次销毁全部销毁。
八付费授权
云平台应具备付费授权机制针对用户账户和组织账户进行独立授权。根据产品的商业策略可执行灵活的付费模式:
时效限制:年付、季付、月付不同时效费用不同功能限制:授权不同的功能费用不同数量限制:最大组织数量限制、最大用户数量限制不同的数量费用不同。
四、技术方案
一备选方案
上文基于『统一身份治理』的理念提出了统一身份管理系统UIMS下关于身份认证和授权部分的主要需求。目前实现统一身份认证和授权的技术手段较多总体可以归纳为以下两类
传统的 Cookie Session 解决方案有状态会话模式基于令牌/票据的解决方案无状态交互模式。
具体有
分布式 SessionOAuth2.0CAS
上述方案各有利弊 分布式 Session 是老牌的成熟解决方案但因其状态化通信的特性与微服务提倡的API导向无状态通信相互违背且共享式存储存在安全隐患因此微服务一般不太采用。 OAuth2.0 是业内成熟的授权登录解决方案然而 OA2.0 提供了4种授权模式能够适应多种场景作为基于令牌的安全框架可以广泛用于需要统一身份认证和授权的场景。 关于 OAuth2.0 的介绍请参考 http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html 在 OAuth2.0 的实施过程中一般会采用 JWT 作为令牌的主要标准JWTJSON Web Token是一种简洁的自包含的 JSON 声明规范因其分散存储和自解签等特点而广泛应用于非集中式认证/授权场景。由于 JWT 信息是经过签名的可以确保发送方的真实性确保信息未经篡改和伪造。但由于其自包含的客户端验签特性令牌一经签发即无法撤销因此单纯采用 JWT 作为统一身份认证和授权方案无法满足帐号统一登出和销毁、帐号封禁和解除这几种类型的需求所以一般配合 OAuth2.0 一起使用。 关于 JWT 的介绍请参考 http://blog.leapoahead.com/2015/09/06/understanding-jwt/ CAS 是时下最成熟的开源单点登录方案包含 CAS Server 和 CAS Client 两部分。CAS Server 是一个 war 包需要独立部署负责用户认证CAS Client 负责处理对客户端受保护资源的访问请求需要认证时重定向到 CAS Server。值得注意的是CAS 是一个认证框架其本身定义了一套灵活完整的认证流程但其兼容主流的认证和授权协议如 OAuth2、SAML、OpenID 等因此一般采用 CAS OAuth2 的方案实现 SSO 和授权登录。关于 CAS 的介绍请参考 https://apereo.github.io/cas/ 在微服务架构下身份认证和用户授权通常分离出来成为独立的 IDP Identity Provider服务。在做技术选型时应从以下几点考虑
满足 SSO 的技术需求满足简便性和安全性的需求满足开放性和扩展性的需求。综合考虑推荐采用无状态 API 模式其中基于 OAuth2.0 的方案能够完全满足。 场景假设构建基于图像的物品识别系统Image-Based Classification System
为便于理解统一认证和授权方案的细节假定一种场景团队准备构建一套基于图像的物品识别系统允许用户通过 H5 应用或 APP 上传图像系统分析后返回识别结果同时期望将此系统开放给社区和行业用户以便商用最后允许第三方应用将自身的功能接入 IBCS 以增强后者的能力。
下图是该系统的微服务架构图 IBCS 微服务架构图
在微服务架构下IBCS 分为内外两层内层处于物理内网环境下也称为内部服务外层处于物理外网环境下也称为外部服务内外通过 API 网关连接。
内部服务IDP 服务、配置服务、图像识别服务属于内部服务通常内部服务之间是相互信任的但在安全要求较高的场景下内部服务也不能互信。外部服务桌面 APP、无线 APP、H5、第三方应用属于外部服务外部服务分为两种类型一种是第一方应用即 IBCS 的一部分如 IBCS 的 APP、H5 这些自家前端和无线端应用另一种是 IBCS 之外的第三方应用。两种类型的授权方式是不一样的前者一般采用 OAuth2.0 的密码模式后者则采用授权码模式。
下文将以物品识别系统为例子介绍这两种推荐方案
二最佳方案 OAuth2.0
1. OAuth2.0 的四种授权模式
授权码模式authorization code简化模式implicit密码模式resource owner password credentials客户端模式client credentials
其中密码模式常用于外部服务的认证、授权和鉴权客户端模式常用于内部服务的认证、授权和鉴权和开放平台应用的授权授权码模式常用于社会化登录和 SSO因此 OAuth2.0 可作为完整的统一身份认证和授权方案。
2. OAuth2.0 的几种重要角色 必须注意的是这些角色是相对的概念。 客户端 Client一般指第三方应用程序例如用 QQ 登录豆瓣网站这里的豆瓣网就是 Client但在微服务体系里Client 通常是服务本身如 APP 端的注册登录服务资源所有者 Resource Owner一般指用户例如用 QQ 登录豆瓣网站这里的所有者便是用户但在微服务体系里资源所有者是服务提供者本身资源服务器 Resource Server一般指资源所有者授权存放用户资源的服务器例如用 QQ 登录豆瓣网站这里的 QQ 就是资源服务器但在微服务体系里服务提供者本身便是资源服务器授权服务器 Authorization Server一般是指服务提供商的授权服务例如用 QQ 登录豆瓣网站这里的 QQ 便是授权服务器类似地在微服务体系里IDP 服务便是授权服务器。
3. IBCS 提供哪些功能
1核心功能以 API 形式暴露
接口描述body返回权限POST /image-classify图像识别{ 图片内容, token }{ 识别结果 }受控接口
2由 UIMS 提供的功能
功能/API描述body返回权限POST /accounts/注册接口{ username, password }{ sign-up-result }非受控接口POST /accounts/login登录接口{ username, password }{ token }受控接口POST /accounts/logout登出接口{ token }{ logout-result }受控接口SignUp-Page统一注册页面UI非受控页面Login-Page统一登录页面UI非受控页面
其中注册接口、SignUp-Page 和 Login-Page 页面是非受控接口/页面意味着无须鉴权即可访问。 SignUp-Page 和 Login-Page 页面是由 UIMS 提供的统一的注册和登录页面当外部服务发起注册或登录请求时有两种作法一是统一跳转到 UIMS 的注册或登录页面用户完成操作后调用 UIMS 的注册和登录 API 完成请求二是在自己的注册和登录页面完成操作然后以用户名和密码作为参数调用 UIMS 的注册和登录 API 完成请求。推荐采用第一种方法类似于全网通行证用户体验统一不用重复开发注册登录页面。 3成为开发者获取 IBCS 的能力集
第一步申请成为开发者。开发者分为个人开发者和组织开发者两类实名认证也分两种类型进行。成为开发者的前提是成为平台的注册用户第二步创建应用平台审核通过后生成 AppId 和 AppSecret 给到开发者每个应用对应一对 AppId 和 AppSecret。值得注意的是每个 AppID 与用户账号是绑定的因此每个 AppId 获取资源和能力的权限受到该用户账户权限的限制典型的例子是对象存储服务OSS/OBS第三步获取 Access Token开发者按照 OAuth2.0 的规范采用客户端client_credentials模式利用申请到的 AppId 和 AppSecret 向 IBCS 申请 token第三步使用 Access Token 与平台进行交互每次调用受控 API 时都携带此 token。在更高安全性要求的场景下也会采用授权码模式。 4成为开发者创建第三方应用
一般来说应当独立建设一个开放平台开发平台作为整个云平台的一个子系统同样依赖于 UIMS。在开放平台上应当提供一套完善的界面和流程以引导用户完成开发者认证和第三方应用接入的所有工作。此外在前期阶段也可以采用线下申请的方式由管理员人工审核在后台手动录入。
在开放平台上创建第三方应用的流程和步骤与上一步骤『成为开发者获取 IBCS 的能力集』一致。所不同的是上个步骤是获取 IBCS 的能力而本步骤『创建第三方应用』是基于开放平台开发应用类似于微信小程序。
5成为开发者将异构系统第三方应用接入 IBCS
应该允许开发者将异构系统第三方应用接入 IBCS以增强 IBCS 的能力。例如假设 IBCS 本身不具备识别特种汽车的能力但允许接入其他开发者开发的基于图像的特种汽车识别应用。
第三方应用接入归属于开放平台的范畴。接入的流程和步骤与第三步骤『成为开发者获取 IBCS 的能力集』一致由开放平台提供标准的 API第三方按照接入规范执行。
4. OAuth2.0 四种授权模式的应用场景
场景描述适用模式用户注册外部服务用户在 APP 提供的注册页面完成注册请求非受控接口无须鉴权用户登录外部服务返回 token用户在 APP 提供的登录页面完成登录请求获得 token密码模式resource owner password credentials用户注册UIMS用户跳转到 UIMS 的注册页面完成注册请求注册成功后跳回到原服务非受控接口无须鉴权用户登录UIMS返回 token用户跳转到 UIMS 的登录页面完成登录操作获得授权码然后携带授权码跳转到重定向URI再获得 token授权码模式authorization code外部服务的鉴权用户在 APP 上使用图像识别服务APP 调用 IBCS 的图像识别 API 并返回结果给用户密码模式resource owner password credentials内部服务的鉴权图像识别服务向配置服务获取配置信息客户端模式client credentials或简单的 HTTP Basic 验证开发者获取 IBCS 能力集客户端模式client credentials或授权码模式authorization code开发者创建第三方应用客户端模式client credentials或授权码模式authorization code开发者接入第三方应用客户端模式client credentials或授权码模式authorization code
5. 客户端鉴权和用户鉴权
服务鉴权从形式上分为
非受控服务/接口无须认证或鉴权客户端认证或鉴权服务自身认证或鉴权客户端服务在访问另一个服务时必须先表明客户端自己的身份业务认证或鉴权用户认证或鉴权用户通过客户端服务访问某个资源时必须验证用户自己的身份。
例如用户通过 APP 登录 IBCS 后访问图像识别服务的过程用户登录后获得 token由 APP 携带此 token 向图像识别服务发起请求图像识别服务首先调用 IDP 服务验证 APP 的身份通过 ClientId 和 ClientSecret然后再验证用户的身份通过 token如果 APP 和用户都获得授权则请求通过返回识别结果。
6. 跨域问题
浏览器的同源策略给 Web 应用划定了安全边界是 Web 应用安全模型的重要基础。基于令牌的安全系统在同源策略的约束下面临两个问题
跨域请求SSO 登录状态的跨域保持。
1CORS 方案
第一个问题一般采用 CORS 方案在服务端的响应头声明 Access-Control-Allow-Origin 参数即可解决跨域请求的问题。
2同域 SSO 方案
第二个问题在同域环境下传统方法是采用 Cookie 的方案。跨域环境下也有几种方案从安全性和简便性考虑推荐采用这种方案
根据业务需求将应用切分为同域 SSO 应用和跨域 SSO 应用两类将需要 SSO 状态保持的应用归到同域 SSO 应用中将其他应用归到跨域 SSO 应用中对于同域 SSO 应用一般是企业内部应用或相关性较高的应用这些应用的域名采用相同的父级域名继续使用 Cookie 方案对于跨域 SSO 应用不提供 SSO 状态保持。当用户首次打开此类应用时由于 Cookie 无法跨域因此服务端无法感知用户的登录状态此时用户是处于未登录状态的当用户访问受控页面或点击登录页面时须重新执行登录操作。
7. 登出和关闭账户
OAuth2.0 是集中式的令牌安全系统可以通过撤销令牌登出系统。关闭账户与此类似。
8. 软件授权
可在 IDP 服务或 API 网关增加规则过滤器将商业授权策略应用到授权规则中。
9. 技术选型 后续会写实践篇敬请期待…… 三将 JWT 应用到 OAuth2.0 方案中 JWT 是一种自包含的客户端令牌系统技术规范这是其与 OAuth2.0 默认令牌的最大不同在应用 JWT 时有几个要点须加以说明。 1. 搭配 API 网关实现令牌撤销
由于 JWT 属于自包含的客户端令牌系统令牌发出后无须服务器验证只需在客户端验证。客户端验证并解签后将得到必要的信息例如用户基本信息和权限标识符。这种设计天然地存在无法撤销令牌的问题。解决方案是网关之外的外部服务继续使用 OAuth2.0 的 AccessToken在网关以内的内部服务使用 JWT这样做有几个好处
外部服务处在不安全的场景中OAuth2.0 的 AccessToken 本身是一串无意义的字符串并非结构化数据这加强了令牌的安全性有效解决 JWT 无法撤销的问题OAuth2.0 的 AccessToken 仍然是集中式的令牌系统外部服务请求资源时会携带 AccessToken 经过网关的拦截。
不过此方案仍然存在两个问题
将一定程度丧失 JWT 客户端解签的优势因为外部服务仍然采用 OAuth2.0 的 AccessToken但相较于传统的 Cookie Session 方案此方案更加轻巧也更加符合微服务无状态 API 的风格对于已发出的 AccessToken客户端在下一次请求之前服务端的令牌系统对此没有控制能力例如 SSOff 将无法很好地实现。
2. 客户端认证/鉴权和用户认证/鉴权
与 OAuth2.0 方案一致客户端同样需要使用 ClientId 和 ClientSecret 认证/鉴权。
3. 公钥和密钥
JWT 一般采用非对称加密算法对 Header 和 Payload 进行签名公钥可以公开存储在外部服务中如 H5、APP。
1非对称算法
非对称算法的重要特点是使用密钥加密时必须用公钥解密用公钥加密时必须用密钥解密。利用此特性通常在服务端采用密钥加密信息然后客户端采用公钥解密信息。由于密钥存储在服务端因此安全性高公钥本身可以公开因此可以在客户端存储。
2公钥解密
JWT 经由服务端用密钥加密后发往客户端客户端使用公钥进行解密便得到了 JWT 的明文。JWT 包含了丰富的信息通常是用户基本信息和权限标识符客户端完全可以信任此 JWT因此不必再依赖于服务端重复鉴权。
4. 服务间认证/鉴权
1内部服务认证/鉴权
以 IBCS 为例当图像识别服务服务携带 JWT 向配置服务请求资源时配置服务使用公钥解密配置服务完全可以信任图像识别服务因此也不必再依赖于鉴权服务的重复认证/鉴权。对于安全性要求不高的场景也可以使用 HTTP Basic 验证进行简单认证/鉴权甚至不认证/鉴权。
2外部服务认证/鉴权
同样外部的 APP 携带 Oauth AccessToken 向内网的图像识别服务发起请求时属于外部服务向内网服务发起请求必须经过 API 网关由网关执行规则过滤和代理认证网关向 IDP 请求校验令牌确保 AccessToken 仍处于有效状态如果 Token 通过检验则由 IDP 生成包含权限标识或Scope的 JWT 返回给网关网关拿到 JWT 后利用公钥进行解密并校验权限标识或Scope通过后再携带此 JWT 向图像识别服务转发请求图像识别服务收到请求后利用公钥解密 JWT 并自行检验其有效性、获取用户信息等无须再请求 IDP。
必须留意在网关拿到 JWT 以后虽然可以连同 Oauth AccessToken 一起缓存下次该服务再发起请求时可直接转发 JWT 而不用再经由 IDP 的进行 JWT 令牌转换但这么做有两个问题
在一定程度上网关抢夺了 IDP 的鉴权工作如果网关不执行令牌有效性过期时间等的检验而是简单通过 Oauth AccessToken 查找出 JWT则丧失了 IDP 集中鉴权的优势。
所以综上所述不建议网关缓存 JWT 并直接转发。
5. 跨域问题
与 OAuth2.0 的跨域解决方案一致。
五、总结
本文给出了微服务架构下的统一身份认证和授权的设计方案从平台级 SaaS 模式下『统一身份治理』的概念出发梳理了关键的需求点提出了对应的解决方案。其中 OAuth2.0 是最佳解决方案不过在实际运用中应当遵循『合适原则』、『简单原则』和『演化原则』三个原则不能盲目照搬。
六、参考链接
认证、授权、鉴权和权限控制 http://www.hyhblog.cn/2018/04/25/user_login_auth_termsSaaShttp://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.htmlSSO https://www.cnblogs.com/EzrealLiu/p/5559255.htmlCAS https://apereo.github.io/cas/UIMS https://mtide.net/%E5%B9%B3%E5%8F%B0%E7%BA%A7SAAS%E6%9E%B6%E6%9E%84%E7%9A%84%E5%9F%BA%E7%A1%80-%E7%BB%9F%E4%B8%80%E8%BA%AB%E4%BB%BD%E7%AE%A1%E7%90%86%E7%B3%BB%E7%BB%9F.html作者mtide 链接https://www.jianshu.com/p/2571f6a4e192 来源简书 著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。
