第4章 Red Hat Process Automation Manager での Spring Security

Spring Security は、Spring Security ライブラリー を設定するサーブレットフィルターのコレクションによって提供されます。これらのフィルターは、ユーザー名とパスワードを使用した認証およびロールを使用した承認を行います。Red Hat Process Automation Manager Spring Boot アプリケーションで生成されるデフォルトの Spring Security 実装は、認証なしで承認を行います。つまり、アプリケーションに対して有効なユーザー名とパスワードを持つユーザーは、ロールなしでアプリケーションにアクセスできます。

サーブレットフィルターは、CSRF (Cross-Site Request Forgery) や CORS (Cross-Origin Resource Sharing) などの一般的な脆弱性から Spring Boot アプリケーションを保護します。Spring Web は DispatcherServlet に依存し、受信した HTTP 要求を @Controller アノテーションが付けられた基盤となる java REST リソースにリダイレクトします。DispatchServlet は、セキュリティーなどの要素に依存しません。ビジネスアプリケーションロジックの外部でセキュリティーなどの実装の詳細を処理することは、優れた方法であり、より効率的です。そのため、Spring はフィルターを使用して HTTP 要求を傍受してから、それらを DispatchServlet にルーティングします。

典型的な Spring Security 実装は、複数のサーブレットフィルターを使用する以下の手順で設定されます。

  1. HTTP 要求からユーザー認証情報を抽出し、デコードまたは復号します。
  2. データベース、Web サービス、Red Hat Single Sign-On などの企業アイデンティティープロバイダーに対して認証情報を検証することにより、完全な認証を行います。
  3. 承認されたユーザーが要求を実行する権限を持っているかどうかを決定することにより、完全な承認を行います。
  4. ユーザーが認証および承認された場合は、要求を DispatchServlet に伝播します。

Spring はこれらの手順を個別のフィルターに分割し、FilterChain で連結させます。この連鎖メソッドは、ほとんどすべてのアイデンティティープロバイダーとセキュリティーフレームワークと連携するために必要な柔軟性を提供します。Spring Security では、プログラムを使用してアプリケーションの FilterChain を定義できます。以下のセクションは、Web サイト https://start.jbpm.org で作成されたビジネスアプリケーションの一部として生成された business-application-service/src/main/java/com/company/service/DefaultWebSecurityConfig.java ファイルからのものです。

@Configuration("kieServerSecurity")
@EnableWebSecurity
public class DefaultWebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override (1)
    protected void configure(HttpSecurity http) throws Exception {
        http
                .cors().and()
                .csrf().disable()       (2)
                .authorizeRequests()    (3)
                .antMatchers("/rest/*").authenticated().and()
                .httpBasic().and()      (4)
                .headers().frameOptions().disable();    (5)
    }
  • (1) デフォルトの configure(HttpSecurity http) メソッドをオーバーライドし、Spring HttpClient fluent API/DSL を使用してカスタムの FilterChain を定義します。
  • (2) ローカルテストにおける CORS トークンおよび CSRF トークンの一般的な脆弱性フィルターを無効にします。
  • (3) パターン rest/*に送信された要求には認証が必要ですが、ロールは定義されていません。
  • (4) 承認ヘッダーによる Basic 認証を許可します (ヘッダー Authorization: Basic dGVzdF91c2VyOnBhc3N3b3Jk など)。
  • (5) 要求/レスポンスから X-Frame-Options ヘッダーを削除します。

この設定により、認証されたユーザーは KIE API を実行できます。

デフォルトの実装は外部アイデンティティープロバイダーに統合されないため、ユーザーはメモリー内の同じ DefaultWebSecurityConfg クラスで定義されます。以下のセクションは、Red Hat Process Automation Manager Spring Boot ビジネスアプリケーションの作成時に提供されるユーザーを示しています。

    @Autowired
    public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication().withUser("user").password("user").roles("kie-server");
        auth.inMemoryAuthentication().withUser("wbadmin").password("wbadmin").roles("admin");
        auth.inMemoryAuthentication().withUser("kieserver").password("kieserver1!").roles("kie-server");
    }

4.1. Spring Security を使用した承認による認証

デフォルトでは、Red Hat Process Automation Manager Spring Boot アプリケーションに対して有効なユーザー名とパスワードを持つユーザーは、ロールなしでアプリケーションにアクセスできます。Spring Security の認証および承認は、HTTPSecurity フィルターチェーン設定から取得します。特定のロールマッピングを持たないユーザーから REST API を保護するには、Spring Security .authorizeRequests() メソッドを使用して、承認する URL を一致させます。

前提条件

  • Red Hat Process Automation Manager Spring Boot アプリケーションがある。

手順

  1. Red Hat Process Automation Manager Spring Boot アプリケーションが含まれるディレクトリーで、テキストエディターまたは IDE で business-application-service/src/main/java/com/company/service/DefaultWebSecurityConfig.java ファイルを開きます。
  2. 特定のロールがある場合にのみ認証されたユーザーによるアクセス要求を承認するには、以下のいずれかの方法で .antMatchers("/rest/*").authenticated().and() 行を編集します。

    • 1 つのロールを承認するには、以下の例のように antMatchers メソッドを編集します。ここで、<role> はユーザーがアクセスするために必要なロールに置き換えます。

      @Configuration("kieServerSecurity")
      @EnableWebSecurity
      public class DefaultWebSecurityConfig extends WebSecurityConfigurerAdapter {
      
          @Override
          protected void configure(HttpSecurity http) throws Exception {
              http
                  .cors().and().csrf().disable()
                  .authorizeRequests()
                      .antMatchers("/**").hasRole("<role>")
                      .anyRequest().authenticated()
                  .and().httpBasic()
                  .and().headers().frameOptions().disable();
          }
          ...
    • さまざまなロールのうちの 1 つを持つユーザーを承認するには、以下の例のように antMatchers メソッドを編集します。ここで、<role> および <role1> はそれぞれ、ユーザーがアクセスするために持つことができるロールです。

      @Configuration("kieServerSecurity")
      @EnableWebSecurity
      public class DefaultWebSecurityConfig extends WebSecurityConfigurerAdapter {
      
          @Override
          protected void configure(HttpSecurity http) throws Exception {
              http
                  .cors().and().csrf().disable()
                  .authorizeRequests()
                      .antMatchers("/**").hasAnyRole("<role>", "<role1")
                      .anyRequest().authenticated()
                  .and().httpBasic()
                  .and().headers().frameOptions().disable();
          }
          ...

authorizeRequests メソッドでは、特定の式に対する要求の承認が必要です。すべての要求が正常に認証されている必要があります。認証は、HTTP Basic 認証を使用して実行されます。認証されたユーザーが、自分では持っていないロールに対して保護されているリソースにアクセスしようとすると、そのユーザーは HTTP 403 (Forbidden) エラーを受け取ります。