Spring Cloud Security[微服务安全](一)初识Spring Cloud Security和OAuth2.0

0. Spring Security

在介绍Spring Cloud Security之前，我们先要介绍一下Spring Security。

Spring Security是一套提供了完整的声明式安全访问控制的解决方案。
Spring Security是基于Spring AOP和Servlet过滤器的，它只能服务基于Spring的应用程序。
除常规认证和授权外，它还提供ACL，LDAP，JAAS，CAS等高级安全特性以满足复杂环境中的安全需求。

核心概念

Principal
代表用户的对象Principal，不仅指人类，还包括一切可以用于验证的设备。
Authority
代表用户的角色Authority，每个用户都应该有一种角色(eg: 管理员或会员)。
Permission
代表授权，需要对角色的权限进行表述。

(注:在Spring Security中，Authority和Permission是两个完全独立的概念，两者没有必然的联系。它们之前需要通过配置进行关联。)

认证和授权

安全方案的实现通常分为认证(Authentication)和授权(Authorization)两部分。

认证(Authentication)
认证是建立系统使用者信息(Principal)的过程。

使用者可以使一个用户，设备，和可以在应用程序中执行某种操作的其它系统。

认证一般通过用户名和密码的正确性校验来完成通过或拒绝。

Spring Security支持的主流认证如下:

HTTP基本认证
HTTP表单认证
HTTP摘要认证
OpenID
LDAP

Spring Security进行认证的步骤:
++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ 1. 用户使用用户名和密码登陆
++
++ 2. 过滤器(UsernamePasswordAuthenticationFilter)获取到用户名
++    和密码，将它们封装成Authentication
++
++ 3. AuthenticationManager认证Token(由Authentication实现类传递)
++
++ 4. AuthenticationManager认证成功，返回一个封装了用户权限信息
++    的Authentication对象，包含用户的上下文信息(角色列表)
++
++ 5. 将Authentication对象赋值给当前的SecurityContext，建立这个用户
++ 的安全上下文(SecurityContextHolder.getContext.setAuthentication())
++
++ 6. 当用户进行一些受到访问控制机制保护的操作，访问控制机制会依据
++    当前安全的上下文信息来检查这个操作所需的权限
++++++++++++++++++++++++++++++++++++++++++++++++++++++

授权(Authorization)
不同的用户组具有的权限是不同的，系统会为不同的用户组分配不同的角色。
每个角色对应一系列权限。
对Web资源的保护，最好使用过滤器(Filter)。
对方法调用的保护，最好使用AOP。

Spring Security基本组件

Spring Security提供了一系列基本组件，如spring-security-acl, spring-security-cas, spring-security-oauth2等。
具体这里就不详述了，读者可以查看官网的介绍。

1. Spring Cloud Security

Spring Cloud Security是用于构建微服务系统架构下的安全的应用程序和服务，它可以轻松实现基于微服务架构的统一的安全认证与授权。

Spring Cloud Security相对于Spring Security整合了Zuul，Feign，而且更加完美地整合了OAuth2.0。

2. OAuth2简介和基本概念

OAuth 2.0是用于授权的行业标准协议。

原理:
OAuth2是用户资源和第三方应用之间的一个中间层。
它把资源和第三方应用隔开，使得第三方应用无法直接访问资源，第三方应用要访问资源需要通过提供凭证(Token)来获得OAuth 2.0授权。

OAuth2的典型例子:

==============================================
== 微信公众号授权提醒
== 页面弹出一个提示框需要获取我们的个人信息
== 单击确定
== 第三方应用会获取我们在微信公众平台中的个人信息
==============================================

OAuth的关键角色:

Authorization Server(认证服务器)
它是授权服务的提供方。
它是用于认证用户的服务器，如果客户端认证通过，发放访问资源服务器的令牌。
Resource Owner(资源拥有者)
拥有该资源的最终用户，他有访问资源的账号密码。
Resource Server(资源服务器)
存放用户资源的服务器。
(注: 如果请求包含正确的访问令牌，可以访问资源)
Client(客户端)
访问资源的客户端。
它可以使任何第三方应用，与授权和资源服务提供方无关。

在用户授权第三方获取私有资源后，第三方通过获取到的token等信息通过授权服务器认证，然后去资源服务器获取资源。

3. OAuth2的运行流程及4种授权模式

OAuth2的运行流程

OAuth 2.0的运行流程.png

OAuth2的4种授权模式

密码模式

密码模式中，资源拥有者负责向客户端提供用户名和密码；
客户端根据用户名和密码箱认证服务器申请令牌，正确后认证服务器发放令牌。

客户端请求参数:

参数名	参数含义	是否必选	备注
grant_type	授权类型	必选	固定为"password"
username	用户名	必选
password	密码	必选
scope	权限范围	可选

缺点:
用户对客户端高度可信，必须把自己的密码发给客户端，存在被黑客窃取的隐患(不推荐)。

授权码模式

在授权码模式中，客户端是通过其后台服务器与认证服务器进行交互的。

授权码模式的运行流程:

OAuth 2.0的授权码模式.png

从以上图中我们可以看到客户端服务器和认证服务器需经过2次握手，客户端服务器才能拿到最终的访问和更新令牌。

第一次握手

客户端申请认证的参数:

参数名	参数含义	是否必选	备注
response_type	授权类型	必选	固定为"code"
client_id	客户端ID	必选
redirect_uri	重定向URI	必选
scope	申请的权限范围	可选
state	客户端的当前状态	建议填写	任意值，安全服务器会原封不动的返回这个值

服务器返回的参数:

参数名	参数含义	是否必选	备注
code	授权码	必选	该码的有效期应该很短(通常为几分钟)且只能使用一次
state	附加参数	可选	服务器返回一模一样的给客户端

第二次握手

客户端收到授权码以后，附上重定向URI，向认证服务器申请访问令牌。

客户端申请令牌的参数:

参数名	参数含义	是否必选	备注
grant_type	授权模式	必选	固定为"authorization_code"
code	上一步获得的授权码	必选
redirect_uri	重定向URI	必选	必须与上一步的URI保持一致
client_id	客户端ID	必选