3 設計上の考慮事項

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

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

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

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

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

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

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

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

• 属性バリデータの相違点

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

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

図 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) を実装して実行時クラスを作成します。この節では、以下の助けになる情報を提供します。

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

• 「Provider」SSPI の目的について

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

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

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

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

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

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

• カスタム セキュリティ プロバイダの実行時クラスの実装には、WebLogic Security フレームワークによるセキュリティ チェックの実行を必要とするコードを含めることはできない。セキュリティ プロバイダは実際にセキュリティ チェックを実行し、WebLogic リソースへのアクセス権を付与する WebLogic Security フレームワークのコンポーネントであるため、そのようなコードを含めると無限反復が発生します。

• セキュリティ プロバイダの実装内で、ローカル (同じサーバ、クラスタ、またはドメイン内) の Java Platform, Enterprise Edition (Java EE) バージョン 5 サービスを使用することはできない。これらの使用を試行することもサポートされていません。たとえば、セキュリティ プロバイダから現在のドメイン内の EJB を呼び出すことは禁止されています。

  他のドメインの Java EE サービスであれば、セキュリティ プロバイダからアクセスおよび使用できます。

「Provider」SSPI の目的について

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

図 3-2 「Provider」SSPI

「図 3-2 「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 インタフェースが含まれています。

• BulkAuthorizationProvider

• BulkAccessDecision

• BulkAdjudicationProvider

• BulkAdjudicator

• BulkRoleProvider

• BulkRoleMapper

バルク アクセス 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 をデプロイできなくなります。

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

DeployableRoleProviderV2 SSPI

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

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

DeployableCredentialProvider SSPI

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

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

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

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

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

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

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

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

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

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

「図 3-4 資格マッピング 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
Adjudicator	AdjudicatorV2
ロール マッピング プロバイダ	RoleProvider DeployableRoleProviderV2
ロール マッパー	RoleMapper
監査プロバイダ	AuditProvider
監査チャネル	AuditChannel
資格マッピング プロバイダ	CredentialProviderV2
資格マッパー	CredentialMapperV2
証明書パス プロバイダ	CertPathProvider
バージョン管理可能なアプリケーションのプロバイダ	VersionableApplicationProvider

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

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

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

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

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

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

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

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

また、この節ではどの必須 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』 (http://java.sun.com/j2se/reference/whitepapers/index.html) を参照してください。

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。セキュリティ プロバイダを WebLogic Server 環境内でコンフィグレーションおよび管理できるようにするための基本的なメソッドが定義されるので、拡張する必要があります。

• 任意 SSPI MBean。セキュリティ プロバイダを管理するための追加メソッドが定義されるので実装することができます。セキュリティ プロバイダのタイプが異なれば、利用できる任意 SSPI MBean も異なります。

詳細については、「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 要素の構文についての詳細なリファレンスは、「A MBean 定義ファイル (MDF) 要素の構文」に収められています。

コード リスト 3-1 DefaultCredentialMapper.xml

<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 のカスタム セキュリティ プロバイダの [プロバイダ固有] タブに自動的に表示されます。カスタム操作を表示するには、コンソール拡張を記述する必要があります(「コンソール拡張機能の記述」を参照)

注意 : サンプル監査プロバイダは、カスタム属性の追加例を提供しています。

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

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 メソッドの throw 句から正しい型のみを送出する必要があります。

• ネストされた例外の場合は、JDK 例外の型または weblogic.management.utils 例外のみを送出する必要があります。

• 実行時例外の場合は、JDK 例外のみを送出するか、JDK 例外を介してのみ渡す必要があります。

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

表 A-1 に示すように、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 階層

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

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

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

「図 3-6 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 を実行すると、以下のことが行われます。

• 必須 SSPI MBean から継承された属性 (MDF に追加されたカスタム属性も同様) により、WebLogic MBeanMaker によって MBean タイプの情報ファイルに完全なゲッター/セッター メソッドが生成される (MBean 情報ファイルは図 3-7 に示されていない)。MBean 情報ファイルの詳細については、「MBean 情報ファイルについて」を参照してください。

  開発者のアクション - なし。これらのメソッドでさらなる作業は必要ありません。

• 任意 SSPI MBean から継承された操作により、MBean の実装ファイルでメソッドが継承される (メソッドの実装は一から記述しなければならない)

  開発者のアクション - 現時点では、WebLogic MBeanMaker では継承されたメソッドのメソッド スタブが生成されません。したがって、適切な実装を提供する必要があります。

• MDF に追加されたカスタム操作により、WebLogic MBeanMaker によってメソッド スタブが生成される。

  開発者のアクション - メソッドの実装を提供する必要があります。ただし、WebLogic MBeanMaker でスタブが生成されるので、Java メソッドのシグネチャを参照する必要はありません。

このことを図 3-7 に示します。

図 3-7 WebLogic MBeanMaker によって提供されるもの

「図 3-7 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-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 Server ドメイン内のあるセキュリティ レルムから新しいセキュリティ レルムにデータを移動する (新しいセキュリティ レルムで、1 つまたは複数の WebLogic セキュリティ プロバイダがカスタム セキュリティ プロバイダに置き換えられる場合)。この場合、管理者は、置き換えの対象とならないセキュリティ プロバイダのセキュリティ データをコピーする必要があります。

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

• 移行の概念

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

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

移行の概念

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

• フォーマット

• 制約

• 移行ファイル

フォーマット

フォーマットとは単に、セキュリティ データのエクスポートまたはインポート方法を指定するデータ フォーマットです。現在、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 Reference Javadoc』の「ImportMBean インタフェース」を参照してください。

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

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

注意 : セキュリティ プロバイダが移行機能を持っていない場合、そのセキュリティ プロバイダの [移行] タブは Administration Console に表示されません。 Administration Console を使用して個々のセキュリティ プロバイダのセキュリティ データを移行する手順については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「セキュリティ データの移行」を参照してください。

図 3-8 WebLogic 認証プロバイダの [移行] タブ

「図 3-8 WebLogic 認証プロバイダの [移行] タブ」の説明

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

注意 : セキュリティ レルム レベルの [移行] タブは、移行機能を持つセキュリティ プロバイダがセキュリティ レルムでコンフィグレーションされているかどうかにかかわらず、Administration Console に常に表示されます。ただし、[移行] タブが機能するのは、1 つまたは複数のセキュリティ プロバイダが移行機能を持っている場合だけです。 Administration Console を使用して個々のセキュリティ プロバイダのセキュリティ データを移行する手順については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「セキュリティ データの移行」を参照してください。

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

「図 3-9 セキュリティ レルムの [移行] タブ」の説明

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

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

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

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

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

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

• 一般例外

• 大きなデータ リストを扱うためのメソッドを提供するインタフェース

• 外部 LDAP サーバと通信するために必要なコンフィグレーション属性を含むインタフェース

  
  

  注意 : Manageable Sample Authentication は、データ リストを扱うためだけでなく、例外用にも weblogic.management.utils パッケージを使用します。

  
  

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

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

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

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

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

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

• WebLogic リソースのタイプ

• WebLogic リソース識別子

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

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

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

• 単一親リソース階層

• ContextHandler と WebLogic リソース

  
  

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

  
  

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

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

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

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

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

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

WebLogic リソースのタイプ

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

• 管理リソース

• アプリケーション リソース

• COM リソース

• コントロール リソース

• EIS リソース

• EJB リソース

• JDBC リソース

• JMS リソース

• JNDI リソース

• リモート リソース

• サーバ リソース

• URL リソース

• Web サービス リソース

• ワーク コンテキスト リソース

  
  

  注意 : これらの各 WebLogic リソースの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』および『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	空
OracleSystemGroup	OracleSystemUser

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

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

表 3-9 デフォルト グローバル ロールとグループの関連付け

グローバル ロール名	グループの関連付け
Admin	Administrators グループ
AdminChannelUser	AdminChannelUsers、Administrators、Deployers、Operators、Monitors、および AppTesters グループ
Anonymous	weblogic.security.WLSPrincipals.getEveryoneGroupname() グループ
CrossDomainConnector	CrossDomainConnectors グループ
Deployer	Deployers グループ
Monitor	Monitors グループ
Operator	Operators グループ
AppTester	AppTesters グループ
OracleSystemRole	OracleSystemGroup

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

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 節では、(http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html) サーブレット コンテナのパターン マッチングのルールが説明されています。これらのルールは、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。

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

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

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

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

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

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

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

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

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

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

注意 : サンプル セキュリティ プロバイダは、プロパティ ファイルを作成し、それらのデータベースとして使用します。たとえば、サンプル認証プロバイダでは、ユーザおよびグループについての必要な情報が格納される 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.
この属性が指定されていない場合、WebLogic Server は、動的グループの URL を評価することでユーザがグループのメンバーかどうかを判定します。   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 データベース デリゲータ クラスの配置

「図 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 を拡張します。

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

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

4. 8.1 では、IdentityAsserter1 の validateActiveTypes 実装が使用されます。

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

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

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

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