Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 11g リリース1(10.3.4) B61623-02 |
|
前 |
次 |
裁決とは、複数の認可プロバイダが構成されている場合に発生するおそれのある認可上の衝突を、それぞれの認可プロバイダのアクセス決定の結果を比較検討することで解消する手続きです。WebLogic Serverでは、裁決プロバイダを使用して、複数のアクセス決定から返される結果を調停し、PERMIT
かDENY
の最終判定を下します。また、裁決プロバイダでは、単一の認可プロバイダのアクセス決定からABSTAIN
の回答が返されたときにどうすべきかを指定することもできます。
以下の節では、裁決プロバイダの概念と機能、およびカスタム裁決プロバイダの開発手順について説明します。
裁決プロバイダは認可プロセスの一部として使用されるので、使用方法は「認可プロセス」で説明されています。
WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogic裁決プロバイダが含まれています。WebLogic裁決プロバイダは、複数の認可プロバイダのアクセス決定から異なる結果が返された場合に裁決を行い、WebLogicリソースへのアクセスを許可するかどうかを最終的に判定します。
WebLogic裁決プロバイダには、動作を制御する「完全一致の許可が必要」という属性があります。「完全一致の許可が必要」属性は、デフォルトではTRUE
に設定されており、WebLogic裁決プロバイダはその設定に従って次のように動作します。
すべての認可プロバイダのアクセス決定がPERMIT
を返した場合、最終的な判定としてTRUE
を返します(つまりWebLogicリソースへのアクセスは許可されます)。
一部の認可プロバイダのアクセス決定がPERMIT
を返し、その他がABSTAIN
を返した場合、FALSE
を返します(つまりWebLogicリソースへのアクセスは拒否されます)。
いずれかの認可プロバイダのアクセス決定がABSTAIN
またはDENY
を返した場合、最終的な判定としてFALSE
を返します(つまりWebLogicリソースへのアクセスは拒否されます)。
「完全一致の許可が必要」属性をFALSE
に変更した場合、WebLogic裁決プロバイダは次のように動作します。
すべての認可プロバイダのアクセス決定がPERMIT
を返した場合、最終的な判定としてTRUE
を返します(つまりWebLogicリソースへのアクセスは許可されます)。
一部の認可プロバイダのアクセス決定がPERMIT
を返し、その他がABSTAIN
を返した場合、最終的な判定としてTRUE
を返します(つまりWebLogicリソースへのアクセスは許可されます)。
いずれかの認可プロバイダのアクセス決定がDENY
を返した場合、最終的な判定としてFALSE
を返します(つまりWebLogicリソースへのアクセスは拒否されます)。
注意: 「完全一致の許可が必要」属性は、WebLogic裁決プロバイダを構成するときに設定します。WebLogic裁決プロバイダの構成の詳細は、『Oracle WebLogic Serverの保護』のWebLogic裁決プロバイダの構成に関する項を参照してください。 |
上記の説明と異なる動作の裁決プロバイダが必要な場合、カスタム裁決プロバイダを開発する必要があります(裁決プロバイダでは、1つの認可プロバイダのアクセス決定がABSTAIN
を返した場合に、指定したセキュリティ要件に基づいてどのように対処するかを指定することもできます)。
WebLogic裁決プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム裁決プロバイダを開発することができます。
適切なSSPIによる実行時クラスの作成、または必要に応じてバルク認可プロバイダを使用
実行時クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム裁決プロバイダの実行時クラスを作成します。
AdjudicationProviderV2
SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getAdjudicator
public AdjudicatorV2 getAdjudicator()
getAdjudicator
メソッドは、AdjudicatorV2
SSPIの実装を取得します。MyAdjudicationProviderImpl
.java
という1つの実行時クラスの場合、getAdjudicator
メソッドの実装は次のようになります。
return this;
実行時クラスが2つの場合、getAdjudicator
メソッドの実装は次のようになります。
return new MyAdjudicatorImpl;
これは、AdjudicationProviderV2
SSPIを実装する実行時クラスが、AdjudicatorV2
SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。
AdjudicationProviderV2
SSPIとgetAdjudicator
メソッドの詳細は、「WebLogic Server APIリファレンスJavadoc」を参照してください。
AdjudicatorV2
SSPIを実装するには、以下のメソッドの実装を提供する必要があります。
initialize
public void initialize(AuthorizerMBean[] accessDecisionClassNames)
initialize
メソッドは、「アクセスは許されるか」という質問への回答を得るために呼び出されるすべての構成済み認可プロバイダのアクセス決定の名前を初期化します。accessDecisionClassNames
パラメータは、裁決プロバイダのadjudicate
メソッドで特定のアクセス決定による判定結果を支持するために使用することもできます。認可プロバイダとアクセス決定の詳細は、「認可プロバイダ」を参照してください。
adjudicate
public boolean adjudicate(Result[] results, Resource resource, ContextHandler handler)
adjudicate
メソッドは、構成済み認可プロバイダのアクセス決定から返された判定結果をすべて受け取り、「アクセスは許されるか」という質問への回答を決定します。
Adjudicator
SSPIとinitialize
およびadjudicate
メソッドの詳細は、「WebLogic Server APIリファレンスJavadoc」を参照してください。
WebLogic Serverのこのリリースには、以下に示すバルク・アクセス・バージョンの裁決プロバイダSSPIインタフェースがあります。
BulkAdjudicationProvider
BulkAdjudicator
バルク・アクセスSSPIインタフェースを使用すると、裁決プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」
ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResource
オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。
バルク・バージョンでないSSPIインタフェースとバルク・バージョンのSSPIインタフェースの使用方法には若干の違いがあります。
BulkAdjudicator.adjudicate()
メソッドはWebLogic Serverの認可マネージャによって渡されたMap (Resource, Result)
インスタンス群のList
を取り、これにはバルク・アクセス決定の結果が含まれます。結果の順序はBulkAdjudicator.initialize()
メソッドに渡されたアクセス決定クラス名の順序と同じです。
BulkAdjudicator.adjudicate()
メソッドはResource
オブジェクトのSet
を返すことにも注意が必要です。このセットにResource
オブジェクトがある場合、そのオブジェクトへのアクセスが付与されていますが、そうでない場合にはアクセスは拒否されています。
カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム裁決プロバイダのMBeanタイプを作成します。
WebLogic Server環境にMBeanタイプのインストール
注意: この手順の実行方法を説明するサンプル・セキュリティ・プロバイダ(Oracle Technology Network Webサイトのhttps://codesamples.samplecode.oracle.com/servlets/tracking?id=S224 から入手可能)がいくつか用意されています。
この節で説明する手順はすべて、Windows環境での作業を想定しています。 |
MBean定義ファイル(MDF)を作成するには、次の手順に従います。
サンプル認証プロバイダのMDFをテキスト・ファイルにコピーします。
注意: サンプル認証プロバイダのMDFは、SampleAuthenticator.xml です(現在、サンプル裁決プロバイダはありません)。 |
MDFで<MBeanType>
要素と<MBeanAttribute>
要素の内容をカスタム裁決プロバイダに合わせて修正します。
カスタム属性および操作(つまり、<MBeanAttribute>
および<MBeanOperation>
要素)をMDFに追加します。
ファイルを保存します。
MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンド・ライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。
MBeanタイプの生成手順は、カスタム裁決プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム裁決プロバイダのMDFにカスタム操作を含めない場合、次の手順に従います。
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF
フラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。
xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true
フラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。
注意: WebLogic MBeanMakerではMDFを一度に1つ処理します。そのため、MDFが複数ある(つまり裁決プロバイダが複数ある)場合には、このプロセスを繰り返す必要があります。 |
カスタム裁決プロバイダのMDFにカスタム操作を含める場合、質問に答えながら手順を進めてください。
MBeanタイプを作成するのは初めてですか。初めての場合は、次の手順に従ってください。
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF
フラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。
xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true
フラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。
注意: バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり裁決プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。 |
MDFのすべてのカスタム操作に対して、メソッド・スタブを使用してメソッドを実装します。
ファイルを保存します。
既存のMBeanタイプの更新ですか。更新の場合は、次の手順に従ってください。
WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF
フラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。
xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true
フラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。
注意: バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり裁決プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。 |
MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。
完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。
このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、ステップ3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。
MBeanインタフェース・ファイルとは、実行時クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。
WebLogic MBeanMakerでは、作成済みのMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでMyAdjudicator
MDFを実行すると、MyAdjudicatorMBean.java
というMBeanインタフェース・ファイルが生成されます。
WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム裁決プロバイダのMBeanファイルと実行時クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。
カスタム裁決プロバイダのMJFを作成するには、次の手順に従います。
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMJF
フラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。
この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。
注意: カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの衝突を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。 |
生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。
MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypes
ディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム裁決プロバイダが「デプロイ」されます。つまり、カスタム裁決プロバイダをWebLogic Server管理コンソールから管理できるようになります。
注意: WL_HOME\server\lib\mbeantypes は、MBeanタイプのインストール用のデフォルト・ディレクトリです。(9.0から、セキュリティ・プロバイダを...\domaindir\lib\mbeantypes からロードすることもできるようになりました。)ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir> コマンド・ライン・フラグを使用すれば、WebLogic Serverは追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に、まずWL_HOME\server\lib\mbeantypes からMBeanタイプをロードします。次に、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。
たとえば、 |
カスタム裁決プロバイダを構成することによって(「管理コンソールによるカスタム裁決プロバイダの構成」を参照) MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用できます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。
カスタム裁決プロバイダを構成するということは、裁決サービスを必要とするアプリケーションがアクセス可能なセキュリティ・レルムにカスタム裁決プロバイダを追加するということです。
カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。WebLogic Server管理コンソールを使用してカスタム裁決プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。