在介绍Spring Cloud Security之前，我们先要介绍一下Spring Security。
成都创新互联公司专注于企业成都营销网站建设、网站重做改版、西湖网站定制设计、自适应品牌网站建设、HTML5、商城系统网站开发、集团公司官网建设、外贸网站制作、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为西湖等各大城市提供网站开发制作服务。
Spring Security是一套提供了完整的声明式安全访问控制的解决方案。
Spring Security是基于Spring AOP和Servlet过滤器的，它只能服务基于Spring的应用程序。
除常规认证和授权外，它还提供 ACL，LDAP，JAAS，CAS 等高级安全特性以满足复杂环境中的安全需求。
(注:在Spring Security中，Authority和Permission是两个完全独立的概念，两者没有必然的联系。它们之前需要通过配置进行关联。)
安全方案的实现通常分为 认证(Authentication) 和 授权(Authorization) 两部分。
使用者可以使一个 用户 ， 设备 ，和可以在应用程序中执行某种操作的 其它系统 。
认证一般通过用户名和密码的正确性校验来完成通过或拒绝。
Spring Security支持的主流认证如下:
Spring Security进行认证的步骤:
++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ 1. 用户使用用户名和密码登陆
++
++ 2. 过滤器(UsernamePasswordAuthenticationFilter)获取到用户名
++ 和密码，将它们封装成Authentication
++
++ 3. AuthenticationManager认证Token(由Authentication实现类传递)
++
++ 4. AuthenticationManager认证成功，返回一个封装了用户权限信息
++ 的Authentication对象，包含用户的上下文信息(角色列表)
++
++ 5. 将Authentication对象赋值给当前的SecurityContext，建立这个用户
++ 的安全上下文( SecurityContextHolder.getContext.setAuthentication() )
++
++ 6. 当用户进行一些受到访问控制机制保护的操作，访问控制机制会依据
++ 当前安全的上下文信息来检查这个操作所需的权限
++++++++++++++++++++++++++++++++++++++++++++++++++++++
Spring Security提供了一系列基本组件，如spring-security-acl, spring-security-cas, spring-security-oauth2等。
具体这里就不详述了，读者可以查看官网的介绍。
Spring Cloud Security是用于构建微服务系统架构下的安全的应用程序和服务，它可以轻松实现基于微服务架构的统一的安全认证与授权。
Spring Cloud Security相对于Spring Security整合了Zuul，Feign，而且更加完美地整合了OAuth2.0。
OAuth 2.0是用于授权的行业标准协议。
原理:
OAuth2是用户资源和第三方应用之间的一个中间层。
它把资源和第三方应用隔开，使得第三方应用无法直接访问资源，第三方应用要访问资源需要通过提供 凭证(Token) 来获得OAuth 2.0授权。
OAuth2的典型例子:
==============================================
== 微信公众号授权提醒
== 页面弹出一个提示框需要获取我们的个人信息
== 单击确定
== 第三方应用会获取我们在微信公众平台中的个人信息
==============================================
OAuth的关键角色:
在用户授权第三方获取私有资源后，第三方通过获取到的token等信息通过授权服务器认证，然后去资源服务器获取资源。
密码模式中，资源拥有者负责向客户端提供用户名和密码；
客户端根据用户名和密码箱认证服务器申请令牌，正确后认证服务器发放令牌。
客户端请求参数:
缺点:
用户对客户端高度可信，必须把自己的密码发给客户端，存在被黑客窃取的隐患(不推荐)。
在授权码模式中，客户端是通过其后台服务器与认证服务器进行交互的。
授权码模式的运行流程:
从以上图中我们可以看到客户端服务器和认证服务器需经过2次握手，客户端服务器才能拿到最终的访问和更新令牌。
客户端申请认证的参数:
服务器返回的参数:
客户端收到授权码以后，附上重定向URI，向认证服务器申请访问令牌。
客户端申请令牌的参数:
服务器返回的参数:
如果访问令牌已经过期，可以使用更新令牌申请一个新的访问令牌。
通过更新令牌申请访问令牌的参数:
这两种模式不常用，因此在这里就不多叙述了。
当前微服务拆分已经成为趋势，大部分公司都对其软件产品做微服务架构调整。对产品先进行业务、模块拆分，大部分也进行前后端分离的业务调整。
服务拆分不能避免的问题那就是：请求跨域问题，针对跨域问题，先前专门做了资料整理
针对这些问题可以查看 《SpringCloud 中跨域资源共享(cors)到底解决了什么？》
还有解决跨域问题开启跨域资源共享(cors)后。
针对这系列问题可查看 《微服务开启跨域资源共享(cors)后，真的会被攻击么？》
阅读CorsConfiguration源码可以发现在CORS 配置中定义
基础CorsConfiguration的定义可自定义跨域配置信息CorsConfig 实现 CorsConfigurationSource
注意在配置时候引用注解@ConfigurationProperties为什么这里使用单一注解并没有直接注入到Bean容器中？针对这问题的分析可阅读 《@
EnableConfigurationProperties 的工作原理》
配置信息CorsConfig基础信息后实现getCorsConfiguration方法
定义Web线程拦截器为了，用于统一处理线程变量！同一个服务肯定不会出现跨域问题。只有不同服务之间调用才会出现此类问题。记得先前在分析 《怎样在输出日志中加入traceId 进行链路追踪》 和 《如何保证各个微服务之间调用的安全性?****》 对个服务之间RPC调用请求线程变量传递问题。
本文主要微服务之间跨域问题的解决方案，至于为什么会存在跨域问题和跨域问题开启后会有哪些攻击模式
在上几篇文章中已逐步分析，解决微服务跨域问题主要分三步走
单体应用场景下只需要考虑从外部进来的请求是不是安全的，里面涉及到的服务之间相互的调用是不需要我们考虑安全的，但是在微服务场景下从订单去调用物流的时候，是需要跨网络，从一个进程进入另一个进程，所以需要考虑 服务之间的通信安全
对于一个服务来说，可观测性是一个很重要的指标，可观测性包含了三个方面的意义
真正的人
可能是一个 Web App 或者手机 App，用户会直接访问这些应用
存储资源的服务器
随着互联网的不断发展，我们在进行服务器开发组织架构上通常会采用分布式架构方法来进行设计。今天，我们就一起来了解一下，微服务架构都有哪些特点。
InfoQ:你近的QConSanFrancisco提出的一个关键前提是，组织如果要从单体大型应用转变为基于微服务的体系结构就得要打破它们的庞大的整体流程。你能再进一步解释一下吗?
RafaelSchloming:对于转变为微服务本身，人们实际上并不怎么关心，他们真正关心的是提升特性的完成速度。为了提升特征的完成速度就必需做出改变，而微服务只是这种改变所产生的一个附属物罢了。
对于组织来说非常常见的一种情况是，当他们发展到一个临界点，增加再多的人也不会提升特性的完成速度。当这种情况发生时，通常是因为组织用于产出特性的结构和/或过程成为了瓶颈，而不是人员的数量。
当一个组织遇到这种障碍，开始调查为什么这些特性似乎花费的时间远远超出了合理的资源，答案往往是，每个特性都需要太多不同团队的协调。
这会发生在两个不同的维度上。你的人员可以按职能划分为团队：产品与开发、质保与运维。你的人员也可以按组件划分:例如，前端与领域模型、搜索索引和消息通知。当单个特性需要跨多个不同的团队进行协调时，交付特性的控制因素是不同团队之间的沟通速度和效率。像这样组织结构的组织实际上是被一个庞大的整体过程所阻碍的，这个过程要求每个特性(在某种程度上)要有许多许多的组织来理解它。
InfoQ:那么如何解决这个问题呢?
Schloming:为了把很多人用在一个问题上，你需要把他们分成团队，因为人们不能在非常大的群体中有效地沟通。你这么做的时候，其实就是在做出一系列的权衡。你所营造的是每支团队内部具有高保真的沟通和协调，而团队之间是低保真和相对较差的协调。
为改进一个组织内的特性完成速度，您可以将你的人组织成独立的、跨职能的、自给自足的特性团队，可以从头到尾自主掌控一个完整的特性。这将以两种方式提高特性的完成速度。先，由于不同的职能(产品、开发、质保和运维)都圈定于一个特性内，你就可以自定义该特性区域的流程了，例如，IT培训分享对于一个没有人正在使用的新特性，你的流程就不需要优先考虑其稳定性了。其次，由于该特性所需的所有组件都由同一个团队拥有，因此，要想赶紧推出一个特性，就可以进行更快速有效的沟通和协调。
