Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 12c 12c (12.2.1.1.0) E79378-01 |
|
![]() 前 |
![]() 次 |
サーブレット認証フィルタは、IDアサーションなどの認証機能のための前処理および後処理を実行するプロバイダです。サーブレット検証フィルタは、主に認証プロバイダの「ヘルパー」として機能する特殊なセキュリティ・プロバイダです。
ServletAuthenticationFilter
インタフェースは、WebLogic Serverにプラグインできる認証フィルタに対してセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を定義します。認証プロセスでサーブレット・コンテナに呼び出させる認証フィルタが認証プロバイダにあることを通知するために、ServletAuthenticationFilter
インタフェースを認証プロバイダの一部として実装します。通常、このインタフェースは認証プロバイダのIDアサーション形式の一部として実装されます。
この章の内容は次のとおりです。
JavaサーブレットAPI 2.3仕様で定義されているように、フィルタは、リクエストがサーブレットに届く前のプリプロセッサ、またはサーブレットから離れたレスポンスのポストプロセッサです。フィルタを使用すると、再利用可能なユニットで反復タスクをカプセル化し、サーブレットまたはJSPページからのレスポンスを変換できます。
サーブレット認証フィルタは、コンテナ・ベースの認証をフィルタが置換または拡張できるようにするフィルタ・オブジェクトの拡張機能です。
WebLogicセキュリティ・フレームワークを使用すると、カスタム認証プロバイダを利用できます。ただし、JavaサーブレットAPI 2.3の仕様により、認証プロセス時は、認証プロバイダとクライアントまたは他のサーバーとの間の対話はアーキテクチャで制限されます。これにより、認証メカニズムは、サーブレット・コンテナが提供する認証メカニズムと互換性のある基本、フォーム、証明書の形式に制限されます。
フィルタには、アーキテクチャ依存の制限はほとんどありません。つまり、サーブレット認証フィルタは、サーブレット・コンテナが提供する認証メカニズムに依存していません。認証プロセスを開始するコンテナの前にフィルタを呼び出せるようにすれば、セキュリティ・レルムは、より柔軟な認証メカニズムを実装できます。たとえば、サーブレット認証フィルタを使用すると、認証用のSAMLプロバイダ・サイトにユーザーをリダイレクトできます。
WebLogic認証プロバイダ内のJAAS LoginModuleは、ログイン・プロセスのカスタマイズに使用できます。ユーザー・データベースの場所のカスタマイズ、ログインの実行に必要な証明データの種類、サブジェクトへのグループの指定は、LoginModuleを介して実装されます。
一方、ログインを実行するためのリモート・サイトへのリダイレクト、問合せ文字列からのログイン情報の抽出、ブラウザとのログイン機能のネゴシエーションは、サーブレット認証フィルタを介して実装されます。
サーブレット認証フィルタを設計する際には、以下の事項を考慮する必要があります。
複数のフィルタを指定可能にする必要がありますか?複数のフィルタを指定可能にすると、構成時に管理上の決定を行うことができるようになります。
特定の実行順序に依存していますか?サーブレット認証フィルタは、フィルタの実行順序に依存しないようにしてください。
各フィルタが認証の前後にリクエストを処理できるようにすることを検討しましたか?その場合、フィルタで呼出しのタイミングを予測しないようにしてください。
フィルタのdoFilterメソッドを呼び出さないことで、残りのフィルタの実行およびサーブレットの認証プロセスを停止できるようにする選択肢を各フィルタに与えることを検討します。
フィルタでブラウザをリダイレクトできるようにする必要がありますか?
フィルタが一方向SSL、双方向SSL、IDアサーション、フォーム認証、および基本認証で機能するようにすることを検討します。たとえば、フォーム認証は双方向のリクエスト・プロセスで、フィルタはフォーム認証用に2回呼び出されます。
サーブレット認証フィルタ・インタフェースを使用すると、認証プロバイダは0個以上のサーブレット認証フィルタ・クラスを実装できます。フィルタは以下の手順で呼び出されます。
認証が発生する前に、サーブレット・コンテナがサーブレット認証フィルタを呼び出します。
サーブレット・コンテナが、サーブレット認証フィルタの構成済みチェーンをWebLogicセキュリティ・フレームワークから取得します。
セキュリティ・フレームワークは、認証プロバイダの順序に従ってサーブレット認証フィルタを返します。1つのプロバイダに複数のサーブレット認証フィルタがある場合、セキュリティ・フレームワークは、ServletAuthenticationFilterのgetAuthenticationFilters
メソッドで返されたjavax.servlet.Filterの順序付けされたリストを使用します。
場合によっては、リクエストを適切に処理するために複数回実行する必要もあるので、フィルタが重複していてもかまいません。
サーブレット・コンテナは、フィルタのinit
メソッドをフィルタごとに呼び出し、フィルタがサービス内に適切に配置されるようにします。
チェーンの最後にあるリソースに対するクライアント・リクエストがあるため、リクエスト/レスポンスのペアがチェーン内を通るたびに、サーブレット・コンテナは、最初のフィルタに対してフィルタのdoFilter
メソッドを呼び出します。
このメソッドに渡されるFilterChain
オブジェクトを使用すると、フィルタは、リクエストとレスポンスをチェーン内の次のエンティティに渡すことができます。フィルタは、FilterChain
オブジェクトを使用して、チェーン内の次のフィルタを呼び出します。または、フィルタの呼出しがチェーン内の最後のフィルタの場合、チェーンの最後のリソースを呼び出します。
すべてのサーブレット認証フィルタがフィルタのdoFilter
メソッドを呼び出す場合、最後のサーブレット認証フィルタがdoFilter
メソッドを呼び出すと、サーブレット・コンテナは、フィルタが存在しない場合と同じように認証を実行します。
ただし、サーブレット認証フィルタがdoFilter
メソッドを呼び出さない場合、残りのフィルタ、サーブレット、およびサーブレット・コンテナの認証手順は呼び出されません。これにより、フィルタは、サーブレットの認証プロセスを置き換えることができます。通常、これには認証の失敗か、別の認証用URLへのリダイレクトが伴います。
サーブレット認証フィルタ・インタフェースを認証プロバイダの一部として実装しても、認証プロバイダは、サーブレット認証フィルタを直接呼び出すわけではありません。サーブレット認証フィルタの実装は、フィルタを配置して呼び出す方法を認識するWebLogicセキュリティ・フレームワークの特定の機能に依存します。
カスタム・サーブレット認証フィルタを開発する場合は、カスタム認証プロバイダがWLS固有のクラス(weblogic.servlet.*
など)およびJava EE固有のクラス(javax.servlet.*
など)を呼び出さないようにしてください。このルールに従うと、WebLogicセキュリティのポータビリティが最大限に高まります。
図13-1にこの要件を示します。
WebLogic Serverには、SPNEGO (Simple and Protected Negotiate)に必要なヘッダー操作を処理するサーブレット認証フィルタが含まれます。「ネゴシエーション・サーブレット認証フィルタ」と呼ばれるこのサーブレット認証フィルタは、WWW-AuthenticateヘッダーおよびAuthorization HTTPヘッダーをサポートするように構成されています。
ネゴシエーション・サーブレット認証フィルタは、ネゴシエート・プロトコルの認可されていないレスポンスに対して適切なWWW-Authenticateヘッダーを生成し、以降のリクエストに対してAuthorizationヘッダーを処理します。このフィルタは、ネゴシエーションIDアサーション・プロバイダを介して使用できます。
デフォルトでは、ネゴシエーションIDアサーション・プロバイダは使用可能ですが、WebLogicデフォルト・セキュリティ・レルムには構成されていません。ネゴシエーションIDアサーション・プロバイダは、WebLogic IDアサーション・プロバイダのかわりとして使用したり、WebLogic IDアサーション・プロバイダと併用したりできます。
カスタム・サーブレット認証フィルタを開発するには、以下の手順に従います。
ランタイム・クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でサーブレット認証フィルタのランタイム・クラスを作成します。
カスタム・サーブレット認証フィルタ・プロバイダのランタイム・クラスの作成例については、「WebLogic MBeanMakerを使用してMBeanタイプを生成する」を参照してください
認証プロセスでサーブレット・コンテナに呼び出させる認証フィルタが認証プロバイダにあることを通知するために、ServletAuthenticationFilter
インタフェースを認証プロバイダの一部として実装します。
サーブレット認証フィルタSSPIを実装する際には、以下のメソッドの実装を提供する必要があります。
サーブレット認証フィルタの取得
public Filter[] getServletAuthenticationFilters
getServletAuthenticationFilters
メソッドは、サーブレット・コンテナの認証プロセスで実行されるjavax.servlet.Filterの順序付けられたリストを返します。コンテナは、サーブレット認証フィルタの複数のインスタンスを取得するために、このメソッドを複数回呼び出すことがあります。このメソッドは、呼出しごとに、フィルタの新しいインスタンスのリストを返す必要があります。
フィルタ・インタフェース・メソッドを実装するには、以下のメソッドの実装を提供する必要があります。通常は、init()
を1回呼び出し、doFilter()を必要に応じた回数呼び出してから、destroy()を1回呼び出します。
destroy
public void destroy()
destroy
メソッドは、フィルタをサービスから取り除くよう指示するためにWebコンテナによって呼び出されます。このメソッドは、フィルタのdoFilterメソッド内のすべてのスレッドが終了した場合、またはタイムアウト期間が過ぎた場合にのみ呼び出されます。Webコンテナは、このメソッドを呼び出した後に、フィルタのこのインスタンスに対して再びdoFilter
メソッドを呼び出しません。
このメソッドを使用すると、フィルタで保持されているリソース(メモリー、ファイル・ハンドル、スレッドなど)をクリーンアップし、永続的な状態をメモリー内のフィルタの現在の状態と同期させることができます。
doFilter
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
チェーンの最後にあるリソースに対するクライアント・リクエストがあるため、リクエスト/レスポンスのペアがチェーン内を通るたびに、フィルタのdoFilter
メソッドがコンテナによって呼び出されます。このメソッドに渡されるFilterChain
を使用すると、フィルタは、リクエストとレスポンスをチェーン内の次のエンティティに渡すことができます。
通常、このメソッドの実装は以下のパターンに従います。
1.リクエストを調べます。
2.必要に応じてカスタム実装でリクエスト・オブジェクトをラップし、入力フィルタ用に内容とヘッダーをフィルタ処理します。
3.必要に応じてカスタム実装でレスポンス・オブジェクトをラップし、出力フィルタ用に内容とヘッダーをフィルタ処理します。
4. FilterChain
オブジェクトを使用してチェーン内の次のエンティティを呼び出すか(chain.doFilter()
)、フィルタ・チェーン内の次のエンティティにリクエスト/レスポンスのペアを渡さずにリクエストの処理をブロックします。
5.フィルタ・チェーン内の次のエンティティの呼出し後に、レスポンスのヘッダーを直接設定します。
init
public void init(FilterConfig filterConfig)
init
メソッドは、フィルタをサービス内に配置するよう指示するためにWebコンテナによって呼び出されます。サーブレット・コンテナは、フィルタのインスタンス化の後でinit
メソッドを一度のみ呼び出します。init
メソッドは、フィルタ処理をフィルタに指示する前に正常に完了している必要があります。
「IDアサーション・プロバイダ」で説明したとおり、チャレンジIDアサーション・インタフェースは、複数のチャレンジ、レスポンス・メッセージ、および状態を必要とするチャレンジ・レスポンス・スキームをサポートします。チャレンジIDアサーション・プロバイダ・インタフェースを使用すると、IDアサーション・プロバイダは、MicrosoftのWindows NTチャレンジ/レスポンス(NTLM)やSPNEGO (Simple and Protected GSS-API Negotiation)などのチャレンジ/レスポンス認証メカニズムを採用した認証プロトコルをサポートできます。
サーブレット認証フィルタを使用すると、サーブレット・コンテナと互換性のある認証メカニズムに制限されることなくチャレンジ/レスポンス・プロトコルを実装できます。ただし、サーブレット認証フィルタは、セキュリティ・フレームワークで提供されている認証環境の外側で機能するので、セキュリティ・フレームワークを利用してプロバイダのコンテキストを判別することはできません。また、サーブレット認証フィルタでは、APIでチャレンジ回数が複数のIDアサーション・プロセスを駆動させる必要があります。
weblogic.security.services.Authentication
クラスが拡張され、サーブレット認証フィルタからの複数のチャレンジ/レスポンスIDアサーションが可能になりました。メソッドおよびインタフェースでは、ChallengeIdentityAsserterV2
SSPIインタフェースとProviderChallengeContext
SSPIインタフェースのラッパーが提供されるので、サーブレット認証フィルタから呼び出すことができます。
これ以外に、セキュリティ・フレームワークのコンテキスト内でサーブレット認証フィルタから複数のチャレンジ/レスポンス・ダイアログを実行する方法はドキュメント化されていません。サーブレット認証フィルタは、ChallengeIdentityAsserterV2
インタフェースおよびProviderChallengeContext
インタフェースを直接呼び出すことはできません。
したがって、複数のチャレンジ/レスポンスIDアサーションをフィルタから実装する場合、ChallengeIdentityAsserterV2
インタフェースとProviderChallengeContext
インタフェースを実装してから、weblogic.security.services.Authentication
メソッドとAppChallengeContect
インタフェースを使用して、サーブレット認証フィルタから目的のフィルタを呼び出す必要があります。
このプロセスを行う手順については、「IDアサーション・プロバイダ」で説明されています。ここでは、概要を示します。
「認証プロバイダ」の説明に従ってカスタム認証プロバイダのMBeanタイプを生成する際には、使用しているサーブレット認証フィルタのMBeanも実装する必要があります。
ServletAuthenticationFilter
MBeanはAuthenticationProvider
MBeanを拡張します。ServletAuthenticationFilter
MBeanはマーカー・インタフェースなので、メソッドはありません。
<?xml version="1.0" ?> <!DOCTYPE MBeanType SYSTEM "commo.dtd"> <MBeanType Name = "ServletAuthenticationFilter" Package = "weblogic.management.security.authentication" Extends = "weblogic.management.security.authentication.AuthenticationProvider" PersistPolicy = "OnUpdate" Abstract = "true" Description = "The SSPI MBean that all Servlet Authentication Filter providers must extend. This MBean is just a marker interface. It has no methods on it." > </MBeanType>
WebLogic MBeanMakerを使用してMDFを実行して中間ファイルを生成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、サーブレット認証フィルタを含むカスタム認証プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。
この手順は、「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」で説明します。
サーブレット認証フィルタを実装するカスタム認証プロバイダを構成するということは、そのカスタム認証プロバイダをセキュリティ・レルムに追加するということです。追加されたカスタム認証プロバイダには、認証サービスを必要とするアプリケーションからアクセスできます。
カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。
WebLogic Server管理コンソールを使用してカスタムの認可プロバイダを構成する手順は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のWebLogicセキュリティ・プロバイダの構成に関する項を参照してください。