Spring Security的角色roles是什么？这篇文章从源码出发，详细解析了Spring Security的角色roles，感兴趣的小伙伴们可以参考借鉴，希望对大家有所帮助。 
我们在进行角色权限控制设计时，一般包括账户（users）、角色（roles）、权限（authorities）这三部分。
1）一个账户一般对应一个或多个角色；
2）一个角色对应多个权限（authorities），反过来一个权限也对应多个角色；
3）账户只和角色关联，通过角色，间接和权限产生关系；
4）角色不是固定死的，是能够动态创建的，每个角色具有的权限能够灵活的进行调整；
5）在系统完成详细设计后，有哪些权限就已经确定下来，权限的层级结构和数量、与账户和角色没半点关系。  
基于以上的说明，我们从源码的角度来说明Spring Security的账户、角色和权限是怎么一回事。
Spring Security工作流程：通过登录的账户，找到该账户对应的角色/权限，并把自定义的权限集合转换为Spring Security认可的权限集合List，然后结合自定义的账号、密码，和新权限集合这三个参数，创建一个Spring Security认可的账号实例，再然后根据自定义的鉴权规则，进行权限控制。  
这里面如何创建账号、角色、权限，实现用户认证、进行鉴权的细节就不讲了，因为这个不是本篇文章的重点，有兴趣的读者可以看我的视频介绍：https://edu.51cto.com/course/21185.html ，里面有详细的如何进行实战型的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的角色有进一步的了解吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读。