WebSphere Application Server - Express for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

WebSphere Application Server での JACC サポート

WebSphere Application Server は、Java Authorization Contract for Containers (JACC) 仕様をサポートし、 サード・パーティーのセキュリティー・プロバイダーが Java 2 Platform, Enterprise Edition (J2EE) 許可を処理できるようにします。

JACC 仕様では、アプリケーション・サーバーおよびプロバイダーの両方のコンテナーが、 いくつかの要件を満たしていることが必要となります。 すなわち、コンテナーは、アプリケーションのデプロイメント時にセキュリティー・ポリシー情報をプロバイダーに伝搬すること、およびすべての許可の決定に対してプロバイダーを呼び出すことができる必要があります。 プロバイダーは、アプリケーションのデプロイメント時に、 ポリシー情報をリポジトリーに保管する必要があります。 プロバイダーはこの情報を使用して、コンテナーから呼び出されたときに、許可を決定します。

JACC のアクセス決定

セキュリティーが使用可能な場合に、 エンタープライズ Bean または Web リソースがアクセスされると、 Enterprise JavaBeans (EJB) コンテナーまたは Web コンテナーはセキュリティー・ランタイムを呼び出し、 アクセスを許可するかどうか許可の決定を行います。 外部プロバイダーを使用する場合、アクセスの決定はそのプロバイダーが代行します。

Java Authorization Contract for Containers (JACC) 仕様に準じて、適切な許可オブジェクトが作成され、 適切なポリシー・コンテキスト・ハンドラーが登録され、さらに適切なポリシー・コンテキスト ID (contextID) が設定されます。 呼び出しは、アクセス決定を行うためにプロバイダーにより実装された java.security.Policy オブジェクト・メソッドに対して行われます。

以下のセクションでは、エンタープライズ Bean および Web リソースの両方に対して、 どのようにプロバイダーが呼び出されるかを説明します。

エンタープライズ Bean についてのアクセス決定

セキュリティーが使用可能な場合に EJB メソッドがアクセスされると、EJB コンテナーは許可検査をセキュリティー・ランタイムに委任します。 JACC が使用可能な場合、セキュリティー・ランタイムは、以下のプロセスを使用して許可検査を実行します。
  1. Bean 名、メソッド名、インターフェース名、およびメソッド・シグニチャーを使用して、 EJBMethodPermission オブジェクトが作成されます。
  2. コンテキスト ID が作成され、PolicyContext.setContextID(contextID) メソッドを使用して、スレッド上に設定されます。
  3. サブジェクト・ポリシー・コンテキスト・ハンドラーなど、必要なポリシー・コンテキスト・ハンドラーが登録されます。
  4. サブジェクトに、プリンシパルを指定した ProtectionDomain オブジェクトが作成されます。 プリンシパルがない場合は、プリンシパル名としてヌルが渡されます。
  5. JACC プロバイダーに実装された Policy オブジェクトの implies メソッドを呼び出すことにより、 アクセス決定は JACC プロバイダーにより代行されます。 EJBMethodPermission および ProtectionDomain オブジェクトは、このメソッドに受け渡されます。
  6. また、isCallerInRole アクセス検査では、 EJBMethodPermission オブジェクトの代わりに EJBRoleRefPermission オブジェクトが作成される以外は、同じプロセスが実行されます。

Web リソースについてのアクセス決定

セキュリティーが使用可能であり、JACC プロバイダーを使用するよう構成されている場合に、 サーブレットや JavaServer Pages (JSP) ファイルなどの Web リソースがアクセスされると、 セキュリティー・ランタイムは、以下のプロセスを使用して JACC プロバイダーに許可の決定を委任します。
  1. URI がクリアされているかを確認するため、WebResourcePermission オブジェクトが作成されます。 プロバイダーが Everyone サブジェクトを受け入れる場合は、それもここで選択されます。
    1. WebResourcePermission オブジェクトが、urlPattern および HTTP メソッドでアクセスされるよう構成されます。
    2. ProtectionDomain オブジェクトが、ヌルのプリンシパル名で作成されます。
    3. JACC プロバイダーの Policy.implies メソッドが、許可および保護ドメインを指定して呼び出されます。 URI アクセスがクリアされている、または Everyone サブジェクトへの任意のアクセスである場合、 プロバイダーは、implies メソッドでアクセスを許可 (truetrue を戻す) します。 アクセスは、それ以上のチェックなしで認可されます。
  2. 前のステップでアクセスが認可されない場合は、 Uniform Resource Identifier (URI) が排除され、除外されているかどうか、 または HTTPS プロトコルを使用してリダイレクトされる必要があるかどうかを確認するために WebUserDataPermission オブジェクトが作成され、使用されます。
    1. WebUserDataPermission オブジェクトは、urlPattern のアクセス、 HTTP メソッドの起動、および要求のトランスポート・タイプが指定されて構成されています。 要求が HTTPS による場合はトランスポート・タイプが CONFIDENTIAL に設定され、それ以外の場合はヌルが受け渡されます。
    2. ProtectionDomain オブジェクトが、ヌルのプリンシパル名で作成されます。
    3. JACC プロバイダーの Policy.implies メソッドが、許可および保護ドメインを指定して呼び出されます。 要求に HTTPS プロトコルが使用されている場合に implies メソッドが false を戻すと、 除外および排除された許可を意味する HTTP 403 エラーが戻されます。 この場合、それ以上の検査は行われません。 要求に HTTPS プロトコルが使用されていない場合に implies が false を戻すと、その要求は HTTPS によ ってリダイレクトされます。
  3. セキュリティー・ランタイムは、ユーザーの認証を試行します。 認証情報がすでに存在する (例えば、LTPA トークン) 場合は、それが使用されます。 それ以外の場合は、ユーザーの信任状を入力する必要があります。
  4. ユーザーのクレデンシャルが検証されると、 ユーザーがその URI へのアクセス権を認可されているかどうか確認する最終の許可検査が行われます。
    1. ステップ 1 では、WebResourcePermission オブジェクトが作成されます。 ProtectionDomain オブジェクトには、その URI へのアクセスを試みるプリンシパルが含まれています。 サブジェクト・ポリシー・コンテキスト・ハンドラーにもユーザーの情報が含まれており、アクセスをチェックするときに使用できます。
    2. プロバイダーの implies メソッドは、Permission オブジェクト、 および以前に作成された ProtectionDomain オブジェクトを使用して呼び出されます。 ユーザーがリソースにアクセスする許可を認可された場合、implies メソッドは true を戻します。 ユーザーがアクセスを認可されなかった場合、implies メソッドは false を戻します。
前にリストされた順番が、後で (例えば、パフォーマンスの改善の目的で) 変更された場合でも、最終的な結果は同じになります。 例えば、リソースが排除または除外されていた場合の最終的な結果は、そのリソースにアクセスできないことです。

サブジェクトからの情報をアクセス決定に使用

アクセス決定に対しプロバイダーが WebSphere Application Server が生成したサブジェクトを信頼する場合、 プロバイダーは、サブジェクト内の公開クレデンシャルを照会し、WSCredential クレデンシャルを取得できます。 WSCredential API を使用すると、名前やユーザーが所属するグループなど、ユーザーについての情報を取得できます。 その情報は、アクセスの決定を行うために使用されます。

プロバイダーがサブジェクトに必要な情報を追加する場合、WebSphere Application Server は、 その情報を使用してアクセスを決定することができます。 プロバイダーは、 Trust Association Interface 機能を使用するか、またはアプリケーション・サーバーにログイン・モジュールを接続することによって、 情報を追加することができます。

『セキュリティー属性の伝搬』セクションには、 サブジェクトに WebSphere Application Server の必要な情報を追加する方法についての追加資料が含まれています。 詳しくは、アプリケーション・サーバー間のセキュリティー属性の伝搬 を参照してください。

JACC での動的モジュール更新

WebSphere Application Server では、特定の条件の下で、Web モジュールの動的更新がサポートされています。 Web モジュールの更新、削除、またはアプリケーションに対する追加が行われた場合、 そのモジュールのみが、適宜に停止および開始されます。 アプリケーション内に存在するその他のモジュールは影響を受けず、アプリケーション自身の停止および再始動は行われません。

デフォルトの許可エンジンを使用する場合は、Web モジュール内の任意のセキュリティー・ポリシーが変更され、 アプリケーションは停止した後再始動されます。 Java Authorization Contract for Containers (JACC) ベースの許可が使用されている場合は、 その振る舞いはプロバイダーがサポートする機能に依存します。 プロバイダーが Web モジュールへの動的変更を処理できる場合、その Web モジュールのみが影響を受けます。 それ以外の場合は、Web モジュールへの新しい変更を有効にするため、アプリケーション全体が停止および再始動されます。

JACC 構成モデルの「動的モジュール更新のサポート」オプションを構成することにより、 プロバイダーが動的更新をサポートするかどうかを示すことができます (詳しくは、Tivoli Access Manager を使用した J2EE リソースへのアクセスの許可 を参照してください)。 このオプションは、管理コンソールを使用して、またはスクリプトにより、使用可能または使用不可に設定できます。 ほとんどのプロバイダーがポリシー情報をその外部リポジトリーに保管し、 それにより動的更新をサポートすることが可能になると予想されます。 ほとんどのプロバイダーでは、このオプションはデフォルトで使用可能になります。

動的モジュール更新のサポート」オプションが使用可能なときに、 セキュリティー役割を含む Web モジュールが動的に追加、変更、または削除された場合は、 指定の Web モジュールのみが影響を受け、再始動されます。 このオプションが使用不可の場合は、アプリケーション全体が再始動されます。 動的更新が実行された場合、影響を受けたモジュールのセキュリティー・ポリシー情報が、プロバイダーに伝搬されます。 セキュリティー・ポリシーの伝搬について詳しくは、JACC ポリシーの伝搬 を参照してください。

JACC プロバイダーの初期化

サーバー始動時に Java Authorization Contract for Containers (JACC) プロバイダーの初期化が必要な場合 (例えば、 クライアント・コードがサーバー・コードと通信できるようにするため)、 このプロバイダーは、com.ibm.wsspi.security.authorization.InitializeJACCProvider インターフェースを実装できます。 詳しくは、JACC をサポートするインターフェース を参照してください。

このインターフェースがインプリメントされると、サーバー始動時に呼び出されます。 JACC 構成モデル内のすべてのカスタム・プロパティーが、そのインプリメンテーションの初期化メソッドに伝搬されます。 カスタム・プロパティーは、管理コンソールまたはスクリプトを使用することにより入力できます。

サーバーのシャットダウン時には、プロバイダーの必要とするクリーンアップ処理のために、クリーンアップ・メソッドが呼び出されます。 このインターフェースのインプリメンテーションは、厳密にオプショナルであり、 プロバイダーがサーバー始動時に初期化を必要とする場合にのみ使用します。

混合ノード環境と JACC

Java Authorization Contract for Containers (JACC) による許可は、 WebSphere Application Server バージョン 6.0.x の新機能です。 また、JACC 構成は、セルのレベルでセットアップされ、 そのセル内のすべてのノードおよびサーバーに適用できます。

JACC ベースの許可を使用する場合、 バージョン 6.0.x および それ以降のノードのみをセルに含める必要があります。 この制約が意味するところは、 バージョン 6.0.x またはそれ以降のセルに、 バージョン 5.x ノードのセットが含まれるような 混合ノード環境は、サポートされていないということです。




関連概念
許可プロバイダー
JACC プロバイダーとしての Tivoli Access Manager の統合
JACC プロバイダー
許可プロバイダー
関連タスク
外部 JACC プロバイダーの使用可能化
Tivoli Access Manager を使用した J2EE リソースへのアクセスの許可
JACC プロバイダーへのインストール済みアプリケーションのセキュリティー・ポリシーの wsadmin スクリプトを使用した伝搬
関連資料
JACC をサポートするインターフェース
セキュリティー許可プロバイダーのトラブルシューティングのヒント
JACC ポリシー・コンテキスト・ハンドラー
JACC ポリシー・コンテキスト ID (ContextID) のフォーマット
JACC ポリシーの伝搬
JACC のプロバイダー・インプリメンテーション・クラスの登録
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 7:05:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.iseries.doc/info/iseriesexp/ae/csec_jaccsupport.html