Spring Security源码解析

      现在流行的通用授权框架有apache的shiro和Spring家族的Spring Security,在涉及今天的微服务鉴权时,需要利用我们的授权框架搭建自己的鉴权服务,今天总理了Spring Security,便于在微服务架构体系中拓展.对于shiro之前用过,单体应用使用起来还是很灵活轻便的.

#################################################################

Spring Security是通过AccessDecisionManager进行授权管理的.就先从他开打.

在Spring Security访问决策管理中,我们能看到基于实现AccessDecisionManager ,Spring Security内部实现这个接口的有4个类,逐个查看:

AbstractAccessDecisionManager:

这个抽象类从图可以看到实际下面被继承了3个类,分别是3种不同的投票策略.这里不一一说明了,有兴趣的可以翻阅源码.

3种不同的策略分别是:

AffirmativeBased的策略：

• 只要有投通过（ACCESS_GRANTED）票，则直接判为通过。
• 如果没有投通过票且反对（ACCESS_DENIED）票在两个及其以上的，则直接判为不通过。

UnanimousBased的策略：

• 无论多少投票者投了多少通过（ACCESS_GRANTED）票，只要有反对票（ACCESS_DENIED），那都判为不通过。
• 如果没有反对票且有投票者投了通过票，那么就判为通过。

ConsensusBased的策略：

• 通过的票数大于反对的票数则判为通过。
• 通过的票数小于反对的票数则判为不通过。
• 通过的票数和反对的票数相等，则可根据配置allowIfEqualGrantedDeniedDecisions（默认为true）进行判断是否通过。

###################################################################

源码中可以看出这三种不同的策略都用到了AccessDecisionVoter接口(访问决策投票器),接口定义了投票方法

投票方法Spring Security内部实现了2种,如图

AuthenticatedVoter:先判定用户是否通过登录认证，没有投反对票,在内部根据用户登录包含的角色信息获取用户实际的权限和当前的请求需要的角色匹配

RoleVoter:只处理ROLE_开头的配置角色参数进行投票（可通过配置rolePrefix的值进行改变）

上面已认证投票方法中需要注意的是:

当前的请求需要的角色和用户登录包含的角色信息获取用户实际的权限这2个核心参数Spring Scerity是如何管理的呢?

我们接着往下走读,查看Spring Scerity core源码

这里userdetails目录全是是Spring Security 管理的用户信息.

这里不一一描述了,需要深入了解可以查看官方源码,主要实现思路如下: