WebSphere Application Server での JACC サポート

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

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 を戻します。
前にリストされた順番が、後で (例えば、パフォーマンスの改善の目的で) 変更された場合でも、最終的な結果は同じになります。 例えば、リソースが排除または除外されていた場合の最終的な結果は、そのリソースにアクセスできないことです。

これらのアクセス許可について詳しくは、『JSR-000115 Java Authorization Contract for Containers (Version 1.5 Maintenance Release)』を参照してください。

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

アクセス決定についてプロバイダーが 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 を使用した Java EE リソースへのアクセスの許可を参照してください)。 このオプションは、管理コンソールを使用して、またはスクリプトにより、使用可能または使用不可に設定できます。 ほとんどのプロバイダーがポリシー情報をその外部リポジトリーに保管し、 それにより動的更新をサポートすることが可能になると予想されます。 ほとんどのプロバイダーでは、このオプションはデフォルトで使用可能になります。

動的モジュール更新のサポート」オプションが使用可能なときに、 セキュリティー・ロールを含む 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 の新機能でした。この機能は、WebSphere Application Server バージョン 9 で、最新の JACC 仕様バージョン 1.5 に拡張されました。

JACC 構成はセル・レベルでセットアップされ、そのセル内のすべてのノードおよびサーバーに適用できます。

JACC ベース許可、バージョン 1.5 の機能を使用することを計画している場合は、セルにはバージョン 9 以降のノードのみが含まれている必要があります。この制限は、バージョン 9 以降のセルにバージョン 8.6.x 以前のノードが含まれた混合ノード環境は、セル内の最も低いサポート・バージョンに基づいた JACC ベース許可でサポートされることを意味しています。この場合は、JACC ベース許可バージョン 1.4 になります。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_jaccsupport
ファイル名:csec_jaccsupport.html