看源码，重新审视Spring Security中的角色（roles）是怎么回事

在网上看见不少的博客、技术文章，发现大家对于Spring Security中的角色（roles）存在较大的误解，最大的误解就是没有搞清楚其中角色和权限的差别（好多人在学习Spring Security时，是不是对于到底加不加“ROLE_”前缀有点犯蒙），有时候觉得在进行权限控制时用权限名称或者用角色名称都差不多（大家这种感觉是对的，如果简单应用确实差不太多）。
        我们在进行角色权限控制设计时，一般包括账户（users）、角色（roles）、权限（authorities）这三部分。
                1）一个账户一般对应一个或多个角色；
                2）一个角色对应多个权限（authorities），反过来一个权限也对应多个角色；
                3）账户只和角色关联，通过角色，间接和权限产生关系；
                4）角色不是固定死的，是能够动态创建的，每个角色具有的权限能够灵活的进行调整；
                5）在系统完成详细设计后，有哪些权限就已经确定下来，权限的层级结构和数量、与账户和角色没半点关系。
        基于以上的说明，我们从源码的角度来说明Spring Security的账户、角色和权限是怎么一回事。
        Spring Security工作流程：通过登录的账户，找到该账户对应的角色/权限，并把自定义的权限集合转换为Spring Security认可的权限集合List<GrantedAuthority>，然后结合自定义的账号、密码，和新权限集合这三个参数，创建一个Spring Security认可的账号实例，再然后根据自定义的鉴权规则，进行权限控制。
        这里面如何创建账号、角色、权限，实现用户认证、进行鉴权的细节就不讲了，因为这个不是本篇文章的重点，有兴趣的读者可以看我的视频介绍：https://edu.51cto.com/sd/091c7 ，里面有详细的如何进行实战型的Spring Security角色权限控制模块的开发。
        重点来了，通过应用角色权限控制的应用，看Spring Security如何利用角色和权限的
四种鉴权的方式：
        hasRole(String role)
        hasAnyRole(String... roles)
        hasAuthority(String authority)
        hasAnyAuthority(String... authorities)
在源码类SecurityExpressionRoot.java中，我们看看这四种方式的实现形式：

大家从上面的图看出什么端倪没有？
        hasRole(String role) --》 hasAnyRole(String... roles) --》hasAnyAuthorityName
        hasAuthority(String authority) --》hasAnyAuthority(String... authorities) --》hasAnyAuthorityName
不管是基于角色，还是基于权限，最后鉴权都落实到hasAnyAuthorityName这个方法上。

follow me，我们继续往下刨根，看看hasAnyAuthorityName这个方法里面有些什么，注意上面代码中的调用hasAnyAuthorityName时，传递的参数，一个是

另外一个是

对应的都是一个实现方法。

从hasAnyAuthorityName这个方法中，我们可以知道，这是把传进去的一个或多个角色/权限，在登录用户具有的权限中进行查找

这里面的大家看到了吧，角色和权限是混合在一起进行鉴权的（题外话，大家看大神们写的代码，注意到其中的var5、var6、var4，这是搞什么？严重不符合命名规范啊）。
那么Spring Security是如何区分集合中的是权限、还是角色呢，我们继续抽丝剥茧，看看该方法中的getRoleWithDefaultPrefix(prefix, role)方法。

看上面的代码清晰明了了吧，说明如下：
        如果传进去的角色名称/权限名称为null，直接返回null；
        如果传进去的角色名称/权限名称不为null，则判断defaultRolePrefix前缀这个参数是否为空和其长度，如果不为空，且长度不为0，则传进的参数为角色名称，那么继续判断其是否是以“ROLE”开始，如果不是，则在名称前添加前缀“ROLE”，并返回新的名称；
        如果不是以上情况，即参数是权限名称或者带有“ROLE_”前缀的角色名称，直接返回传进去的字符串参数。

看了以上的部分源码解析，我们可以得出什么结论呢（以角色、权限存放在数据库为例）：
        1、原生的角色和权限并没有本质的区别，在鉴权时走的是完全相同的一个通道；
        2、在进行权限控制时，角色可加可不加“ROLE”前缀，但在数据库中定义时，角色名称一定要添加“ROLE”前缀；
        3、角色与权限之间并没有建立映射关系，角色是角色、权限是权限，这与我们实际应用中对角色的要求有很大出入；
        4、实际应用中的角色被固化到代码中，也与实际要求不符，实际应用中，权限作为子节点可以写死，而角色作为全部或者部分权限的集合应该可以灵活调整；
        5、不管是角色鉴权，还是权限鉴权，都只是以角色/权限的名称作为判断依据，所以权限的名称要唯一。
        另外，从Spring Security的源码分析中可以发现，我们还可以通过RoleHierarchy进行角色的继承（默认admin登录只能访问/admin，访问不了/user；而user登录只能访问/user），但在实际项目中，最主要强调的是角色的灵活性，而不是继承性。
        所以，对角色的管理、角色和权限的映射关系，都需要我们自己来实现。
        好了，对Spring Security角色（roles）的分析就到此结束，从以上分析看，我们如果要把Spring Security应用于实际项目中，还需要做不少工作，至于如何简洁高效的利用Spring Security进行角色权限控制模块的开发，有兴趣的读者可以参见视频：https://edu.51cto.com/sd/091c7 ，希望对大家有有所帮助。