微服务架构中的认证权限控制设计.docx

微服务架构中的认证权限控制设计第一节引言： 本文系《认证鉴权与API权限控制在微服务架构中的设计与实现》系列的第一篇，本系列预计四篇文章讲解微服务下的认证鉴权与API权限控制的实现。1. 背景最近在做权限相关服务的开发，在系统微服务化后，原有的单体应用是基于Session的安全权限方式，不能满足现有的微服务架构的认证与鉴权需求。微服务架构下，一个应用会被拆分成若干个微应用，每个微应用都需要对访问进行鉴权，每个微应用都需要明确当前访问用户以及其权限。尤其当访问来源不只是浏览器，还包括其他服务的调用时，单体应用架构下的鉴权方式就不是特别合适了。在微服务架构下，要考虑外部应用接入的场景、用户–服务的鉴权、服务–服务的鉴权等多种鉴权场景。比如用户A访问User Service，A如果未登录，则首先需要登录，请求获取授权token。获取token之后，A将携带着token去请求访问某个文件，这样就需要对A的身份进行校验，并且A可以访问该文件。为了适应架构的变化、需求的变化，auth权限模块被单独出来作为一个基础的微服务系统，为其他业务service提供服务。2. 系统架构的变更单体应用架构到分布式架构，简化的权限部分变化如下面两图所示。（1）单体应用简化版架构图：（2）分布式应用简化版架构图：分布式架构，特别是微服务架构的优点是可以清晰的划分出业务逻辑来，让每个微服务承担职责单一的功能，毕竟越简单的东西越稳定。但是，微服务也带来了很多的问题。比如完成一个业务操作，需要跨很多个微服务的调用，那么如何用权限系统去控制用户对不同微服务的调用，对我们来说是个挑战。当业务微服务的调用接入权限系统后，不能拖累它们的吞吐量，当权限系统出现问题后，不能阻塞它们的业务调用进度，当然更不能改变业务逻辑。新的业务微服务快速接入权限系统相对容易把控，那么对于公司已有的微服务，如何能不改动它们的架构方式的前提下，快速接入，对我们来说，也是一大挑战。3. 技术方案这主要包括两方面需求：其一是认证与鉴权，对于请求的用户身份的授权以及合法性鉴权；其二是API级别的操作权限控制，这个在第一点之后，当鉴定完用户身份合法之后，对于该用户的某个具体请求是否具有该操作执行权限进行校验。3.1 认证与鉴权对于第一个需求，笔者调查了一些实现方案：分布式Session方案分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为key来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。基于OAuth2 Token方案随着 Restful API、微服务的兴起，基于Token的认证现在已经越来越普遍。Token和Session ID 不同，并非只是一个key。Token一般会包含用户的相关信息，通过验证Token就可以完成身份校验。用户输入登录信息，发送到身份认证服务进行认证。AuthorizationServer验证登录信息是否正确，返回用户基础信息、权限范围、有效时间等信息，客户端存储接口。用户将Token放在HTTP请求头中，发起相关API调用。被调用的微服务，验证Token。ResourceServer返回相关资源和数据。这边选用了第二种方案，基于OAuth2 Token认证的好处如下：服务端无状态：Token机制在服务端不需要存储Session信息，因为Token自身包含了所有用户的相关信息。性能较好，因为在验证Token时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。现在很多应用都是同时面向移动端和Web端，OAuth2 Token机制可以支持移动设备。最后一点，也是挺重要的，OAuth2与Spring Security结合使用，Spring Security OAuth2的文档写得较为详细。OAuth2根据使用场景不同，分成了4种模式：授权码模式（authorization code）简化模式（implicit）密码模式（resource owner password credentials）客户端模式（client credentials）对于上述OAuth2四种模式不熟的同学，可以自行百度OAuth2，阮一峰的文章有解释。常使用的是password模式和client模式。3.2 操作权限控制对于第二个需求，笔者主要看了Spring Security和Shiro。ShiroShiro是一个强大而灵活的开源安全框架，能够非常清晰的处理认证、授权、管理会话以及密码加密。Shiro很容易入手，上手快控