标签：roles 角色 Spring 源码 Security 权限 鉴权 String
在网上看见不少的博客、技术文章，发现大家对于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_”前缀的角色名称，直接返回传进去的字符串参数。
看了以上Spring Security的部分源码解析，我们可以得出什么结论呢（以角色、权限存放在数据库为例）：
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 ，希望对大家有有所帮助。
标签：roles,角色,Spring,源码,Security,权限,鉴权,String 来源： https://blog.51cto.com/3058076/2467692
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。