Spring Security - セキュリティなし、フィルタなし、アクセスpermitAll

Spring Security –セキュリティなし、フィルターなし、アクセス許可All

1. 概要

Spring Securityは、リクエストパターンを保護されていない、またはすべてのアクセスを許可するように構成するためのいくつかのメカニズムを提供します。これらのメカニズムのそれぞれに依存します-これは、そのパスでセキュリティフィルターチェーンをまったく実行しないか、フィルターチェーンを実行してアクセスを許可することを意味します。

参考文献：

Spring Security –ロールと特権

Spring Securityアプリケーションのロールと特権をマップする方法：セットアップ、認証、登録プロセス。

REST APIのSpring Security

Spring SecurityでREST APIを保護する方法-XML構成、web.xml、認証用のHTTPステータスコードなど

Springセキュリティ式– hasRoleの例

hasRole Spring Security Expressionの紹介：@PreAuthorizeによるメソッドセキュリティと同様に、URLおよびページ内でWeb認証を設定します。

2. access=”permitAll”

access=”permitAll”を使用して<intercept-url>要素を設定すると、すべての要求がその特定のパス上のallowedになるように承認が構成されます。

または、Java構成を介して：

http.authorizeRequests().antMatchers("/login*").permitAll();

これはwithout disabling the security filtersで達成されます。これらは引き続き実行されるため、SpringSecurity関連の機能は引き続き使用できます。

3. filters=”none”

これは、deprecated and replaced in Spring 3.1.であったSpring3.1より前の機能です。

filters属性は、その特定の要求パスでSpringSecurityフィルターチェーンを完全に無効にします。

これにより、リクエストの処理にSpring Securityの機能が必要な場合に問題が発生する可能性があります。

これは3.0より新しいSpringバージョンの非推奨機能であるため、Spring 3.1で使用すると、起動時にランタイム例外が発生します。

SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: The use of "filters='none'" is no longer supported.
Please define a separate  element for the pattern you want to exclude
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
    at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68)

4. security=”none”

上記のエラーメッセージで見たように、Spring 3.1はfilters=”none”を新しい式–security=”none”に置き換えます。

スコープも変更されました。これは、<intercept-url>要素レベルでは指定されなくなりました。代わりに、Spring 3.1ではmultiple <http> elementsを定義できます。それぞれに独自のセキュリティフィルターチェーン構成があります。そのため、新しいセキュリティ属性は<http>要素レベルに属します。

実際には、これは次のようになります。

またはJava構成の場合：

web.ignoring().antMatchers("/resources/**");

古い代わりに：

filters=”none”と同様に、これもその要求パスのセキュリティフィルターチェーンを完全に無効にします。そのため、要求がアプリケーションで処理されると、Springセキュリティ機能は使用できなくなります。

これは、実際の処理が行われないserving static resourcesを主に扱う上記の例では問題になりません。ただし、リクエストが何らかの方法でプログラムによって処理される場合、requires-channel、現在のユーザーへのアクセス、セキュリティで保護されたメソッドの呼び出しなどのセキュリティ機能は利用できません。

同じ理由で、security=”none”で既に構成されている<http>要素に追加の属性を指定しても意味がありません。これは、その要求パスが保護されておらず、属性が単に無視されるためです。

または、access='IS_AUTHENTICATED_ANONYMOUSLY'を使用して匿名アクセスを許可することもできます。

**5. security=”none”の警告**

複数の<http>要素を使用する場合（一部はsecurity=”none”で構成されます）、これらの要素が定義される順序が重要であることに注意してください。最初に特定の<http>パスを設定し、最後にユニバーサルパターンに従います。

また、<http>要素doesn’t specify a patternの場合、デフォルトでは、ユニバーサル一致パターンにマップされることに注意してください–“ /*” – so again, this element needs to be last. If the order of the elements is not correct, the *creation of the security filter chain will fail：

Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**')
is defined  before other patterns in the filter chain, causing them to be ignored.
Please check the ordering in your  namespace or FilterChainProxy bean configuration
    at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
    at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39)

6. 結論

この記事では、filters=”none”, security=”none” and access=”permitAll”の違いに焦点を当てて、SpringSecurityを使用してパスへのアクセスを許可するオプションについて説明します。

いつものように、例は利用可能なover on GitHubです。

TOC