这是我参与更文挑战的第3天，活动详情查看： 更文挑战
背景
目前在公司做一个spring cloud的微服务的项目，在权限验证方面发现了很多痛点：
- 多种登录方式糅合到了一起，代码不清晰
我们的项目支持web端sso登录，还支持企微端的oauth登录，还支持第三方机器访问的密钥登录。登录方式非常多，而缺少统一的管理。目前分了两个过滤器，其中一个过滤器专门解决密钥登录，另一个过滤器根据请求的header参数，判断是web端还是企微端，用了if else，代码结构不清晰，多种登录方式层次不合理。
- url访问混乱
我们是一个前后端分离的项目，对于不需要验证的url，是把它放在了apollo配置里，然后在过滤器里做判断，确定该url是否要经过验证。但是我们判断的方式比较简单粗暴，并未使用正则，仅仅是字符串匹配，而且我们的url是restful风格的请求，一个url可能既有GET方法，又有POST方法，面对此种方法，判断就失效了。
- 授权方面的设计不健全
我们的项目对授权模块的设计比较简单，首先是做了菜单权限的管理，根据用户角色来确定所能访问的菜单，对于后端接口，在代码里强耦合了角色判断，不够灵活。另外随着项目规模扩大，角色越来越多，仅仅通过角色来鉴权不能满足需求，需要更细粒度的权限控制。
方案调研
基于以上几个痛点，我开始了对Java权限方案的调研。
首先是shiro，官网地址：shiro.apache.org/index.html
Apache Shiro 是 Java 的一个安全框架， 提供了认证、授权、加密和会话管理等功能。目前，使用 Apache Shiro 的人越来越多，因为它相当简单，对比 Spring Security，可能没有 Spring Security 做的功能强大，但是在实际工作时可能并不需要那么复杂的东西，所以使用小而简单的 Shiro 就足够了。对于它俩到底哪个好，这个不必纠结，能更简单的解决项目问题就好了。
核心功能是这么几个：
- Authentication：身份认证 / 登录，验证用户是不是拥有相应的身份；
- Authorization：授权，即权限验证，验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限；
- Session Management：会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中；会话可以是普通 JavaSE 环境的，也可以是如 Web 环境的；
- Cryptography：加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储；
同时我也去调研了spring security，但是由于过于复杂被劝退了。。
对比shiro和spring security，结合网上的资料，我总结了以下几点异同：
相同点：
- 认证功能
- 授权功能
- 加密功能
- 会话管理
- 缓存支持
- rememberMe功能.......
不同点：
- Spring Security基于Spring开发，项目中如果使用Spring作为基础，配合Spring Security做权限更加方便，而Shiro需要和Spring进行整合开发
- Spring Security功能比Shiro更加丰富些，例如安全防护
- Spring Security社区资源比Shiro丰富
- Shiro的配置和使用比较简单，Spring Security上手复杂
- Shiro依赖性低，不需要任何框架和容器，可以独立运行，而Spring Security依赖于Spring容器
于是我首先采用shiro，对项目进行改造，但是发现shiro与spring结合需要很多代码改动，在测试的过程中发现了非常多的坑，这方面的网络资源也非常少，鱼龙混杂，而且大部分都是spring mvc项目，不是微服务的或者前后端分离的，导致我在测试的过程中不太顺利。还有一点就是shiro的鉴权是根据url做的，还是没有解决我的restful请求，同一个路由可能有多个方法（比如get,post）的问题。
我希望寻找到一种对当前代码侵入比较小，而且能支持restful接口和spring cloud，并且上手成本较低的权限框架来做我们的权限功能，经过调研，我找到了dromara社区的一款开源产品sureness。
国内有人在shiro的基础上进行了改造，开源了一款权限认证框架Sureness，这个一个面向REST API，无框架依赖，可以动态修改权限，多认证策略，更快速度，易用易扩展的认证鉴权框架。我把它作为下一阶段研究的目标。
sureness项目地址：