WebLogic セキュリティ プロバイダの開発
![]() |
![]() |
![]() |
![]() |
資格マッピングとは、対象リソースにアクセスするユーザを認証するための適切な資格群を、レガシー システムの認証メカニズムを用いて取得するプロセスのことです。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 には、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 の目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getCredentialProviderV2
メソッドは CredentialMapperV2
SSPI の実装を取得します。図 2-3 にあるような MyCredentialMapperProviderImpl
.java
という 1 つの実行時クラスの場合、getCredentialProvider
メソッドの実装は次のようになります。
これは、CredentialProviderV2
SSPI を実装する実行時クラスが、CredentialMapperV2
SSPI を実装するクラスを取得する場合のファクトリとして使用されるためです。
CredentialProviderV2
SSPI と getCredentialProvider
メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
注意 : DeployableCredentialProvider SSPI は、このリリースの WebLogic Server では非推奨になっています。
DeployableCredentialProvider
SSPI を実装するには、「「Provider」SSPI の目的について」および「CredentialProviderV2 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 API リファレンス Javadoc を参照してください。
CredentialMapperV2 インタフェースは、アプリケーション内でスコープされている特定のリソースに対応する資格群を取得できるオブジェクトのセキュリティ サービス プロバイダ インタフェース (SSPI) を定義します。
以下の資格の種類のみがサポートされており、CredentialMapperV2
インタフェースに渡されます。
CredentialMapperV2
SSPI を実装するには、以下のメソッドの実装を提供する必要があります。
public Object getCredential(Subject requestor, String initiator, Resource resource, ContextHandler handler, String credType);
getCredential
メソッドは、指定したイニシエータに関連付けられている対象リソースから、指定した種類の資格を返します。
CredentialMapper
V2 SSPI と getCredential
および getCredentials
メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループはその後、資格マッピング プロバイダなど、他のタイプのセキュリティ プロバイダによって、サブジェクトから抽出されます。セキュリティ レルム内でコンフィグレーションされた認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザおよびグループの情報もまた、少し異なる方法で抽出する必要があります。
コード リスト 10-1 では、サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするために、カスタム資格マッピング プロバイダが使用できるコードを示しています。このコードは、実装することを選択した getCredentials
メソッドの形式に属しています。コードでは、weblogic.security.SubjectUtils
クラスで使用可能なメソッドを利用します。
コード リスト 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 もカスタム操作も実装しない場合、次の手順に従います。
java -DMDF=
xmlfile -Dfiles=
filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF
フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。filesdir で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true
フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name>
オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり資格マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。
カスタム資格マッピング プロバイダの MDF に任意 SSPI MBean またはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。
java -DMDF=
xmlfile -Dfiles=
filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF
フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。filesdir で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true
フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name>
オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり資格マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java
という名前が付けられます。たとえば、MyCredentialMapper
という MDF の場合には、編集すべき MBean 実装ファイルの名前は MyCredentialMapperImpl.java
です。
java -DMDF=
xmlfile -Dfiles=
filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF
フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。filesdir で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true
フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name>
オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、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 を作成するには、次の手順に従います。
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 つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム クラスと BEA のカスタム クラスとの衝突を防ぐことができます。ネームスペースのデフォルトは vendor です。-targetNameSpace
引数を WebLogicMBeanMaker または関連する WLMBeanMaker ant タスクに渡すと、このデフォルトを変更できます。
既存の 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
です。初めて使用するバージョンが 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 タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『WebLogic Security プログラミングの概要』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。
カスタム資格マッピング プロバイダをコンフィグレーションすることによって (「Administration Console によるカスタム資格マッピング プロバイダのコンフィグレーション」を参照) MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。
カスタム資格マッピング プロバイダをコンフィグレーションするということは、資格マッピング サービスを必要とするアプリケーションがアクセス可能なセキュリティ レルムにカスタム資格マッピング プロバイダを追加するということです。
カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。この節では、カスタム資格マッピング プロバイダのコンフィグレーション担当者向けの重要な情報を取り上げます。
注意 : WebLogic Server Administration Console を使用してカスタム資格マッピング プロバイダをコンフィグレーションする手順は、『WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」で説明されています。
注意 : DeployableCredentialProvider SSPI は、このリリースの WebLogic Server では非推奨になっています。
エンタープライズ JavaBean (EJB) や Web アプリケーションなどのアプリケーションの中には、関連デプロイメント情報を Java 2 Enterprise Edition (J2EE) デプロイメント記述子に格納するものがあります。リソース アダプタの場合、デプロイメント記述子ファイル (weblogic-ra.xml
) には、ユーザ名/パスワードの組み合わせなど、資格マップを作成するための情報が含まれます。この資格マップ情報は、WebLogic Server 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\resadapter\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 は、このリリースの WebLogic Server では非推奨になっています。
カスタム資格マッピング プロバイダの開発の一環として DeployableCredentialProvider
SSPI を実装し、カスタム資格マッピング プロバイダでデプロイ可能な資格マップをサポートしたい場合、カスタム資格マッピング プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、Administration Console で [資格マッピング デプロイメントを有効化] チェック ボックスがチェックされていることを確認する必要があります。チェックがはずれていると、資格マッピング プロバイダに対するデプロイメントは「オフ」と見なされます。このため、複数の資格マッピング プロバイダがコンフィグレーションされている場合、[資格マッピング デプロイメントを有効化] チェック ボックスを使用して、資格マップのデプロイメントに使用する資格マッピング プロバイダを指定できます。
注意 : [デプロイの資格マッピングを無視] チェック ボックス (「資格マッピング プロバイダ、リソース アダプタ、およびデプロイメント記述子を管理する」で説明したようにセキュリティ レルム レベルで指定) では、コンフィグレーション済みの資格マッピング プロバイダのセキュリティ データベースに資格マップをコピーするかどうかを指定します。[資格マッピング デプロイメントを有効化] チェック ボックス (コンフィグレーション済みの資格マッピング プロバイダごとに指定) では、資格マッピング プロバイダがデプロイ済みの資格マップを格納するかどうかを指定します。
WebLogic Server Administration Console を使用してカスタム資格マッピング プロバイダをコンフィグレーションすると、必要な資格マッピング サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられた資格マップを管理する方法を管理者にも提供する必要があります。たとえば WebLogic 資格マッピング プロバイダには、資格マッピング ページが管理者向けに用意されており、さまざまなコネクタ モジュールの資格マッピングを追加、変更、または削除することができます。
カスタム資格マッピング プロバイダを開発すると、管理者は資格マッピング ページも右クリック メニューも利用できません。したがって、資格マップを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム資格マッピング プロバイダのデータベースの資格マップを読み書きできなければなりません。
WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法では、カスタム資格マッピング プロバイダ向けにコンソール拡張を作成する必要も、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
![]() ![]() |
![]() |
![]() |