spring cloud security做统一认证中心

说说在使用spring cloud security微服务统一权限+nuxtjs做前后端分离时，的一些经验吧

在谈之前，我先把spring cloud security的原理罗嗦一遍

Spring cloud security 是包含了spring security 和spring security oauth，这可以算是两个框架。Spring security实现了一组过滤器链，我直接把之前写的粘过来

其实spring security中过滤器有2种（我个人分的）

1. 普通过滤器，就是简单的filter
2. Spring安全过滤器，它也是一个filter，但是并没有注册在应用服务器的Filter链中

我为什么这么分呢，也是有理由的，因为，普通过滤器在执行的时候走的是tomcat的ApplicationFilterChain的实现。而spring 安全过滤器实现的是VirtualFilterChain，这是spring对FilterChain接口的实现。而所谓的spring安全过滤器其实都封装在这个VirtualFilterChain内部，以list数组的成员变量存放，调用时，也使用了责任链的设计模式调用。

那这还是有问题的，比如DelegatingFilterProxy的作用和FilterChainProxy的作用是什么

为什么搞两个代理出来干吗？

其实这个也是别有用意，DelegatingFilterProxy其实就是一个Filter的实现类。他在spring security中是安全过滤器的入口点。当请求到达这个过滤器的时候他会把请求转交给FilterChainProxy。所有的安全过滤器由FilterChainProxy统一调度管理。

使用DelegatingFilterProxy的作用可以保证晚期生成FilterChainProxy，什么叫晚期生成，就是spring在启动的时候就把这个DelegatingFIlterProxy所要代理的Filter的名称固定了，而此时，这个Filter并不存在，由我们后期开发和配置，方便增减过滤器，这也是spring 在代理的时候使用bean name去代理的原因。

 

上面啰嗦了一大堆也没有谈spring security的核心原理，现在开始

其实，所谓的安全，就是保证我们的接口在我们的控制的情况下被访问。就是，谁能访问，谁不能访问。很简单的一个问题，但是要牵扯出几个基本概念。

你是谁？你能干什么？

用正规一点的话说，叫认证和访问控制

那么spring security是如何认证的呢？

当请求到达受保护的接口之前，一定会经过FilterSecurityInterceptor。FilterSecurityInterceptor会从当前请求中获取SecurityContext，这个SecurityContext是从当前线程中拿到的。那么当前线程中怎么就有了呢，是SecurityContextPersistenceFilter放进去的。SecurityContext中包含了当前登录用户的认证信息。如果当前用户没有登录，会拿到一个匿名的用户。然后FilterSecurityInterceptor根据配置信息判断，当前接口是否允许匿名访问，如果允许，则会调用api。如果拒绝，则抛出相应的异常，比如UnAuthenticationException

，类似的异常还有DenyAccessException，访问拒绝，就是权限不够。这些异常会被ExceptionTranslatorFilter所捕获。然后根据异常信息，做请求转发。如果未认证则跳转到登录页面。如果访问拒绝，则跳转到错误页面。

当跳转到登录面时，用户点击登录按钮时，请求被认证过滤器所拦截。这里的认证过滤器是一个抽象的认证过滤器，具体的实现可以是，用户名密码认证。手机验证码认证。第三方认证如微信，qq登录。

授权其实也讲了，也是由FilterSecurityInterceptor处理，判断当前用户是否有相应的权限。其实在真正的实现起来是要和rbac结合的。系统安全和rbac模型是两回事。

Spring security的简单流程也就是这样。

 

下面说说spring cloud security，这就是在spring security的基础之上加了一个对oauth2 认证的实现。Oauth2认证主要有2种

1. 授权码模式的认证
2. 密码模式的认证（一般在app环境下使用）

我这里讲基于授权码模式的认证时，我所遇到的坑。

《未完》