ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発
11gリリース1(10.3.6)
B61623-04
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

11 資格証明マッピング・プロバイダ

資格証明マッピングとは、ターゲット・リソースにアクセスするユーザーを認証するための適切な資格証明のセットを、レガシー・システムのデータベースを用いて取得するプロセスのことです。WebLogic Serverでは、資格証明マッピング・プロバイダを使用して資格証明マッピング・サービスを提供し、新しいタイプの資格証明をWebLogic Server環境に導入します。

以下の節では、資格証明マッピング・プロバイダの概念と機能、およびカスタム資格証明マッピング・プロバイダの開発手順について説明します。

資格証明マッピングの概念

サブジェクト、つまりWebLogicリソース・リクエストの発信元は、資格証明というセキュリティ関連の属性を持っています。資格証明には、新しいサービスにアクセスするサブジェクトを認証するための情報が含まれています。こうした資格証明には、ユーザー名/パスワードの組合せ、Kerberosチケット、および公開鍵証明書などがあります。また、サブジェクトが特定のアクティビティを実行することを許可するデータも資格証明に含まれています。たとえば、暗号鍵が表す資格証明を持っていれば、サブジェクトは署名したり、データを暗号化したりすることができます。

資格証明マップは、WebLogic Serverが使用する資格証明と、レガシー・システム(または任意のリモート・システム)で使用する資格証明とのマッピングです。これにより、WebLogic Serverは、そのシステム内の特定のリソースへの接続方法を知ります。つまり、資格証明マップを使用することで、WebLogic Serverは認証済みサブジェクトに代わってリモート・システムにログインできます。資格証明マッピング・プロバイダを開発すると、資格証明をこのようにマップできます。

資格証明マッピング・プロセス

資格証明マッピング・プロセスにおける資格証明マッピング・プロバイダとWebLogicセキュリティ・フレームワークとの対話を図11-1に示し、続いてそれについて説明します。

図11-1 資格証明マッピング・プロバイダと資格証明マッピング・プロセス

図11-1の説明が続きます
「図11-1 資格証明マッピング・プロバイダと資格証明マッピング・プロセス」の説明

一般に、資格証明マッピングは以下のように実行されます。

  1. JavaServer Page (JSP)、サーブレット、Enterprise JavaBeans (EJB)、リソース・アダプタなどのアプリケーション・コンポーネントは、適切なリソース・コンテナを通じてWebLogicセキュリティ・フレームワークを呼び出します。呼出しの中で、アプリケーション・コンポーネントは、サブジェクト(「誰が」リクエストしているのか)、WebLogicリソース(「何を」リクエストしているのか)、およびWebLogicリソースにアクセスするために必要な資格証明のタイプについての情報を渡します。

  2. WebLogicセキュリティ・フレームワークは、資格証明に対するアプリケーション・コンポーネントのリクエストを構成済み資格証明マッピング・プロバイダに送信します。トークンをサポートするかどうかは、資格証明マッピング・プロバイダによって異なります。トークンをサポートしている場合は、その処理が行われます。

  3. 資格証明マッピング・プロバイダは、レガシー・システムのデータベースを照会して、アプリケーション・コンポーネントがリクエストしているものに一致する資格証明群を取得します。

  4. 資格証明マッピング・プロバイダは、資格証明をWebLogicセキュリティ・フレームワークに返します。

  5. WebLogicセキュリティ・フレームワークは、リソース・コンテナを通じてリクエスト側のアプリケーション・コンポーネントに資格証明を返します。

    アプリケーション・コンポーネントは、資格証明を使用して外部システムにアクセスします。外部システムには、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_TYPECredentialMapperV2.PKI_TRUSTED_CERTIFICATE_TYPEです。

また、WebLogic ServerにはSAML資格証明マッピング・プロバイダが含まれています。SAML資格証明マッピング・プロバイダでは、ターゲットのサイトまたはリソースに基づく認証されたサブジェクトに対するSAML 1.1および2.0アサーションを生成します。要求されたターゲットが、構成されておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザー情報およびグループ・メンバーシップは、(そのように構成された場合)AttributeStatement内に置かれます。

『Oracle WebLogic Serverセキュリティのプログラミング』のSAML SSO属性サポートの構成に関する項で説明されているように、WebLogic Serverでは、追加属性(グループ情報以外)を取得してSAMLアサーションに書き込んだり、着信SAMLアサーションからの属性のマップを可能にするカスタム属性マッパーの使用をサポートするために、SAML 1.1および2.0の資格証明マッピング・プロバイダとIDアサーション・プロバイダのメカニズムが強化されています。

SAML資格証明マッピング・プロバイダでは、CredentialMapperV2.SAML_ASSERTION_B64_TYPECredentialMapperV2.SAML_ASSERTION_DOM_TYPE、およびCredentialMapperV2.SAML_ASSERTION_TYPEの各トークン・タイプがサポートされています。

SAML 2.0資格証明マッピング・プロバイダでは、CredentialMapperV2.SAML2_ASSERTION_DOM_TYPEトークン・タイプおよびCredentialMapperV2.SAML2_ASSERTION_TYPEトークン・タイプがサポートされています。

初期状態の資格証明マッピング・プロバイダが開発者のニーズを満たさない場合は、カスタム資格証明マッピング・プロバイダを開発する必要があります。ただし、WebLogic Serverリソース・コンテナでリクエストされるのは、次のトークンの種類のみです。

カスタム資格証明マッピング・プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール・マッピング、または資格証明マッピング用にカスタム・セキュリティ・プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、第14章「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。

カスタム資格証明マッピング・プロバイダの開発方法

WebLogic資格証明マッピング・プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム資格証明マッピング・プロバイダを開発することができます。

  1. 適切なSSPIによるランタイム・クラスの作成

  2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

  3. 資格証明マップを管理するためのメカニズムの提供

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格証明マッピング・プロバイダのランタイム・クラスを作成します。

CredentialProviderV2 SSPIの実装

CredentialProviderV2 SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。

  • getCredentialProvider

    public CredentialMapperV2 getCredentialProvider();
    

    getCredentialProviderV2メソッドはCredentialMapperV2 SSPIの実装を取得します。(図3-3にあるような)MyCredentialMapperProviderImpl.javaという単一のランタイム・クラスの場合、getCredentialProviderメソッドの実装は次のようになります:

    return this;
    

    ランタイム・クラスが2つの場合、getCredentialProviderメソッドの実装は次のようになります。

    return new MyCredentialMapperImpl;
    

    これは、CredentialProviderV2 SSPIを実装するランタイム・クラスが、CredentialMapperV2 SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。

CredentialProviderV2 SSPIとgetCredentialProviderメソッドの詳細は、WebLogic Server APIリファレンスJavadocを参照してください。

DeployableCredentialProvider SSPIの実装


注意:

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インタフェースは、アプリケーション内でスコープが指定されている特定のリソースに対して適切な資格証明群の取得が可能なオブジェクトのセキュリティ・サービス・プロバイダ・インタフェース(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メソッドは、指定したイニシエータに関連付けられているターゲット・リソースから、指定した種類の資格証明を複数返します。

CredentialMapperV2 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; 
}

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格証明マッピング・プロバイダのMBeanタイプを作成します。

  1. MBean定義ファイル(MDF)の作成

  2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

  3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

  4. WebLogic Server環境にMBeanタイプをインストールする


    注意:

    この手順の実行方法を説明するサンプル・セキュリティ・プロバイダ(Oracle Technology Network Webサイトのhttps://codesamples.samplecode.oracle.com/servlets/tracking?id=S224から入手可能)がいくつか用意されています。

    この節で説明する手順はすべて、Windows環境での作業を想定しています。


MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

  1. サンプル認証プロバイダのMDFをテキスト・ファイルにコピーします。


    注意:

    サンプル認証プロバイダのMDFは、SimpleSampleAuthenticator.xmlです。(現在、サンプル資格証明マッピング・プロバイダはありません)。

  2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム資格証明マッピング・プロバイダに合わせて修正します。

  3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

  4. ファイルを保存します。


    注意:

    MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの生成手順は、カスタム資格証明マッピング・プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

オプショナルSSPI MBeanとカスタム操作を追加しない場合

カスタム資格証明マッピング・プロバイダのMDFにオプショナルSSPI MBeanもカスタム操作も実装しない場合、次の手順に従います。

  1. 新しいDOSシェルを作成します。

  2. 次のコマンドを入力します。

    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 (つまり資格証明マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

  3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

オプショナルSSPI MBeanまたはカスタム操作を追加する場合

カスタム資格証明マッピング・プロバイダのMDFにオプショナルSSPI MBeanまたはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

  1. 新しいDOSシェルを作成します。

  2. 次のコマンドを入力します。

    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 (つまり資格証明マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

  3. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

    1. MBean実装ファイルを見つけます。

      WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、MyCredentialMapperという名前のMDFの場合、編集されるMBean実装ファイルはMyCredentialMapperImpl.javaという名前になります。

    2. MDFで実装したオプショナルSSPI MBeanごとに、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

  4. MDFにカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

  5. ファイルを保存します。

  6. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

  1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

  2. 新しいDOSシェルを作成します。

  3. 次のコマンドを入力します。

    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 (つまり資格証明マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

  4. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

    1. MBean実装ファイルを見つけます。

      WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleCredentialMapperという名前のMDFの場合、編集されるMBean実装ファイルはSampleCredentialMapperImpl.javaという名前になります。

    2. ステップ1で一時ディレクトリに保存した既存のMBean実装ファイルを開きます。

    3. 既存のMBean実装ファイルを、WebLogic MBeanMakerによって生成されたMBean実装ファイルと同期させます。

      これには、メソッドの実装を既存のMBean実装ファイルから新しく生成されたMBean実装ファイルにコピー(または、新しく生成されたMBean実装ファイルから既存のMBean実装ファイルに新しいメソッドを追加)し、いずれのMBean実装ファイルにも入っているメソッドのメソッド・シグネチャへの変更が、使用するMBean実装ファイルに反映されていることを確認するといった作業が必要です。

    4. MDFを修正して元のMDFにはないオプショナルSSPI MBeanを実装した場合は、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

  5. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

  6. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

  7. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

  8. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済みのMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでMyCredentialMapper MDFを実行すると、MyCredentialMapperMBean.javaというMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム資格証明マッピング・プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム資格証明マッピング・プロバイダのMJFを作成するには、次の手順に従います。

  1. 新しいDOSシェルを作成します。

  2. 次のコマンドを入力します。

    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環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム資格証明マッピング・プロバイダが「デプロイ」されます。つまり、カスタム資格証明マッピング・プロバイダをWebLogic Server管理コンソールから管理できるようになります。


注意:

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 WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。


カスタム資格証明マッピング・プロバイダを構成することによって(「資格証明マップを管理するためのメカニズムの提供」を参照) MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

資格証明マップを管理するためのメカニズムの提供

WebLogic Server管理コンソールを使用してカスタム資格証明マッピング・プロバイダを構成すると、必要な資格証明マッピング・サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ・プロバイダに関連付けられた資格証明マップを管理する方法を管理者にも提供する必要があります。たとえばWebLogic資格証明マッピング・プロバイダには、資格証明マッピング・ページが管理者向けに用意されており、様々なコネクタ・モジュールの資格証明マッピングを追加、変更、または削除することができます。

カスタム資格証明マッピング・プロバイダを開発すると、管理者は資格証明マッピング・ページも右クリック・メニューも利用できません。したがって、資格証明マップを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム資格証明マッピング・プロバイダのデータベースの資格証明マップを読み書きできなければなりません。

それには、以下の2通りの方法があります。

オプション1 :資格証明マップ管理用のスタンドアロン・ツールの開発

WebLogic Server管理コンソールとまったく別のツールを開発する場合には、この方法を選択します。

この方法では、カスタム資格証明マッピング・プロバイダ向けにコンソール拡張を作成する必要も、管理MBeanを開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。

  1. WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogicリソース識別子」を参照してください。

  2. ローカル・ユーザーとリモート・ユーザーとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。

  3. カスタム資格証明マッピング・プロバイダのデータベースの式を読み書きします。

オプション2 : 管理コンソールに既存の資格証明マップ管理ツールの統合

WebLogic Server管理コンソールとは別のツールを持っており、それを管理コンソールから起動する場合には、この方法を選択します。

この方法の場合、ツールでは以下のことを行う必要があります。

  1. WebLogicリソースのIDを特定します。詳細については、「WebLogicリソース識別子」を参照してください。

  2. ローカル・ユーザーとリモート・ユーザーとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。

  3. カスタム資格証明マッピング・プロバイダのデータベースの式を読み書きします。

  4. 『Oracle WebLogic Server管理コンソールの拡張』で説明されているように、基本的なコンソール拡張手法を使用して管理コンソールにリンクします。