WebLogic Security サービスの開発
|
 |
 |
|
資格マッピングとは、対象リソースにアクセスするユーザを認証するための適切な資格群を、レガシー システムの認証メカニズムを用いて取得するプロセスのことです。WebLogic Server では、資格マッピング プロバイダを使用して資格マッピング サービスを提供し、新しいタイプの資格を WebLogic Server 環境に導入します。
以下の節では、資格マッピング プロバイダの概念と機能、およびカスタム資格マッピング プロバイダの開発手順について説明します。
サブジェクト、つまり WebLogic リソース リクエストの発信元は、資格というセキュリティ関連の属性を持っています。資格には、新しいサービスにアクセスするサブジェクトを認証するための情報が含まれています。こうした資格には、ユーザ名/パスワードの組み合わせ、Kerberos チケット、および公開鍵証明書などがあります。また、サブジェクトが特定のアクティビティを実行することを許可するデータも資格に含まれています。たとえば、暗号鍵が表す資格を持っていれば、サブジェクトは署名したり、データを暗号化したりすることができます。
資格マップは、WebLogic Server で使用する資格と、レガシー システムで使用する資格とのマップです。WebLogic Server は、このマップによって、そのシステム内の特定のリソースへの接続方法を知ります。つまり、資格マップを使用することで、WebLogic Server は認証済みサブジェクトに代わってリモート システムにログインできます。資格マッピング プロバイダを開発すると、資格をこのようにマップできます。
資格マッピング プロバイダと WebLogic Security フレームワークとの対話を 図 10-1 に示し、その後それについて説明します。
図 10-1 資格マッピング プロバイダと資格マッピング プロセス
WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic 資格マッピング プロバイダが含まれています。WebLogic 資格マッピング プロバイダは、WebLogic Server のユーザおよびグループを、他の外部システムが必要とする適切なユーザ名/パスワード資格にマップします。必要な資格マッピングが WebLogic Server のユーザおよびグループと他のシステムのユーザ名/パスワードとの間のマッピングであれば、WebLogic 資格マッピング プロバイダで十分です。しかし、WebLogic Server のユーザおよびグループを他のタイプの資格 (Kerberos チケットなど) にマップしたい場合は、カスタム資格マッピング プロバイダを開発する必要があります。
WebLogic 資格マッピング プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム資格マッピング プロバイダを開発することができます。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格マッピング プロバイダの実行時クラスを作成します。
注意 : セキュリティ レルムでは、少なくとも 1 つの資格マッピング プロバイダが DeployableCredentialProvider SSPI を実装する必要があり、そうでなければリソース アダプタをデプロイすることが不可能になります。
CredentialProvider SSPI を実装するには、「「Provider」SSPI の目的を理解する」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getCredentialProvider メソッドは、CredentialMapper SSPI の実装を取得します。図 2-3 にあるような MyCredentialMapperProviderImpl.java という 1 つの実行時クラスの場合、getCredentialProvider メソッドの実装は次のようになります。
この理由は、CredentialProvider SSPI を実装する実行時クラスが、CredentialMapper SSPI を実装するクラスを取得するためのファクトリとして使用されるからです。
CredentialProvider SSPI と getCredentialProvider メソッドの詳細については、WebLogic Server 8.1 API リファレンス Javadoc を参照してください。
DeployableCredentialProvider SSPI を実装するには、「「Provider」SSPI の目的を理解する」および「CredentialProvider SSPI を実装する」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
public void deployCredentialMapping(Resource resource, String initiatingPrincipal, String eisUsername, String eisPassword)throws ResourceCreationException;
deployCredentialMapping メソッドは、資格マップをデプロイします (つまり、デプロイ済みのリソース アダプタに代わって資格マッピングをデータベースに作成します)。マッピングがすでに存在する場合、マッピングは削除され、このマッピングによって置き換えられます。resource パラメータは、String で表される開始元プリンシパルがアクセスを要求している WebLogic リソースを表します。エンタープライズ情報システム (EIS) のユーザ名およびパスワードは、資格のマップ先のレガシー システム (リモート システム) における資格です。
注意 : deployCredentialMapping/undeployCredentialMappings メソッドは、ユーザ名/パスワード資格のみを操作します。
DeployableCredentialProvider SSPI と deployCredentialMapping および undeployCredentialMappings メソッドの詳細については、「WebLogic Server 8.1 API リファレンス Javadoc」を参照してください。
CredentialMapper SSPI を実装するには、以下のメソッドの実装を提供する必要があります。
public java.util.Vector getCredentials(Subject requestor, Subject initiator, Resource resource, String[] credentialTypes);
getCredentials メソッドは、サブジェクトの ID に基づいて、対象リソースの適切な資格群を取得します。このバージョンのメソッドは、リモート システムのデータベースに照会して、サブジェクト内のすべてのプリンシパルに関して一致する資格のリストを (ベクトルとして) 返します。
CredentialMapper SSPI と getCredentials メソッドの詳細については、「WebLogic Server 8.1 API リファレンス Javadoc」を参照してください。
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループはその後、資格マッピング プロバイダなど、他のタイプのセキュリティ プロバイダによって、サブジェクトから抽出されます。セキュリティ レルム内でコンフィグレーションされた認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザおよびグループの情報もまた、少し異なる方法で抽出する必要があります。
コード リスト 10-1 では、サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするために、カスタム資格マッピング プロバイダが使用できるコードを示しています。このコードは、実装することを選択した getCredentials メソッドの形式に属しています。
コード リスト 10-1 サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするサンプル コード
/**
* サブジェクトがユーザ/グループ名に一致するかどうかを判断する
*
* @param principalWant このロール内のプリンシパルの名前を含む文字列
* (ロール定義)
*
* @param subject ユーザのグループだけでなくリソースにもアクセスしようとしている
* ユーザを識別するプリンシパルを含むサブジェクト
*
* @return 現在のサブジェクトがロール内のプリンシパル名に一致していれば true、
* それ以外の場合は false の boolean
*/
private boolean subjectMatches(String principalWant, Subject subject)
{
// 最初に、グループ名の一致かどうかを確認
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// 2 番目に、ユーザ名の一致かどうかを確認
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// 一致せず
return false;
}
カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格マッピング プロバイダの MBean タイプを作成します。
注意 : これらの手順の実行方法は、いくつかのサンプル セキュリティ プロバイダ (dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能) に示されています。
この節で説明する手順はすべて、Windows 環境での作業を想定しています。
MBean 定義ファイル (MDF) を作成するには、次の手順に従います。
注意 : MDF 要素の構文についての完全なリファレンスは、「MBean 定義ファイル (MDF) 要素の構文」に収められています。
MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。
MBean タイプの生成手順は、カスタム資格マッピング プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム資格マッピング プロバイダの MDF に任意 SSPI MBean もカスタム操作も実装しない場合、次の手順に従います。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまり資格マッピング プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
カスタム資格マッピング プロバイダの MDF に任意 SSPI MBean またはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまり資格マッピング プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。たとえば、MyCredentialMapper という MDF の場合には、編集すべき MBean 実装ファイルの名前は MyCredentialMapperImpl.java です。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまり資格マッピング プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。たとえば、SampleCredentialMapper という MDF の場合には、編集すべき MBean 実装ファイルの名前は SampleCredentialMapperImpl.java です。
これには、メソッドの実装を既存の MBean 実装ファイルから新しく生成された MBean 実装ファイルにコピー (または、新しく生成された MBean 実装ファイルから既存の MBean 実装ファイルに新しいメソッドを追加) し、いずれの MBean 実装ファイルにも入っているメソッドのメソッド シグネチャへの変更が使用する MBean 実装ファイルに反映されていることを確認するといった作業が必要です。
MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「「Provider」SSPI の目的を理解する」で説明されているように、これは initialize メソッドで使用するのが一般的です。
WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker で MyCredentialMapper MDF を実行すると、MyCredentialMapperMBean.java という MBean インタフェース ファイルが生成されます。
WebLogic MBeanMaker で MDF を実行して中間ファイルを作成し、MBean 実装ファイルを手作業で編集してその中にメソッドの内容を記述したら、カスタム資格マッピング プロバイダの MBean ファイルと実行時クラスを MBean JAR ファイル (MJF) にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMaker によって自動化されます。
カスタム資格マッピング プロバイダの MJF を作成するには、次の手順に従います。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMJF フラグは WebLogic MBeanMaker が新しい MBean タイプを含む JAR ファイルを構築すべきであることを示し、jarfile は MJF の名前、filesdir は WebLogic MBeanMaker で MJF に JAR 化する対象ファイルが存在する場所を示します。
この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfile が指定されていて、エラーが発生しなかった場合には、指定された名前の MJF が作成されます。
注意 : 既存の MJF を更新する場合は、MJF をいったん削除してから再生成します。WebLogic MBeanMaker にも -DIncludeSource オプションがあり、それを指定すると、生成される MJF にソース ファイルを含めるかどうかを制御することができます。ソース ファイルには、生成されたソースと MDF そのものがあります。デフォルトは false です。このオプションは、-DMJF を使用しない場合には無視されます。
生成された MJF は、自らの WebLogic Server 環境にインストールすることも、顧客に配布してそれぞれの WebLogic Server 環境にインストールしてもらうこともできます。
MBean タイプを WebLogic Server 環境にインストールするには、MJF を WebLogic Server の WL_HOME\server\lib\mbeantypes ディレクトリにコピーします。ここで、WL_HOME は WebLogic Server の最上位のインストール ディレクトリです。このインストール コマンドによって、カスタム資格マッピング プロバイダが「デプロイ」されます。つまり、カスタム資格マッピング プロバイダを WebLogic Server Administration Console から管理できるようになります。
注意 : MBean タイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypes です。ただし、サーバを起動するときに -Dweblogic.alternateTypesDirectory=<dir> コマンドライン フラグを使用すれば、WebLogic Server が追加ディレクトリで MBean タイプを検索します。<dir> は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Server は常に最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードします。たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirY の場合、WebLogic Server は最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードしてから、dirX および dirY にある有効なアーカイブをロードします。WebLogic Server に追加ディレクトリで MBean タイプを検索するように指示する際に Java セキュリティ マネージャを使用している場合には、weblogic.policy ファイルを更新して、MBean タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『WebLogic Security プログラマーズ ガイド』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。
カスタム資格マッピング プロバイダをコンフィグレーションすることによって (「Administration Console を使用してカスタム資格マッピング プロバイダをコンフィグレーションする」を参照) MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。詳細については、『WebLogic Server のコンフィグレーションと管理』の「障害が発生したサーバの回復」の「セキュリティ データのバックアップ」を参照してください。
カスタム資格マッピング プロバイダをコンフィグレーションするということは、資格マッピング サービスを必要とするアプリケーションがアクセス可能なセキュリティ レルムにカスタム資格マッピング プロバイダを追加するということです。
カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。この節では、カスタム資格マッピング プロバイダのコンフィグレーション担当者向けの重要な情報を取り上げます。
注意 : WebLogic Server Administration Console を使用してカスタム資格マッピング プロバイダをコンフィグレーションする手順は、『WebLogic Security の管理』の「カスタム セキュリティ プロバイダのコンフィグレーション」で説明されています。
エンタープライズ JavaBean (EJB) や Web アプリケーションなどのアプリケーションの中には、関連デプロイメント情報を Java 2 Enterprise Edition (J2EE) デプロイメント記述子に格納するものがあります。リソース アダプタの場合、デプロイメント記述子ファイル (weblogic-ra.xml) には、ユーザ名/パスワードの組み合わせなど、資格マップを作成するための情報が含まれます。この資格マップ情報は、WebLogic Server Administration Console で資格マッピング プロバイダを初めてコンフィグレーションするときに含めるのが一般的です。
Administration Console には、この目的のために [デプロイの資格マッピングを無視] チェック ボックスが用意されています。開発者または管理者は、カスタム資格マッピング プロバイダを初めてコンフィグレーションするときに、このチェック ボックスのチェックがはずれていることを確認する必要があります。
注意 : [デプロイの資格マッピングを無視] チェック ボックスはデフォルトでチェックがはずれています。[デプロイの資格マッピングを無視] チェック ボックスにアクセスするには、Administration Console の左ペインで [セキュリティ｜レルム｜realm] (realm はセキュリティ レルムの名前) をクリックします。
[デプロイの資格マッピングを無視] チェック ボックスのチェックをはずしてリソース アダプタ (コネクタ) をデプロイすると、WebLogic Server は、コード リスト 10-2 に例を示した weblogic-ra.xml デプロイメント記述子から資格マップを読み出します。この情報は、資格マッピング プロバイダのセキュリティ プロバイダ データベースにコピーされます。
コード リスト 10-2 weblogic-ra.xml ファイルのサンプル
<weblogic-connection-factory-dd>
<connection-factory-name>LogicalNameOfBlackBoxNoTx</connection-factory-name>
<jndi-name>eis/BlackBoxNoTxConnectorJNDINAME</jndi-name>
<map-config-property>
<map-config-property-name>ConnectionURL</map-config-property-name>
<map-config-property-value>jdbc:pointbase:server://localhost/demo
<map-config-property-value>
</map-config-property>
<security-principal-map>
<map-entry>
<initiating-principal>*</initiating-principal>
<resource-principal>
<resource-username>examples</resource-username>
<resource-password>examples</resource-password>
</resource-principal>
</map-entry>
</security-principal-map>
</weblogic-connection-factory-dd>
注意 : コード リスト 10-2 に示したサンプル リソース アダプタのデプロイメント記述子は、WL_HOME\samples\server\src\examples\jconnector\simple\rars\META-INF にあります。WL_HOME は、WebLogic Server の最上位インストール ディレクトリです。
デプロイメント記述子ファイルでも Administration Console でも追加の資格マップを設定することができますが、リソース アダプタのデプロイメント記述子に定義されている資格マップをいったんコピーしてから、Administration Console を使用して追加の資格マップを定義することをお勧めします。この理由は、資格マッピング プロバイダのコンフィグレーション中に Administration Console を使用して資格マップを変更すると、その内容が weblogic-ra.xml ファイルに保持されないからです。Administration Console を使用して再デプロイする、ディスク上でリソース アダプタ (コネクタ) を変更した、または WebLogic Server を再起動したといった場合に、リソース アダプタ (コネクタ) を再デプロイするときには、[デプロイの資格マッピングを無視] チェック ボックスをチェックする必要があります。チェック ボックスをチェックしないと、Administration Console を使用して定義した資格マッピングがデプロイメント記述子で定義されている資格マップによって上書きされます。
カスタム資格マッピング プロバイダの開発の一環として DeployableCredentialProvider SSPI を実装し、カスタム資格マッピング プロバイダでデプロイ可能な資格マップをサポートしたい場合、カスタム資格マッピング プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、Administration Console で [資格マッピング デプロイメントを有効化] チェック ボックスがチェックされていることを確認する必要があります。チェックがはずれていると、資格マッピング プロバイダに対するデプロイメントは「オフ」と見なされます。このため、複数の資格マッピング プロバイダがコンフィグレーションされている場合、[資格マッピング デプロイメントを有効化] チェック ボックスを使用して、資格マップのデプロイメントに使用する資格マッピング プロバイダを指定できます。
注意 : [デプロイの資格マッピングを無視] チェック ボックス (「資格マッピング プロバイダ、リソース アダプタ、およびデプロイメント記述子の管理」で説明したようにセキュリティ レルム レベルで指定) では、コンフィグレーション済みの資格マッピング プロバイダのセキュリティ データベースに資格マップをコピーするかどうかを指定します。[資格マッピング デプロイメントを有効化] チェック ボックス (コンフィグレーション済みの資格マッピング プロバイダごとに指定) では、資格マッピング プロバイダがデプロイ済みの資格マップを格納するかどうかを指定します。
WebLogic Server Administration Console を使用してカスタム資格マッピング プロバイダをコンフィグレーションすると、必要な資格マッピング サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられた資格マップを管理する方法を管理者にも提供する必要があります。たとえば WebLogic 資格マッピング プロバイダには、資格マッピング ページ (図 10-2 を参照) が管理者向けに用意されており、コネクタ モジュールを右クリックして [資格マッピングの定義] オプションを選択すると、さまざまなコネクタ モジュールの資格マッピングを追加、変更、または削除することができます。
図 10-2 WebLogic 資格マッピング プロバイダの資格マッピング ページ
カスタム資格マッピング プロバイダを開発すると、管理者は資格マッピング ページも右クリック メニューも利用できません。したがって、資格マップを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム資格マッピング プロバイダのデータベースの資格マップを読み書きできなければなりません。
カスタム資格マッピング プロバイダ用にコンソール拡張を作成する方法の主な利点は、WebLogic リソースの ID が自動的にわかるので、その WebLogic リソースがリソース階層のどこにあるかもわかるということです。この情報は、資格マッピング プロバイダのデータベースから式を読み書きするために必要です。また、WebLogic 資格マッピング プロバイダの資格マッピング ページのように、作成したページを既存の WebLogic Server Administration Console の GUI に統合できるという利点もあります。
weblogic.management.console.extensibility.SecurityExtensionV2 インタフェースの getExtensionForUserPasswordCredential() および getExtentionForUserPasswordCredentialMapping() メソッドを実装します。 getExtensionForUserPasswordCredential() メソッドの実装で、リソース ID/リモート ユーザとリモート ユーザ パスワードとのマッピングを定義したページを返すようにします。getExtentionForUserPasswordCredentialMapping() メソッドの実装で、WebLogic リソース ID/WebLogic ユーザとリモート ユーザ パスワードとのマッピングを定義したページを返すようにします。
注意 : 詳細については、「カスタム セキュリティ プロバイダ用のコンソール拡張の記述」を参照してください。
UserPasswordCredentialMapEditor および UserPasswordCredentialMapReader 資格マッピング用任意 SSPI MBean を実装し、作成した資格マッピング ページとカスタム資格マッピング プロバイダのデータベースとの間の仲介役となる管理 MBean を開発します。詳細については、「拡張および実装する SSPI MBean を決定する」と「表 2-5」 を参照してください。WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法の場合、「オプション 1 : コンソール拡張を使用して独自の「資格マッピング」ページを作成する」で説明したカスタム資格マッピング プロバイダ用のコンソール拡張を記述する必要もなく、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
|
|
|