n要素認証にJava構成を使用する [closed] 質問する

Question

まず、使用しているインターフェースと、認証プロセスでそれらが果たす役割について説明します。

Authentication- ユーザの認証結果を表します。そのユーザに付与された権限と、ユーザについて必要となる可能性のある追加の詳細を保持します。フレームワークにはどのような詳細が必要になるかを知る方法がないため、認証オブジェクトにはgetDetails任意のオブジェクトを返すことができるメソッド
AuthenticationProvider- 何らかの方法でオブジェクトを作成できるオブジェクトAuthentication。再利用性を高めるために、一部の（またはほとんどの）アプリケーションでは、各アプリケーションが特定のユーザーの詳細を必要とする可能性があるため、AuthenticationProviderオブジェクトにユーザーの詳細を設定することを控えていますAuthentication。代わりに、ユーザーの詳細を解決するプロセスを設定可能なメソッドに委任します。UserDetailsService
UserDetailsService- 1つの戦略アプリケーションに必要なユーザーの詳細を取得します。

したがって、カスタムを作成する場合、AuthenticationProviderを必要とする方法で実装する必要すらない場合がありUserDetailsServiceます。決定はあなた次第であり、他のプロジェクトで実装を再利用する予定があるかどうかによって異なります。

コードのコンパイルの問題については、を提供する 2 つの方法が混在していますUserDetailsService。では、フィールドにアノテーションCustomAuthenticationProviderを付けています。つまり、コンテナー (この場合は Spring アプリケーションコンテキスト) は適切な実装を見つけ、実行時にリフレクションを使用してそのフィールドにそれを注入します。コンテキストによってこのフィールドを設定するプロセスは、依存性注入と呼ばれます。クラスでは、クラスに存在しないメソッドを通じてフィールドを設定することで、自分で実装を提供しようとしています。userService@InjectSecurityConfigsetUserDetailsService

この問題を解決するには、UserDetails サービスを提供する方法の 1 つを選択し、次のいずれかを実行する必要があります。

アノテーションを削除し@Injectてメソッドを作成するsetUserDetailsServiceか、
存在しないメソッドを呼び出す行を削除し、実装をUserDetailsServiceBeanとして宣言します。

どちらの方法を選択すべきかという点については、クラスをSecurityConfig他のプロジェクトで再利用できるようにする方法が見つかる場合は、依存性注入の方法のほうが適している可能性があります。その場合は、(@Importアノテーションを使用して) インポートし、次のアプリケーションで別のUserDetailsSerice実装を Bean として宣言して動作させることができます。

通常、のようなクラスはSecurityConfig実際には再利用できないため、セッターを作成し、依存性注入を削除することがおそらく最初の選択肢になります。

編集

実用的な、しかし単純な実装（このブログの記事）だろう：

public class CustomAuthenticationProvider implements AuthenticationProvider{

    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String name = authentication.getName();
        String password = authentication.getCredentials().toString();
        List<GrantedAuthority> grantedAuths = new ArrayList<>();
        if (name.equals("admin") && password.equals("system")) {
            grantedAuths.add(new SimpleGrantedAuthority("ROLE_ADMIN"));  
        } 
        if(pincodeEntered(name)){
            grantedAuths.add(new SimpleGrantedAuthority("ROLE_PINCODE_USER"));  
        }
        Authentication auth = new UsernamePasswordAuthenticationToken(name, password, grantedAuths);
    }

    @Override
    public boolean supports(Class<?> authentication) {
        return authentication.equals(UsernamePasswordAuthenticationToken.class);
    }

    private boolean pincodeEntered(String userName){
        // do your check here
        return true;
    }
}

次に、構成クラスで次のメソッドを変更します。

@Bean
AuthenticationProvider customAuthenticationProvider() {
        return new CustomAuthenticationProvider();
}

Answer 1

まず、使用しているインターフェースと、認証プロセスでそれらが果たす役割について説明します。

Authentication- ユーザの認証結果を表します。そのユーザに付与された権限と、ユーザについて必要となる可能性のある追加の詳細を保持します。フレームワークにはどのような詳細が必要になるかを知る方法がないため、認証オブジェクトにはgetDetails任意のオブジェクトを返すことができるメソッド
AuthenticationProvider- 何らかの方法でオブジェクトを作成できるオブジェクトAuthentication。再利用性を高めるために、一部の（またはほとんどの）アプリケーションでは、各アプリケーションが特定のユーザーの詳細を必要とする可能性があるため、AuthenticationProviderオブジェクトにユーザーの詳細を設定することを控えていますAuthentication。代わりに、ユーザーの詳細を解決するプロセスを設定可能なメソッドに委任します。UserDetailsService
UserDetailsService- 1つの戦略アプリケーションに必要なユーザーの詳細を取得します。

したがって、カスタムを作成する場合、AuthenticationProviderを必要とする方法で実装する必要すらない場合がありUserDetailsServiceます。決定はあなた次第であり、他のプロジェクトで実装を再利用する予定があるかどうかによって異なります。

コードのコンパイルの問題については、を提供する 2 つの方法が混在していますUserDetailsService。では、フィールドにアノテーションCustomAuthenticationProviderを付けています。つまり、コンテナー (この場合は Spring アプリケーションコンテキスト) は適切な実装を見つけ、実行時にリフレクションを使用してそのフィールドにそれを注入します。コンテキストによってこのフィールドを設定するプロセスは、依存性注入と呼ばれます。クラスでは、クラスに存在しないメソッドを通じてフィールドを設定することで、自分で実装を提供しようとしています。userService@InjectSecurityConfigsetUserDetailsService

この問題を解決するには、UserDetails サービスを提供する方法の 1 つを選択し、次のいずれかを実行する必要があります。

アノテーションを削除し@Injectてメソッドを作成するsetUserDetailsServiceか、
存在しないメソッドを呼び出す行を削除し、実装をUserDetailsServiceBeanとして宣言します。

どちらの方法を選択すべきかという点については、クラスをSecurityConfig他のプロジェクトで再利用できるようにする方法が見つかる場合は、依存性注入の方法のほうが適している可能性があります。その場合は、(@Importアノテーションを使用して) インポートし、次のアプリケーションで別のUserDetailsSerice実装を Bean として宣言して動作させることができます。

通常、のようなクラスはSecurityConfig実際には再利用できないため、セッターを作成し、依存性注入を削除することがおそらく最初の選択肢になります。

編集

実用的な、しかし単純な実装（このブログの記事）だろう：

public class CustomAuthenticationProvider implements AuthenticationProvider{

    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String name = authentication.getName();
        String password = authentication.getCredentials().toString();
        List<GrantedAuthority> grantedAuths = new ArrayList<>();
        if (name.equals("admin") && password.equals("system")) {
            grantedAuths.add(new SimpleGrantedAuthority("ROLE_ADMIN"));  
        } 
        if(pincodeEntered(name)){
            grantedAuths.add(new SimpleGrantedAuthority("ROLE_PINCODE_USER"));  
        }
        Authentication auth = new UsernamePasswordAuthenticationToken(name, password, grantedAuths);
    }

    @Override
    public boolean supports(Class<?> authentication) {
        return authentication.equals(UsernamePasswordAuthenticationToken.class);
    }

    private boolean pincodeEntered(String userName){
        // do your check here
        return true;
    }
}

次に、構成クラスで次のメソッドを変更します。

@Bean
AuthenticationProvider customAuthenticationProvider() {
        return new CustomAuthenticationProvider();
}

n要素認証にJava構成を使用する [closed] 質問する

ダウンロードしてマシンに再現する

ベストアンサー1

おすすめ記事