Spring Security には、アクセスを承認/制御するための権限GrantedAuthority
を取得するためのインターフェースなどの概念と実装があります。
私は、 createSubUsersやdeleteAccountsなどの操作を許可し、それを管理者(ロールを持つ)に許可したいと思いますROLE_ADMIN
。
オンラインで見るチュートリアルやデモを見て混乱しています。読んだ内容を関連付けようとしていますが、この 2 つを同じものとして扱っているように思います。
hasRole
文字列を消費するのですねGrantedAuthority
。私の理解は間違いなく間違っています。Spring Security では、これらは概念的にどのようなものですか?
ユーザーの役割を、その役割の権限とは別に保存するにはどうすればよいですか?
org.springframework.security.core.userdetails.UserDetails
また、認証プロバイダーが参照する DAO で使用されるインターフェースも調べています。これはUser
、(最後の GrantedAuthority に注意) を消費します。
public User(String username,
String password,
boolean enabled,
boolean accountNonExpired,
boolean credentialsNonExpired,
boolean accountNonLocked,
Collection<? extends GrantedAuthority> authorities)
それとも、他の 2 つを区別する他の方法はありますか? それとも、サポートされていないので、独自に作成する必要がありますか?
ベストアンサー1
GrantedAuthority は「許可」または「権利」であると考えてください。これらの「許可」は (通常) 文字列として表現されます ( メソッドを使用getAuthority()
)。これらの文字列によって許可を識別し、投票者が何かへのアクセスを許可するかどうかを決定できるようになります。
セキュリティ コンテキストに配置することで、ユーザーにさまざまな GrantedAuthority (権限) を付与できます。通常、これを行うには、必要な GrantedAuthorities を返す UserDetails 実装を返す独自の UserDetailsService を実装します。
ロール (多くの例で使用されているように) は、ロールがプレフィックスで始まる GrantedAuthority であるという命名規則を持つ単なる「権限」ですROLE_
。それ以上のものではありません。ロールは、単に GrantedAuthority、つまり「権限」であり、「権利」です。Spring Security では、プレフィックス付きのロールが特別に処理される場所が多数あります。たとえば、プレフィックスがデフォルトとして使用されるROLE_
RoleVoter などです。これにより、プレフィックスなしでロール名を提供できます。Spring Security 4 より前では、この「ロール」の特別な処理はあまり一貫して行われておらず、権限とロールは同じように扱われることが多かったです (たとえば、メソッドの実装で確認できます)。ROLE_
ROLE_
hasAuthority()
セキュリティ式ルート- は単に を呼び出しますhasRole()
。Spring Security 4 では、ロールの扱いがより一貫しており、「ロール」を扱うコード ( RoleVoter
、hasRole
式など) は常にROLE_
プレフィックスを追加します。プレフィックスが自動的に追加されるためhasAuthority('ROLE_ADMIN')
、 は と同じ意味になります。Spring Security 3 から 4 を参照してください。hasRole('ADMIN')
ROLE_
移行ガイド詳細については。
ただし、ロールは特別なROLE_
プレフィックスを持つ権限にすぎません。したがって、Spring Security 3 では は@PreAuthorize("hasRole('ROLE_XYZ')")
と同じであり@PreAuthorize("hasAuthority('ROLE_XYZ')")
、Spring Security 4 では は@PreAuthorize("hasRole('XYZ')")
と同じです@PreAuthorize("hasAuthority('ROLE_XYZ')")
。
ユースケースに関して:
ユーザーには役割があり、役割によって特定の操作を実行できます。
GrantedAuthorities
ユーザーが属するロールとロールが実行できる操作については、のようになります。GrantedAuthorities
ロールの にはプレフィックスが付きROLE_
、操作にはプレフィックスが付きますOP_
。操作権限の例としてはOP_DELETE_ACCOUNT
、OP_CREATE_USER
、などがあります。ロールには、、などOP_RUN_BATCH_JOB
があります。ROLE_ADMIN
ROLE_USER
ROLE_OWNER
最終的には、エンティティをGrantedAuthority
次の (疑似コード) 例のように実装することになります。
@Entity
class Role implements GrantedAuthority {
@Id
private String id;
@ManyToMany
private final List<Operation> allowedOperations = new ArrayList<>();
@Override
public String getAuthority() {
return id;
}
public Collection<GrantedAuthority> getAllowedOperations() {
return allowedOperations;
}
}
@Entity
class User {
@Id
private String id;
@ManyToMany
private final List<Role> roles = new ArrayList<>();
public Collection<Role> getRoles() {
return roles;
}
}
@Entity
class Operation implements GrantedAuthority {
@Id
private String id;
@Override
public String getAuthority() {
return id;
}
}
データベースに作成するロールと操作の ID は、 GrantedAuthority 表現 ( など) になります。ROLE_ADMIN
ユーザーOP_DELETE_ACCOUNT
が認証されると、そのすべてのロールのすべての GrantedAuthorities と対応する操作が UserDetails.getAuthorities() メソッドから返されることを確認します。
例: ID を持つ管理者ロールには、ROLE_ADMIN
操作OP_DELETE_ACCOUNT
、OP_READ_ACCOUNT
がOP_RUN_BATCH_JOB
割り当てられています。ID を持つユーザー ロールには、ROLE_USER
操作 が割り当てられていますOP_READ_ACCOUNT
。
管理者がログインすると、セキュリティコンテキストには GrantedAuthorities: ROLE_ADMIN
、OP_DELETE_ACCOUNT
、OP_READ_ACCOUNT
が含まれます。OP_RUN_BATCH_JOB
ユーザーがログに記録すると、次のようになります: ROLE_USER
、OP_READ_ACCOUNT
UserDetailsService は、すべてのロールとそれらのロールのすべての操作を収集し、返された UserDetails インスタンスのメソッド getAuthorities() で使用できるようにします。