> WebLogic セキュリティ プロバイダの開発 > 設計上の考慮事項

WebLogic セキュリティ プロバイダの開発

     前  次    新しいページで目次を開く     
ここから内容の開始

設計上の考慮事項

開発作業を綿密に計画すると、カスタム セキュリティ プロバイダの開発に要する時間と労力を大幅に削減できます。以下の節では、最初に知っておくと役立つ、セキュリティ プロバイダの概念と機能について詳しく説明します。

 

セキュリティ プロバイダの一般的なアーキテクチャ

作成できるセキュリティ プロバイダにはさまざまなタイプがありますが (『WebLogic Security について』の「セキュリティ プロバイダのタイプ」を参照)、どのプロバイダも同じ一般的なアーキテクチャに従っています。図 3-1 に、セキュリティ プロバイダの一般的なアーキテクチャを示します。このアーキテクチャの説明については図の下を参照してください。

図 3-1 セキュリティ プロバイダのアーキテクチャ

セキュリティ プロバイダのアーキテクチャ

注意 : SSPI および SSPI を使用して作成する実行時クラス (実装) はどちらも .java ファイルです。図 3-1 の左側を参照してください。
注意 : 図 3-1 の右側のファイルと同様、MyFooMBean は .xml ファイルとして開始します。このファイルで、SSPI MBean を拡張 (および任意で実装) します。この MBean 定義ファイル (MDF) が WebLogic MBeanMaker ユーティリティで実行される場合、このユーティリティでは MBean タイプ用の .java ファイルが生成されます。「カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成」を参照してください。

図 3-1 は、カスタム セキュリティ プロバイダの開発時に作成された 1 つの実行時クラス (MyFooProviderImpl) と MBean タイプ (MyFooMBean) の関係を示しています。プロセスは WebLogic Server インスタンスの起動時に始まり、WebLogic Security フレームワークは以下のことを行います。

  1. セキュリティ レルムでセキュリティ プロバイダと関連付けられた MBean タイプを見つけます。
  2. MBean タイプからセキュリティ プロバイダの実行時クラス (2 つある場合は「Provider」SSPI を実装する方の実行時クラス) の名前を取得します。
  3. セキュリティ プロバイダが初期化 (コンフィグレーション データの読み込み) に使用する適切な MBean インスタンスを渡します。

このため、実行時クラス (1 つまたは複数) と MBean タイプの両方で「セキュリティ プロバイダ」と呼ばれるものが形成されます。

 

セキュリティ サービス プロバイダ インタフェース (SSPI)

「開発プロセスの概要」で説明したように、カスタム セキュリティ プロバイダの開発ではまず最初に多くのセキュリティ サービス プロバイダ インタフェース (SSPI) を実装して実行時クラスを作成します。この節では、以下の助けになる情報を提供します。

また、この節では各タイプのセキュリティ プロバイダでどの SSPI を実装できるのかを示す「SSPI クイック リファレンス」も提供します。

2 つの重要な制限について

セキュリティ プロバイダは、以下の制限事項に準拠している必要があります。

「Provider」SSPI の目的について

名前が「Provider」というサフィックスで終わる各 SSPI (たとえば CredentialProvider) は、セキュリティ プロバイダのサービスを WebLogic Security フレームワークにエクスポーズします。これによって、セキュリティ プロバイダの操作 (初期化、開始、停止など) が可能になります。

図 3-2 「Provider」SSPI

「Provider」SSPI

図 3-2 で示されているように、セキュリティ サービスを WebLogic Security フレームワークにエクスポーズする SSPI は WebLogic Server によって提供され、そのすべてが以下のメソッドを持つ SecurityProvider インタフェースの拡張です。

initialize

public void initialize(ProviderMBean providerMBean, SecurityServices securityServices)
initialize メソッドは、セキュリティ プロバイダの関連付けられた MBean インスタンスに限定できる ProviderMBean を引数として取ります。その MBean インスタンスは生成する MBean タイプから作成され、カスタム セキュリティ プロバイダを WebLogic Server 環境で管理できるようにするコンフィグレーション データを含みます。このコンフィグレーション データがある場合は、initialize メソッドを使用してそれを抽出する必要があります。 securityServices 引数は、カスタム セキュリティ プロバイダで監査サービスを取得して使用する際の取得先となるオブジェクトです。監査サービスと監査の詳細については、「監査プロバイダ」および「カスタム セキュリティ プロバイダからのイベントの監査」を参照してください。

getDescription

public String getDescription()
このメソッドは、カスタム セキュリティ プロバイダについて簡単に説明したテキストを返します。

shutdown

public void shutdown()
このメソッドは、カスタム セキュリティ プロバイダを停止させます。

SecurityProvider を拡張するものなので、名前が「Provider」で終わる SSPI を実装する実行時クラスは継承したメソッドの実装を提供する必要があります。

バルク アクセス プロバイダの目的について

WebLogic Server のこのリリースには、以下に示すバルク アクセス バージョンの認可プロバイダ、裁決プロバイダ、およびロール マッピング プロバイダの SSPI インタフェースが含まれています。

バルク アクセス SSPI インタフェースを使用すると、認可、裁決、およびロール マッピング プロバイダにおいて、1 回の呼び出しで複数の判定要求を取得できます。「for」ループなどで複数の呼び出しを実行する必要がありません。バルク SSPI バリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡された Resource オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。

詳細については、「バルク認可プロバイダ」、「バルク裁決プロバイダ」、および「バルク ロール マッピング プロバイダ」を参照してください。

実装する「Provider」インタフェースの決定

名前が「Deployable」で始まり、「Provider」で終わる SSPI の実装 (DeployableRoleProviderV2 など) は、カスタム セキュリティ プロバイダのサービスを WebLogic Security フレームワークにエクスポーズします (「「Provider」SSPI の目的について」を参照)。ただし、それらの SSPI の実装では追加のタスクも実行されます。これらの SSPI はまた、サーブレット デプロイメント記述子 (web.xml、weblogic.xml)、EJB デプロイメント記述子 (ejb-jar.xml、weblogic-ejb.jar.xml)、および EAR デプロイメント記述子 (application.xml、weblogic-application.xml) をはじめとするデプロイメント記述子におけるセキュリティのサポートを提供します。

認可プロバイダ、資格マッピング プロバイダ、およびロール マッピング プロバイダには、デプロイ可能バージョンの「Provider」SSPI があります。

注意 : セキュリティ ポリシー、セキュリティ ロール、および資格を格納するセキュリティ プロバイダ データベースが読み込み専用の場合、認可、ロール マッピング、および資格マッピングの各セキュリティ プロバイダ用にデプロイ可能ではないバージョンの SSPI を実装できます。ただし、その場合でも、デプロイメントを処理するセキュリティ プロバイダのデプロイ可能バージョンをコンフィグレーションする必要があります。

DeployableAuthorizationProviderV2 SSPI

Web アプリケーションまたはエンタープライズ JavaBean (EJB) のデプロイメントに代わってセキュリティ ポリシーをデプロイできる認可プロバイダでは、AuthorizationProvider SSPI ではなく DeployableAuthorizationProviderV2 SSPI を実装する必要があります。しかし、DeployableAuthorizationProviderV2 SSPI は AuthorizationProvider SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、Web アプリケーションや EJB のデプロイメント作業では、認可プロバイダがポリシーの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つの認可プロバイダが DeployableAuthorizationProviderV2 SSPI をサポートする必要があり、サポートされていない場合、Web アプリケーションや EJB をデプロイできなくなります。

注意 : セキュリティ ポリシーに関する詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』の「セキュリティ ポリシー」を参照してください。

DeployableRoleProviderV2 SSPI

Web アプリケーションまたはエンタープライズ JavaBean (EJB) のデプロイメントに代わってセキュリティ ロールをデプロイできるロール マッピング プロバイダでは、RoleProvider SSPI ではなく DeployableRoleProviderV2 SSPI を実装する必要があります。しかし、DeployableRoleProviderV2 SSPI は RoleProvider SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、Web アプリケーションや EJB のデプロイメント作業では、ロール マッピング プロバイダがセキュリティ ロールの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つのロール マッピング プロバイダがこの SSPI をサポートする必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。

注意 : セキュリティ ロールの詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。

DeployableCredentialProvider SSPI

注意 : DeployableCredentialProvider インタフェースは、このリリースの WebLogic Server で非推奨になりました。

リソース アダプタ (RA) のデプロイメントに代わってセキュリティ ポリシーをデプロイできる資格マッピング プロバイダでは、CredentialProvider SSPI ではなく DeployableCredentialProvider SSPI を実装する必要があります。しかし、DeployableCredentialProvider SSPI は CredentialProvider SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、リソース アダプタのデプロイメント作業では、資格マッピング プロバイダが資格およびマッピングの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つの資格マッピング プロバイダがこの SSPI をサポートする必要があり、そうでなければ、リソース アダプタをデプロイすることが不可能になります。

注意 : 資格の詳細については、「資格マッピングの概念」を参照してください。セキュリティ ポリシーに関する詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』の「セキュリティ ポリシー」を参照してください。

SSPI 階層を理解し、実行時クラスを 1 つ作成するのか 2 つ作成するのかを決定する

図 3-3 は、資格マッピング プロバイダを使用してすべての SSPI に共通の継承階層を示すとともに、そうしたインタフェースをどのように実行時クラスで実装できるのかを示します。この例では、BEA が提供する SecurityProvider インタフェースと、CredentialProviderV2 および CredentialMapperV2 SSPI を使用します。図 3-3 は、CredentialProviderV2 および CredentialMapperV2 SSPI を実装する MyCredentialMapperProviderImpl という 1 つの実行時クラスを表しています。

図 3-3 資格マッピング SSPI と 1 つの実行時クラス

資格マッピング SSPI と 1 つの実行時クラス

図 3-3 は SSPI を実装できる方法の 1 つにすぎません (1 つの実行時クラスを作成する方法)。必要に応じて、図 3-4 に示すように 2 つの実行時クラスを使用することもできます。1 つは名前が「Provider」で終わる SSPI (CredentialProviderV2 など) の実装のための実行時クラス、もう 1 つは他の SSPI (CredentialMapperV2 SSPI など) の実装のための実行時クラスです。

2 つの実行時クラスがある場合、名前が「Provider」で終わる SSPI を実装するクラスは他の SSPI を実装する実行時クラスを生成するためのファクトリとして機能します。たとえば、図 3-4 では、MyCredentialMapperProviderImpl が MyCredentialMapperImpl を生成するためのファクトリとして機能します。

図 3-4 資格マッピング SSPI と 2 つの実行時クラス

資格マッピング SSPI と 2 つの実行時クラス

注意 : 実行時実装クラスを 2 つにする場合は、セキュリティ プロバイダの MBean タイプを生成するときに必ず両方の実行時実装クラスを MBean JAR ファイル (MJF) に含める必要があります。詳細については、「カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成」を参照してください。

SSPI クイック リファレンス

表 3-1 に、セキュリティ プロバイダのタイプ (およびそれらのコンポーネント) と、その開発に使用する SSPI およびその他のインタフェースとの対応を示します。

表 3-1 セキュリティ プロバイダとそのコンポーネント、および対応する SSPI
タイプ/コンポーネント
SSPI/インタフェース
認証プロバイダ
AuthenticationProviderV2
     LoginModule (JAAS)
  LoginModule
ID アサーション プロバイダ
AuthenticationProviderV2
     ID アサータ
  IdentityAsserterV2
プリンシパル検証プロバイダ
PrincipalValidator
認可
AuthorizationProvider
DeployableAuthorizationProviderV2
     アクセス決定
  AccessDecision
裁決プロバイダ
AdjudicationProviderV2
     裁決
  AdjudicatorV2
ロール マッピング プロバイダ
RoleProvider
DeployableRoleProviderV2
     ロール マッパー
  RoleMapper
監査プロバイダ
AuditProvider
     監査チャネル
   AuditChannel
資格マッピング プロバイダ
CredentialProviderV2
     資格マッパー
   CredentialMapperV2
証明書パス プロバイダ
CertPathProvider
バージョン管理可能なアプリケーションのプロバイダ
VersionableApplicationProvider

注意 : カスタム セキュリティ プロバイダの実行時クラスを作成するために使用する SSPI は、weblogic.security.spi パッケージに配置されます。このパッケージの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。

 

セキュリティ サービス プロバイダ インタフェース (SSPI) MBean

「開発プロセスの概要」で説明されているように、カスタム セキュリティ プロバイダ開発の 2 番目の手順では、カスタム セキュリティ プロバイダの MBean タイプを生成します。この節では、以下の助けになる情報を提供します。

また、この節ではどの必須 SSPI MBean を拡張する必要があるのか、そしてどの任意 SSPI MBean を各タイプのセキュリティ プロバイダで実装できるのかを示す「SSPI MBean クイック リファレンス」も提供します。

MBean タイプが必要な理由について

カスタム セキュリティ プロバイダの実行時クラスを作成することに加えて、MBean タイプを生成することも必要です。MBean という用語は管理対象 Bean (managed bean) の略で、JMX (Java Management eXtensions) で管理可能なリソースを表す Java オブジェクトのことです。

注意 : JMX は Sun Microsystems によって策定された仕様で、標準的な管理アーキテクチャ、API、および管理サービスを定義しています。詳細については、『Java Management Extensions White Paper』を参照してください。

MBean タイプは、MBean のインスタンスのファクトリです。MBean のインスタンスは、WebLogic Server Administration Console を使用して作成できます。MBean のインスタンスが作成されたら、Administration Console でそのインスタンスを使用してカスタム セキュリティ プロバイダをコンフィグレーションおよび管理できます。

注意 : すべての MBean インスタンスは自分の親タイプを認識しているので、MBean タイプのコンフィグレーションを変更すると、Administration Console を使用して作成したすべてのインスタンスのコンフィグレーションも更新されます。詳細については、「SSPI MBean の階層と Administration Console に対する影響について」を参照してください。

拡張および実装する SSPI MBean の決定

MBean タイプを作成するには SSPI MBean という MBean インタフェースを使用します。カスタム セキュリティ プロバイダ用の MBean タイプを作成するのに利用できる SSPI MBean には、以下の 2 つのタイプがあります。

詳細については、「SSPI MBean クイック リファレンス」を参照してください。

MBean 定義ファイル (MDF) の基本的な要素について

MBean 定義ファイル (MDF) は、WebLogic MBeanMaker ユーティリティで、MBean タイプを構成する Java ファイルを生成するために使用される XML ファイルです。すべての MDF では、作成済みのセキュリティ プロバイダのタイプに固有の必須 SSPI MBean を拡張する必要があり、これに加えて任意 SSPI MBean を実装することもできます。

コード リスト 3-1 に、サンプルの MBean 定義ファイル (MDF) を示します。その内容の説明については、リストの下を参照してください。具体的には、WebLogic 資格マッピング プロバイダの MBean タイプを生成するために使用する MDF です。DeployableCredentialProvider インタフェースは、このリリースの WebLogic Server で非推奨になったので注意してください。

注意 : MDF 要素の構文についての詳細なリファレンスは、「MBean 定義ファイル (MDF) 要素の構文」に収められています。
コード リスト 3-1 DefaultCredentialMapper.xml 
<?xml version="1.0" ?>
<!DOCTYPE MBeanType SYSTEM "commo.dtd">
<MBeanType
 Name = "DefaultCredentialMapper"
 DisplayName = "DefaultCredentialMapper"
 Package = "weblogic.security.providers.credentials"
 Extends = "weblogic.management.security.credentials. DeployableCredentialMapper"
 Implements = "weblogic.management.security.credentials. UserPasswordCredentialMapEditor,
weblogic.management.security.credentials.UserPasswordCredentialMapExtendedReader,
weblogic.management.security.ApplicationVersioner,
weblogic.management.security.Import,
weblogic.management.security.Export"
PersistPolicy = "OnUpdate"
 Description = "This MBean represents configuration attributes for the WebLogic Credential Mapping provider.&lt;p&gt;"
>
<MBeanAttribute
 Name = "ProviderClassName"
 Type = "java.lang.String"
 Writeable = "false"
 Default = "&quot;weblogic.security.providers.credentials. DefaultCredentialMapperProviderImpl&quot;"
 Description = "The name of the Java class that loads the WebLogic Credential Mapping provider."
/>
<MBeanAttribute
 Name = "Description"
 Type = "java.lang.String"
 Writeable = "false"
 Default = "&quot;Provider that performs Default Credential Mapping&quot;"
 Description = "A short description of the WebLogic Credential Mapping provider."
/>
<MBeanAttribute
 Name = "Version"
 Type = "java.lang.String"
 Writeable = "false"
 Default = "&quot;1.0&quot;"
 Description = "The version of the WebLogic Credential Mapping provider."
/>
:
:
</MBeanType>

<MBeanType> タグ内の太字の属性は、この MDF が DefaultCredentialMapper という名前であり、DeployableCredentialMapper という必須 SSPI MBean を拡張するものであることを示しています。また、この MDF では、UserPasswordCredentialMapEditor 任意 SSPI MBean を実装することで付加的な管理機能も組み込んでいます。

<MBeanAttribute> タグで定義される ProviderClassName、Description、および Version の各属性は、セキュリティ プロバイダの基本的なコンフィグレーション方法を定義するものであり、Provider という基本必須 SSPI MBean から継承されるものなので、セキュリティ プロバイダの MBean タイプを生成するために使用されるどのような MDF でも必須です (図 3-5 を参照)。ProviderClassName 属性は特に重要です。ProviderClassName 属性の値は、セキュリティ プロバイダの実行時クラスの Java ファイル名 (すなわち、「Provider」という文字列で終わる適切な SSPI の実装) です。コード リスト 3-1 で示されているサンプルの実行時クラスは、DefaultCredentialMapperProviderImpl.java です。

コード リスト 3-1 では示されていませんが、<MBeanAttribute> タグや <MBeanOperation> タグを使用して MDF に属性や操作を追加できます。ほとんどのカスタム属性は、WebLogic Server Administration Console のカスタム セキュリティ プロバイダの [プロバイダ固有] タブに自動的に表示されます。カスタム操作を表示するには、コンソール拡張を記述する必要があります (「コンソール拡張機能の記述」を参照)。

注意 : サンプル監査プロバイダ (dev2dev Web サイトの「Code Samples」で入手可能) は、カスタム属性の追加例を提供しています。

カスタム プロバイダとクラスパス

WL_HOME\server\lib\mbeantypes からロードされるクラスは、WebLogic Server にデプロイされている他の JAR ファイルや EAR ファイルからは認識されません。共有する必要がある共通のユーティリティ クラスがある場合、そのクラスはシステムのクラス パスに配置する必要があります。

注意 : MBean タイプのインストール用のディレクトリは、デフォルトでは WL_HOME\server\lib\mbeantypes ですが、初めて使用するバージョンが 9.0 の場合、セキュリティ プロバイダは ...\domaindir\lib\mbeantypes からもロードできます。...\domaindir\lib\mbeantypes ディレクトリからロードした JAR ファイルは複数のアプリケーションで共有できるので、明示的にシステム クラスパスに配置する必要はありません。

MBean オペレーションから例外を送出する

カスタム プロバイダの MBean は、JDK 例外の型または weblogic.management.utils 例外の型のみを送出する必要があります。それ以外の場合、JMX クライアントには、例外を受け付ける必要があるコードが含まれていない可能性があります。

MBean 属性に対して非クリアテキスト値を指定する

表 A-2 に示すように、Encrypted 属性を使用すると、MBean 属性の値がクリアテキストとして表示されないように指定できます。たとえば、パスワードの入力を取得したときに MBean 属性の値を暗号化する場合などです。以下のコードでは、Encrypted 属性の使用例を示します。 

<MBeanAttribute
Name        = "PrivatePassPhrase"
Type        = "java.lang.String"
Encrypted   = "true"
Default     = "&quot;&quot;"
Description = "The Keystore password."
/>

SSPI MBean の階層と Administration Console に対する影響について

MBean 定義ファイル (MDF) で拡張する必須 SSPI MBean (基本 SSPI MBean である Provider に至るまで) に指定されている属性と操作はすべて、関連するセキュリティ プロバイダの WebLogic Server Administration Console ページに自動的に表示されます。これらの属性と操作は、カスタム セキュリティ プロバイダをコンフィグレーションおよび管理するために使用します。

注意 : 認証セキュリティ プロバイダに限っては、MDF で実装される任意 SSPI MBean で指定された属性と操作も Administration Console で自動的にサポートされます。他のタイプのセキュリティ プロバイダの場合、任意 SSPI MBean から継承された属性/操作を Administration Console で使用するには、コンソール拡張機能を記述する必要があります。詳細については、「コンソール拡張機能の記述」を参照してください。

図 3-5 は、WebLogic 資格マッピング MDF を例としてセキュリティ プロバイダの SSPI MBean 階層を示すとともに、どの属性/操作が WebLogic 資格マッピング プロバイダの Administration Console で表示されるのかを示します。

図 3-5 資格マッピング プロバイダの SSPI MBean 階層

資格マッピング プロバイダの SSPI MBean 階層

図 3-5 に示されているように、DefaultCredentialMapper MDF の SSPI MBean の階層を実装することにより、図 3-6 のページが Administration Console で表示されます。DefaultCredentialMapper MDF の部分的なリストは、コード リスト 3-1 に示してあります。

図 3-6 DefaultCredentialMapper の場合の Administration Console ページ

DefaultCredentialMapper の場合の Administration Console ページ

[名前]、[説明]、および [バージョン] の各フィールドは、Provider という基本必須 SSPI MBean から継承され DefaultCredentialMapper MDF に指定されている同名の属性から得られたものです。DefaultCredentialMapper MDF 内の DisplayName 属性から [名前] フィールドの値が生成されるほか、Description と Version の各属性からも、それぞれ対応するフィールドの値が生成されることに注意します。なお、[プロバイダ固有] ページの [資格マッピング デプロイメントを有効化] フィールドが表示されているのは、DefaultCredentialMapper MDF の拡張元である DeployableCredentialMapper 必須 SSPI MBean に CredentialMappingDeploymentEnabled 属性が定義されているためです。この Administration Console ページには、UserPasswordCredentialMapEditor 任意 SSPI MBean の DefaultCredentialMapper の実装に対応するフィールドは表示されません。

WebLogic MBeanMaker によって提供されるものについて

WebLogic MBeanMaker は、MBean 定義ファイル (MDF) を入力とし、MBean タイプのファイルを出力するコマンドライン ユーティリティです。WebLogic MBeanMaker を使用して作成した MDF を実行すると、以下のことが行われます。

これについて、図 3-7 に示します。

図 3-7 WebLogic MBeanMaker で提供されるもの

WebLogic MBeanMaker で提供されるもの

MBean 情報ファイルについて

MBean 情報ファイルには、MBean 定義ファイル内のデータのコンパイル済みの定義が、JMX Model MBeans で要求される形式で含まれます。このファイルの形式は、それぞれがそのエンティティを記述する記述子タグのセットを持つ属性、操作、通知のリストです。加えて、MBean 自体にも、一連の記述子タグがあります。この形式の例を次に示します。

MBean + tags

attribute1 + tags, attribute2 + tags ...

operation1 + tags, operation2 + tags ...

notification1 + tags, notification2 + tags ...

必要に応じて、標準の JMX サーバの getMBeanInfo メソッドを呼び出し、ModelMBeanInfo を取得することで、実行時にこの情報にアクセスできます。

注意 : 返された構造を解釈する方法を決定するために、必ず JMX 仕様を参照してください。

SSPI MBean クイック リファレンス

カスタム セキュリティ プロバイダの開発の一部として実装する必要のある SSPI のリストに基づいて、拡張する必要のある必須 SSPI MBean を表 3-2 で特定できます。また、表 3-3 から表 3-5 では、セキュリティ プロバイダを管理するために実装できる任意 SSPI MBean を特定できます。

表 3-2 必須 SSPI MBean
タイプ
パッケージ名
必須 SSPI MBean
認証プロバイダ
authentication
Authenticator
ID アサーション プロバイダ
authentication
IdentityAsserter
認可プロバイダ
authorization
Authorizer または DeployableAuthorizer
裁決プロバイダ
authorization
Adjudicator
ロール マッピング プロバイダ
authorization
RoleMapper または DeployableRoleMapper
監査プロバイダ
audit
Auditor
資格マッピング プロバイダ
credentials
CredentialMapper または DeployableCredentialMapper
証明書パス プロバイダ
pk
CertPathBuilder または CertPathValidator

注意 : 表 3-2 に示した必須 SSPI MBean は、weblogic.management.security.<Package_Name> というパッケージに定義されています。

表 3-3 認証用任意 SSPI MBean
任意 SSPI MBean
用途
GroupEditor
グループを作成する。当該グループがすでに存在する場合には、例外が送出される。
GroupMemberLister
グループのメンバーを列挙する。
GroupReader
グループに関するデータを読み込む。
GroupRemover
グループを削除する。
MemberGroupLister
あるユーザまたはグループが所属するグループを列挙する。
UserEditor
ユーザを作成、編集、および削除する。
UserPasswordEditor
ユーザのパスワードを変更する。
UserReader
ユーザに関するデータを読み込む。
UserRemover
ユーザを削除する。

注意 : 表 3-3 に示した認証用任意 SSPI MBean は、weblogic.management.security.authentication パッケージに定義されています。また、これらは WebLogic Server Administration Console でもサポートされます。
注意 : 表 3-3 に示した認証用任意 SSPI MBean の実装方法の例については、dev2dev Web サイトの「Code Samples」にある、Manageable Sample Authentication Provider のコードを確認してください。

表 3-4 認可用任意 SSPI MBean
任意 SSPI MBean
用途
PolicyConsumer
プロバイダでポリシーの消費をサポートすることを示す。
PolicyEditor
セキュリティ ポリシーを作成、編集、および削除する。
PolicyLister
ポリシーに関するデータをリストする。
PolicyReader
セキュリティ ポリシーに関するデータを読み込む。
PolicyStore
ポリシーをポリシー ストアで管理する。
RoleEditor
セキュリティ ロールを作成、編集、および削除する。
RoleReader
セキュリティ ロールに関するデータを読み込む。
RoleLister
ロールに関するデータをリストする。

注意 : 表 3-4 に示した認可用任意 SSPI MBean は、weblogic.management.security.authorization パッケージに定義されています。

表 3-5 資格マッピング用任意 SSPI MBean
任意 SSPI MBean
用途
UserPasswordCredentialMapEditor
WebLogic ユーザをリモートのユーザ名およびパスワードにマップする資格マップを編集する。
UserPasswordCredentialMapExtendedReader
WebLogic ユーザをリモートのユーザ名およびパスワードにマップする資格マップを読み込む。
UserPasswordCredentialMapReader
WebLogic ユーザをリモートのユーザ名およびパスワードにマップする資格マップを読み込む。

注意 : 表 3-5 に示した資格マッピング用任意 SSPI MBean は、weblogic.management.security.credentials パッケージに定義されています。

 

セキュリティ データの移行

一部の WebLogic セキュリティ プロバイダは、セキュリティ データの移行をサポートするように開発されています。つまり、(WebLogic 認証プロバイダの) ユーザとグループ、(WebLogic 認可プロバイダの) セキュリティ ポリシー、(WebLogic ロール マッピング プロバイダの) セキュリティ ロール、または (WebLogic 資格マッピング プロバイダの) 資格マップを、セキュリティ レルムからエクスポートして別のセキュリティ レルムにインポートできます。管理者は、これらの WebLogic セキュリティ プロバイダのセキュリティ データを個別に移行したり、すべての WebLogic セキュリティ プロバイダのセキュリティ データ (セキュリティ レルム全体のセキュリティ データ) を一度に移行したりできます。

管理者にとって、セキュリティ データの移行は次のような場合に有用です。

以下の節では、セキュリティ データの移行の詳細について説明します。

移行の概念

セキュリティ データを移行する前に、以下の概念を理解しておく必要があります。

フォーマット

フォーマットとは単に、セキュリティ データのエクスポートまたはインポート方法を指定するデータ フォーマットです。現在、WebLogic Server はセキュリティ プロバイダの開発者に、標準の公開されたフォーマットを提供していません。このため、フォーマットは任意に選択できますが、あるセキュリティ プロバイダから別のセキュリティ プロバイダにデータをエクスポートおよびインポートするには、両方のセキュリティ プロバイダが同じフォーマットの処理方法を理解している必要があります。サポートされるフォーマットは、特定のセキュリティ プロバイダが処理方法を理解しているデータ フォーマットのリストです。

注意 : WebLogic セキュリティ プロバイダで使用されるデータ フォーマットは非公開であるため、現時点では、WebLogic セキュリティ プロバイダとカスタム セキュリティ プロバイダの間でセキュリティ データを移行することはできません。また、別のベンダのセキュリティ プロバイダとセキュリティ データを交換するには、セキュリティ ベンダがそのための標準フォーマットに従って連携する必要があります。

制約

制約は、エクスポートまたはインポート処理のオプションの指定に使用されるキーと値の組み合わせです。制約を使用すると、セキュリティ プロバイダのデータベースからエクスポートまたはインポートするセキュリティ データを管理者が制御できます。たとえば、管理者は、認証プロバイダのデータベースから、グループではなくユーザまたはユーザのサブセットだけをエクスポートすることができます。サポートされる制約は、特定のセキュリティ プロバイダの移行処理で管理者が指定できる制約のリストです。たとえば、認証プロバイダのデータベースを使用して、ユーザとグループをインポートできますが、セキュリティ ポリシーはインポートできません。

移行ファイル

エクスポート ファイルは、移行処理のエクスポートの段階で、セキュリティ データを (指定されたフォーマットで) 書き込むファイルです。インポート ファイルは、移行処理のインポートの段階で、セキュリティ データを (指定されたフォーマットで) 読み込むファイルです。エクスポート ファイルとインポート ファイルのどちらも、あるセキュリティ プロバイダのデータベースから別の場所に移行する際の、セキュリティ データの一時的な格納場所です。

警告 : 移行ファイルは、保護措置を取らない限り保護されません。移行ファイルには重要なデータが入っているので、扱いには十分な注意が必要です。

カスタム セキュリティ プロバイダへの移行サポートの追加

WebLogic セキュリティ プロバイダのようにセキュリティ データの移行をサポートするカスタム セキュリティ プロバイダを開発する場合、そのプロバイダの MBean タイプを生成するための MBean 定義ファイル (MDF) で weblogic.management.security.ImportMBean および weblogic.management.security.ExportMBean 任意 SSPI MBean を拡張してから、そのメソッドを実装する必要があります。こうした任意 SSPI MBean には、それぞれ表 3-6 と表 3-7 に示す属性と操作が定義されています。

表 3-6 ExportMBean 任意 SSPI MBean の属性と操作
属性/操作
説明
SupportedExportFormats
セキュリティ プロバイダがサポートしているエクスポート データ フォーマットのリスト。
SupportedExportConstraints
セキュリティ プロバイダがサポートしているエクスポート制約のリスト。
exportData
プロバイダ固有のセキュリティ データを指定されたフォーマットでエクスポートする。
   format
プロバイダ固有のデータをエクスポートするフォーマットを指定する exportData 操作のパラメータ。
   filename
プロバイダ固有のデータをエクスポートするためのファイルの絶対パスを指定する exportData 操作のパラメータ。

注意 : セキュリティ データの移行をサポートする WebLogic セキュリティ プロバイダは、(作業対象のサーバを基準とする) 相対パスでも指定できるように実装されている。すでに存在しているディレクトリを指定する必要がある。ディレクトリは WebLogic Server によって作成されない。
   constraints
プロバイダ固有のデータをエクスポートする場合の制約を指定する exportData 操作のパラメータ。

注意 : 詳細については、WebLogic Server API リファレンス Javadoc の ExportMBean インタフェースを参照してください。

表 3-7 ImportMBean 任意 SSPI MBean の属性と操作
属性/操作
説明
SupportedImportFormats
セキュリティ プロバイダがサポートしているインポート データ フォーマットのリスト。
SupportedImportConstraints
セキュリティ プロバイダがサポートしているインポート制約のリスト。
importData
プロバイダ固有のデータを指定されたフォーマットでインポートする。
   format
プロバイダ固有のデータをインポートするフォーマットを指定する importData 操作のパラメータ。
   filename
プロバイダ固有のデータをインポートするためのファイル名の絶対パスを指定する importData 操作のパラメータ。

注意 : セキュリティ データの移行をサポートする WebLogic セキュリティ プロバイダは、(作業対象のサーバを基準とする) 相対パスでも指定できるように実装されている。すでに存在しているディレクトリを指定する必要がある。ディレクトリは WebLogic Server によって作成されない。
   constraints
プロバイダ固有のデータをインポートする場合の制約を指定する importData 操作のパラメータ。

注意 : 詳細については、WebLogic Server API リファレンス Javadoc の ImportMBean インタフェースを参照してください。

セキュリティ データの移行に関する Administration Console のサポート

カスタム セキュリティ プロバイダの MDF で拡張可能な他の任意 SSPI MBean と違い、ExportMBean および ImportMBean 任意 SSPI MBean から継承した属性および操作は、関連付けられているセキュリティ プロバイダの WebLogic Server Administration Console ページの [移行] タブに自動的に表示されます (図 3-8 を参照)。これにより、管理者は各セキュリティ プロバイダのセキュリティ データを個別にエクスポートおよびインポートすることができます。

注意 : セキュリティ プロバイダに移行機能がない場合、そのセキュリティ プロバイダの [移行] タブは Administration Console に表示されません。

Administration Console を使用して個々のセキュリティ プロバイダのセキュリティ データを移行する手順については、「セキュリティ データの移行」を参照してください。
図 3-8 WebLogic 認証プロバイダの [移行] タブ

WebLogic 認証プロバイダの [移行] タブ

また、セキュリティ レルムに移行機能を持つセキュリティ プロバイダがコンフィグレーションされている場合、管理者はセキュリティ レルム レベルの [移行] タブ (図 3-9 を参照) を使用して、セキュリティ レルムにあるすべてのセキュリティ プロバイダのセキュリティ データを一度にエクスポートまたはインポートできます。

注意 : セキュリティ レルム レベルの [移行] タブは、移行機能を持つセキュリティ プロバイダがセキュリティ レルムでコンフィグレーションされているかどうかにかかわらず、Administration Console に常に表示されます。ただし、[移行] タブが機能するのは、1 つまたは複数のセキュリティ プロバイダが移行機能を持っている場合だけです。

すべてのセキュリティ プロバイダのセキュリティ データを一度に移行する手順については、『WebLogic Server のセキュリティ』の「セキュリティ データの移行」を参照してください。
図 3-9 セキュリティ レルムの [移行] タブ

セキュリティ レルムの [移行] タブ

注意 : また、管理者は、ExportMBean および ImportMBean 任意 SSPI MBean を拡張する場合、Administration Console ではなく WebLogic Scripting Tool (WLST) を使用してもセキュリティ データを移行できます。詳細については、『WebLogic Scripting Tool ガイド』を参照してください。

MDF に属性または操作を追加する場合、Administration Console で使用できるように、やはりコンソール拡張を記述する必要があります。

 

セキュリティ プロバイダの開発者向け管理ユーティリティ

weblogic.management.utils パッケージには、開発者にとって特にカスタム セキュリティ プロバイダの MBean タイプを生成する際に役立つ、補足的な管理インタフェースと例外が含まれています。カスタム セキュリティ プロバイダを開発する際に、これらのインタフェースと例外を実装する必要はありません (カスタム セキュリティ プロバイダの MDF で任意 SSPI MBean を実装してこれらを継承する場合を除く)。

注意 : このインタフェースとクラスは、一般的な用途のユーティリティ、つまり非セキュリティ MBean にも使用できるものなので、weblogic.management.security ではなくこのパッケージに入っています。さまざまな種類の MBean については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」で説明します。

weblogic.management.utils パッケージには、以下のユーティリティが含まれています。

注意 : Manageable Sample Authentication Provider (dev2dev Web サイトの「Code Samples」から入手可能なサンプル セキュリティ プロバイダ) は、データ リストを扱うためだけでなく、例外用にも weblogic.management.utils パッケージを使用します。

詳細については、WebLogic Server API リファレンス Javadoc の weblogic.management.utils パッケージを参照してください。

 

セキュリティ プロバイダと WebLogic リソース

WebLogic リソースは、権限のないアクセスから保護することができる WebLogic Server エンティティを表す構造化オブジェクトです。カスタムの認可プロバイダ、ロールマッピング プロバイダ、および資格マッピング プロバイダの開発者は、これらのセキュリティ プロバイダが、WebLogic リソースおよびそれらのリソースのセキュリティに使用されるセキュリティ ポリシーとどのように対話するかを理解しておく必要があります。

注意 : セキュリティ ポリシーは、以前のリリースの WebLogic Server で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) とパーミッションに代わるものです。

以下の節では、セキュリティ プロバイダと WebLogic リソースについて説明します。

注意 : 詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。

WebLogic リソースのアーキテクチャ

weblogic.security.spi パッケージに定義されている Resource インタフェースは、権限のないアクセスから保護できる WebLogic リソースを表すオブジェクトを定義します。weblogic.security.service パッケージに定義されている ResourceBase クラスは、より詳細な WebLogic リソース タイプの抽象基底クラスで、リソースを拡張するためのモデルです (詳細については、図 3-10 と「WebLogic リソースのタイプ」を参照)。

図 3-10 WebLogic リソースのアーキテクチャ

WebLogic リソースのアーキテクチャ

ResourceBase クラスには、BEA が提供する getID、getKeys、getValues、および toString メソッドの実装が含まれています。詳細については、WebLogic Server API リファレンス Javadoc の ResourceBase クラスを参照してください。

このアーキテクチャにより、特定の WebLogic リソースを意識することなくセキュリティ プロバイダを開発できます。このため、新しいリソース タイプが追加されても、セキュリティ プロバイダを修正する必要がありません。

WebLogic リソースのタイプ

図 3-10 に示されているように、weblogic.security.service パッケージの特定のクラスは ResourceBase クラスの拡張であるため、WebLogic リソースの特定のタイプの実装を提供します。以下の WebLogic リソースの実装を使用できます。

注意 : これらの各 WebLogic リソースの詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』および WebLogic Server API リファレンス Javadoc の weblogic.security.service パッケージを参照してください。

WebLogic リソース識別子

各 WebLogic リソース (「WebLogic リソースのタイプ」を参照) は、その toString() 表現か、または getID() メソッドを使用して取得した ID によって識別できます。

toString() メソッド

WebLogic リソースの実装の toString() メソッドを使用すると、その WebLogic リソースの説明が String 形式で返されます。最初に、WebLogic リソースのタイプが不等号括弧内に出力されます。次に、各キーとその値が順番に出力されます。これらのキーはカンマで区切られます。示される値はカンマで区切られ、中括弧で囲まれます。各値はそのまま出力されますが、カンマ (,)、開き中括弧 ({)、閉じ中括弧 (})、およびバック スラッシュ (\) はそれぞれバック スラッシュでエスケープされます。たとえば、次のような EJB リソースがあるとします。

EJBResource ("myApp",
             "MyJarFile",
             "myEJB",
             "myMethod",
             "Home",
             new String[] {"argumentType1", "argumentType2"}
            );

このリソースは、以下の toString 出力を生成します。

type=<ejb>, app=myApp, module="MyJarFile", ejb=myEJB, method="myMethod", methodInterface="Home", methodParams={argumentType1, argumentType2}

toString() メソッドによって提供される WebLogic リソース記述の形式は公開されており (つまり Resource オブジェクトを使用せずに記述を作成でき)、逆変換できます (つまりこの String 形式を元の WebLogic リソースに戻せます)。

注意 : コード リスト 3-2 に、toString() メソッドを使用して WebLogic リソースを識別する方法について示します。

リソース ID と getID() メソッド

定義済みの各 WebLogic リソース タイプに定義されている getID() メソッドは、セキュリティ プロバイダで WebLogic リソースをユニークに識別するために使用できる 64 ビット ハッシュコードを返します。リソース ID は、以下のアルゴリズムを使用して、高速の実行時キャッシングに効果的に使用できます。

  1. WebLogic リソースを取得します。
  2. getID メソッドを使用して WebLogic リソースのリソース ID を取得します。
  3. キャッシュ内でそのリソース ID をルックアップします。
  4. リソース ID が見つかれば、それに対応するセキュリティ ポリシーを返します。
  5. リソース ID が見つからなければ、以下を実行します。
    1. toString() メソッドを使用して、セキュリティ プロバイダ データベース内で WebLogic リソースをルックアップします。
    2. リソース ID とセキュリティ ポリシーをキャッシュに格納します。
    3. セキュリティ ポリシーを返します。
注意 : コード リスト 3-3 に、認可プロバイダで getID() メソッドを使用して WebLogic リソースを識別する方法と、そのアルゴリズムの実装例を示します。

このメソッドは何度実行しても同じ値を返すという保証はないので、このリソース ID を使用してセキュリティ プロバイダ データベースに WebLogic リソースに関する情報を格納しないようにしてください。代わりに、WebLogic リソースの toString() メソッドを使用して、リソース対セキュリティ ポリシーおよびリソース対セキュリティ ロール マッピングを、対応するセキュリティ プロバイダ データベースに格納するようにします。

注意 : セキュリティ プロバイダ データベースの詳細については、「セキュリティ プロバイダ データベースの初期化」を参照してください。toString メソッドの詳細については、「toString() メソッド」を参照してください。

WebLogic リソースのデフォルト グループの作成

カスタム認証プロバイダの実行時クラスを記述する場合は、デフォルト グループをいくつか作成しておく必要があります。表 3-8 に、このタスクに役立つ情報を示します。

表 3-8 デフォルト グループとグループ メンバシップ
グループ名
グループ メンバシップ
Administrators
空、または管理ユーザ
Deployers
空
Monitors
空
Operators
空
AppTesters
空

WebLogic リソースのデフォルト セキュリティ ロールの作成

カスタム ロール マッピング プロバイダの実行時クラスを記述する場合は、デフォルト グローバル ロールをいくつか作成しておく必要があります。表 3-9 に、このタスクに役立つ情報を示します。

表 3-9 デフォルト グローバル ロールとグループの関連付け
グローバル ロール名
グループの関連付け
Admin
Administrators グループ
Anonymous
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
Deployer
Deployers グループ
Monitor
Monitors グループ
Operator
Operators グループ
AppTester
AppTesters

注意 : グローバルおよびスコープ指定セキュリティ ロールの詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。

WebLogic リソースのデフォルト セキュリティ ポリシーの作成

カスタム認可プロバイダの実行時クラスを記述する場合は、デフォルト セキュリティ ポリシーをいくつか作成しておく必要があります。これらのデフォルト セキュリティ ポリシーで、初期状態からさまざまなタイプの WebLogic リソースを保護します。表 3-10 に、このタスクに役立つ情報を示します。

表 3-10 WebLogic リソースのデフォルト セキュリティ ポリシー
WebLogic リソース コンストラクタ
セキュリティ ポリシー
new AdminResource(null, null, null)
Admin グローバル ロール
new AdminResource("Configuration", null, null)
Admin、Deployer、Monitor、または Operator グローバル ロール
new AdminResource("FileDownload", null, null)
Admin または Deployer グローバル ロール
new AdminResource("FileUpload", null, null)
Admin または Deployer グローバル ロール
New AdminResource("ViewLog", null, null)
Admin または Deployer グローバル ロール
new ControlResource(null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new EISResource(null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new EJBResource(null, null, null, null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new JDBCResource(null, null, null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new JNDIResource(null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new JMSResource(null, null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new ServerResource(null, null, null)
Admin または Operator グローバル ロール
new URLResource(null, null, null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new WebServiceResource(null, null, null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
new WorkContext(null, null)
weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ

注意 : アプリケーションおよび COM リソースにはデフォルト セキュリティ ポリシーを設定しないでください (つまり、デフォルトですべてのユーザにパーミッションを付与しないでください)。

セキュリティ プロバイダの実行時クラスでの WebLogic リソースのルックアップ

コード リスト 3-2 に、認可プロバイダの実行時クラスで WebLogic リソースをルックアップする方法について示します。このアルゴリズムは、認可プロバイダのセキュリティ プロバイダ データベースに WebLogic リソースとセキュリティ ポリシーのマッピングが格納されていることを前提にしています。コード リスト 3-2 に示すアルゴリズムの使用、つまり getParentResource メソッドの呼び出しの使用は必須ではありません (getParentResource メソッドの詳細については「単一親リソース階層」を参照)。

コード リスト 3-2 認可プロバイダで WebLogic リソースをルックアップする方法 : toString メソッドの使用 
Policy findPolicy(Resource resource) {
   Resource myResource = resource;
   while (myResource != null) {
      String resourceText = myResource.toString();
      Policy policy = lookupInDB(resourceText);
      if (policy != null) return policy;
      myResource = myResource.getParentResource();
   }
   return null;
}

getID メソッドを使用することで、WebLogic リソースのルックアップ アルゴリズムを最適化できます (コード リスト 3-2 に示したように toString メソッドだけを使用すると、文字列が頻繁に連結されるためパフォーマンスが低下する場合があります)。getID メソッドは WebLogic リソース自身の内部で計算されキャッシュされるハッシュ処理なのでより高速で効率的です。このため getID メソッドを使用すると、toString 値の計算がリソースにつき一度だけで済みます (コード リスト 3-3 を参照)。

コード リスト 3-3 認可プロバイダで WebLogic リソースをルックアップする方法 : getID メソッドの使用 
Policy findPolicy(Resource resource) {
   Resource myResource = resource;
   while (myResource != null) {
      long id = myResource.getID();
      Policy policy = lookupInCache(id);
      if (policy != null) return policy;
      String resourceText = myResource.toString();
      Policy policy = lookupInDB(resourceText);
      if (policy != null) {
         addToCache(id, policy);
         return policy;
      }
      myResource = myResource.getParentResource();
   }
   return null;
}
注意 : getID メソッドは、サービス パック間または将来の WebLogic Server リリース間で保証されません。このため、getID 値はセキュリティ プロバイダ データベースに格納しないでください。

単一親リソース階層

WebLogic リソースの粒度は自由に設定できます。たとえば、Web アプリケーション全体、その Web アプリケーション内の特定のエンタープライズ JavaBean (EJB)、あるいはその EJB 内の単一のメソッドを WebLogic リソースと見なすことができます。

WebLogic リソースは、特殊性が最も高いものから最も低いものまでの階層構造に整理されます。各 WebLogic リソース タイプでは、getParentResource メソッドを使用できます (必須ではありません)。

WebLogic セキュリティ プロバイダは、次のように単一親リソース階層を使用します。WebLogic セキュリティ プロバイダが特定の WebLogic リソースにアクセスしようとして、そのリソースが見つからない場合、WebLogic セキュリティ プロバイダはそのリソースの getParentResource メソッドを呼び出します。このメソッドによって現在の WebLogic リソースの親リソースが返され、WebLogic セキュリティ プロバイダはリソース階層を上って次の (特殊性のより低い) リソースを保護できるようになります。たとえば、呼び出し側が以下の URL リソースにアクセスしようとしたとします。

type=<url>, application=myApp, contextPath="/mywebapp", uri=foo/bar/my.jsp

この URL リソースが見つからない場合、WebLogic セキュリティ プロバイダは以下のリソースを検索して保護しようとします。順序は以下のとおりです。 

type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/bar/*
type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/*
type=<url>, application=myApp, contextPath="/mywebapp", uri=*.jsp
type=<url>, application=myApp, contextPath="/mywebapp", uri=/*
type=<url>, application=myApp, contextPath="/mywebapp"
type=<url>, application=myApp
type=<app>, application=myApp
type=<url>
注意 : getParentResource メソッドの詳細については、WebLogic Server API リファレンス Javadoc で定義済みの WebLogic リソース タイプのいずれかまたは Resource インタフェースを参照してください。

URL リソースのパターン マッチング

Java サーブレット 2.3 仕様の SRV.11.1 および SRV.11.2 節では、サーブレット コンテナのパターン マッチングのルールが説明されています。これらのルールは、URL リソースに対しても使用されます。以下の例では、URL リソースのパターン マッチングに関するいくつかの重要な概念を示します。

例 1

URL リソース type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp, httpMethod=GET の場合、リソース階層は次のように使用されます (予想と異なっている可能性がある URL パターンが含まれる、3 行目と 4 行目に注意)。

  1. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp, httpMethod=GET
  2. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp
  3. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp/*, httpMethod=GET
  4. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp/*
  5. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*, httpMethod=GET
  6. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*
  7. type=<url>, application=myApp, contextPath=/mywebapp, uri=*.jsp, httpMethod=GET
  8. type=<url>, application=myApp, contextPath=/mywebapp, uri=*.jsp
  9. type=<url>, application=myApp, contextPath=/mywebapp, uri=/*, httpMethod=GET
  10. type=<url>, application=myApp, contextPath=/mywebapp, uri=/*
  11. type=<url>, application=myApp, contextPath=/mywebapptype=<url>, application=myApp
  12. type=<app>, application=myApp
  13. type=<url>
例 2

URL リソース type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo の場合、リソース階層は次のように使用されます (予想と異なっている可能性がある URL パターンが含まれる、2 行目に注意)。

  1. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo
  2. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*
  3. type=<url>, application=myApp, contextPath=/mywebapp, uri=/*
  4. type=<url>, application=myApp, contextPath=/mywebapp
  5. type=<url>, application=myApp
  6. type=<app>, application=myApp
  7. type=<url>

ContextHandler と WebLogic リソース

ContextHandler は、リソース コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール マッピング決定を行うセキュリティ プロバイダに渡す高性能な WebLogic クラスです。ContextHandler インタフェースを使用すると、内部 WebLogic リソース コンテナで WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandler は本質的には名前と値のリストなので、セキュリティ プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandler の使用には、WebLogic リソース コンテナとセキュリティ プロバイダの間の緊密な連携が不可欠です。ContextHandler の名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElement オブジェクトによって表されます。

注意 : ContextHandler インタフェースと ContextElement クラスの詳細については、WebLogic Server API リファレンス Javadoc で weblogic.security.service パッケージを参照してください。

リソース タイプにはさまざまなコンテキスト要素があり、その値をカスタム プロバイダ開発の一部として検査できます。つまり、すべてのコンテナがすべてのコンテキスト要素を渡すとは限らないことになります。

表 3-11 に利用できる ContextHandler エントリの一覧を示します。

表 3-11 コンテキスト ハンドラのエントリ
コンテキスト要素名
説明と型
com.bea.contextelement.
servlet.HttpServletRequest
HTTP によるサーブレット アクセス要求または SOAP メッセージ。
javax.http.servlet.HttpServletRequest
com.bea.contextelement.
servlet.HttpServletResponse
HTTP によるサーブレット アクセス応答または SOAP メッセージ。
javax.http.servlet.HttpServletResponse
com.bea.contextelement.
wli.Message
WebLogic Integration メッセージ。メッセージは監査ログに送られる。
java.io.InputStream
com.bea.contextelement.
channel.Port
要求の受け付けまたは処理を行うネットワーク チャネルの内部リスン ポート。
java.lang.Integer
com.bea.contextelement.
channel.PublicPort
要求の受け付けまたは処理を行うネットワーク チャネルの外部リスン ポート。
java.lang.Integer
com.bea.contextelement.
channel.RemotePort
要求の受け付けまたは処理を行うネットワーク チャネルの TCP/IP 接続のリモート エンドのポート。
java.lang.Integer
com.bea.contextelement.
channel.Protocol
要求の受け付けまたは処理を行うネットワーク チャネルの要求を行うためのプロトコル。
java.lang.String
com.bea.contextelement.
channel.Address
要求の受け付けまたは処理を行うネットワーク チャネルの内部リスン アドレス。
java.lang.String
com.bea.contextelement.
channel.PublicAddress
要求の受け付けまたは処理を行うネットワーク チャネルの外部リスン アドレス。
java.lang.String
com.bea.contextelement.
channel.RemoteAddress
要求の受け付けまたは処理を行うネットワーク チャネルの TCP/IP 接続のリモート アドレス。
java.lang.String
com.bea.contextelement.
channel.ChannelName
要求の受け付けまたは処理を行うネットワーク チャネルの名前。
java.lang.String
com.bea.contextelement.
channel.Secure
SSL による要求の受け付けまたは処理を行うネットワーク チャネルかどうかを示す。
java.lang.Boolean
com.bea.contextelement.
ejb20.Parameter[1-N]
パラメータに基づくオブジェクト。
com.bea.contextelement.
wsee.SOAPMessage
javax.xml.rpc.handler.MessageContext
com.bea.contextelement.
entitlement.EAuxiliaryID
WebLogic Server 内部プロセスによって使用される。
weblogic.entitlement.expression.EAuxiliary
com.bea.contextelement.
security.ChainPrevalidatedBySSL
SSL フレームワークが証明書チェーンを検証した。つまり、チェーン内の証明書が相互に適切に署名しており、チェーンが終了する証明書がサーバの信頼性のある CA の 1 つであり、チェーンが基本制約ルールに準拠していて、チェーン内の証明書が期限切れではなかった。
java.lang.Boolean
com.bea.contextelement.
xml.SecurityToken
このリリースの WebLogic Server では使用されない。
weblogic.xml.crypto.wss.provider.SecurityToken
com.bea.contextelement.
xml.SecurityTokenAssertion
このリリースの WebLogic Server では使用されない。
java.util.Map
com.bea.contextelement.
webservice.Integrity{id:XXXXX}
javax.security.auth.Subject
com.bea.contextelement.
saml.SSLClientCertificateChain
SSL クライアント証明書チェーンが SSL 接続から取得され、sender-vouches SAML アサーションが受信された。
java.security.cert.X509Certificate[]
com.bea.contextelement.
saml.MessageSignerCertificate
Web サービス メッセージに署名するための証明書。
java.security.cert.X509Certificate
com.bea.contextelement.
saml.subject.ConfirmationMethod
SAML アサーションのタイプ (bearer、artifact、sender-vouches、holder-of-key)。
java.lang.String
com.bea.contextelement.
saml.subject.dom.KeyInfo
holder-of-key SAML アサーションでのサブジェクト確認のために使用される <ds:KeyInfo> 要素。
org.w3c.dom.Element

コード リスト 3-4 では、URL (Web) リソースの ContextHandler を介して、HttpServletRequest および HttpServletResponse コンテキスト要素オブジェクトにアクセスする方法を示します。このコードはたとえば、AccessDecision SSPI 実装の isAccessAllowed() メソッドで使用できます (詳細については、「AccessDecision SSPI を実装する」を参照)。

コード リスト 3-4 例 : URL リソースの ContextHandler でのコンテキスト要素へのアクセス 
static final String SERVLETREQUESTNAME = "com.bea.contextelement.servlet.HttpServletRequest";
if (resource instanceof URLResource) {
   HttpServletRequest req = 
      (HttpServletRequest)handler.getValue(SERVLETREQUESTNAME);
}
注意 : RoleMapper SSPI 実装の getRoles() メソッドや、AuditContext インタフェース実装の getContext() メソッドでこれらのコンテキスト要素にアクセスすることもできます (詳細については、それぞれ「RoleMapper SSPI を実装する」と「監査コンテキスト」を参照)。

コンテキスト ハンドラをサポートするプロバイダとインタフェース

ContextHandler インタフェースを使用すると、WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダまたはインタフェースで、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。

表 3-12 に、コンテキスト ハンドラのサポートについて示します。

表 3-12 コンテキスト ハンドラがサポートされるメソッドとクラス
メソッド
説明
AccessDecision.isAccessAllowed()
isAccessAllowed() メソッドは ContextHandler オブジェクトを受け取り、これを必要に応じてアクセス決定で使用して、認可判定に使用可能な追加情報が取得される。呼び出し側で追加情報を提供できない場合、null 値が指定される。
AdjudicatorV2.adjudicate()
AdjudicatorV2 SSPI インタフェースの実装は裁決プロバイダの一部であり、すべてのアクセス決定の isAccessAllowed メソッドが正常に (例外を送出せずに) 呼び出されて返された後で呼び出される。AdjudicatorV2 SSPI は別の引数でリソースと ContextHandler を受け取る。AuthorizationManager が裁決プロバイダを呼び出すときに、AccessDecision に渡されたのと同じリソースおよび ContextHandler が渡される。このようにして、裁決プロバイダで AccessDecision に利用できるすべての情報が入手される。
AuditAtnEventV2.getContext()
JAAS LoginModule.login() メソッドと IdentityAsserter.assertIdentity() メソッドは ContextHandler にアクセスでき、AuditAtnEventV2 インタフェースでもこのデータを取得できるので関連情報を監査できる。getContext() メソッドは weblogic.security.spi.AuditContext から継承される。getContext() では ContextHandler オブジェクトを取得し、ContextHandler オブジェクトから付加的な監査情報を取得できる。
AuditCertPathBuilderEvent.getContext()、AuditCertPathValidatorEvent.getContext()
getContext メソッドでは必要に応じて ContextHandler オブジェクトを取得でき、ContextHandler オブジェクトによって証明書パスのルックアップと検証の方法に関する付加的なデータが指定される。
AuditConfigurationEvent.getContext()
AuditConfigurationEvent.getContext() メソッドでは ContextHandler オブジェクトを取得し、ContextHandler オブジェクトから付加的な監査情報を取得できる。
AuditContext.getContext()
AuditContext.getContext() メソッドでは ContextHandler オブジェクトを取得し、ContextHandler オブジェクトから付加的な監査情報を取得できる。
AuditCredentialMappingEvent.getContext()
getContext メソッドは必要に応じて ContextHandler オブジェクトを取得でき、ContextHandler オブジェクトによって資格マッピングの監査イベントに関する付加的なデータが指定される。
CertPathBuilderParameterSpi.getContext および CertPathValidatorParameterSpi.getContext
CertPathBuilderParameterSpi および CertPathValidatorParameterSpi インタフェースには getContext() メソッドがあり、このメソッドで ContextHandler を取得できる。ContextHandler により特別なパラメータで証明書パスの構築および検証に使用できる情報が渡される。
ChallengeIdentityAsserterV2.assertChallengeIdentity()、ChallengeIdentityAsserterV2.continueChallengeIdentity()、および ChallengeIdentityAsserterV2.getChallengeIdentity()
ChallengeIdentityAsserterV2 のメソッド群では ContextHandler オブジェクトを受け取り、これは必要に応じて ID アサーション プロバイダでチャレンジ ID のアサーション用の追加情報の取得に使用できる。
CredentialMapperV2.getCredentials()
CredentialMapper.getCredentials() および CredentialMapper.getCredential() メソッドには、任意の特別なデータが指定される ContextHandler パラメータがある。
IdentityAsserterV2.assertIdentity()
IdentityAsserterV2 プロバイダを使用するとセキュリティ フレームワークで assertIdentity メソッドに ContextHandler を渡すことが可能。ContextHandler オブジェクトは必要に応じて、ID アサーションで使用する付加的な情報の取得に使用できる。ContextHandler を使用すると、たとえばユーザが HttpServletRequest から特別な情報を抽出したり、HttpServletResponse にクッキーを設定したりできるようになる。
LoginModule.login()
ContextHandler は JAAS CallbackHandler パラメータに渡すことができる。CallbackHandler は可変引数のデータ構造で、login() メソッドに渡される。この方法で ContextHandler を追加すると、たとえばユーザが HttpServletRequest から特別な情報を抽出したり、HttpServletResponse にクッキーを設定したりできるようになる。この実装には、認証と ID アサーションの両方に使用される LoginModule 群が含まれる。
EJB およびサーブレット コンテナでは、Principal Authenticator を呼び出す際に CallbackHandler へ ContextHandler を追加する必要がある。具体的には、weblogic.security.auth.callback.ContextHandlerCallback をインスタンス化して CallbackHandler の invokeCallback メソッドに渡し、このセキュリティ操作に関連する ContextHandler を取得する必要がある。この操作に関連付けられている ContextHandler がない場合、javax.security.auth.callback.UnsupportedCallbackException が送出される。
RoleMapper.getRoles()
getRoles() メソッドは ContextHandler オブジェクトを受け取り、これは必要に応じてロール マッピング プロバイダで認可判定に使用可能な追加情報の取得に使用される。呼び出し側で追加情報を提供できない場合、null 値が指定される。
URLCallbackHandler および SimpleCallbackHandler クラス
WebLogic Server バージョン 9.0 以降では、weblogic.security.URLCallbackHandler クラスおよび weblogic.security.SimpleCallbackHandler クラスが更新されて ContextHandler を扱えるようになっている。
URLCallbackHandler はアプリケーション開発者が認証 API の一部としてユーザ名、パスワード、URL、および ContextHandler を返すために使用する CallbackHandler。
SimpleCallbackHandler はアプリケーション開発者が認証 API の一部としてユーザ名、パスワード、および ContextHandler を返すために使用する単純な CallbackHandler。

 

セキュリティ プロバイダ データベースの初期化

注意 : この節を読む前に、『WebLogic Security について』の「セキュリティ プロバイダ データベース」に目を通しておいてください。

セキュリティ プロバイダ データベースは、少なくとも、認証、認可、ロール マッピング、および資格マッピングの各プロバイダで必要なデフォルトのユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、または資格で初期化する必要があります。所定のセキュリティ プロバイダのデータベースを初期化してからでないと、セキュリティ プロバイダは使えるようになりません。また、カスタム セキュリティ プロバイダの実行時クラスを記述する際に、データベースの機能を考慮する必要があります。セキュリティ プロバイダのデータベースの初期化に使用する方法は、ユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、または資格情報の格納に外部管理のデータベースを使用するかどうか、およびデータベースがすでに存在するのか作成する必要があるのかなど、多くの要因に左右されます。

以下の節では、セキュリティ プロバイダ データベースを初期化するためのベスト プラクティスについて説明します。

ベスト プラクティス : データベースがない場合のシンプルなデータベースの作成

認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、または資格マッピング プロバイダは、それが初めて使用されるときには、セキュリティ サービスを提供するために必要な情報のあるデータベースを見つけようとします。セキュリティ プロバイダがデータベースを見つけられない場合は、セキュリティ プロバイダにデータベースを作成させて、デフォルトのユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格を自動的に格納することができます。このオプションは、開発およびテストに便利です。

WebLogic セキュリティ プロバイダとサンプル セキュリティ プロバイダは両方ともこのプラクティスに従います。WebLogic の認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、ユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格の情報を組み込み LDAP サーバに格納します。これらの WebLogic セキュリティ プロバイダのいずれかを使用する場合は、『WebLogic Server のセキュリティ』の「組み込み LDAP サーバのコンフィグレーション」で説明されている指示に従う必要があります。

注意 : サンプル セキュリティ プロバイダは、dev2dev Web サイトの「Code Samples」で入手できます。たとえば、サンプル認証プロバイダでは、ユーザおよびグループについての必要な情報が格納される SampleAuthenticatorDatabase.java というファイルが作成されます。

ベスト プラクティス : 既存のデータベースのコンフィグレーション

外部 LDAP サーバなどのデータベースがすでにある場合は、認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダが必要とするユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格の情報をそのデータベースに格納できます。既存のデータベースへの情報の格納は、それを目的としてすでに用意されているどのようなツールを使用しても行うことができます。

データベースに必要な情報が格納されたら、そのデータベースを参照するようにセキュリティ プロバイダをコンフィグレーションする必要があります。そのためには、セキュリティ プロバイダの MBean 定義ファイル (MDF) でカスタム属性を追加します。カスタム属性の例には、データベースのホスト、ポート、パスワードなどがあります。WebLogic MBeanMaker を通じて MDF を実行し、さらにいくつかの手順を行ってカスタム セキュリティ プロバイダの MBean タイプを生成したら、WebLogic Server Administration Console を使用してそれらの属性がデータベースを指すように設定します。

注意 : MDF、MBean タイプ、および WebLogic MBeanMaker の詳細については、「カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成」を参照してください。

コード リスト 3-5 に、WebLogic LDAP 認証プロバイダの MDF に属する一部のカスタム属性を例として示します。これらの属性を使用することにより、WebLogic LDAP 認証プロバイダのデータベース (外部 LDAP サーバ) についての情報を指定することができるので、プロバイダでユーザおよびグループについての情報を見つけることができます。

コード リスト 3-5 LDAPAuthenticator.xml 
...
<MBeanAttribute
 Name = "UserObjectClass"
 Type = "java.lang.String"
 Default = "&quot;person&quot;"
 Description = "The LDAP object class that stores users."
/>
<MBeanAttribute
 Name = "UserNameAttribute"
 Type = "java.lang.String"
 Default = "&quot;uid&quot;"
 Description = "The attribute of an LDAP user object that specifies the name of 
   the user."
/>
<MBeanAttribute
 Name = "UserDynamicGroupDNAttribute"
 Type = "java.lang.String"
 Description = "The attribute of an LDAP user object that specifies the
   distinguished names (DNs) of dynamic groups to which this user belongs.
   If such an attribute does not exist, WebLogic Server determines if a
   user is a member of a group by evaluating the URLs on the dynamic group.
   If a group contains other groups, WebLogic Server evaluates the URLs on
   any of the descendents of the group."
/>
<MBeanAttribute
 Name = "UserBaseDN"
 Type = "java.lang.String"
 Default = "&quot;ou=people, o=example.com&quot;"
 Description = "The base distinguished name (DN) of the tree in the LDAP directory
   that contains users."
/>
<MBeanAttribute
 Name = "UserSearchScope"
 Type = "java.lang.String"
 Default = "&quot;subtree&quot;"
 LegalValues = "subtree,onelevel"
 Description = "Specifies how deep in the LDAP directory tree to search for Users.
   Valid values are &lt;code&gt;subtree&lt;/code&gt;
   and &lt;code&gt;onelevel&lt;/code&gt;."
/>
...

ベスト プラクティス : データベース初期化の委託

可能な限り、セキュリティ プロバイダとセキュリティ プロバイダ データベースの間の初期化呼び出しは、データベース デリゲータという中間クラスを介して行う必要があります。データベース デリゲータは、図 3-11 で示すようにセキュリティ プロバイダの実行時クラスおよび MBean タイプと対話する必要があります。

図 3-11 データベース デリゲータ クラスの配置

データベース デリゲータ クラスの配置

データベース デリゲータは、WebLogic の認証プロバイダと資格マッピング プロバイダで使用されます。たとえば、WebLogic 認証プロバイダはデータベース デリゲータに働きかけてデフォルトのユーザおよびグループで組み込み LDAP サーバを初期化します。デフォルトのユーザおよびグループは、デフォルト セキュリティ レルムの認証サービスを提供するために必要な情報です。

カスタム セキュリティ プロバイダを開発するアプリケーション開発者およびセキュリティ ベンダは、データベース デリゲータを使用することをお勧めします。データベース デリゲータを使用すると、セキュリティ プロバイダのデータベースが隠蔽され、データベースへの呼び出しが一元化されるメリットがあります。

 

属性バリデータの相違点

バリデータは、さまざまな種類の式を検証できるクラスによって実装されるインタフェースです。このリリースの WebLogic Server では、セキュリティ プロバイダの属性バリデータ メソッドの継承ルールが、8.1 のルールとは異なっています。

8.1 で属性バリデータを有効にする場合、派生した MBean は、MBean 実装ファイルでその属性バリデータのメソッドをカスタマイズするだけで済みました。バージョン 9.0 以降で属性バリデータを有効にする場合、派生した MBean は、メソッドをカスタマイズするだけでなく、MDF ファイルでその属性バリデータを明示的に宣言する必要もあります。明示的に宣言しなかった場合、カスタマイズされたメソッドのコードは無視されます。

以下の例では、すべての ID アサーション MBean 実装の基本クラス weblogic.management.security.authentication.IdentityAsserterImpl を示します。

IdentityAsserterImpl は、認証プロバイダ MBean 実装を拡張し、認証プロバイダの MBean 実装がコンフィグレーション属性にアクセスできるようにします。

8.1 では、次の手順で可能になります。

  1. IdentityAsserter1 という ID アサーション プロバイダを作成します。MDF ファイルで、このプロバイダが weblogic.management.security.authentication.IdentityAsserter を拡張するように指定します。
  2. WebLogic MBeanMaker を使用して MBean タイプを生成します。MBeanMaker で生成された実装ファイルは通常、IdentityAsserter1Impl.java という名前になります。これは、weblogic.management.security.authentication.IdentityAsserterImpl を拡張します。

    3. そのため、MBean は、属性バリデータ メソッドを持つ activeTypes 属性を継承します。validateActiveTypes(String[] activeTypes) メソッドにより、サポートされているタイプのみが activeTypes に含まれます。

  3. 実装ファイルを変更し、validateActiveTypes メソッドの別の実装を指定します。たとえば、アクティブなタイプをさらに制限したり、ルールを緩めたりすることができます。
  4. 8.1 では、IdentityAsserter1 の validateActiveTypes 実装が使用されます。

    5. バージョン 9.0 以降では、基本 IdentityAsserter の validateActiveTypes 実装が代わりに使用されます。つまり、IdentityAsserter1 の validateActiveTypes 実装は、通知なしで無視されます。

バージョン 9.0 以降でのこの違いに対処するには、IdentityAsserter1 の MDF ファイルの MBeanOperation サブ要素で属性バリデータを再宣言します。

カスタム バリデータの場合の属性バリデータの相違点

セキュリティ プロバイダの属性バリデータの継承ルールの相違点は、カスタム バリデータにも適用されます。プロバイダに、カスタム バリデータを持つ属性を宣言させることができます。そのプロバイダから別のプロバイダを派生させ、バリデータの別の実装を記述できます。8.1 では、派生したプロバイダのバリデータが使用されます。バージョン 9.0 以降では、基本プロバイダのバリデータが代わりに使用され、派生したバリデータは通知なしで無視されます。


ページの先頭       前  次