290

Spring Security には、アクセスを認可/制御するための権限GrantedAuthorityを取得するためのインターフェースなどの概念と実装があります。

createSubUsersやdeleteAccountsなどの許可された操作を管理者( role で)に許可したいと思い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つを区別する他の方法はありますか? または、サポートされていないため、独自に作成する必要がありますか?

4

4 に答える 4

435

GrantedAuthority を「許可」または「権利」と考えてください。これらの「許可」は、(通常) 文字列として (getAuthority()メソッドを使用して) 表現されます。これらの文字列により、アクセス許可を識別し、有権者に何かへのアクセスを許可するかどうかを決定させることができます。

ユーザーをセキュリティ コンテキストに入れることで、さまざまな GrantedAuthority (権限) をユーザーに付与できます。これは通常、必要な GrantedAuthorities を返す UserDetails 実装を返す独自の UserDetailsS​​ervice を実装することによって行います。

役割 (多くの例で使用されているように) は、役割が接頭辞 で始まる GrantedAuthority であるという命名規則を持つ単なる「許可」ROLE_です。もう何もありません。役割は単に GrantedAuthority - 「許可」 - 「権利」です。ROLE_Spring セキュリティでは、プレフィックスがデフォルトとして使用される RoleVoter など、プレフィックスを持つロールが特別に処理される場所がたくさんありROLE_ます。ROLE_これにより、プレフィックスなしでロール名を指定できます。Spring security 4 より前では、この「ロール」の特別な処理はあまり一貫して行われておらず、権限とロールはしばしば同じように扱われていました (たとえば、hasAuthority()hasRole()）。Spring Security 4 では、ロールの処理がより一貫しており、「ロール」 ( RoleVoter、式など) を処理するコードは常にプレフィックスをhasRole追加します。ROLE_Soは、プレフィックスが自動的に追加されるため、hasAuthority('ROLE_ADMIN')と同じことを意味します。詳細については、Spring Security 3 から 4への移行ガイドを参照してください。hasRole('ADMIN')ROLE_

ROLE_ただし、役割は特別な接頭辞が付いた単なる権限です。したがって、Spring セキュリティ 3@PreAuthorize("hasRole('ROLE_XYZ')")は と同じで@PreAuthorize("hasAuthority('ROLE_XYZ')")あり、Spring セキュリティ 4@PreAuthorize("hasRole('XYZ')")は と同じ@PreAuthorize("hasAuthority('ROLE_XYZ')")です。

ユースケースについて：

ユーザーには役割があり、役割は特定の操作を実行できます。

ユーザーがGrantedAuthorities属する役割と、役割が実行できる操作に行き着く可能性があります。GrantedAuthoritiesロールには接頭辞がROLE_あり、操作には接頭辞がありますOP_。操作権限の例はOP_DELETE_ACCOUNT、、などです。役割は、、、OP_CREATE_USERなどです。OP_RUN_BATCH_JOBROLE_ADMINROLE_USERROLE_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;
    }
}

ROLE_ADMINデータベースで作成する役割と操作の ID は、GrantedAuthority 表現 (例: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

UserDetailsS​​ervice は、すべてのロールとそれらのロールのすべての操作を収集し、返された UserDetails インスタンスでメソッド getAuthorities() によってそれらを利用できるようにします。

于 2013-10-23T12:55:49.623 に答える
12

私の知る限り、GrantedAuthority とロールは春のセキュリティと同じです。GrantedAuthority の getAuthority() 文字列は役割です (デフォルトの実装 SimpleGrantedAuthority による)。

あなたの場合、階層的な役割を使用できるかもしれません

<bean id="roleVoter" class="org.springframework.security.access.vote.RoleHierarchyVoter">
    <constructor-arg ref="roleHierarchy" />
</bean>
<bean id="roleHierarchy"
        class="org.springframework.security.access.hierarchicalroles.RoleHierarchyImpl">
    <property name="hierarchy">
        <value>
            ROLE_ADMIN > ROLE_createSubUsers
            ROLE_ADMIN > ROLE_deleteAccounts 
            ROLE_USER > ROLE_viewAccounts
        </value>
    </property>
</bean>

あなたが探している正確なソルではありませんが、お役に立てば幸いです

編集：コメントに返信

役割は、Spring-Security の許可のようなものです。intercept-url を hasRole とともに使用すると、どのロール/パーミッションに対してどの操作を許可するかを非常にきめ細かく制御できます。

アプリケーションで処理する方法は、view_account、delete_account、add_account などの操作 (または残りの URL) ごとにパーミッション (つまりロール) を定義することです。次に、admin、guest_user、normal_user などの各ユーザーの論理プロファイルを作成します。プロファイルは、Spring-Security から独立した、パーミッションの単なる論理グループです。新しいユーザーが追加されると、そのユーザーにプロファイルが割り当てられます (すべての許可された権限を持ちます)。これで、ユーザーが何らかのアクションを実行しようとすると、そのアクションの権限/ロールがユーザーの grantAuthorities に対してチェックされます。

また、defaultn RoleVoter はプレフィックス ROLE_ を使用するため、ROLE_ で始まる権限はロールと見なされます。ロール ボッターでカスタム RolePrefix を使用し、Spring セキュリティで使用することで、このデフォルトの動作を変更できます。

于 2013-10-23T09:57:47.770 に答える