Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 11g リリース1(10.3.4) B61623-02 |
|
![]() 前 |
![]() 次 |
資格証明マッピングとは、対象リソースにアクセスするユーザーを認証するための適切な資格証明群を、レガシー・システムの認証メカニズムを用いて取得するプロセスのことです。WebLogic Serverでは、資格証明マッピング・プロバイダを使用して資格証明マッピング・サービスを提供し、新しいタイプの資格証明をWebLogic Server環境に導入します。
以下の節では、資格証明マッピング・プロバイダの概念と機能、およびカスタム資格証明マッピング・プロバイダの開発手順について説明します。
サブジェクト、つまりWebLogicリソース・リクエストの発信元は、資格証明というセキュリティ関連の属性を持っています。資格証明には、新しいサービスにアクセスするサブジェクトを認証するための情報が含まれています。こうした資格証明には、ユーザー名/パスワードの組合せ、Kerberosチケット、および公開鍵証明書などがあります。また、サブジェクトが特定のアクティビティを実行することを許可するデータも資格証明に含まれています。たとえば、暗号鍵が表す資格証明を持っていれば、サブジェクトは署名したり、データを暗号化したりすることができます。
資格証明マップは、WebLogic Serverで使用する資格証明と、レガシー・システムで使用する資格証明とのマップです。WebLogic Serverは、このマップによって、そのシステム内の特定のリソースへの接続方法を知ります。つまり、資格証明マップを使用することで、WebLogic Serverは認証済みサブジェクトにかわってリモート・システムにログインできます。資格証明マッピング・プロバイダを開発すると、資格証明をこのようにマップできます。
資格証明マッピング・プロセスにおける資格証明マッピング・プロバイダとWebLogic Securityフレームワークとの対話を図11-1に示し、続いてそれについて説明します。
一般に、資格証明マッピングは以下のように実行されます。
JavaServer Page (JSP)、サーブレット、Enterprise JavaBeans (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および2.0アサーションを生成します。要求された対象が、コンフィグレーションされておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザー情報およびグループ・メンバーシップは、(そのようにコンフィグレーションされた場合)AttributeStatement内に置かれます。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』のSAML SSO属性サポートのコンフィグレーションに関する項で説明されているように、WebLogic Serverでは、追加属性(グループ情報以外)を取得してSAMLアサーションに書き込んだり、着信SAMLアサーションからの属性のマップを可能にするカスタム属性マッパーの使用をサポートするために、SAML 1.1および2.0の資格証明マッピング・プロバイダとアイデンティティ・アサーション・プロバイダのメカニズムが強化されています。
SAML資格証明マッピング・プロバイダでは、CredentialMapperV2.SAML_ASSERTION_B64_TYPE
、CredentialMapperV2.SAML_ASSERTION_DOM_TYPE
、およびCredentialMapperV2.SAML_ASSERTION_TYPE
の各トークン・タイプがサポートされています。
SAML 2.0資格証明マッピング・プロバイダでは、CredentialMapperV2.SAML2_ASSERTION_DOM_TYPE
トークン・タイプおよびCredentialMapperV2.SAML2_ASSERTION_TYPE
トークン・タイプがサポートされています。
初期状態の資格証明マッピング・プロバイダが開発者のニーズを満たさない場合は、カスタム資格証明マッピング・プロバイダを開発する必要があります。ただし、WebLogic Serverリソース・コンテナでリクエストされるのは、次のトークンの種類のみです。
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.SAML2_ASSERTION_DOM_TYPE
CredentialMapperV2.SAML2_ASSERTION_TYPE
CredentialMapperV2.USER_PASSWORD_TYPE
セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール・マッピング、または資格証明マッピング用にカスタム・セキュリティ・プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。
WebLogic資格証明マッピング・プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム資格証明マッピング・プロバイダを開発することができます。
実行時クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格証明マッピング・プロバイダの実行時クラスを作成します。
CredentialProviderV2
SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getCredentialProvider
public CredentialMapperV2 getCredentialProvider();
getCredentialProviderV2
メソッドはCredentialMapperV2
SSPIの実装を取得します。(図3-3にあるような) java
MyCredentialMapperProviderImpljava
という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
SAML2_ASSERTION_DOM_TYPE
SAML2_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
メソッドは、指定したイニシエータに関連付けられている対象リソースから、指定した種類の資格証明を複数返します。
CredentialMapper
V2 SSPIとgetCredential
およびgetCredentials
メソッドの詳細は、WebLogic Server APIリファレンスJavadocを参照してください。
認証プロバイダは、サブジェクト内へのユーザーおよびグループの格納を担当するセキュリティ・プロバイダです。ユーザーおよびグループはその後、資格証明マッピング・プロバイダなど、他のタイプのセキュリティ・プロバイダによって、サブジェクトから抽出されます。セキュリティ・レルム内で構成された認証プロバイダがレルム・アダプタ認証プロバイダである場合、ユーザーおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザーおよびグループの情報もまた、少し異なる方法で抽出する必要があります。
例11-1では、サブジェクトへの格納にレルム・アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザー名またはグループ名に一致するかどうかをチェックするため、カスタム資格証明マッピング・プロバイダで使用できるコードを示します。このコードは、実装することを選択したgetCredentials
メソッドの形式に属しています。コードでは、weblogic.security.SubjectUtils
クラスで使用可能なメソッドを利用します。
例11-1 サンプル・コード:サブジェクトがユーザー名またはグループ名に一致するかどうかのチェック
/** * Determines if the Subject matches a user/group name. * * @param principalWant A String containing the name of a principal in this role * (that is, the role definition). * * @param subject A Subject that contains the Principals that identify the user * who is trying to access the resource as well as the user's groups. * * @return A boolean. true if the current subject matches the name of the * principal in the role, false otherwise. */ private boolean subjectMatches(String principalWant, Subject subject) { // first, see if it's a group name match if (SubjectUtils.isUserInGroup(subject, principalWant)) { return true; } // second, see if it's a user name match if (principalWant.equals(SubjectUtils.getUsername(subject))) { return true; } // didn't match return false; }
カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格証明マッピング・プロバイダのMBeanタイプを作成します。
WebLogic Server環境にMBeanタイプをインストールする
注意: この手順の実行方法を説明するサンプル・セキュリティ・プロバイダ(Oracle Technology Network Webサイトのhttps://codesamples.samplecode.oracle.com/servlets/tracking?id=S224 から入手可能)がいくつか用意されています。
この節で説明する手順はすべて、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管理コンソールから管理できるようになります。
注意: 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管理コンソールを使用してカスタム資格証明マッピング・プロバイダを構成すると、必要な資格証明マッピング・サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ・プロバイダに関連付けられた資格証明マップを管理する方法を管理者にも提供する必要があります。たとえばWebLogic資格証明マッピング・プロバイダには、資格証明マッピング・ページが管理者向けに用意されており、様々なコネクタ・モジュールの資格証明マッピングを追加、変更、または削除することができます。
カスタム資格証明マッピング・プロバイダを開発すると、管理者は資格証明マッピング・ページも右クリック・メニューも利用できません。したがって、資格証明マップを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム資格証明マッピング・プロバイダのデータベースの資格証明マップを読み書きできなければなりません。
それには、以下の2通りの方法があります。
WebLogic Server管理コンソールとまったく別のツールを開発する場合には、この方法を選択します。
この方法では、カスタム資格証明マッピング・プロバイダ向けにコンソール拡張を作成する必要も、管理MBeanを開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogicリソース識別子」を参照してください。
ローカル・ユーザーとリモート・ユーザーとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。
カスタム資格証明マッピング・プロバイダのデータベースの式を読み書きします。
WebLogic Server管理コンソールとは別のツールを持っており、それを管理コンソールから起動する場合には、この方法を選択します。
この方法の場合、ツールでは以下のことを行う必要があります。
WebLogicリソースのIDを特定します。詳細については、「WebLogicリソース識別子」を参照してください。
ローカル・ユーザーとリモート・ユーザーとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。
カスタム資格証明マッピング・プロバイダのデータベースの式を読み書きします。
『Oracle WebLogic Server管理コンソールの拡張』で説明されているように、基本的なコンソール拡張手法を使用して管理コンソールにリンクします。