Java EE コネクター・セキュリティー
Java™ 2 Platform, Enterprise Edition (Java EE) コネクター・アーキテクチャーは、J2EE を異機種のエンタープライズ情報システム (EIS) に接続するための標準のアーキテクチャーを定義します。 EIS には、例えば Enterprise Resource Planning (ERP)、 メインフレーム・トランザクション処理 (TP)、 およびデータベース・システムなどがあります。
コネクター・アーキテクチャーは、EIS ベンダーが自身の EIS 用の標準のリソース・アダプターを提供できるようにします。 リソース・アダプターは、Java アプリケーションが EIS への接続に使用するシステム・レベルのソフトウェア・ドライバーです。 このリソース・アダプターは、アプリケーション・サーバーにプラグインし、 EIS、アプリケーション・サーバー、およびエンタープライズ・アプリケーション間の接続性を提供します。 EIS の情報へのアクセスには、通常、無許可アクセスを防ぐためアクセス制御が必要です。 J2EE アプリケーションは、接続を開くために EIS への認証を行う必要があります。
- BasicPassword: EIS 固有の、基本のユーザー・パスワード・ベースの認証メカニズム
Kerbv5: Kerberos バージョン 5 ベースの認証メカニズム
アプリケーションは、デプロイメント記述子の resource-ref エレメントで、アプリケーション管理のサインオンを使用するか、またはコンテナーが管理するサインオンを使用するかを定義します。 各 resource-ref エレメントには、単一の接続ファクトリー参照バインディングが記述されます。 resource-ref エレメント内の res-auth エレメント (Application または Container のいずれかの値) は、 エンタープライズ Bean コードがサインオンを実行できるか、またはアプリケーション・サーバーが プリンシパル・マッピング構成を使用して、リソース・マネージャーへサインオンできるかを表します。resource-ref エレメントは、通常、アセンブリー・ツールを使用して、アプリケーションのアセンブル時に定義されます。 resource-ref は、デプロイメント時間でも、定義あるいは再定義できます。
アプリケーション管理のサインオン
EIS システムにアクセスするには、アプリケーションが Java Naming and Directory Interface (JNDI) 名前空間から接続ファクトリーを配置し、その接続ファクトリー・オブジェクトで getConnection メソッドを呼び出します。 getConnection メソッドでは、ユーザー ID およびパスワードの引数が必要です。 J2EE アプリケーションでは、getConnection メソッドにユーザー ID およびパスワードを受け渡すことができ、 その後、その情報をリソース・アダプターに受け渡します。 ただし、アプリケーション・コード内でユーザー ID およびパスワードを指定することで、セキュリティーが侵害される可能性があります。
ユーザー ID およびパスワードは、Java ソース・コードにコード化されると、組織内の開発者やテスト担当者が使用できるようになります。また、Java クラスが逆コンパイルされると、ユーザー ID およびパスワードはユーザーに読まれてしまいます。
ユーザー ID およびパスワードを変更する場合は、必ず最初にコードの変更が必要になります。 代わりの方法として、アプリケーション・コードは、パーシスタント・ストレージまたは外部サービスから、ユーザー ID およびパスワードのセットを取得できます。 この方法では、IT 管理者が、アプリケーション固有の手段を使用して、ユーザー ID およびパスワードを構成し、管理する必要があります。
この認証データにアクセスするために、アプリケーション・サーバーでは、コンポーネント管理の認証別名をリソース上で指定することができます。この認証データは、すべてのリソースへの参照に共通です。
をクリックします。「コンポーネント管理認証別名を使用」を選択します。- getConnection メソッドに渡されるユーザー ID およびパスワード
- 接続ファクトリーまたはデータ・ソース内のコンポーネント管理認証別名
- データ・ソース内のカスタム・プロパティーのユーザー名およびパスワード
ユーザー名およびパスワードのプロパティーは、リソース・アダプター・アーカイブ (RAR) ファイル内に初期定義が可能です。
これらのプロパティーは、管理コンソールで定義することも、wsadmin スクリプトを使用して、カスタム・プロパティーから定義することもできます。
ユーザーによるリソースへの接続が使用可能であるカスタム・プロパティーは、使用しないでください。
コンテナー管理サインオン
ターゲット・エンタープライズ情報システム (EIS) のユーザー ID およびパスワードは、アプリケーション・サーバーにより提供できます。 この製品には、コンテナー管理のサインオン機能があります。 アプリケーション・サーバーは、ターゲット EIS に応じた適切な認証データを検索して、 クライアントが接続を確立できるようにします。アプリケーション・コードがコンテナー管理のサインオンを使用するように構成されている場合、アプリケーション・コードで getConnection 呼び出しでユーザー ID およびパスワードを提供する必要はありません。また、認証データがすべてのリソースへの参照について共通である必要もありません。 この製品は、Java Authentication and Authorization Service (JAAS) プラグイン可能認証メカニズムを使用して、事前に構成された JAAS ログイン構成を使用します。また、LoginModule を使用して、実行中のスレッドのクライアント・セキュリティー ID とクレデンシャルを、事前に構成されたユーザー ID とパスワードにマップします。
この製品は、指定されたターゲット EIS に対し、実行中のスレッドのすべてのクライアント ID を事前に構成された ユーザー ID およびパスワードにマップする、デフォルトの多対 1 のクレデンシャル・マッピング LoginModule モジュールに対応しています。デフォルトのマッピング・モジュールは、構成された Java 2 Connector (J2C) 認証データ・エントリーにより指定された PasswordCredential クレデンシャルを戻す、特別な目的の JAAS LoginModule モジュールです。 デフォルト・マッピングの LoginModule モジュールは、テーブル検索を行いますが、 実際の認証は行いません。ユーザー ID およびパスワードは、J2C 認証データ・リスト内に、別名とともに保管されています。
J2C 認証データ・リストは、「J2C 認証データ」の「グローバル・セキュリティー」パネルにあります。デフォルトのプリンシパルおよびクレデンシャルのマッピング機能は、DefaultPrincipalMapping アプリケーションの JAAS ログイン構成により定義されています。
Java 認証・承認サービス」管理コンソールを使用して変更された J2C 認証データは、その変更がリポジトリーに保存され、テスト接続が実行されると、 有効になります。また、wsadmin スクリプトを使用して変更された J2C 認証データは、 アプリケーション・サーバーの所定のサーバー・プロセスに対して、アプリケーションが開始または再開されると、有効になります。 J2C 認証データの変更は、SecurityAdmin MBean メソッド updateAuthDataCfg を呼び出すことによって有効になります。HashMap パラメーターをヌルに設定し、Securityadmin MBean が、リポジトリー内の最新の値を使用して、J2C 認証データをリフレッシュできるようにします。
DefaultPrincipalMapping ログイン構成は 変更しないでください。この頻繁に使用されるデフォルト・マッピング構成に対するパフォーマンスの強化が製品に含まれているためです。この製品では、DefaultPrincipalMapping 構成の変更、デフォルトの LoginModule モジュールの変更、 または構成におけるカスタム LoginModule モジュールのスタッキングがサポートされていません。
z/OS® プラットフォームでは、ユーザー ID およびパスワードが存在しない場合、またはデフォルトで別名になっている場合、WebSphere® Application Server ランタイムにより、サブジェクト内の System Authorization Facility (SAF) ユーザー ID が検索されます。
ほとんどのシステムでは、多対 1 マッピングのデフォルトの方法で十分です。 ただし、この製品は、カスタムのプリンシパルおよびクレデンシャルのマッピング構成をサポートしています。 固有の名前で新規の JAAS ログイン構成を作成することにより、カスタムのマッピング・モジュールをアプリケーション・ログイン JAAS 構成に追加できます。 例えば、カスタム・マッピング・モジュールにより、1 対 1 マッピングまたは Kerberos 機能を提供できます。
また、トラステッド接続によって、クライアント ID の伝搬をサポートしつつ、1 対 1 のマッピングも提供します。DB2® トラステッド・コンテキスト・オブジェクトの使用に加えて、トラステッド接続は、接続プールの利点を生かして、接続を閉じて別の ID で再開する際のパフォーマンス負荷を削減することができます。 また、トラステッド接続を使用することで、単一ユーザーにすべての権限を割り当てる必要がなくなり、DB2 データベースのセキュリティーも強化されます。 接続を開くためのクレデンシャルが DB2 サーバーによって信頼されているユーザーが接続を確立します。 そうするとこのユーザーは、アプリケーションから DB2 サーバーにアクセスする他のユーザーの ID の表明についても信頼されます。 実装された信頼できる接続に、TrustedConnectionMapping という新しいマッピング構成が作成されています。
また、WebSphere Application Server 管理コンソールを使用して、リソース・マネージャー接続ファクトリー参照を、構成済みのリソース・ファクトリーの 1 つにバインドすることもできます。 アプリケーションのデプロイメント記述子の res-auth エレメントの値が Container の場合は、マッピング構成を指定する必要があります。マッピング構成を指定するには、 の「参照」で「リソース参照」リンクを使用します。追加の指示については、『リソース参照のリソースへのマッピング』トピックを参照してください。
J2C マッピング・モジュールおよびマッピング・プロパティー
マッピング・モジュールは、プリンシパルおよびクレデンシャルのマッピング機能を提供する特殊な JAAS ログイン・モジュールです。 カスタム・マッピング・モジュールの定義と構成は、管理コンソールを使用して行います。
また、各 JAAS ログイン構成のログイン・オプションを使用することにより、コンテキスト・データを定義し、マッピング・モジュールに受け渡すことができます。 この製品では、各接続ファクトリー参照バインディングのマッピング・プロパティーを使用して、コンテキスト・データを定義することもできます。
各 JAAS ログイン構成に定義されているログイン・オプションは、同一の JAAS ログイン構成およびマッピング・モジュールを使用するリソース全体で共有されます。 各接続ファクトリー参照バインディング用に定義されたマッピング・プロパティーは、そのリソース参照により排他的に使用されます。
外部マッピング・サービスが使用される使用法シナリオを想定します。
例えば、Tivoli® Access Manager グローバル・サインオン (GSO) サービスを使用するとします。 Tivoli Access Manager GSO を使用し、両方のバックエンド・サーバーに対し認証データを検索します。
2 つの EIS サーバー (DB2 および MQ) があります。 ただし、DB2 用の認証データは、MQ 用のデータと異なります。 マッピング JAAS ログイン構成のログイン・オプションを使用し、Tivoli Access Manager GSO サービスへの接続の確立に必要なパラメーターを指定します。 接続ファクトリー参照バインディングのマッピング・プロパティーを使用し、 ユーザー ID およびパスワードを必要とする EIS サーバーを指定します。
マッピング・モジュールの開発について詳しくは、『J2C プリンシパル・マッピング・モジュール』を参照してください。
- 接続ファクトリーでのマッピング構成は、リソース・マネージャー接続ファクトリー参照に移動されました。 WebSphere Application Server バージョン 5 JAAS コールバック・タイプを使用して開発されたマッピング・ログイン・モジュールは、リソース・マネージャー接続ファクトリー参照により使用できます。 ただし、マッピング・ログイン・モジュールは、カスタム・マッピング・プロパティーの機能を利用できません。
- 接続ファクトリー参照バインディングは、マッピング・プロパティーをサポートし、 新規の WSMappingPropertiesCallback コールバックの方法により、それらのプロパティーをマッピング・ログイン・モジュールに受け渡します。 さらに、WSMappingPropertiesCallback コールバックおよび新規の WSManagedConnectionFactoryCallback コールバックは、com.ibm.wsspi パッケージに定義されています。 新規コールバック・タイプを持つ、新規マッピング・ログイン・モジュールを使用します。
インバウンド SecurityContext を使用したセキュアなメッセージ配信
EIS リソース・アダプターによって、セキュリティー・インフロー・コンテキストを使用するアプリケーション・サーバーにセキュリティー情報が提供されます。 セキュリティー・インフロー・コンテキストのメカニズムによって、作業マネージャーは Work インスタンスのアクションを設定済み ID のもとで実行できます。 このようなアクションには、アプリケーション・サーバーのセキュリティー・ドメインで構成された ID の下でメッセージ駆動型 Bean (MDB) として処理される、Java EE メッセージ・エンドポイントへのメッセージの配信も含まれます。
メッセージ・エンドポイントへのセキュアなメッセージ配信には、グローバル・セキュリティー構成でグローバル・セキュリティーが有効である必要があります。 また、メッセージ・エンドポイント MDB を提供するアプリケーションをホストするアプリケーション・サーバーで、アプリケーション・セキュリティーが有効である必要があります。 グローバル・セキュリティーについて詳しくは、トピック『グローバル・セキュリティーの設定』を参照してください。
アプリケーション・デプロイメント記述子のセキュリティー・ポリシーを、アプリケーション・レルムでユーザー ID と関連付けたロールとして構成する必要があります。 このアプリケーション・レルムは、アプリケーションを有効範囲とするセキュリティー・ドメインのユーザー・レジストリーとなります。 このセキュリティー構成により、EJB セキュリティーが有効となり、アプリケーション・レルム内の特定のユーザー ID に MDB メソッドへアクセスする権限を与えることができます。 セキュリティーの概要について詳しくは、トピック『セキュリティー』を参照してください。
セキュアなメッセージ配信には、WorkContextProvider および SecurityContext インターフェースの実装を両方とも定義するリソース・アダプターが必要です。 セキュアなメッセージを送達するには、まずリソース・アダプターが SecurityContext の実装を提供する Work インスタンスをサブミットします。 この SecurityContext は、作業マネージャーが Work インスタンスの実行対象を確立するために使用されます。
実行サブジェクトの確立中に、SecurityContext は Java Authentication Service Provider Interface for Containers (JASPIC) コールバックの実装を提供できます。作業マネージャーはこの実装を使用して、呼び出し元 ID およびグループ ID (CallerPrincipalCallback、GroupPrincipalCallback) を判別したり、呼び出し元 ID とパスワード (PasswordValidationCallback) を認証したりします。 呼び出し元 ID がアプリケーション・レルムにある場合、作業マネージャーは呼び出し元のプリンシパル、任意のグループ・プリンシパル、およびすべてのプライベート・クレデンシャルを含む WSSubject インスタンスを構成することにより、その ID を表明します。
別の方法として、SecurityContext が、別のログイン・モジュールまたは認証モジュールによって作成された WSSubject インスタンスを実行対象として提供することもできます。 作業マネージャーは、呼び出し元のプリンシパルがアプリケーション・レルムまたはトラステッド・レルムにある場合のみ、この WSSubject インスタンスを受け入れます。 レルムについて詳しくは、トピック『複数セキュリティー・ドメインのインバウンド・トラステッド・レルムを構成する』を参照してください。
作業マネージャーは、WSSubject インスタンスを確立できない場合、Work インスタンスを拒否します。 確立できた場合、作業マネージャーは、表明された、または受け入れられた WSSubject インスタンスに基づいて、管理対象スレッドにそのインスタンスをディスパッチします。 SecurityContext が呼び出し元 ID を提供しない場合、Work インスタンスは認証されていない呼び出し元のプリンシパルを含む WSSubject インスタンスに基づいてディスパッチします。
ディスパッチされると、Work インスタンスはセキュアなアプリケーションの MDB へのメッセージ配信を試行できます。 Work インスタンスに対して確立された WSSubject インスタンスに基づいて、すべてのメッセージが送達されます。 WSSubject インスタンスの呼び出し元プリンシパルがアプリケーション・デプロイメント記述子で宣言されたロールに関連付けられると、EJB セキュリティー・コラボレーターによって、MDB の onMessage メソッドにアクセスできます。 関連付けができない場合、コラボレーターはアクセスを拒否し、メッセージの送達は失敗します。 送達の間、MDB は EJB コンテキストのメソッドである isCallerInRole および getCallerPrincipal を使用して、追加のアクセス決定を行うことができます。 また MDB は、呼び出し元のプリンシパルが許可されているセキュリティー・ドメイン内の他のエンティティーにアクセスすることもできます。