Web メッセージング機能付きアプリケーションの保護

Web メッセージング機能付きアプリケーションの構成には 2 つの異なる特徴があります。1 つは着信 URI の保護で、もう 1 つはサービス統合バスに対するクライアント認証と許可の構成です。

Web メッセージング URI の保護

作成している Web メッセージング・アプリケーションの種類によっては、Web メッセージング URI へのアクセスを制限したい場合があります。 Web メッセージング URI は、標準的な Web アプリケーション・セキュリティー・メソッドによって保護できます。Web メッセージング URI が保護されると、通常の Web アプリケーション・セキュリティー・メソッドを使用して Bayeux ハンドシェーク要求が認証および許可されます。 詳しくは、 アセンブリーおよびデプロイメント中のアプリケーションの保護のセクションを参照してください。アプリケーション・セキュリティーが有効な場合、トランスポート・セキュリティーを有効にするのが一般的です。 Web メッセージング・サービスは Web コンテナー・トランスポート・チェーンを共有しており、セキュア・トランスポート・チェーンで Web メッセージング・サービスを使用可能にした場合は、すべての Bayeux 操作について通信が保護されます。

サービス統合バスの認証と許可

セキュリティーを有効にした Web メッセージング機能付きアプリケーションを 構成する際には、特別な理由がない限り、セキュリティー要件をサービス統合バスの相互作用に拡張する必要があることを 理解することが重要です。セキュリティー・モデルを計画する際には、 以下に説明するサービス統合バスに対するセキュリティーのそれぞれの側面を 考慮する必要があります。詳しくは、サービス統合セキュリティーについてのトピックを参照してください。 Web メッセージング・クライアントがセキュアなサービス統合バスに接続しているときには、サービス統合バスのリソースにアクセスするために、クライアントは認証を受け、許可されなければなりません。

Web メッセージング・クライアントは、保護されたサービス統合バスに対する認証を行うクレデンシャルを提供する必要があります。 クレデンシャルを提供する方法として、JavaTM 2 Connector 認証別名と Web クレデンシャルの 2 つがあります。最良の手段は、アプリケーションのニーズによって異なります。authType および authAlias Web メッセージング構成オプションで、どちらのタイプを使用するかを指定します。 構成情報について詳しくは、サービス統合バスの構成のトピックを参照してください。

Java 2 Connector 認証別名

 Java 2 Connector 認証別名は、サービス統合バスに対して Web メッセージング・クライアントが認証を行うことができるようにする方法の 1 つです。 認証別名は次のような状況で使用する必要があります。

  • Web セキュリティーが無効になっており、バス・セキュリティーが有効になっている。 認証別名の指定は、Web メッセージング・クライアントがサービス統合バスにアクセスできるための唯一の可能なソリューションです。
  • 1 つの URI に加わるすべての Web メッセージング・クライアントが同じサービス統合バスのトピック・スペースおよびトピック許可を持つことを許可する。 この場合、 認証された 1 人 1 人の Web ユーザーのアクセス権を管理するよりも、 1 つの認証インスタンスの許可アクセス権を管理する方が簡単です。
Web クレデンシャル Web セキュリティーが有効になっているときは、セキュアなサービス統合バスに接続するための認証情報として Web クレデンシャルを使用することができます。基本認証と LTPA シングル・サインオンの Cookie が、サポートされている 2 種類の Web クレデンシャルです。以下の状況では、Web メッセージング構成ファイルを設定して基本の authType か sso を使用する必要があります。
  • Web セキュリティーが有効な場合。基本認証または LTPA の Cookie の情報は、HTTP 要求で読めるものであることが必要です。この情報が使用できないと、セキュアなサービス統合バスへのアクセスは失敗します。Web クレデンシャルを読み取る機能は、トラスト・アソシエーション・インターセプターが使用中の場合は制限される可能性があります。その場合は、Java 2 Connector 認証別名しか使用できません。
  • きめ細かな Web メッセージングのユーザー・トピック・スペースまたはトピック権限が必要な場合。この場合、以下の許可ステップに従って、サービス統合バスのリソースに対するユーザーまたはグループのアクセス権を許可する必要があります。

   

サービス統合バスは、 権限をさまざまな細分度で検証できる、一連のセキュリティー検査を 提供しています。次の権限レベルは、指定されたすべての認証データについて適合する必要があります。

バス・コネクター権限 サービス統合バスへアクセスするために必要な権限の 第 1 レベルは、バスに接続することができること、すなわちバス・コネクター権限です。 他の権限と同様、このアクセス権は個々のユーザーに付与することも、またはユーザー・グループに付与することもできます。 バス・コネクター・ロールに対する権限の構成方法について詳しくは、バス・コネクター・ロールの管理のトピックを参照してください。
トピック・スペース (宛先) のセキュリティー アプリケーションがバス・コネクター権限の検査に合格したら、次に必要なのは宛先へのアクセスです。 Bayeaux アプリケーションの場合、これは Bayeaux 構成またはチャネル名で指定されたトピック・スペース宛先 (複数の場合もあります) になります。

それぞれの宛先には、宛先に関連付けられた個々のロール・セットがあり、それが、特定のアプリケーションやユーザーが実行できるアクションの種類を厳密に管理します。 Bayeaux アプリケーションでは、最も重要な共通の役割は、アプリケーションがサブスクリプションを作成してイベントを受信することができるようにする Receiver ロールと、イベントをトピック・スペースにパブリッシュする Sender ロール役割です。 所定のトピック・スペースについてこれら権限のロールを構成する方法について詳しくは、次の宛先セキュリティーのトピックを参照してください。

トピックのセキュリティー トピック・スペース内では、個々のトピックや複数のトピック分野に対するきめ細かなアクセス権の制御を構成することも可能です。 すなわち、アプリケーションには、別のアプリケーションから別のトピック上に公開されたイベントは、 たとえそれが同じトピック・スペース上に公開されていても、見えません。

トピック・レベルのセキュリティーを構成する方法について詳しくは、以下のトピックを参照してください。



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