blocks|key|1687015|text|理解这些概念之间关系的另一种方法是将角色解释为权威的容器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1687016|权限是针对特定操作的细粒度权限，有时还带有特定的数据范围或上下文。例如，读、写、管理可以表示对给定信息范围的各种级别的许可。|1687017|此外，权限在请求的处理流程中执行得很深，而角色在到达控制器之前通过请求过滤方式进行过滤。最佳实践规定了在业务层中通过Controller实现授权实施。|1687018|另一方面，角色是一组权限的粗粒度表示。ROLE_READER将只具有读取或查看权限，而ROLE_EDITOR将同时具有读取和写入权限。角色主要用于在请求处理的外围的第一次筛选，例如http。...+.antMatcher(...).hasRole(ROLE_MANAGER)|1687019|在请求的处理流程中深入实施的授权允许更细粒度的权限应用。例如，用户可能对第一级资源具有读写权限，但仅具有对子资源的读写权限。拥有ROLE_READER会限制他编辑第一级资源的权限，因为他需要写权限才能编辑这个资源，但是@PreAuthorize拦截器可以阻止他编辑子资源的试探性权限。|1687020|杰克|1687021|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Another way to understand the relationship between these concepts is to interpret a ROLE as a container of Authorities.

Authorities are fine-grained permissions targeting a specific action coupled sometimes with specific data scope or context. For instance, Read, Write, Manage, can represent various levels of permissions to a given scope of information. 

Also, authorities are enforced deep in the processing flow of a request while ROLE are filtered by request filter way before reaching the Controller. Best practices prescribe implementing the authorities enforcement past the Controller in the business layer.

On the other hand, ROLES are coarse grained representation of an set of permissions. A ROLE_READER would only have Read or View authority while a ROLE_EDITOR would have both Read and Write. Roles are mainly used for a first screening at the outskirt of the request processing such as
http.
 ...
 .antMatcher(...).hasRole(ROLE_MANAGER) 

The Authorities being enforced deep in the request's process flow allows a finer grained application of the permission. For instance, a user may have Read Write permission to first level a resource but only Read to a sub-resource. Having a ROLE_READER would restrain his right to edit the first level resource as he needs the Write permission to edit this resource but a @PreAuthorize interceptor could block his tentative to edit the sub-resource.

Jake

blocks|key|1900558|text|正如其他人所提到的，我认为角色是更细粒度权限的容器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1900559|尽管我发现层级角色实现缺乏对这些细粒度权限的精细控制。|1900560|因此，我创建了一个库来管理这些关系，并在安全上下文中按照已授予的权限注入权限。|1900561|我可能在应用程序中有一组权限，比如创建、读取、更新、删除，然后与用户的角色相关联。|1900562|或更具体的权限，如READ_POST、READ_PUBLISHED_POST、CREATE_POST、PUBLISH_POST|1900563|这些权限是相对静态的，但角色与它们的关系可能是动态的。|1900564|示例：|1900565|@Autowired+
RolePermissionsRepository+repository;

public+void+setup(){
++String+roleName+=+"ROLE_ADMIN";
++List<String>+permissions+=+new+ArrayList<String>();
++permissions.add("CREATE");
++permissions.add("READ");
++permissions.add("UPDATE");
++permissions.add("DELETE");
++repository.save(new+RolePermissions(roleName,+permissions));
}|code-block|syntax|javascript|1900566|您可以创建API来管理这些权限与角色的关系。|1900567|我不想复制/粘贴另一个答案，所以这里有一个关于SO的更完整解释的链接。|1900568|https://stackoverflow.com/a/60251931/1308685|offset|length|1900569|为了重用我的实现，我创建了一个repo。请随时贡献自己的力量！|1900570|https://github.com/savantly-net/spring-role-permissions|1900571|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|0|0|0|0|0|0|0|0|0|18|0|0|0|0|1J|1|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1F|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1G|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1H|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1I|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1J|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|1K|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1L|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1M|8|@]|9|@$Y|1N|Z|1O|1|1P]]|A|$]]|$1|10|3|11|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1R|8|@]|9|@$Y|1S|Z|1T|1|1U]]|A|$]]|$1|14|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|X]]|1B|$5|17|18|19|A|$1A|13]]]]

Like others have mentioned, I think of roles as containers for more granular permissions. 

Although I found the Hierarchy Role implementation to be lacking fine control of these granular permission. 
So I created a library to manage the relationships and inject the permissions as granted authorities in the security context. 

I may have a set of permissions in the app, something like CREATE, READ, UPDATE, DELETE, that are then associated with the user's Role. 

Or more specific permissions like READ_POST, READ_PUBLISHED_POST, CREATE_POST, PUBLISH_POST 

These permissions are relatively static, but the relationship of roles to them may be dynamic.

Example - 

<pre><code>@Autowired 
RolePermissionsRepository repository;

public void setup(){
 String roleName = "ROLE_ADMIN";
 List&lt;String&gt; permissions = new ArrayList&lt;String&gt;();
 permissions.add("CREATE");
 permissions.add("READ");
 permissions.add("UPDATE");
 permissions.add("DELETE");
 repository.save(new RolePermissions(roleName, permissions));
}
</code></pre>

You may create APIs to manage the relationship of these permissions to a role.

I don't want to copy/paste another answer, so here's the link to a more complete explanation on SO. 
<a href="https://stackoverflow.com/a/60251931/1308685">https://stackoverflow.com/a/60251931/1308685</a>

To re-use my implementation, I created a repo. Please feel free to contribute! 
<a href="https://github.com/savantly-net/spring-role-permissions" rel="noreferrer">https://github.com/savantly-net/spring-role-permissions</a>

There are concepts and implementations in Spring Security, such as the <code>GrantedAuthority</code> interface to get an authority to authorize/control an access. 

I would like that to permissible operations, such as createSubUsers, or deleteAccounts, which I would allow to an admin (with role <code>ROLE_ADMIN</code>). 

I am getting confused as the tutorials/demos I see online. I try to connect what I read, but I think we treat the two interchangeably.

I see <code>hasRole</code> consuming a <code>GrantedAuthority</code> string? I most definitely am doing it wrong in understanding. What are these conceptually in Spring Security? 

How do I store the role of a user, separate from the authorities for that role?

I'm also looking at the <code>org.springframework.security.core.userdetails.UserDetails</code> interface which is used in the authentication-provider referenced DAO, which consumes a <code>User</code> (note last GrantedAuthority):

<pre><code>public User(String username, 
 String password, 
 boolean enabled, 
 boolean accountNonExpired,
 boolean credentialsNonExpired, 
 boolean accountNonLocked, 
 Collection&lt;? extends GrantedAuthority&gt; authorities)
</code></pre>

Or is there any other way to differentiate the other two? Or is it not supported and we have to make our own?

Difference between Role and GrantedAuthority in Spring Security

身份验证

容器

Spring Security中有一些概念和实现，比如用来获得授权/控制访问权限的GrantedAuthority接口。我希望这是允许的操作，如createSubUsers或deleteAccounts，我会允许管理员(具有ROLE_ADMIN角色)。我对我在网上看到的教程/演示感到困惑。我试着将我读到的东西联系起来，...

问Spring Security中Role和GrantedAuthority的区别
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Spring Security中Role和GrantedAuthority的区别EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Spring Security中Role和GrantedAuthority的区别
EN