セキュリティ ガイド

     前  次    新しいウィンドウで目次を開く     
ここから内容

AquaLogic Service Bus セキュリティについて

AquaLogic Service Bus では、通信の整合性とプライバシを保証し、認可されたユーザだけが AquaLogic Service Bus ドメインのリソースにアクセスできるようにするために、オープンな業界標準をサポートしています。また、セキュリティ サービスの構成要素として、基になっている WebLogic セキュリティ フレームワークを使用します。WebLogic セキュリティ フレームワークでは、ドメインを保護するための作業が認証、認可、資格マッピング、監査などの複数のコンポーネント (プロバイダ) に分かれています。特定の AquaLogic Service Bus ドメインに対して、必要なプロバイダのみをコンフィグレーションします。

以下の節では、AquaLogic Service Bus のセキュリティ モデルとその機能について説明します。

 


着信セキュリティ

着信セキュリティによって、AquaLogic Service Bus プロキシ サービスは認可されたクライアントから出された要求のみを処理できます (デフォルトでは、すべての匿名ユーザまたは認証ユーザがプロキシ サービスに接続できます)。また、クライアントからデータが送信されたときに、認可されていないユーザがそのデータを参照または変更していないことが保証されます。

プロキシ サービスは、サービス コンシューマと他のプロキシ サービスという 2 つのタイプのクライアントを持つことができます。図 2-1 に、プロキシ サービスとそのクライアント間の通信が着信セキュリティによって保護され、一方プロキシ サービスとビジネス サービス間の通信が発信セキュリティによって保護されることを示します。

図 2-1 着信セキュリティと発信セキュリティ

着信セキュリティと発信セキュリティ

着信セキュリティはプロキシ サービスの作成時に設定し、ニーズの変化に応じて変更できます。外向きのプロキシ サービス (サービス コンシューマから要求を受信します) の場合は、双方向 SSL over HTTPS などの厳密なセキュリティ要件の設定を検討します。他の AquaLogic Service Bus プロキシ サービスからのみ要求を受信することが保証されているプロキシ サービスの場合は、これよりセキュリティの低いプロトコルを使用できます。

プロキシ サービスで、デジタル署名、暗号化、または SSL 認証に対して公開鍵インフラストラクチャ (PKI) テクノロジを使用する場合は、証明書とペアのプライベート キーを提供するプロキシ サービス プロバイダを作成します。詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス プロバイダ」を参照してください

各プロキシ サービスに対し、次の着信セキュリティ チェックをコンフィグレーションできます。

 


発信セキュリティ

発信セキュリティは、プロキシ サービスとビジネス サービス間の通信を保護します。発信セキュリティのために行うタスクのほとんどは、ビジネス サービスで指定される転送レベルまたはメッセージレベルのセキュリティ要件に準拠するためのプロキシ サービスのコンフィグレーションのためのものです。

たとえば、ビジネス サービスでユーザ名とパスワード トークンを要求する場合は、サービス アカウントを作成します。このサービス アカウントは、ユーザ名とパスワードを直接含み、発信要求に含まれていたユーザ名とパスワードを渡すか、または発信要求に含まれていたユーザ名に応じてユーザ名とパスワードを提供します。詳細については、『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照してください

ビジネス サービスでデジタル署名または SSL 認証のために PKI テクノロジを使用する必要がある場合は、証明書とペアのプライベート キーを提供するプロキシ サービス プロバイダを作成します。詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス プロバイダ」を参照してください

 


ID の伝播のオプション

AquaLogic Service Bus のセキュリティの設計時に決定する必要がある主な項目の 1 つは、クライアントが提供する ID の処理 (伝播) 方法です。AquaLogic Service Bus のコンフィグレーションによって、次のことを実行できます。

表 2-1 は、AquaLogic Service Bus がクライアント ID をビジネス サービスに伝播する方法に影響するオプションについての説明です。

表 2-1 ID の伝播のオプション
オプション
説明
クライアントが提供する必要があるのはどのタイプの資格か。
転送レベルのセキュリティの場合、AquaLogic Service Bus は既存のセキュリティ要件に合わせる。AquaLogic Service Bus のクライアントは、ユーザ名とパスワード トークン、SSL 証明書、またはコンフィグレーションした認証プロバイダによってサポートされる他のタイプのトークンを提供できる。
メッセージレベルのセキュリティの場合、AquaLogic Service Bus ではユーザ名トークン、X.509 トークン、および SAML トークン プロファイル (「サポートされる標準とセキュリティ プロバイダ」を参照) をサポートする。
Web サービス セキュリティを使用する新しいビジネス サービス用のセキュリティ要件を確立する場合は、SAML トークンを提供するようクライアントに要求することを推奨する。SAML は、Web サービス内でユーザ ID を伝播するための新しい標準である。「認証での SAML の使用」を参照。
AquaLogic Service Bus でクライアントを認証するように要求するか、またはクライアントが提供する資格をそのまま認証のためにビジネス サービスに渡すか。
AquaLogic Service Bus でクライアントに認証を要求するときは、新たなセキュリティのレイヤを追加する。通常、追加するセキュリティ レイヤが多いほど、ドメインの安全性が高くなる。
AquaLogic Service Bus でユーザを認証できるようにするには、AquaLogic Service Bus Console でユーザ アカウントを作成する必要がある。ユーザの集合が非常に大きい場合は、AquaLogic Service Bus Console でユーザ アカウントの大規模なデータベースを保守するだけの価値があるかどうかを検討する必要がある。
X.509 トークンまたは SAML トークンを提供するクライアントを AquaLogic Service Bus で認証する場合は、どの AquaLogic Service Bus ユーザがトークンにマップされるか。
AquaLogic Service Bus で認証するようにクライアントに要求し、特定の認証されたユーザのみがプロキシ サービスにアクセスできる (認可される) ように、デフォルトのアクセス制御ポリシーを変更することを推奨する。
X.509 証明書、SAML トークン、またはユーザ名とパスワード以外の別のタイプの資格を提供するクライアントの認証と認可を行うには、クライアントの資格を AquaLogic Service Bus ユーザにマップする ID アサーション プロバイダをコンフィグレーションする必要がある。AquaLogic Service Bus はこのユーザ名を使用して、クライアントのセキュリティ コンテキストを確立する。
ユーザ名とパスワード トークンを提供するクライアントを AquaLogic Service Bus で認証する場合は、次の処理を行うかどうか。
  • クライアントのユーザ名とパスワードをビジネス サービスに渡す
  • クライアントのユーザ名を新しいユーザ名とパスワードにマップし、新しい資格をビジネス サービスに渡す
クライアントが提供するユーザ名とパスワードをビジネス サービスに渡す場合、クライアントはビジネス サービスが要求する資格を保守する責任がある。ビジネス サービスがセキュリティ要件を変更する場合は、対応する変更を行うように各クライアントに通知する必要がある。
ビジネス サービスが要件を頻繁に変更する可能性がある場合は、クライアントの提供する資格からビジネス サービスの要求する資格へのマッピングについて検討する。ビジネス サービスのクライアントが増えると、この資格マッピングを保守するために必要な作業が多くなる。

表 2-2 は、着信および発信の転送レベルのセキュリティに対して適用できる要件のすべての組み合わせについての説明です。

表 2-2 転送レベルのセキュリティ要件の組み合わせ
着信要件
組み合わせ可能な発信要件
コンフィグレーション方法
クライアントが HTTP または HTTPS ヘッダ内にユーザ名とパスワードを提供し、AquaLogic Service Bus がクライアントを認証する。
クライアントの資格を HTTP または HTTPS ヘッダで渡す。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. 発信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「発信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    パススルー サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。
クライアントの資格を別の AquaLogic Service Bus ユーザにマップし、新しい資格を HTTP または HTTPS ヘッダで渡す。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. 発信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「発信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    ユーザ マッピング サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。
クライアントが HTTP または HTTPS ヘッダ内にユーザ名とパスワードを提供し、AquaLogic Service Bus はクライアントを認証しない
クライアントの資格を HTTP または HTTPS ヘッダで渡す。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    HTTP または認証なし用か、あるいは HTTPS、一方向 SSL、または認証なし用にプロキシ サービスをコンフィグレーションする。
  2. 発信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「発信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    HTTP 基本認証用か、あるいは HTTPS、一方向 SSL、または基本認証用にビジネス サービスをコンフィグレーションする。
    また、パススルー サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。
クライアントの資格を EJB over RMI に渡す。EJB コンテナでユーザを認証する。
パススルー サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照
あらゆる形のローカル認証 (HTTP または HTTPS 基本、あるいは資格マッピングによる HTTPS クライアント証明書)。
クライアントの資格を EJB over RMI に渡す。EJB コンテナでユーザを認証する。
パススルー サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照
クライアントの資格を別の AquaLogic Service Bus ユーザにマップし、新しい資格を EJB over RMI に渡す。EJB コンテナでユーザを認証する。
ユーザ マッピング サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照

表 2-3 は、着信および発信のメッセージレベルのセキュリティに対して適用できる要件のすべての組み合わせについての説明です。場合によっては、転送レベルのセキュリティの着信要件が、発信メッセージレベルのセキュリティに適用できる要件に影響します

表 2-3 メッセージレベルのセキュリティ要件の組み合わせ
着信要件
組み合わせ可能な発信要件
コンフィグレーション方法
クライアントが HTTP または HTTPS ヘッダ内にユーザ名とパスワードを提供し、AquaLogic Service Bus がクライアントを認証する。
クライアントの資格を SOAP ヘッダで渡す。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. パススルー サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照
クライアントの資格を別の AquaLogic Service Bus ユーザにマップし、新しい資格を SOAP ヘッダで渡す。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. ユーザ マッピング サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照
クライアント資格を SAML トークンにマップする。AquaLogic Service Bus がユーザ ID アサーションを行う。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. SAML 資格マッピング プロバイダをコンフィグレーションする。「SAML 資格マッピングのコンフィグレーション : 主な手順」を参照してください。
クライアントが HTTP または HTTPS ヘッダ内にユーザ名とパスワードを提供し、AquaLogic Service Bus はクライアントを認証しない
クライアントの資格を SOAP ヘッダで渡す。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    HTTP または認証なし用か、あるいは HTTPS、一方向 SSL、または認証なし用にプロキシ サービスをコンフィグレーションする。
  2. 発信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「発信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
    HTTP 基本認証用か、あるいは HTTPS、一方向 SSL、または基本認証用にビジネス サービスをコンフィグレーションする。
    また、パススルー サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。
クライアントが HTTPS クライアント証明書認証 (双方向 SSL) の一部として証明書を提供し、AquaLogic Service Bus がクライアントを認証する。
クライアント資格を SAML トークンにマップする。AquaLogic Service Bus がユーザ ID アサーションを行う。
  1. 着信 HTTPS (または HTTP) セキュリティをコンフィグレーションする。「着信 HTTPS セキュリティのコンフィグレーション : 主な手順」を参照。
  2. SAML 資格マッピング プロバイダをコンフィグレーションする。「SAML 資格マッピングのコンフィグレーション : 主な手順」を参照してください。
アクティブな仲介プロキシ サービスが、ユーザ名トークン プロファイルによる Web サービス セキュリティを強制する。
SOAP メッセージのユーザ名とパスワード トークンとして資格をコード化する。
パスワード (パスワード ダイジェストではない) を要求する WS-Policy ステートメントでアクティブな仲介プロキシ サービスを作成する。「アクティブな仲介プロキシ サービスの作成 : 主な手順」を参照。
SOAP メッセージの SAML トークンとして資格をコード化する。
  1. パスワードを要求する WS-Policy ステートメントでアクティブな仲介プロキシ サービスを作成する。「アクティブな仲介プロキシ サービスの作成 : 主な手順」を参照。
  2. SAML 資格マッピング プロバイダをコンフィグレーションする。「SAML 資格マッピングのコンフィグレーション : 主な手順」を参照してください。
アクティブな仲介プロキシ サービスが、X.509 トークン プロファイルによる Web サービス セキュリティを強制する。
SOAP メッセージの SAML トークンとして資格をコード化する。
  1. デジタル署名および必要に応じて X.509 トークンによる認証を要求する WS-Policy ステートメントで、アクティブな仲介プロキシ サービスを作成する。「アクティブな仲介プロキシ サービスの作成 : 主な手順」を参照。
  2. SAML 資格マッピング プロバイダをコンフィグレーションする。「SAML 資格マッピングのコンフィグレーション : 主な手順」を参照してください。
アクティブな仲介プロキシ サービスが、SAML トークン プロファイルによる Web サービス セキュリティを強制する。
発信 SOAP メッセージに新しい SAML トークンを生成する。
  1. SAML トークンを要求する WS-Policy ステートメントでアクティブな仲介プロキシ サービスを作成する。「着信要求での SAML トークンの認証」を参照。
  2. SAML 資格マッピング プロバイダをコンフィグレーションする。「SAML 資格マッピングのコンフィグレーション : 主な手順」を参照してください。
ユーザ名とパスワード、X.509 トークン、または SAML トークンを渡すことができるパススルー プロキシ サービス。
ユーザ名トークン プロファイル、X.509 トークン プロファイル、または SAML トークン プロファイルを使用するビジネス サービス。
  1. パススルー プロキシ サービスを作成する。「パススルー プロキシ サービスの作成 : 主な手順」を参照。
  2. いずれかのトークン プロファイルを強制するビジネス サービスを作成する。「発信メッセージレベルのセキュリティのコンフィグレーション : 主な手順」または「SAML パススルー ID の伝播のコンフィグレーション」を参照。

着信 Tuxedo 要求の場合は、次のセキュリティ要件をコンフィグレーションできます。

AquaLogic Service Bus での Tuxedo の使用については、『Tuxedo の相互運用性ソリューション』を参照してください

例 : ユーザ名トークンによる認証

図 2-2 に、AquaLogic Service Bus を次のようにコンフィグレーションしたときの、AquaLogic Service Bus 全体のユーザ ID の流れを示します。

この図は、着信要求で開始され、発信要求で終了します。

  1. あるクライアントがプロキシ サービスに要求を送信します。要求には、ユーザ名とパスワード資格が含まれます。
  2. クライアントは、認証のために X.509 証明書などの他のタイプのトークンを送信することもできます。クライアントが証明書トークンを送信する場合は、トークンの ID を AquaLogic Service Bus セキュリティ コンテキストにマップするように ID アサーション プロバイダをコンフィグレーションする必要があります。

  3. プロキシ サービスは、ドメインの認証プロバイダ ストアにそのユーザが存在するかどうかをドメインの認証プロバイダに問い合わせます。
  4. ユーザが存在する場合、プロキシ サービス用にコンフィグレーションしたアクセス制御ポリシーを評価するように、プロキシ サービスがドメインの認証プロバイダに依頼します。

  5. プロキシ サービスのアクセス制御ポリシーによってユーザのアクセスが許可されている場合、プロキシ サービスはメッセージを処理します。ビジネス サービスへの発信要求生成の一部として、プロキシ サービスは、ビジネス サービスが要求するユーザ名とパスワードを提供するようにビジネス サービスに依頼します。
  6. ビジネス サービスは、その資格のサービス アカウントを問い合わせます。サービス アカウントのコンフィグレーション方法に応じて、次のいずれかの処理を行います。

    • 特定の (静的な) ユーザ名とパスワードをコード化するようにプロキシ サービスに要求する。
    • クライアントが提供するユーザ名とパスワードを渡すようにプロキシ サービスに要求する。
    • 認証プロバイダから返されたユーザ名を別の (リモート) ユーザ名にマップし、このリモート ユーザ名をコード化するようにプロキシ サービスに要求する。
  7. プロキシ サービスは、サービス アカウントから返されたユーザ名とパスワードと共に発信要求を送信します。
  8. 図 2-2 サービス アカウントの使用方法


    サービス アカウントの使用方法

 


管理セキュリティ

プロキシ サービスやビジネス サービスの作成など、管理機能へのアクセスを保護するため、AquaLogic Service Bus には、事前定義されたアクセス特権を持つ 4 つのセキュリティ ロールが用意されています。

セキュリティ ロールとは、実行時にユーザやグループに動的に与えることができる ID です。これらの管理セキュリティ ロールのアクセス特権は変更できませんが、それらのロールのいずれかにユーザまたはグループを入れるための条件は変更できます。

管理ユーザをロールに割り当てるときは、すべての WebLogic Server および AquaLogic Service Bus リソースへの完全なアクセス権を持つ WebLogic Server Admin ロールに最低 1 人のユーザを割り当てます。

詳細については、「管理セキュリティのコンフィグレーション」を参照してください。

 


WebLogic Security フレームワークのコンフィグレーション : 主な手順

AquaLogic Service Bus セキュリティの初期コンフィグレーション タスクの多くでは、WebLogic Security フレームワークのコンフィグレーションのために WebLogic Server Administration Console で作業する必要があります。これらの初期タスクの後は、ほとんどのセキュリティ タスクを AquaLogic Service Bus Console から実行できます。

AquaLogic Service Bus に対して WebLogic Security フレームワークをコンフィグレーションするには

  1. 転送レベルのセキュリティの一部として SSL の使用を計画している場合は、次の処理を行います。
    1. WebLogic Server Administration Console で、ID と信頼をコンフィグレーションします。『WebLogic Server のセキュリティ』の「ID と信頼のコンフィグレーション」を参照してください
    2. WebLogic Server Administration Console で、SSL をコンフィグレーションします。『WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」を参照してください
    3. AquaLogic Service Bus では、すべての HTTPS 通信はデフォルトの WebLogic Server (SSL) セキュリティ ネットワーク チャネルを使用する必要があります。これは、AquaLogic Service Bus でサポートする唯一の SSL ネットワーク チャネルです。

      SSL コンフィグレーションに対して次のことを実行するようお勧めします。

    • 双方向 SSL をコンフィグレーションする場合は、「クライアント証明書を要求するが強制しない」モードか、「クライアント証明書を要求し強制する」モードのいずれかを選択する必要がある。可能な限り、「クライアント証明書を要求し強制する」モードを選択することをお勧めします。詳細については、『WebLogic Security について』の「セキュリティの基礎概念」にある「セキュア ソケットレイヤ (SSL)」を参照してください
    • プロダクション環境では、ホスト名検証が有効であることを確認する。『WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」にある「ホスト名検証の使い方」を参照してください
  2. WebLogic Server Administration Console で、プロキシ サービスが着信セキュリティに対して使用する認証プロバイダをコンフィグレーションします。
  3. 表 2-4 は、AquaLogic Service Bus で通常コンフィグレーションする認証プロバイダについての説明です。コンフィグレーションできるすべての認証プロバイダの説明については、『WebLogic Server のセキュリティ』の「セキュリティ プロバイダ」を参照してください

    表 2-4 認証プロバイダ
    クライアントに提供を要求するもの
    構成内容
    単純なユーザ名とパスワード
    WebLogic 認証プロバイダ。AquaLogic Service Bus Console を使用して、アクセスを許可するクライアントのユーザ名とパスワードを入力する。
    『AquaLogic Service Bus Console の使い方』の「セキュリティ コンフィグレーション」にある「ユーザの追加」を参照
    着信 HTTPS と双方向 SSL 認証用の X.509 トークン
    以下のすべてが含まれる。
    • WebLogic ID アサーション プロバイダ。このプロバイダは、X.509 トークンを検証できるが、デフォルトでは検証は行われない。このプロバイダが X.509 トークンをサポートできるようにする。さらに、このプロバイダがユーザ名マッパーを使用できるようにする。『WebLogic Security について』の「セキュリティの基礎概念」にある「認証」の「ID アサーションとトークン」を参照
    • WebLogic 証明書パス プロバイダ。チェックに基づいて信頼された認証局を使用して、証明書チェーンを作成して検証する。
    着信 Web サービス セキュリティ X.509 トークン認証用の X.509 トークン
    プロキシ サービスまたはビジネス サービスのいずれかが抽象 WS-Policy ステートメントを使用する Web サービスである場合は、以下もコンフィグレーションする必要がある。
    • __SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__ という Web サービス セキュリティ コンフィグレーションで、UseX509ForIdentity プロパティを追加し、true に設定する。WebLogic Server Administration Console オンライン ヘルプで「X.509 証明書を使用した ID の証明」を参照。
    SAML トークン
    以下のすべてが含まれる。
    • WebLogic SAML ID アサーション プロバイダ V2。このプロバイダは、Security Assertion Markup Language 1.1 (SAML) に基づいてユーザを認証する。
    • WebLogic SAML 資格マッピング プロバイダ V2。このプロバイダは、AquaLogic Service Bus ユーザをリモート ユーザにマップする。

  4. 着信要求で WS-Security デジタル署名を要求するプロキシ サービスまたはビジネス サービスの作成を計画している場合は、証明書レジストリ プロバイダを有効にします。このプロバイダは、登録した証明書のリストに対して着信証明書を検証する証明書パス プロバイダです。
  5. WebLogic Server Administration オンライン ヘルプの「証明書パス プロバイダのコンフィグレーション」を参照してください

  6. ユーザ名とパスワード トークンを要求するようにメッセージレベルのセキュリティ (着信要求または発信要求) をコンフィグレーションする場合、およびメッセージでクリアテキスト パスワードではなくパスワード ダイジェストを提供する場合は、次の操作を行います。
    1. WebLogic Server Administration Console で、AquaLogic Service Bus によって提供される 2 つの Web サービス セキュリティ コンフィグレーションを探し、UsePasswordDigest プロパティの値を true に設定します。
    2. この AquaLogic Service Bus Web サービス セキュリティ コンフィグレーションは次の名前です。
      __SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__
      __SERVICE_BUS_OUTBOUND_WEB_SERVICE_SECURITY_MBEAN__

      Web サービス セキュリティ コンフィグレーションの値の設定については、WebLogic Server Administration Console オンライン ヘルプの「SOAP メッセージでのパスワード ダイジェストの使用」を参照してください

    3. 手順 2 でコンフィグレーションした各認証プロバイダに対し、WebLogic Server Administration Console で [パスワード ダイジェストを有効化] チェック ボックスを選択します。
    4. 手順 2 でコンフィグレーションした各 ID アサーション プロバイダに対し、WebLogic Server Administration Console でアクティブ トークン タイプの 1 つとして wsse:PasswordDigest を設定します。
  7. プロキシ サービス プロバイダ (発信要求でキーと証明書のペアを渡します) の作成を計画している場合は、WebLogic Server Administration Console を使用して、PKI 資格マッピング プロバイダをコンフィグレーションします。AquaLogic Service Bus をホストする任意の WebLogic Server ドメインで、最大 1 つの PKI 資格マッピング プロバイダをコンフィグレーションできます。
  8. PKI 資格マッピング プロバイダは、デジタル署名や暗号化 (Web サービス セキュリティ)、および発信 SSL 認証に使用できるキー ペアに AquaLogic Service Bus プロキシ サービス プロバイダをマップします。詳細については、『WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」にある「PKI 資格マッピング プロバイダのコンフィグレーション」を参照してください

    PKI 資格マッピング プロバイダが使用するキー ペアと信頼される証明局 (CA) 証明書は、キーストアに格納します。PKI 資格マッピングは、WebLogic Server が使用する ID キーストア (通常は、SSL 通信用のキーペアを格納するために使用するキーストアと同じです)、または別のキーストアに格納できます。各 WebLogic Server インスタンスがそれぞれ独自の各キーストア コピーにアクセスするようにコンフィグレーションします。PKI 資格マッパーで参照されるすべてのエントリがすべてのキーストアに存在する必要があります (同じエリアスを使用した同じエントリ)。WebLogic Server でのキーストアのコンフィグレーションについては、『WebLogic Security について』の「セキュリティの基礎概念」にある「ID と信頼」を参照してください

    注意 : AquaLogic Service Bus ドメインを作成すると、デフォルトでドメインにユーザ名/パスワード資格マッピング プロバイダが含まれ、ユーザ名とパスワード用の資格マッピングが必要な場合に使用できます。このユーザ名/パスワード資格マッピング プロバイダの他に、1 つの PKI 資格マッピング プロバイダを追加できます。AquaLogic Service Bus ドメインは、最大 1 つのユーザ名/パスワード資格マッピング プロバイダ、1 つの PKI 資格マッピング プロバイダ、および複数の SAML 資格マッピング プロバイダを持つことができます。
  9. セキュリティ監査を有効にする場合は、次の操作を行います。
    1. WebLogic Server Administration Console で、監査プロバイダをコンフィグレーションします。『WebLogic Server のセキュリティ』の「WebLogic 監査プロバイダのコンフィグレーション」を参照してください
    2. WS-Security に関連したイベントの監査を有効にするには、各 AquaLogic Service Bus サーバの起動時に、サーバの起動コマンドで次の Java オプションを指定します。
    3. 注意 : -Dcom.bea.wli.sb.security.AuditWebServiceSecurityErrors=true

      AquaLogic Service Bus はセキュリティ イベントの監査をサポートしますが、コンフィグレーション監査をサポートしません。コンフィグレーション監査では、ユーザがドメイン内のリソースのコンフィグレーションを変更したり、ドメイン内のリソースに対して管理操作を呼び出したりすると、ログ メッセージが出されて監査イベントが生成されます。『WebLogic Server のセキュリティ』の「コンフィグレーション監査」を参照してください

  10. まだ実行していない場合は、WebLogic Server Administration Console で変更をアクティブ化します。WebLogic Server の再起動が必要になる変更を行った場合は、Administration Console に再起動が必要であることが表示されます。このようなメッセージが表示された場合は、AquaLogic Service Bus をホストするすべての WebLogic Server インスタンスを再起動して、セキュリティ プロバイダに対する変更が残りのコンフィグレーション手順に対して有効になるようにします。

 


サポートされる標準とセキュリティ プロバイダ

AquaLogic Service Bus の今回のリリースでは、次の標準がサポートされます。

表 2-5 Web サービス セキュリティと関連する標準
標準
バージョン
WS-Security
1.0
WS-Policy
WS-Policy 仕様は完全には標準化されていないため、AquaLogic Service Bus では、2002 年 12 月 18 日バージョンの Web サービス セキュリティ ポリシー言語 (WS-SecurityPolicy) 仕様に記述されているアサーションに基づく WebLogic Server 独自の形式をサポートしている。AquaLogic Service Bus の今回のリリースには、最新版の仕様 (2005 年 7 月 13 日) は組み込まれていない
WS-Policy Attachment
1.0
WS-Security : Username Token Profile
1.0
WS-Security : X.509 Token Profile
1.0
WS-Security : SAML Token Profile
1.0
SAML
1.1

WebLogic Server でサポートされる標準については、WebLogic Server リリース ノートの WebLogic Server の新機能に関する説明にある「標準のサポート」を参照してください。

WebLogic セキュリティ プロバイダのサポート

AquaLogic Service Bus では、WebLogic 認証プロバイダ、ID アサーション プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、資格マッピング プロバイダ、証明書検索と検証 (CLV) プロバイダなど、WebLogic Server に含まれるセキュリティ プロバイダをサポートします。さらに、AquaLogic Service Bus 2.5 では、WebLogic SAML ID アサーション プロバイダ V2 と WebLogic SAML 資格マッピング プロバイダ V2 をサポートします。

AquaLogic Service Bus のリリース 2.5 では、独自のポリシー言語を使用するデフォルトの WebLogic 認可プロバイダとデフォルトのロール マッピング プロバイダのサポートが廃止されています。これらのプロバイダの代わりに、OASIS 標準の eXtensible Access Control Markup Language (XACML) を用いた WebLogic XACML 認可プロバイダおよび XACML ロール マッピング プロバイダを使用することをお勧めします。デフォルトの WebLogic 認可プロバイダおよびデフォルトのロール マッピング プロバイダを使用していた以前のリリースの AquaLogic Service Bus をアップグレードする場合、WebLogic Server Administration Console を使用して、XACML プロバイダに認可データおよびロール マッピング データをインポートします。AquaLogic Service Bus アップグレード ガイドの AquaLogic Service Bus 環境のアップグレードに関する説明を参照してください

Netegrity、Oracle-Oblix、RSA などのサードパーティ セキュリティ プロバイダはテストされていないため、AquaLogic Service Bus 2.5 では確認されていません。ただし、AquaLogic Service Bus セキュリティ アーキテクチャでは、サードパーティ認証、認可、およびロールマッピング プロバイダの使用をサポートします。AquaLogic Service Bus 2.5 でのサードパーティ セキュリティ プロバイダのサポートについては、BEA カスタマ サポートにお問い合わせください。

セキュリティ プロバイダの詳細については、『WebLogic Security について』の「WebLogic Security サービスのアーキテクチャ」にある「WebLogic セキュリティ プロバイダ」を参照してください。


  ページの先頭       前  次