Spring Http Basic(基本)とDigest(要約)検証

6173 ワード

Basic(基本)とDigest(要約)検証は、Webアプリケーションで人気のあるオプションメカニズムです.Basic検証は、通常、無状態のクライアントを処理するために使用され、要求されるたびに証明書が添付されます.一般的な使い方は、フォームベースの検証とともに使用することです.ここでのアプリケーションでは、ブラウザベースのユーザーインタフェースとウェブサービスが同時に使用されます.しかしながら、basic検証は、テキストを用いてパスワードを転送するので、HTTPSなどの暗号化された転送経路のみで送信されるべきである.
9.1.  BasicAuthenticationFilter BasicAuthenticationFilterは、HTTPヘッダを介して送信されたbasic認証証明書の処理を担当する.これは、通常のユーザエージェント(例えば、IEおよびNavigator)のようにSpringリモートプロトコルによる呼び出し(例えば、HessianおよびBurlap)を認証するために使用することができる.HTTP基本認証の実行基準はRFC 1945,11章,BasicAuthenticationFilterでこのRFCに適合する.基本認証は、ユーザーエージェントで広く公開されているため、実装も特に簡単である(username:passwordをBase 64符号化し、HTTPヘッダに入れるだけである).
9.1.1. コンフィギュレーション
HTTP基本認証を実現するには,まずフィルタチェーンにBasicAuthenticationFilterを定義する.また、アプリケーションcontextでBasicAuthenticationFilterとコラボレーションのクラスを定義します.
<bean id="basicAuthenticationFilter"
  class="org.springframework.security.web.authentication.www.BasicAuthenticationFilter">
  <property name="authenticationManager" ref="authenticationManager"/>
  <property name="authenticationEntryPoint" ref="authenticationEntryPoint"/>
</bean>

<bean id="authenticationEntryPoint"
  class="org.springframework.security.web.authentication.www.BasicAuthenticationEntryPoint">
  <property name="realmName" value="Name Of Your Realm"/>
</bean>
                

構成されたAuthenticationManagerは、各認証要求を処理する.認証に失敗した場合、構成されたAuthenticationEntryPointは、認証プロセスを再試行するために使用されます.通常、BasicAuthenticationEntryPointを使用すると、対応するヘッダを使用してHTTP基本検証を再試行する401応答が返されます.検証が成功すれば、得られたAuthenticationの対象をSecurityContextHolderに入れる.
認証イベントが成功した場合、またはHTTPヘッダにサポートされている認証要求が含まれていないために認証が行われなかった場合、フィルタチェーンは通常のように継続します.唯一フィルタを遮断する場合は、認証に失敗してAuthenticationEntryPointが呼び出されたときに、上記の段落で議論したようにします.
9.2.  DigestAuthenticationFilter
Spring Securityは  DigestAuthenticationFilterは、HTTPヘッダの要約認証証明書を処理することができる.要約認証は、多くの基本認証の欠陥を解決しようと試みており、特に純粋なテキストで証明書が送信されないことを保証しています.多くのユーザーは、FireFoxとIEを含む要約認証をサポートしています.HTTPダイジェスト認証の実行基準はRFC 2617に定義され、これはRFC 2069という初期ダイジェスト認証基準の更新である.Spring Security  DigestAuthenticationFilterは「auth」の安全品質(qop)を保証し、RFC 2617に明記され、RFC 2069と互換性を提供する.暗号化されていないHTTP(TLS/HTTPがないなど)を使用し、最大のセキュリティを認証したい場合は、要約認証が魅力的です.実際、要約認証はWebDAVプロトコルの強制的な要求であり、RFC 2518の17.1章に書かれているので、基本認証の代わりにより多くの代替を見ることを期待すべきである.
要約認証は、フォーム認証、基本認証、要約認証の中で最も安全な選択ですが、より安全であることは、より複雑なユーザーエージェントの実現を意味します.要約認証の中心は「nonce」です.これは、サーバによって生成された値です.Spring Securityのnonceは次の形式を採用しています.
                base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key))

                expirationTime:   The date and time when the nonce expires, expressed in milliseconds
                key:              A private key to prevent modification of the nonce token
            

このDigestAuthenticationEntryPointには、keyを指定することによってnonceフラグを生成する属性があり、nonceValiditySecondsの属性によって期限が決定される(デフォルト300、5分).Nonceが有効である限り、要約は、ユーザ名、パスワード、nonce、要求されたURI、クライアント生成nonce(ランダム値のみ、ユーザエージェントが要求ごとに1つずつ生成する)、realm名などを含む直列文字列で計算され、MD 5ハッシュが1回実行されます.サーバとユーザーエージェントは、このサマリー計算を実行し、パスワードなどの値が異なる場合、異なるハッシュコードを生成します.Spring Securityの実装では、サーバによって生成されたnonceが期限切れになった場合(要約は有効)、DigestAuthenticationEntryPoint"stale=true"ヘッダ情報を送信します.これは、パスワードやユーザーのようなユーザーを邪魔する必要がなくなり、新しいnonceを簡単に試してみるだけであることをユーザーエージェントに示します.DigestAuthenticationEntryPoint  nonceValiditySecondsパラメータは、適切な値としてプログラムに添付されます.セキュリティ要件が高いユーザは、nonceがexpirationTimeに達するまで、ブロックされた認証ヘッダを、本体を偽造するために使用することができることに注意すべきである.適切な構成を選択する場合、これは考慮しなければならない重要な条件ですが、セキュリティに対する要求が高いプログラムでは、最初の要求はまずTLS/HTTPSの上で実行されます.
要約認証はより複雑な実装が必要であるため、ここではユーザエージェントの問題がしばしば発生する.例えば、IEは、同じセッションの要求プロセスにおいて「 」フラグをブロックすることができない.そこでSpring Securityはすべての状態情報を「nonce」タグに要約する.私たちのテストでは、Spring SecurityはFireFoxとIEで動作し、nonceタイムアウトなどを正しく処理することができます.
9.2.1. Configuration
理論を見直して、それをどのように使うかを見てみましょう.HTTP要約認証を実現するためには、DigestAuthenticationFilterをフィルタチェーンに定義する必要がある.アプリケーションcontextでは、DigestAuthenticationFilterと必要なパートナーを定義する必要があります.
<bean id="digestnFilter" class=
    "org.springframework.security.web.authentication.www.DigestAuthenticationFilter">
  <property name="userDetailsService" ref="jdbcDaoImpl"/>
  <property name="authenticationEntryPoint" ref="digestEntryPoint"/>
  <property name="userCache" ref="userCache"/>
</bean>

<bean id="digestEntryPoint" class=
    "org.springframework.security.web.authentication.www.DigestAuthenticationEntryPoint">
  <property name="realmName" value="Contacts Realm via Digest Authentication"/>
  <property name="key" value="acegi"/>
  <property name="nonceValiditySeconds" value="10"/>
</bean>
                
UserDetailsServiceを構成する必要があります.  DigestAuthenticationFilterは、ユーザの純粋なテキストパスワードに直接アクセスする必要があります.DAOでコードされたパスワードを使用すると、要約認証は機能しません.DAO協力者は、UserCacheとともに、通常DaoAuthenticationProviderを使用して直接共有される.このAuthenticationEntryPoint属性は、DigestAuthenticationEntryPointでなければならない.これにより、DigestAuthenticationFilterは、要約計算時に正しいrealmNameおよびkeyを得ることができる.BasicAuthenticationFilterのように、認証に成功すると、Authentication要求フラグがSecurityContextHolderに格納されます.HTTPヘッダにサマリー認証要求が含まれていないため、認証イベントが成功した場合、または認証を実行する必要がない場合、フィルタチェーンは正常に継続します.フィルタチェーンが中断された唯一のケースは、認証に失敗すると、上述したようにAuthenticationEntryPointが呼び出されることである.
要約認証のRFCは、セキュリティを向上させるために、追加の機能範囲を必要とします.たとえば、nonceはリクエストのたびに変換できます.しかし、Spring Securityの設計構想は、最小限の複雑さの実現(ユーザエージェントが互換性を持たないことは間違いない)であり、サーバ側の状態を保存することも避けられる.これらの機能の詳細を検討したい場合は、RFC 2617を見ることをお勧めします.私たちが知っているように、Spring Security実装クラスはRFCの最低基準を遵守しています.