| Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発 11g リリース 1 (10.3.1) B55527-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発 11g リリース 1 (10.3.1) B55527-01 |
|
戻る |
次へ |
資格マッピングとは、対象リソースにアクセスするユーザを認証するための適切な資格群を、レガシー システムの認証メカニズムを用いて取得するプロセスのことです。WebLogic Server では、資格マッピング プロバイダを使用して資格マッピング サービスを提供し、新しいタイプの資格を WebLogic Server 環境に導入します。
以下の節では、資格マッピング プロバイダの概念と機能、およびカスタム資格マッピング プロバイダの開発手順について説明します。
サブジェクト、つまり WebLogic リソース要求の発信元は、資格というセキュリティ関連の属性を持っています。資格には、新しいサービスにアクセスするサブジェクトを認証するための情報が含まれています。こうした資格には、ユーザ名/パスワードの組み合わせ、Kerberos チケット、および公開鍵証明書などがあります。また、サブジェクトが特定のアクティビティを実行することを許可するデータも資格に含まれています。たとえば、暗号鍵が表す資格を持っていれば、サブジェクトは署名したり、データを暗号化したりすることができます。
資格マップは、WebLogic Server で使用する資格と、レガシー システムで使用する資格とのマップです。WebLogic Server は、このマップによって、そのシステム内の特定のリソースへの接続方法を知ります。つまり、資格マップを使用することで、WebLogic Server は認証済みサブジェクトに代わってリモート システムにログインできます。資格マッピング プロバイダを開発すると、資格をこのようにマップできます。
資格マッピング プロセスにおける資格マッピング プロバイダと WebLogic Security フレームワークとの対話を図 11-1 に示し、続いてそれについて説明します。
一般に、資格マッピングは以下のように実行されます。
JavaServer Page (JSP)、サーブレット、エンタープライズ JavaBean (EJB)、リソース アダプタなどのアプリケーション コンポーネントは、適切なリソース コンテナを通じて WebLogic Security フレームワークを呼び出します。呼び出しの中で、アプリケーション コンポーネントは、サブジェクト (「誰が」要求しているのか)、WebLogic リソース (「何を」要求しているのか)、および WebLogic リソースにアクセスするために必要な資格のタイプについての情報を渡します。
WebLogic Security フレームワークは、資格に対するアプリケーション コンポーネントの要求をコンフィグレーション済み資格マッピング プロバイダに送信します。トークンをサポートするかどうかは、資格マッピング プロバイダによって異なります。トークンをサポートしている場合は、その処理が行われます。
資格マッピング プロバイダは、レガシー システムのデータベースを照会して、アプリケーション コンポーネントが要求しているものに一致する資格群を取得します。
資格マッピング プロバイダは、資格を WebLogic Security フレームワークに返します。
WebLogic Security フレームワークは、リソース コンテナを通じて要求側のアプリケーション コンポーネントに資格を返します。
アプリケーション コンポーネントは、資格を使用して外部システムにアクセスします。外部システムには、Oracle や SQL Server などのデータベース リソースがあります。
WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic 資格マッピング プロバイダが含まれています。WebLogic 資格マッピング プロバイダは、WebLogic Server のユーザおよびグループを、他の外部システムが必要とする適切なユーザ名/パスワード資格にマップします。必要な資格マッピングが WebLogic Server のユーザおよびグループと他のシステムのユーザ名/パスワードとの間のマッピングであれば、WebLogic 資格マッピング プロバイダで十分です。
WebLogic Server には、PKI 資格マッピング プロバイダがあります。WebLogic Server の PKI (公開鍵インフラストラクチャ) 資格マッピング プロバイダは、WebLogic Server のサブジェクト (開始者) と対象リソース (および必要であれば資格アクション) を、対象リソースを使用する際にアプリケーションで使用するキー ペアまたは公開証明書にマップします。PKI 資格マッピング プロバイダは、サブジェクトとリソース名を使用して対応する資格をキーストアから検索します。PKI 資格マッピング プロバイダで使用可能なトークンの種類は CredentialMapperV2.PKI_KEY_PAIR_TYPE と CredentialMapperV2.PKI_TRUSTED_CERTIFICATE_TYPE です。
WebLogic Server には、SAML 資格マッピング プロバイダもあります。SAML 資格マッピング プロバイダは、対象サイトまたはリソースに基づく認証されたサブジェクトに対する SAML 1.1 アサーションを生成します。要求された対象が、コンフィグレーションされておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザ情報およびグループ メンバシップは、(そのようにコンフィグレーションされた場合) AttributeStatement 内に置かれます。SAML 資格マッピング プロバイダで使用可能なトークンの種類は CredentialMapperV2.SAML_ASSERTION_B64_TYPE、CredentialMapperV2.SAML_ASSERTION_DOM_TYPE、および CredentialMapperV2.SAML_ASSERTION_TYPE です。
初期状態の資格マッピング プロバイダが開発者のニーズを満たさない場合は、カスタム資格マッピング プロバイダを開発する必要があります。ただし、WLS リソース コンテナで要求されるのは、以下のトークンの種類のみです。
CredentialMapperV2.PASSWORD_TYPE
CredentialMapperV2.PKI_KEY_PAIR_TYPE
CredentialMapperV2.PKI_TRUSTED_CERTIFICATE_TYPE
CredentialMapperV2.SAML_ASSERTION_B64_TYPE
CredentialMapperV2.SAML_ASSERTION_DOM_TYPE
CredentialMapperV2.SAML_ASSERTION_TYPE
CredentialMapperV2.USER_PASSWORD_TYPE
セキュリティ レルムのすべての認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール マッピング、または資格マッピング用にカスタム セキュリティ プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションの SSPI を実装する必要があります。
WebLogic 資格マッピング プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム資格マッピング プロバイダを開発することができます。
実行時クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格マッピング プロバイダの実行時クラスを作成します。
CredentialProviderV2 SSPI を実装するには、「「Provider」SSPI の目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getCredentialProvider
public CredentialMapperV2 getCredentialProvider();
getCredentialProviderV2 メソッドは CredentialMapperV2 SSPI の実装を取得します。(図 3-3 にあるような) javaMyCredentialMapperProviderImpljava という 1 つの実行時クラスの場合、getCredentialProvider メソッドの実装は次のようになります。
return this;
実行時クラスが 2 つの場合、getCredentialProvider メソッドの実装は次のようになります。
return new MyCredentialMapperImpl;
これは、CredentialProviderV2 SSPI を実装する実行時クラスが、CredentialMapperV2 SSPI を実装するクラスを取得する場合のファクトリとして使用されるためです。
CredentialProviderV2 SSPI と getCredentialProvider メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
|
注意 : DeployableCredentialProvider SSPI は、このリリースの WebLogic Server では非推奨になっています。 |
DeployableCredentialProvider SSPI を実装するには、「「Provider」SSPI の目的について」および「CredentialProviderV2 SSPI の実装」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
deployCredentialMapping
public void deployCredentialMapping(Resource resource, String initiatingPrincipal, String eisUsername, String eisPassword)throws ResourceCreationException;
deployCredentialMapping メソッドは資格マップをデプロイします。マッピングがすでに存在する場合、マッピングは削除され、このマッピングによって置き換えられます。resource パラメータは、String で表される開始元プリンシパルがアクセスを要求している WebLogic リソースを表します。エンタープライズ情報システム (EIS) のユーザ名およびパスワードは、資格のマップ先のレガシー システム (リモート システム) における資格です。
undeployCredentialMappings
public void undeployCredentialMappings(Resource resource) throws ResourceRemovalException;
undeployCredentialMappings メソッドは、資格マップをアンデプロイします (つまり、アンデプロイ済みのリソース アダプタに代わって資格マッピングをデータベースから削除します)。resource パラメータは、マッピングを削除する WebLogic リソースを表します。
|
注意 : deployCredentialMapping メソッド、および undeployCredentialMappings メソッドは、ユーザ名/パスワード資格のみを操作します。 |
DeployableCredentialProvider SSPI、deployCredentialMapping メソッド、および undeployCredentialMappings メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
CredentialMapperV2 インタフェースは、アプリケーション内でスコープされている特定のリソースに対応する資格群を取得できるオブジェクトのセキュリティ サービス プロバイダ インタフェース (SSPI) を定義します。
以下の資格の種類のみがサポートされており、CredentialMapperV2 インタフェースに渡されます。
PASSWORD_TYPE
PKI_KEY_PAIR_TYPE
PKI_TRUSTED_CERTIFICATE_TYPE
SAML_ASSERTION_B64_TYPE
SAML_ASSERTION_DOM_TYPE
SAML_ASSERTION_TYPE
USER_PASSWORD_TYPE
CredentialMapperV2 SSPI を実装するには、以下のメソッドの実装を提供する必要があります。
getCredential
public Object getCredential(Subject requestor, String initiator, Resource resource, ContextHandler handler, String credType);
getCredential メソッドは、指定したイニシエータに関連付けられている対象リソースから、指定した種類の資格を返します。
getCredentials
public Object[] getCredentials(Subject requestor, Subject initiator, Resource resource, ContextHandler handler, String credType);
getCredentials メソッドは、指定したイニシエータに関連付けられている対象リソースから、指定した種類の資格を複数返します。
CredentialMapperV2 SSPI と getCredential および getCredentials メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループはその後、資格マッピング プロバイダなど、他のタイプのセキュリティ プロバイダによって、サブジェクトから抽出されます。セキュリティ レルム内でコンフィグレーションされた認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザおよびグループの情報もまた、少し異なる方法で抽出する必要があります。
コード リスト 11-1 では、サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするため、カスタム資格マッピング プロバイダで使用できるコードを示します。このコードは、実装することを選択した getCredentials メソッドの形式に属しています。コードでは、weblogic.security.SubjectUtils クラスで使用可能なメソッドを利用します。
コード リスト 11-1 サンプル コード : サブジェクトがユーザ名またはグループ名に一致するかどうかのチェック
/**
* サブジェクトがユーザ/グループ名に一致するかどうかを判断する。
*
* @param principalWant このロールのプリンシパル名を含む文字列
* (つまり、ロール定義)。
*
* @param subject リソースにアクセスしようとしているユーザおよびそのユーザのグループを
* 識別するプリンシパルを含むサブジェクト。
*
* @return ブール値。現在のサブジェクトがロールのプリンシパルに
* 一致する場合は true、それ以外の場合は false。
*/
private boolean subjectMatches(String principalWant, Subject subject)
{
// まず、グループ名が一致しているかどうかを調べる
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// 次に、ユーザ名が一致しているかどうかを調べる
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// 一致しなかった場合
return false;
}
カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格マッピング プロバイダの MBean タイプを作成します。
WebLogic Server 環境に MBean タイプのインストール
|
注意 : この節で説明する手順はすべて、Windows 環境での作業を想定しています。 |
MBean 定義ファイル (MDF) を作成するには、次の手順に従います。
サンプル認証プロバイダの MDF をテキスト ファイルにコピーします。
|
注意 : サンプル認証プロバイダの MDF は、SimpleSampleAuthenticator.xml です (現在、サンプル資格マッピング プロバイダはありません)。 |
MDF で <MBeanType> 要素と <MBeanAttribute> 要素の内容をカスタム資格マッピング プロバイダに合わせて修正します。
カスタム属性および操作 (つまり、<MBeanAttribute> および <MBeanOperation> 要素) を MDF に追加します。
ファイルを保存します。
MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。
MBean タイプの生成手順は、カスタム資格マッピング プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム資格マッピング プロバイダの MDF に任意 SSPI 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 に任意 SSPI MBean またはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。
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 (つまり資格マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
任意 SSPI MBean を MDF に実装した場合は、次の手順に従います。
MBean 実装ファイルを見つけます。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。 たとえば、MyCredentialMapper という MDF の場合には、編集すべき MBean 実装ファイルの名前は MyCredentialMapperImpl.java です。
MDF で実装した任意 SSPI MBean ごとに、各メソッドを実装します。任意 SSPI MBean が継承するメソッドもすべて実装してください。
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 (つまり資格マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
任意 SSPI MBean を MDF に実装した場合は、次の手順に従います。
MBean 実装ファイルを見つけます。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。 たとえば、SampleCredentialMapper という MDF の場合には、編集すべき MBean 実装ファイルの名前は SampleCredentialMapperImpl.java です。
手順 1 で一時ディレクトリに保存した既存の MBean 実装ファイルを開きます。
既存の MBean 実装ファイルを、WebLogic MBeanMaker によって生成された MBean 実装ファイルと同期させます。
これには、メソッドの実装を既存の MBean 実装ファイルから新しく生成された MBean 実装ファイルにコピー (または、新しく生成された MBean 実装ファイルから既存の MBean 実装ファイルに新しいメソッドを追加) し、いずれの MBean 実装ファイルにも入っているメソッドのメソッド シグネチャへの変更が、使用する MBean 実装ファイルに反映されていることを確認するといった作業が必要です。
MDF を修正して元の MDF にはない任意 SSPI MBean を実装した場合は、各メソッドを実装します。任意 SSPI MBean が継承するメソッドもすべて実装してください。
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 で MyCredentialMapper MDF を実行すると、MyCredentialMapperMBean.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 Administration Console から管理できるようになります。
|
注意 : MBean タイプのインストール用のディレクトリは、デフォルトではWL_HOME\server\lib\mbeantypes ですが、初めて使用するバージョンが 9.0 の場合、セキュリティ プロバイダは ...\domaindir\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 タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズガイド』の「Java セキュリティを使用しての WebLogic リソースの保護」を参照してください。 |
カスタム資格マッピング プロバイダをコンフィグレーションすることによって (「資格マップを管理するためのメカニズムの提供」を参照) MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。
WebLogic Server Administration Console を使用してカスタム資格マッピング プロバイダをコンフィグレーションすると、必要な資格マッピング サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられた資格マップを管理する方法を管理者にも提供する必要があります。たとえば WebLogic 資格マッピング プロバイダには、資格マッピング ページが管理者向けに用意されており、さまざまなコネクタ モジュールの資格マッピングを追加、変更、または削除することができます。
カスタム資格マッピング プロバイダを開発すると、管理者は資格マッピング ページも右クリック メニューも利用できません。したがって、資格マップを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム資格マッピング プロバイダのデータベースの資格マップを読み書きできなければなりません。
それには、以下の 2 通りの方法があります。
WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法では、カスタム資格マッピング プロバイダ向けにコンソール拡張を作成する必要も、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogic リソースの ID を特定します。ID がコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogic リソース識別子」を参照してください。
ローカル ユーザとリモート ユーザとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。
カスタム資格マッピング プロバイダのデータベースの式を読み書きします。
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
この方法の場合、ツールでは以下のことを行う必要があります。
WebLogic リソースの ID を特定します。詳細については、「WebLogic リソース識別子」を参照してください。
ローカル ユーザとリモート ユーザとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。
カスタム資格マッピング プロバイダのデータベースの式を読み書きします。
『Oracle Fusion Middleware Oracle WebLogic ServerAdministration Console の拡張』に説明されているように、基本コンソール拡張を使用して Administration Console にリンクします。
