2

Spring 3.1 アプリをこのように構成しました

<http use-expressions="true" entry-point-ref="http401UnauthorizedEntryPoint">

    <intercept-url pattern="/app/demo" access="hasRole('Demo')" />
    <intercept-url pattern="/app/**" access="isAuthenticated()" />
    <intercept-url pattern="/admin/**" access="hasRole('Admin')" />

    <custom-filter position="PRE_AUTH_FILTER"
        ref="currentWindowsIdentityAuthenticationFilter" />

    <logout invalidate-session="true" delete-cookies="JSESSIONID"
        logout-url="/logout" logout-success-url="/logout-success" />

</http>

カスタム事前認証フィルターを作成しました。ルート URL でアプリを呼び出すと/、フィルター チェーンがフックされ、事前認証フィルターが実行されますが、このリソースは保護されていません。これは、ログアウトが設計どおりに機能しないことを意味します。ログアウト後、再度ログインが実行されます。

org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter私の実装はクラスに基づいています。

これは正常な動作ですか、それとも何らかの方法で修正できますか? 保護された URL に対してのみ認証を実行したいと思います。

security='none'余談ですが、すべてのページでセキュリティ コンテキストを維持したいので、構成するつもりはありません。

Pastebinに適切なログアウトを投稿しました。ここに含めるには冗長すぎます。

4

2 に答える 2

1

あなたが望むのは<http>、ログアウトURLのフィルターなしで特別なものを作成しているようです:

<http pattern="/logout/**" security="none" />

<http use-expressions="true" entry-point-ref="http401UnauthorizedEntryPoint">

    <intercept-url pattern="/app/demo" access="hasRole('Demo')" />
    <intercept-url pattern="/app/**" access="isAuthenticated()" />
    <intercept-url pattern="/admin/**" access="hasRole('Admin')" />

    <custom-filter position="PRE_AUTH_FILTER"
        ref="currentWindowsIdentityAuthenticationFilter" />

    <logout invalidate-session="true" delete-cookies="JSESSIONID"
        logout-url="/logout" logout-success-url="/logout-success" />

</http>

リクエスト マッチング メカニズムの詳細については、こちらをご覧ください。

編集：

@LukeTaylor は、別のフィルター チェーンを作成する場合は、パターンを要素に入れる必要があると述べました(これは明示的にどこかに文書化されていますか?) PRE_AUTH_FILTER。フィルタなしで追加さ<http>れました。これにより、ログアウト リクエストでの認証が防止されます。/logout

/otherそれでも、 PRE_AUTH_FILTER の適用などのリクエストを防ぐ方法がわかりません。<http>1 つの方法としては、名前空間の構成を放棄して 2 つのパターンで手動filterChainProxy<sec:filter-chain>構成にすることも考えられますが、それが価値があるかどうかはわかりません。

@Michael-O: 例外についてIllegalArgumentException: A universal match pattern ('/**') is defined before other patterns- 奇妙なことですが、セキュリティの XML 構成全体ですか? それとも、ルークが言ったことの結果にすぎないのかもしれません（別の<http>要素にはパターンが必要です）...

于 2012-09-27T15:37:09.993 に答える
0

問題を特定することはできましたが、チェーン全体の仕組みが原因で、現在のように解決することはできません。

契約は次のとおりです。

<http>要素を定義するときに、/**Spring Security に、定義したパターンの下のすべてのパスでフィルター チェーン全体を起動するように依頼します。それらのいずれかが保護を必要とするかどうかは問題ではありません。Rob Winch が非常に役立つビデオを公開しました。デフォルトのフィルター スタックをよく見ると、どのフィルターが適用されているかがわかります。これらの中に私のフィルターがあります。

/私のログ ファイルの最初の 10 行は、構成が一致するため、チェーン全体が起動されたことを示してい<http>ます。最後に、FilterSecurityInterceptorはこのリソースを保護する必要がないことを確認します。さらに、 もCurrentWindowsIdentityAuthenticationFilter起動され、不要な認証を実行していることがわかります。

なんで？ヘッダーベースのフィルターや URL 処理フィルターと比較して、認証を意図的に開始するためのトリガー/エントリ ポイントがなく、URL が保護を必要とするかどうかに関係なく、クライアントに挑戦せずに行うだけです。このようなものを定義して<http pattern="/unprotected-url" security="none" />も、保護されていないパスのセキュリティ コンテキストが失われるため、まったく節約できません。URL 保護に関係なく、クライアントのログイン状態を維持したい。

これは今どのように解決できますか？次の 2 つのオプションがあります。

  1. <http>などの要素を定義しますが/app/**、/admin/**これは本当に面倒で、あちこちに繰り返しが含まれています。そのような解決策はお勧めしません。さらに、 の他の URL にはおそらく sec コンテキストがありません/**。これは望ましくありません。
  2. preauth フィルターを 2 つのフィルターに分割します。
    1. CurrentWindowsIdentityPreAuthenticationFilter
    2. CurrentWindowsIdentityUrlAuthenticationFilter

2 番目のオプションは、問題を解決します。

CurrentWindowsIdentityPreAuthenticationFilter: そのままで、常に認証を実行します。スクリプト アクセスや REST リクエストなどの M2M 通信に非常に役立ちます。 CurrentWindowsIdentityUrlAuthenticationFilter：人間関係にとてもよく合います。基本的にフォームベースのフィルターのように機能します。たとえば、URL を定義すると/login、保護されたリソースを要求したときに にリダイレクトされ、自動認証が成功すると、実際のリソースにリダイレクトされます。認証が完了しました。事前認証フィルターは/loginフォームベースと同様にのみトリガーされるため、公開リソースは認証されないままです。ログアウトすると、ログアウトしたままになります。

Spring 関係者の誰かが私の分析を確認できれば幸いです。

于 2012-09-29T22:09:22.123 に答える