| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Security サービスの開発 > 設計上の考慮事項 |
|
WebLogic Security サービスの開発
|
開発作業を綿密に計画すると、カスタム セキュリティ プロバイダの開発に要する時間と労力を大幅に削減できます。 以下の節では、最初に知っておくと役立つ、セキュリティ プロバイダの概念と機能について詳しく説明します。
作成できるセキュリティ プロバイダにはさまざまなタイプがありますが (『WebLogic Security の紹介』の「セキュリティ プロバイダのタイプ」を参照)、それらのプロバイダはすべて同じアーキテクチャに基づきます。 図 2-1 は、セキュリティ プロバイダの一般的なアーキテクチャを示しています。その説明は、図の下を参照してください。
注意: SSPI および SSPI を使用して作成する実行時クラス (実装) は両方とも .java ファイルです。図 2-1 の左側を参照してください。
図 2-1 の右側のファイルと同様、MyFooMBean は .xml ファイルとして開始します。このファイルで、SSPI MBean を拡張 (および任意で実装) します。この MBean 定義ファイル (MDF) が WebLogic MBeanMaker ユーティリティで実行される場合、このユーティリティでは MBean タイプ用の .java ファイルが生成されます。カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成を参照してください。
図 2-1 は、カスタム セキュリティ プロバイダの開発時に作成された 1 つの実行時クラス (MyFooProviderImpl) と MBean タイプ (MyFooMBean) の関係を示しています。 プロセスは WebLogic Server インスタンスの起動時に始まり、WebLogic Security フレームワークは以下のことを行います。
このため、実行時クラスと MBean タイプの両方で「セキュリティ プロバイダ」と呼ばれるものが形成されます。
セキュリティ サービス プロバイダ インタフェース (SSPI)
開発プロセスの概要で説明されているように、カスタム セキュリティ プロバイダの開発ではまず最初に多くのセキュリティ サービス プロバイダ インタフェース (SSPI) を実装して実行時クラスを作成します。この節では、以下の助けになる情報を提供します。
また、この節では各タイプのセキュリティ プロバイダでどの SSPI を実装できるのかを示す SSPI クイック リファレンスも提供します。
カスタム セキュリティ プロバイダの実行時クラスの実装には、WebLogic Security フレームワークによって実行されるセキュリティ チェックを必要とするコードを含めないでください。 セキュリティ プロバイダは、実際にセキュリティ チェックを行い WebLogic リソースへのアクセスを許可する WebLogic Security フレームワークのコンポーネントなので、そうしたコードを含めると無限反復が発生します。
名前が「Provider」という接尾辞で終わる各 SSPI (たとえば CredentialProvider) は、セキュリティ プロバイダのサービスを WebLogic Security フレームワークに公開します。このことで、セキュリティ プロバイダの操作 (初期化、開始、停止など) が可能となります。
図 2-2 で示されているように、セキュリティ サービスを WebLogic Security フレームワークに公開する SSPI は WebLogic Server によって提供され、そのすべてが以下のメソッドを持つ SecurityProvider インタフェースを拡張します。
SecurityProvider を拡張するものなので、名前が「Provider」で終わる SSPI を実装する実行時クラスは継承したメソッドの実装を提供する必要があります。
名前が「Deployable」で始まり、「Provider」で終わる SSPI の実装 (DeployableCredentialProvider など) は、カスタム セキュリティ プロバイダのサービスを 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 を実装します。ただし、その場合でも、デプロイメントを処理するセキュリティ プロバイダのデプロイ可能バージョンをコンフィグレーションする必要があります。
DeployableAuthorizationProvider SSPI
Web アプリケーションまたはエンタープライズ JavaBean (EJB) のデプロイメントに代わってセキュリティ ポリシーをデプロイできる認可プロバイダでは、AuthorizationProvider SSPI ではなく DeployableAuthorizationProvider SSPI を実装する必要があります。しかし、DeployableAuthorizationProvider SSPI は AuthorizationProvider SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。 というのも、Web アプリケーションや EJB のデプロイメント作業では、認可プロバイダがセキュリティ ポリシーの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つの認可プロバイダが DeployableAuthorizationProvider SSPI をサポートする必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。
注意: セキュリティ ポリシーの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」を参照してください。
Web アプリケーションまたはエンタープライズ JavaBean (EJB) のデプロイメントに代わってセキュリティ ロールをデプロイできるロール マッピング プロバイダでは、RoleProvider SSPI ではなく DeployableRoleProvider SSPI を実装する必要があります。しかし、DeployableRoleProvider SSPI は RoleProvider SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。 というのも、Web アプリケーションや EJB のデプロイメント作業では、ロール マッピング プロバイダがセキュリティ ロールの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つのロール マッピング プロバイダが この SSPI をサポートする必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。
注意: セキュリティ ロールの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。
DeployableCredentialProvider SSPI
リソース アダプタ (RA) のデプロイメントに代わってセキュリティ ポリシーをデプロイできる資格マッピング プロバイダでは、CredentialProvider SSPI ではなく DeployableCredentialProvider SSPI を実装する必要があります。しかし、DeployableCredentialProvider SSPI は CredentialProvider SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、リソース アダプタのデプロイメント作業では、資格マッピング プロバイダが資格およびマッピングの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つの資格マッピング プロバイダがこの SSPI をサポートする必要があり、そうでなければ、リソース アダプタをデプロイすることが不可能になります。
注意: 資格の詳細については、資格マッピングの概念を参照してください。 セキュリティ ポリシーの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」を参照してください。
SSPI 階層を理解し、実行時クラスを 1 つ作成するのか 2 つ作成するのかを決定する
図 2-3 は、資格マッピング プロバイダを使用してすべての SSPI に共通の継承階層を示すとともに、実行時クラスでどのようにそれらのインタフェースを実装できるのかを示します。 この例で、BEA は SecurityProvider インタフェースと、CredentialProvider、DeployableCredentialProvider、および CredentialMapper SSPI を提供します。 図 2-3 は、DeployableCredentialProvider SSPI および CredentialMapper SSPI を実装する MyCredentialMapperProviderImpl という 1 つの実行時クラスを示しています。
図2-3 資格マッピング SSPI と 1 つの実行時クラス
ただし、図 2-3 は SSPI を実装できる 1 つの方法のみを示します (1 つの実行時クラスを作成する方法)。 必要に応じて、図 2-4 で示されているように 2 つの実行時クラスを使用することもできます。2 つとは、名前が「Provider」で終わる SSPI (CredentialProvider や DeployableCredentialProvider など) の実装のための実行時クラスと、他の SSPI (CredentialMapper SSPI など) の実装のための実行時クラスです。
2 つの実行時クラスがある場合、名前が「Provider」で終わる SSPI を実装するクラスは他の SSPI を実装する実行時クラスを生成するためのファクトリとして機能します。たとえば 図 2-4 では、MyCredentialMapperProviderImpl が MyCredentialMapperImpl を生成するためのファクトリとして機能します。
図2-4 資格マッピング SSPI と 2 つの実行時クラス
注意: 実行時実装クラスを 2 つにする場合は、セキュリティ プロバイダの MBean タイプを生成するときに必ず両方の実行時実装クラスを MBean JAR ファイル (MJF) に格納する必要があります。詳細については、カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成を参照してください。
表 2-1 は、セキュリティ プロバイダのタイプ (およびそれらのコンポーネント) をそれらを開発するための SSPI およびその他のインタフェースと対応させて示しています。
注意: カスタム セキュリティ プロバイダの実行時クラスを作成するために使用する SSPI は、weblogic.security.spi パッケージに配置されます。 このパッケージの詳細については、WebLogic Server 7.0 API リファレンス Javadoc を参照してください。
セキュリティ サービス プロバイダ インタフェース (SSPI) MBean
開発プロセスの概要で説明されているように、カスタム セキュリティ プロバイダ開発の 2 番目の手順ではカスタム セキュリティ プロバイダの MBean タイプを生成します。この節では、以下の助けになる情報を提供します。
また、この節ではどの必須 SSPI MBean を拡張する必要があるのか、そしてどの任意 SSPI MBean を各タイプのセキュリティ プロバイダで実装できるのかを示す SSPI 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 に対する影響を理解するを参照してください。
MBean タイプを作成するには SSPI MBean という MBean インタフェースを使用します。カスタム セキュリティ プロバイダ用の MBean タイプを作成するのに利用できる SSPI MBean には、以下の 2 つのタイプがあります。
詳細については、SSPI MBean クイック リファレンスを参照してください。
MBean 定義ファイル (MDF) の基本的な要素を理解する
MBean 定義ファイル (MDF) は、WebLogic MBeanMaker ユーティリティで、MBean タイプを構成する Java ファイルを生成するために使用される XML ファイルです。 すべての MDF では、作成済みのセキュリティ プロバイダのタイプに固有の必須 SSPI MBean を拡張する必要があり、さらに任意 SSPI MBean を実装することができます。
リスト2-1 は、サンプルの MBean 定義ファイル (MDF) を示しています。その内容の説明については、リストの下を参照してください。具体的には、WebLogic 資格マッピング プロバイダの MBean タイプを生成するために使用する MDF です。
注意: MDF 要素の構文についての完全なリファレンスは、MBean 定義ファイル (MDF) 要素の構文.に収められています。
コード リスト 2-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"
PersistPolicy = "OnUpdate"
Description = "This MBean represents configuration attributes for the WebLogic Credential Mapping provider.<p>"
>
<MBeanAttribute
Name = "ProviderClassName"
Type = "java.lang.String"
Writeable = "false"
Default = ""weblogic.security.providers.credentials. DefaultCredentialMapperProviderImpl""
Description = "The name of the Java class that loads the WebLogic Credential Mapping provider."
/>
<MBeanAttribute
Name = "Description"
Type = "java.lang.String"
Writeable = "false"
Default = ""Provider that performs Default Credential Mapping""
Description = "A short description of the WebLogic Credential Mapping provider."
/>
<MBeanAttribute
Name = "Version"
Type = "java.lang.String"
Writeable = "false"
Default = ""1.0""
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 でも必須です 図 2-6 を参照)。ProviderClassName 属性は特に重要です。ProviderClassName 属性の値は、セキュリティ プロバイダの実行時クラスの Java ファイル名 (すなわち、「Provider」という文字列で終わる適切な SSPI の実装) です。リスト2-1 で示されているサンプルの実行時クラスは、DefaultCredentialMapperProviderImpl.java です。
リスト2-1 では示されていませんが、<MBeanAttribute> タグおよび <MBeanOperation> タグを使用して MDF に属性と操作を追加することができます。ほとんどのカスタム属性は、WebLogic Administration Console のカスタム セキュリティ プロバイダの [詳細] タブに自動的に表示されます。例については図 2-5 を参照してください。 ただし、カスタム操作を表示するには、コンソール拡張機能を記述する必要があります。コンソール拡張の記述を参照してください。
注意: サンプル監査プロバイダ (dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能) では、カスタム属性を追加する例が提供されています。
SSPI MBean の階層と Administration Console に対する影響を理解する
MBean 定義ファイル (MDF) で拡張する必須 SSPI MBean (基本 SSPI MBean である Provider に至るまで) に指定されている属性と操作はすべて、関連するセキュリティ プロバイダの WebLogic Server Administration Console ページに自動的に表示されます。これらの属性と操作は、カスタム セキュリティ プロバイダをコンフィグレーションおよび管理するために使用します。
注意: 認証セキュリティ プロバイダに限っては、MDF で実装される任意 SSPI MBean で指定された属性と操作も Administration Console で自動的にサポートされます。他のタイプのセキュリティ プロバイダの場合、任意 SSPI MBean から継承された属性/操作を Administration Console で使用するには、コンソール拡張機能を記述する必要があります。詳細については、コンソール拡張の記述を参照してください。
図 2-6 は、WebLogic 資格マッピング MDF を例に使用してセキュリティ プロバイダの SSPI MBean 階層を示すとともに、どの属性/操作が WebLogic 資格マッピング プロバイダの Administration Console で表示されるのかを示します。
図2-6 資格マッピング プロバイダの SSPI MBean 階層
図 2-6 で示されているように、DefaultCredentialMapper MDF の SSPI MBean の階層を実装することにより、図 2-7 のページが Administration Console で表示されます。DefaultCredentialMapper MDF のリストはリスト2-1 に示してあります。
図2-7 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 MDF の実装に対応するフィールドは表示されません。
WebLogic MBeanMaker によって提供されるものを理解する
WebLogic MBeanMaker は、MBean 定義ファイル (MDF) を入力とし、MBean タイプのファイルを出力するコマンドライン ユーティリティです。WebLogic MBeanMaker を使用して作成した MDF を実行すると、以下のことが行われます。
開発者の必要なアクション : 現時点では、WebLogic MBeanMaker では継承されたメソッドのメソッド スタブが生成されません。したがって、「Mapping MDF Operation Declarations to Java Method Signatures Document」 (dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能) を利用して適切な実装を提供する必要があります。
このことを 図 2-8 に示します。
図2-8 WebLogic MBeanMaker によって提供されるもの
MBean 情報ファイルには、MBean 定義ファイル内のコンパイルされたデータ定義が JMX Model MBean で要求される形式で含まれます。 このファイルのフォーマットは属性、操作、および通知のリストであり、エンティティごとにそのエンティティを記述する記述子タグのセットがあります。 さらに MBean 自体にも記述子タグのセットが付きます。 このフォーマットの例は次のとおりです。
attribute1 + タグ, attribute2 + タグ ...
operation1 + タグ, operation2 + タグ ...
notification1 + タグ, notification2 + タグ ...
必要に応じて、標準の JMX サーバの getMBeanInfo メソッドを呼び出して ModelMBeanInfo を取得することで、実行時にこの情報にアクセスできます。
注意: JMX 仕様を参照して、返される構造の解釈方法を確認してください。
カスタム セキュリティ プロバイダの開発の一部として実装する必要のある SSPI のリストに基づいて、拡張する必要のある必須 SSPI MBean を 表 2-2 で特定してください。また、表 2-3 から 表 2-5 を使用して、セキュリティ プロバイダを管理するために実装する必要のある任意 SSPI MBean を特定してください。
注意: 表 2-2 に示した必須 SSPI MBean は、weblogic.management.security.<パッケージ名> というパッケージに定義されています。
注意: 表 2-3 に示す認証用任意 SSPI MBean は、weblogic.management.security.authentication パッケージに定義されています。また、これらは WebLogic Server Administration Console でもサポートされます。
表 2-3 で示されている認証用任意 SSPI MBean の実装方法を示す例については、Manageable Sample Authentication Provider (dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能) のコードを参照してください。
注意: 表 2-4 に示す認可用任意 SSPI MBean は、weblogic.management.security.authorization パッケージに定義されています。
注意: 表 2-5 に示す資格マッピング用任意 SSPI MBean は、weblogic.management.security.credentials パッケージに定義されています。
weblogic.management.utils パッケージには、開発者にとって特にカスタム セキュリティ プロバイダの MBean タイプを生成する際に役立つ管理インタフェースと例外が含まれています。 これらのインタフェースと例外の実装には、カスタム セキュリティ プロバイダの MDF で任意 SSPI MBean を実装してこれらを継承する場合を除いて、カスタム セキュリティ プロバイダを開発する必要がありません。
注意: このインタフェースとクラスは、一般的な用途のユーティリティ、つまり非セキュリティ MBeean にも使用できるものなので、weblogic.management.security ではなくこのパッケージに入っています。 MBean のさまざまなタイプについては、『WebLogic JMX Service プログラマーズ ガイド』の「WebLogic Server 管理対象リソースと MBean」を参照してください。
weblogic.management.utils パッケージには、以下のユーティリティが含まれています。
注意: Manageable Sample Authentication Provider (dev2dev Web サイトの「Code Samples: WebLogic Server」から入手可能なサンプル セキュリティ プロバイダ) は、データ リストを扱うためだけでなく、例外用にも weblogic.management.utils パッケージを使用します。
詳細については、WebLogic Server 7.0 API リファレンス Javadoc の weblogic.management.utils パッケージを参照してください。
WebLogic リソースは、権限のないアクセスから保護することができる WebLogic Server エンティティを表す構造化オブジェクトです。カスタムの認可プロバイダ、ロールマッピング プロバイダ、および資格マッピング プロバイダの開発者は、これらのセキュリティ プロバイダが、WebLogic リソースおよびそれらのリソースのセキュリティに使用されるセキュリティ ポリシーとどのように対話するかを理解しておく必要があります。
注意: セキュリティ ポリシーは、以前のリリースの WebLogic Server で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) とパーミッションに代わるものです。
以下の節では、セキュリティ プロバイダと WebLogic リソースについて説明します。
注意: 詳細については、『WebLogic リソースのセキュリティ』を参照してください。
weblogic.security.spi パッケージに定義されている Resource インタフェースは、権限のないアクセスから保護できる WebLogic リソースを表すオブジェクトを定義します。 weblogic.security.service パッケージに定義されている ResourceBase クラスは、より詳細な WebLogic リソース タイプの抽象基底クラスで、リソースを拡張するためのモデルです。詳細については、図 2-9 とWebLogic リソースのタイプを参照してください。
ResourceBase クラスには、BEA が提供する getID、getKeys、getValues、および toString メソッドの実装が含まれています。 詳細については、WebLogic Server 7.0 API リファレンス Javadoc の ResourceBase クラスを参照してください。
このアーキテクチャにより、特定の WebLogic リソースを意識することなくセキュリティ プロバイダを開発できます。このため、新しいリソース タイプが追加されても、セキュリティ プロバイダを修正する必要がありません。
図 2-9 に示したように、weblogic.security.service パッケージの特定のクラスは ResourceBase クラスの拡張であるため、WebLogic リソースの特定のタイプの実装を提供します。以下の WebLogic リソースの実装を使用できます。
注意: これらの各 WebLogic リソースの詳細については、『WebLogic リソースのセキュリティ』および WebLogic Server 7.0 API リファレンス Javadoc の weblogic.security.service パッケージを参照してください。
各 WebLogic リソース (WebLogic リソースのタイプを参照) は、その toString() 表現か、または getID メソッドを使用して取得される ID によって識別できます。
これらの 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 リソースに戻すことができます)。
注意: リスト2-2 に、toString() メソッドを使用して WebLogic リソースを識別する方法を示します。
定義済みの各 WebLogic リソース タイプに定義されている getID() メソッドは、セキュリティ プロバイダで WebLogic リソースをユニークに識別するために使用できる 64 ビット ハッシュコードを返します。リソース ID は、以下のアルゴリズムを使用して、高速の実行時キャッシングに効果的に使用できます。
注意: リスト2-3 に、認可プロバイダで getID() メソッドを使用して WebLogic リソースを識別する方法と、そのアルゴリズムの実装例を示します。
このメソッドは何度実行しても同じ値を返すという保証はないので、このリソース ID を使用してセキュリティ プロバイダ データベースに WebLogic リソースに関する情報を格納してはいけません。代わりに、WebLogic リソースの toString() メソッドを使用して、リソース対セキュリティ ポリシーおよびリソース対セキュリティ ロール マッピングを、対応するセキュリティ プロバイダ データベースに格納するようにしてください。
注意: セキュリティ プロバイダ データベースの詳細については、セキュリティ プロバイダ データベースの初期化を参照してください。toString() メソッドの詳細についてはtoString() メソッドを参照してください。
カスタム認証プロバイダの実行時クラスを記述する場合は、デフォルト グループをいくつか作成しておく必要があります。 表 2-6 は、このタスクを行う場合に役立つ情報を示しています。
WebLogic リソースのデフォルト セキュリティ ロールの作成
カスタム ロール マッピング プロバイダの実行時クラスを記述する場合は、デフォルト グローバル ロールをいくつか作成しておく必要があります。 表 2-7 は、このタスクを行う場合に役立つ情報を示しています。
注意: グローバル ロールとスコープ ロールの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。
WebLogic リソースのデフォルト セキュリティ ポリシーの作成
カスタム認可プロバイダの実行時クラスを記述する場合は、デフォルト セキュリティ ポリシーをいくつか作成しておく必要があります。 これらのデフォルト セキュリティ ポリシーは、初期状態でさまざまなタイプの WebLogic リソースを保護します。 表 2-8 は、このタスクを行う場合に役立つ情報を示しています。
注意: アプリケーションおよび COM リソースにはデフォルト セキュリティ ポリシーを設定しないでください (つまり、デフォルトですべてのユーザにパーミッションを付与しないでください)。
セキュリティ プロバイダの実行時クラスでの WebLogic リソースのルックアップ
リスト2-2 に、認可プロバイダの実行時クラスで WebLogic リソースをルックアップする方法を示します。このアルゴリズムは、認可プロバイダのセキュリティ プロバイダ データベースに WebLogic リソースとセキュリティ ポリシーのマッピングが格納されていることを前提にしています。 リスト2-2 に示すアルゴリズムと getParentResource メソッドの使用は必須ではありません。getParentResource メソッドの詳細については 単一親リソース階層を参照してください。
コード リスト 2-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 リソースのルックアップ アルゴリズムを最適化できます。リスト2-2 に示すように toString メソッドを使用すると文字列の連結のためにパフォーマンスが低下する場合があります。getID メソッドは WebLogic リソース自身の内部で計算およびキャッシュされるハッシュ処理なのでより高速で効率的です。 このため、getID メソッドを使用する場合、toString 値の計算はリソースにつき一度しか必要ありません。リスト2-3 を参照してください。
コード リスト 2-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 7.0 API リファレンス Javadoc で任意の定義済み WebLogic リソース タイプまたは Resource インタフェースを参照してください。
Java サーブレット仕様 2.3 のセクション SRV.11.1 および SRV.11.2 では、サーブレット コンテナのパターン マッチング ルールが説明されています。 そのルールは、URL リソースにも使用します。 以下の例は、URL リソースのパターン マッチングに関する重要な概念を示しています。
URL リソース type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp, httpMethod=GET では、次のようなリソース階層が使用されます。 行 3 と行 4 に注目してください。URL パターンが、予想とは異なるかもしれません。
URL リソース type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo では、次のようなリソース階層が使用されます。 行 2 に注目してください。URL パターンが、予想とは異なるかもしれません。
ContextHandler と WebLogic リソース
ContextHandler は、リソース コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール マッピング決定を行うセキュリティ プロバイダに渡す高性能な WebLogic クラスです。ContextHandler インタフェースを使用すると、内部 WebLogic リソース コンテナが WebLogic Security フレームワーク呼び出しに追加情報を渡すことができるようになります。その結果、セキュリティ プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandler は本質的には名前と値のリストなので、セキュリティ プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandler の使用には、WebLogic リソース コンテナとセキュリティ プロバイダの間の緊密な連携が不可欠です。ContextHandler の名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElement オブジェクトによって表されます。
注意: ContextHandler インタフェースおよび ContextElement クラスの詳細については、WebLogic Server 7.0 API リファレンス Javadoc の weblogic.security.service パッケージを参照してください。
現在、2 種類の WebLogic リソース コンテナ (サーブレット コンテナと EJB コンテナ) が ContextHandler を WebLogic Security フレームワークに渡します。 そのため、URL (Web) および EJB のリソース タイプには、異なるコンテキスト要素が含まれます。これらのコンテキスト要素の値は、カスタム認可プロバイダまたはカスタム ロール マッピング プロバイダの開発の一部として調べることができます。 表 2-9 および 表 2-10 は、URL リソースおよび EJB リソースの ContextHandler の各コンテキスト要素を示しています。
|
EJB の ejb-jar.xml デプロイメント記述子の <method-param> 要素を介して、各パラメータのオブジェクト タイプとセマンティクスを判別する。 |
|
リスト2-4 では、URL (Web) リソースの ContextHandler を介して、HttpServletRequest および HttpServletResponse コンテキスト要素オブジェクトにアクセスする方法を示します。たとえば、このコードを AccessDecision SSPI 実装の isAccessAllowed() メソッドで使用できます。詳細については、AccessDecision SSPI を実装するを参照してください。
コード リスト 2-4 例 : URL リソースの ContextHandler でのコンテキスト要素へのアクセス
static final String SERVLETREQUESTNAME = "HttpServletRequest";
if (resource instanceof URLResource) {
HttpServletRequest req =
(HttpServletRequest)handler.getValue(SERVLETREQUESTNAME);
}注意: RoleMapper SSPI 実装の getRoles() メソッドや、AuditContext インタフェース実装の getContext() メソッドでこれらのコンテキスト要素にアクセスすることもできます。詳細については、それぞれ RoleMapper SSPI を実装すると監査コンテキストを参照してください。
注意: この節を読む前に、『WebLogic Security の紹介』の「セキュリティ プロバイダ データベース」に目を通しておいてください。
セキュリティ プロバイダのデータベースは、少なくとも、認証、認可、ロール マッピング、および資格マッピングの各プロバイダで必要なデフォルトのユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、または資格で初期化する必要があります。 セキュリティ プロバイダのデータベースを初期化してから、セキュリティ プロバイダを使用してください。また、カスタム セキュリティ プロバイダ用の実行時クラスを記述する場合にこのデータベースがどのように機能するかについても考えておく必要があります。 セキュリティ プロバイダのデータベースを初期化する方法は、数多くの要因によって決まります。要因としては、外部で管理されるデータベースがユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、資格の情報の格納に使用されるかどうか、データベースが既に存在しているかどうか (作成する必要があるかどうか)、などがあります。
以下の節では、セキュリティ プロバイダ データベースを初期化するためのベスト プラクティスについて説明します。
ベスト プラクティス : データベースがない場合のシンプルなデータベースの作成
認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、または資格マッピング プロバイダは、それが初めて使用されるときには、セキュリティ サービスを提供するために必要な情報のあるデータベースを見つけようとします。 セキュリティ プロバイダがデータベースを見つけられない場合は、セキュリティ プロバイダにデータベースを作成させて、デフォルトのユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格を自動的に格納することができます。このオプションは、開発およびテストに便利です。
WebLogic セキュリティ プロバイダとサンプル セキュリティ プロバイダは両方ともこのプラクティスに従います。 WebLogic の認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、ユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格の情報を組み込み LDAP サーバに格納します。 これらの WebLogic セキュリティ プロバイダのいずれかを使用する場合は、『WebLogic Security の管理』の「組み込み LDAP サーバのコンフィグレーション」で説明されている指示に従う必要があります。
注意: dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能なサンプル セキュリティ プロバイダは、単純に properties ファイルを作成してそれをデータベースとして使用します。たとえば、サンプル認証プロバイダでは、ユーザおよびグループについての必要な情報が格納される SampleAuthenticatorDatabase.java というファイルが作成されます。
ベスト プラクティス : 既存のデータベースのコンフィグレーション
外部 LDAP サーバなどのデータベースが既にある場合は、認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダが必要とするユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格の情報をそのデータベースに格納できます。既存のデータベースへの情報の格納は、それを目的として既に用意されているどのようなツールを使用しても行うことができます。
データベースに必要な情報が格納されたら、そのデータベースを参照するようにセキュリティ プロバイダをコンフィグレーションする必要があります。そのためには、セキュリティ プロバイダの MBean 定義ファイル (MDF) でカスタム属性を追加します。カスタム属性の例には、データベースのホスト、ポート、パスワードなどがあります。WebLogic MBeanMaker を通じて MDF を実行し、さらにいくつかのステップを行ってカスタム セキュリティ プロバイダの MBean タイプを生成したら、WebLogic Server Administration Console を使用してそれらの属性がデータベースを指すように設定します。
注意: MDF、MBean タイプ、および WebLogic MBeanMaker の詳細については、カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成を参照してください。
リスト2-5 は、WebLogic LDAP 認証プロバイダの MDF に属する一部のカスタム属性を例として示しています。これらの属性を使用することにより、WebLogic LDAP 認証プロバイダのデータベース (外部 LDAP サーバ) についての情報を指定することができるので、プロバイダでユーザおよびグループについての情報を見つけることができます。
コード リスト 2-5 LDAPAuthenticator.xml
...
<MBeanAttribute
Name = "UserObjectClass"
Type = "java.lang.String"
Default = ""person""
Description = "The LDAP object class that stores users."
/>
<MBeanAttribute
Name = "UserNameAttribute"
Type = "java.lang.String"
Default = ""uid""
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 = ""ou=people, o=example.com""
Description = "The base distinguished name (DN) of the tree in the LDAP directory
that contains users."
/>
<MBeanAttribute
Name = "UserSearchScope"
Type = "java.lang.String"
Default = ""subtree""
LegalValues = "subtree,onelevel"
Description = "Specifies how deep in the LDAP directory tree to search for Users.
Valid values are <code>subtree</code>
and <code>onelevel</code>."
/>
...
可能な限り、セキュリティ プロバイダとセキュリティ プロバイダ データベースの間の初期化呼び出しは、データベース デリゲータという中間クラスを介して行う必要があります。データベース デリゲータは、図 2-10 で示されているようにセキュリティ プロバイダの実行時クラスおよび MBean タイプと対話する必要があります。
データベース デリゲータは、WebLogic の認証プロバイダと資格マッピング プロバイダで使用されます。たとえば、WebLogic 認証プロバイダはデータベース デリゲータに働きかけてデフォルトのユーザおよびグループで組み込み LDAP サーバを初期化します。デフォルトのユーザおよびグループは、デフォルト セキュリティ レルムの認証サービスを提供するために必要な情報です。
カスタム セキュリティ プロバイダを開発するアプリケーション開発者およびセキュリティ ベンダは、データベース デリゲータを使用することをお勧めします。データベース デリゲータを使用すると、セキュリティ プロバイダのデータベースが隠蔽され、データベースへの呼び出しが一元化されるメリットがあります。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
