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 クイック リファレンス」も提供します。
カスタム セキュリティ プロバイダの実行時クラスの実装には、WebLogic Security フレームワークによるセキュリティ チェックの実行を必要とするコードを含めることはできません。セキュリティ プロバイダは実際にセキュリティ チェックを実行し、WebLogic リソースへのアクセス権を付与する WebLogic Security フレームワークのコンポーネントであるため、そのようなコードを含めると無限反復が発生します。
名前が「Provider」という接尾辞で終わる各 SSPI (たとえば CredentialProvider) は、セキュリティ プロバイダのサービスを WebLogic Security フレームワークにエクスポーズします。このことで、セキュリティ プロバイダの操作 (初期化、開始、停止など) が可能となります。
図 2-2 で示されているように、セキュリティ サービスを WebLogic Security フレームワークにエクスポーズする SSPI は WebLogic Server によって提供され、そのすべてが以下のメソッドを持つ SecurityProvider インタフェースを拡張します。
public void initialize(ProviderMBean providerMBean, SecurityServices securityServices)
initialize メソッドは、セキュリティ プロバイダの関連付けられた MBean インスタンスに限定できる ProviderMBean を引数として取ります。その MBean インスタンスは生成する MBean タイプから作成され、カスタム セキュリティ プロバイダを WebLogic Server 環境で管理できるようにするコンフィグレーション データを含みます。このコンフィグレーション データがある場合は、initialize メソッドを使用してそれを抽出する必要があります。
securityServices 引数は、カスタム セキュリティ プロバイダで監査サービスを取得して使用する際の取得先となるオブジェクトです。監査サービスと監査の詳細については、「監査プロバイダ」および「カスタム セキュリティ プロバイダからのイベントの監査」を参照してください。
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 を実装します。ただし、その場合でも、デプロイメントを処理するセキュリティ プロバイダのデプロイ可能バージョンをコンフィグレーションする必要があります。
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 リソースのセキュリティ』の「セキュリティ ロール」を参照してください。
リソース アダプタ (RA) のデプロイメントに代わってセキュリティ ポリシーをデプロイできる資格マッピング プロバイダでは、CredentialProvider SSPI ではなく DeployableCredentialProvider SSPI を実装する必要があります。しかし、DeployableCredentialProvider SSPI は CredentialProvider SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、リソース アダプタのデプロイメント作業では、資格マッピング プロバイダが資格およびマッピングの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つの資格マッピング プロバイダがこの SSPI をサポートする必要があり、そうでなければ、リソース アダプタをデプロイすることが不可能になります。
注意 : 資格の詳細については、「資格マッピングの概念」を参照してください。セキュリティ ポリシーの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」を参照してください。
図 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 8.1 API リファレンス Javadoc」を参照してください。
「開発プロセスの概要」で説明されているように、カスタム セキュリティ プロバイダ開発の 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) は、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」で入手可能) は、カスタム属性の追加例を提供しています。
WL_HOME\server\lib\mbeantypes からロードされたクラスは、WebLogic Server にデプロイされている他の JAR および EAR ファイルからは見えません。共有すべき共通のユーティリティ クラスがある場合は、そのクラスをシステム クラスパス、ドメイン ディレクトリ、またはドメインの weblogic.ext.dirs ディレクトリに配置する必要があります。
表 A-2 に示すように、Encrypted 属性を使用すると、MBean 属性の値がクリア テキストとして表示されないように指定できます。たとえば、パスワードの入力を取得するときに MBean 属性の値を暗号化します。以下のコードでは、Encrypted 属性の使用例を示します。
Description = "The Keystore password."
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 は、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 MBeans で要求される形式で含まれます。このファイルの形式は、それぞれがそのエンティティを記述する記述子タグのセットを持つ属性、操作、通知のリストです。加えて、MBean 自体にも、一連の記述子タグがあります。この形式の例を次に示します。
attribute1 + tags, attribute2 + tags ...
operation1 + tags, operation2 + tags ...
notification1 + tags, notification2 + tags ...
必要に応じて、標準の JMX サーバの getMBeanInfo メソッドを呼び出し、ModelMBeanInfo を取得することで、実行時にこの情報にアクセスできます。
注意 : 返された構造を解釈する方法を決定するために、必ず JMX 仕様を参照してください。
カスタム セキュリティ プロバイダの開発の一部として実装する必要のある SSPI のリストに基づいて、拡張する必要のある必須 SSPI MBean を表 2-2 で特定してください。また、表 2-3 から表 2-5 を使用して、セキュリティ プロバイダを管理するために実装する必要のある任意 SSPI MBean を特定してください。
注意 : 表 2-2 に示した必須 SSPI MBean は、weblogic.management.security.<Package_Name> というパッケージに定義されています。
注意 : 表 2-3 に示す認証用任意 SSPI MBean は、weblogic.management.security.authentication パッケージに定義されています。また、これらは WebLogic Server Administration Console でもサポートされます。
表 2-3 に示す認証用任意 SSPI MBean の実装方法の例については、dev2dev Web サイトの「Code Samples: WebLogic Server」にある、Manageable Sample Authentication Provider のコードを確認してください。
注意 : 表 2-4 に示す認可用任意 SSPI MBean は、weblogic.management.security.authorization パッケージに定義されています。
注意 : 表 2-5 に示す資格マッピング用任意 SSPI MBean は、weblogic.management.security.credentials パッケージに定義されています。
一部の WebLogic セキュリティ プロバイダは、セキュリティ データの移行をサポートするように開発されています。つまり、(WebLogic 認証プロバイダの) ユーザとグループ、(WebLogic 認可プロバイダの) セキュリティ ポリシー、(WebLogic ロール マッピング プロバイダの) セキュリティ ロール、または (WebLogic 資格マッピング プロバイダの) 資格マップを、セキュリティ レルムからエクスポートして別のセキュリティ レルムにインポートできます。管理者は、これらの WebLogic セキュリティ プロバイダのセキュリティ データを個別に移行したり、すべての WebLogic セキュリティ プロバイダのセキュリティ データ (セキュリティ レルム全体のセキュリティ データ) を一度に移行したりできます。
管理者にとって、セキュリティ データの移行は次のような場合に有用です。
以下の節では、セキュリティ データの移行の詳細について説明します。
セキュリティ データを移行する前に、以下の概念を理解しておく必要があります。
フォーマットとは単に、セキュリティ データのエクスポートまたはインポート方法を指定するデータ フォーマットです。現在、WebLogic Server はセキュリティ プロバイダの開発者に、標準の公開されたフォーマットを提供していません。このため、フォーマットは任意に選択できますが、あるセキュリティ プロバイダから別のセキュリティ プロバイダにデータをエクスポートおよびインポートするには、両方のセキュリティ プロバイダが同じフォーマットの処理方法を理解している必要があります。サポートされるフォーマットは、特定のセキュリティ プロバイダが処理方法を理解しているデータ フォーマットのリストです。
注意 : WebLogic セキュリティ プロバイダで使用されるデータ フォーマットは非公開であるため、現時点では、WebLogic セキュリティ プロバイダとカスタム セキュリティ プロバイダの間でセキュリティ データを移行することはできません。また、別のベンダのセキュリティ プロバイダとセキュリティ データを交換するには、セキュリティ ベンダがそのための標準フォーマットに従って連携する必要があります。
制約は、エクスポートまたはインポート処理のオプションの指定に使用されるキーと値の組み合わせです。制約を使用すると、セキュリティ プロバイダのデータベースからエクスポートまたはインポートするセキュリティ データを管理者が制御できます。たとえば、管理者は、認証プロバイダのデータベースから、グループではなくユーザまたはユーザのサブセットだけをエクスポートすることができます。サポートされる制約は、特定のセキュリティ プロバイダの移行処理で管理者が指定できる制約のリストです。たとえば、認証プロバイダのデータベースを使用して、ユーザとグループをインポートできますが、セキュリティ ポリシーはインポートできません。
エクスポート ファイルは、移行処理のエクスポートの段階で、セキュリティ データを (指定されたフォーマットで) 書き込むファイルです。インポート ファイルは、移行処理のインポートの段階で、セキュリティ データを (指定されたフォーマットで) 読み込むファイルです。エクスポート ファイルとインポート ファイルのどちらも、あるセキュリティ プロバイダのデータベースから別の場所に移行する際の、セキュリティ データの一時的な格納場所です。
警告 : 移行ファイルは、保護措置を取らない限り保護されません。移行ファイルには重要なデータが入っているので、扱いには十分な注意が必要です。
WebLogic セキュリティ プロバイダのようにセキュリティ データの移行をサポートするカスタム セキュリティ プロバイダを開発する場合、そのプロバイダの MBean タイプを生成するための MBean 定義ファイルで weblogic.management.security.ImportMBean および weblogic.management.security.ExportMBean 任意 SSPI MBean を拡張してから、これらのメソッドを実装する必要があります。これらの任意 SSPI MBean には、表 2-6 および表 2-7 に示されている属性と操作が含まれています。
注意 : 詳細については、WebLogic Server 8.1 API リファレンス Javadoc の「ExportMBean インタフェース」を参照してください。
注意 : 詳細については、WebLogic Server 8.1 API リファレンス Javadoc の「ImportMBean インタフェース」を参照してください。
カスタム セキュリティ プロバイダの MDF で拡張可能な他の任意 SSPI MBean と違い、ExportMBean および ImportMBean 任意 SSPI MBean から継承した属性および操作は、関連付けられているセキュリティ プロバイダの WebLogic Server Administration Console ページの [移行] タブに自動的に表示されます (図 2-9 を参照)。これにより、管理者は各セキュリティ プロバイダのセキュリティ データを個別にエクスポートおよびインポートすることができます。
注意 : セキュリティ プロバイダが移行機能を持っていない場合、そのセキュリティ プロバイダの [移行] タブは Administration Console に表示されません。
Administration Console を使用して個々のセキュリティ プロバイダのセキュリティ データを移行する手順については、「セキュリティ プロバイダからのセキュリティ データのインポートおよびエクスポート」を参照してください。
図 2-9 WebLogic 認証プロバイダの [移行] タブ
また、セキュリティ レルムでコンフィグレーションされているセキュリティ プロバイダが移行機能を持っている場合、管理者は、セキュリティ レルム レベルの [移行] タブ (図 2-10 を参照) を使用して、それらのセキュリティ プロバイダすべてのセキュリティ データを一度にエクスポートまたはインポートできます。
注意 : セキュリティ レルム レベルの [移行] タブは、移行機能を持つセキュリティ プロバイダがセキュリティ レルムでコンフィグレーションされているかどうかにかかわらず、Administration Console に常に表示されます。ただし、[移行] タブが機能するのは、1 つまたは複数のセキュリティ プロバイダが移行機能を持っている場合だけです。
Administration Console を使用してすべてのセキュリティ プロバイダのセキュリティ データを一度に移行する手順については、『WebLogic Security の管理』の「セキュリティ プロバイダからのセキュリティ データのインポートおよびエクスポート」を参照してください。
注意 : また、管理者は、ExportMBean および ImportMBean 任意 SSPI MBean を拡張する場合、Administration Console ではなく weblogic.Admin コマンドライン ユーティリティを使用してセキュリティ データを移行することができます。
MDF に属性または操作を追加する場合、Administration Console で使用できるように、やはりコンソール拡張を記述する必要があります。詳細については、「カスタム セキュリティ プロバイダ用のコンソール拡張の記述」を参照してください。
weblogic.management.utils パッケージには、開発者にとって特にカスタム セキュリティ プロバイダの MBean タイプを生成する際に役立つ、補足的な管理インタフェースと例外が含まれています。カスタム セキュリティ プロバイダを開発する際に、これらのインタフェースと例外を実装する必要はありません (カスタム セキュリティ プロバイダの MDF で任意 SSPI MBean を実装してこれらを継承する場合を除く)。
注意 : このインタフェースとクラスは、一般的な用途のユーティリティ、つまり非セキュリティ MBean にも使用できるものなので、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 8.1 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-11 と「WebLogic リソースのタイプ」を参照)。
ResourceBase クラスには、BEA が提供する getID、getKeys、getValues、および toString メソッドの実装が含まれています。詳細については、WebLogic Server 8.1 API リファレンス Javadoc の「ResourceBase クラス」を参照してください。
このアーキテクチャにより、特定の WebLogic リソースを意識することなくセキュリティ プロバイダを開発できます。このため、新しいリソース タイプが追加されても、セキュリティ プロバイダを修正する必要がありません。
図 2-11 に示したように、weblogic.security.service パッケージの特定のクラスは ResourceBase クラスの拡張であるため、WebLogic リソースの特定のタイプの実装を提供します。以下の WebLogic リソースの実装を使用できます。
注意 : これらの各 WebLogic リソースの詳細については、『WebLogic リソースのセキュリティ』および WebLogic Server 8.1 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-8 は、このタスクを行う場合に役立つ情報を示しています。
カスタム ロール マッピング プロバイダの実行時クラスを記述する場合は、デフォルト グローバル ロールをいくつか作成しておく必要があります。表 2-9 は、このタスクを行う場合に役立つ情報を示しています。
注意 : グローバル ロールとスコープ ロールの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。
カスタム認可プロバイダの実行時クラスを記述する場合は、デフォルト セキュリティ ポリシーをいくつか作成しておく必要があります。これらのデフォルト セキュリティ ポリシーは、初期状態でさまざまなタイプの WebLogic リソースを保護します。表 2-10 は、このタスクを行う場合に役立つ情報を示しています。
注意 : アプリケーションおよび COM リソースにはデフォルト セキュリティ ポリシーを設定しないでください (つまり、デフォルトですべてのユーザにパーミッションを付与しないでください)。
コード リスト 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 8.1 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 の場合、リソース階層は次のように使用されます (予想と異なっている可能性がある URL パターンが含まれる、3 行目と 4 行目に注意)。
URL リソース type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo の場合、リソース階層は次のように使用されます (予想と異なっている可能性がある URL パターンが含まれる、2 行目に注意)。
ContextHandler は、リソース コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール マッピング決定を行うセキュリティ プロバイダに渡す高性能な WebLogic クラスです。ContextHandler インタフェースを使用すると、内部 WebLogic リソース コンテナで WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandler は本質的には名前と値のリストなので、セキュリティ プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandler の使用には、WebLogic リソース コンテナとセキュリティ プロバイダの間の緊密な連携が不可欠です。ContextHandler の名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElement オブジェクトによって表されます。
注意 : ContextHandler インタフェースおよび ContextElement クラスの詳細については、WebLogic Server 8.1 API リファレンス Javadoc の「weblogic.security.service パッケージ」を参照してください。
現在、2 種類の WebLogic リソース コンテナ (サーブレット コンテナと EJB コンテナ) が ContextHandler を WebLogic Security フレームワークに渡します。そのため、URL (Web) および EJB のリソース タイプには、異なるコンテキスト要素が含まれます。これらのコンテキスト要素の値は、カスタム認可プロバイダまたはカスタム ロール マッピング プロバイダの開発の一部として調べることができます。表 2-11 および表 2-12 は、URL リソースおよび EJB リソースの ContextHandler の各コンテキスト要素を示しています。
|
|
|
コード リスト 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」で入手できます。たとえば、サンプル認証プロバイダでは、ユーザおよびグループについての必要な情報が格納される SampleAuthenticatorDatabase.java というファイルが作成されます。
外部 LDAP サーバなどのデータベースがすでにある場合は、認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダが必要とするユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格の情報をそのデータベースに格納できます。既存のデータベースへの情報の格納は、それを目的としてすでに用意されているどのようなツールを使用しても行うことができます。
データベースに必要な情報が格納されたら、そのデータベースを参照するようにセキュリティ プロバイダをコンフィグレーションする必要があります。そのためには、セキュリティ プロバイダの MBean 定義ファイル (MDF) でカスタム属性を追加します。カスタム属性の例には、データベースのホスト、ポート、パスワードなどがあります。WebLogic MBeanMaker を通じて MDF を実行し、さらにいくつかの手順を行ってカスタム セキュリティ プロバイダの MBean タイプを生成したら、WebLogic Server Administration Console を使用してそれらの属性がデータベースを指すように設定します。
注意 : MDF、MBean タイプ、および WebLogic MBeanMaker の詳細については、「カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成」を参照してください。
コード リスト 2-5 は、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-12 で示されているようにセキュリティ プロバイダの実行時クラスおよび MBean タイプと対話する必要があります。
データベース デリゲータは、WebLogic の認証プロバイダと資格マッピング プロバイダで使用されます。たとえば、WebLogic 認証プロバイダはデータベース デリゲータに働きかけてデフォルトのユーザおよびグループで組み込み LDAP サーバを初期化します。デフォルトのユーザおよびグループは、デフォルト セキュリティ レルムの認証サービスを提供するために必要な情報です。
カスタム セキュリティ プロバイダを開発するアプリケーション開発者およびセキュリティ ベンダは、データベース デリゲータを使用することをお勧めします。データベース デリゲータを使用すると、セキュリティ プロバイダのデータベースが隠蔽され、データベースへの呼び出しが一元化されるメリットがあります。
|
|
|
![[詳細] タブの例](wwimages/cm_det.gif "[詳細] タブの例")
![WebLogic 認証プロバイダの [移行] タブ](wwimages/p_mig.gif "WebLogic 認証プロバイダの [移行] タブ")
![セキュリティ レルムの [移行] タブ](wwimages/r_mig.gif "セキュリティ レルムの [移行] タブ")
