> セキュリティ ガイド > AquaLogic Service Bus セキュリティについて

セキュリティ ガイド

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

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 証明書、またはコンフィグレーションした ID アサーション プロバイダによってサポートされる他のタイプのカスタム認証トークンを提供できる。
メッセージレベルのセキュリティの場合、AquaLogic Service Bus ではユーザ名トークン、X.509 トークン、コンフィグレーションした認証プロバイダまたは ID アサーション プロバイダによってサポートされるその他のカスタム認証トークン、および 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 で認証する場合は、どの AquaLogic Service Bus ユーザがトークンにマップされるか。
AquaLogic Service Bus で認証するようにクライアントに要求し、特定の認証されたユーザのみがプロキシ サービスにアクセスできる (認可される) ように、デフォルトのアクセス制御ポリシーを変更することを推奨する。
ユーザ名とパスワード以外のカスタム認証トークンを提供するクライアントの認証と認可を行うには、クライアントの資格を AquaLogic Service Bus ユーザにマップする ID アサーション プロバイダをコンフィグレーションする必要がある。AquaLogic Service Bus はこのユーザ名を使用して、クライアントのセキュリティ コンテキストを確立する。
ユーザ名とパスワード トークンを提供するクライアントを AquaLogic Service Bus で認証する場合は、次の処理を行うかどうか。
  • クライアントのユーザ名とパスワードをビジネス サービスに渡す
  • クライアントのユーザ名を新しいユーザ名とパスワードにマップし、新しい資格をビジネス サービスに渡す
カスタム ユーザ名/パスワード トークンが使用される場合は、「カスタム認証トークンとは」に記述されているように、パススルー サービス アカウントを使用すると、発信 HTTP 基本認証または発信 WS-Security ユーザ名トークン認証に対し、カスタム トークン内のユーザ名/パスワードを使用できる。
クライアントが提供するユーザ名とパスワードをビジネス サービスに渡す場合、クライアントはビジネス サービスが要求する資格を保守する責任がある。ビジネス サービスがセキュリティ要件を変更する場合は、対応する変更を行うように各クライアントに通知する必要がある。
ビジネス サービスが要件を頻繁に変更する可能性がある場合は、クライアントの提供する資格からビジネス サービスの要求する資格へのマッピングについて検討する。ビジネス サービスのクライアントが増えると、この資格マッピングを保守するために必要な作業が多くなる。

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

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

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

表 2-3 メッセージレベルのセキュリティ要件の組み合わせ
着信要件
組み合わせ可能な発信要件
コンフィグレーション方法
クライアントが HTTP ヘッダ内にユーザ名とパスワード、またはカスタム認証トークンを提供し、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 資格マッピングのコンフィグレーション : 主な手順」を参照。
クライアントがメッセージ ヘッダまたはメッセージ本体内にユーザ名とパスワード、またはカスタム認証トークンを提供し、AquaLogic Service Bus がクライアントを認証する。
クライアントの資格を SOAP ヘッダで渡す。
  1. カスタム トークンまたはユーザ名とパスワードを処理する認証プロバイダまたは ID アサーション プロバイダをコンフィグレーションする。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. パススルー サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照。
クライアントの資格を別の AquaLogic Service Bus ユーザにマップし、新しい資格を SOAP ヘッダで渡す。
  1. カスタム トークンまたはユーザ名とパスワードを処理する認証プロバイダまたは ID アサーション プロバイダをコンフィグレーションする。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. ユーザ マッピング サービス アカウントを作成し、そのアカウントをビジネス サービスに付加する。『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照。
クライアント資格を SAML トークンにマップする。AquaLogic Service Bus がユーザ ID アサーションを行う。
  1. カスタム トークンまたはユーザ名とパスワードを処理する認証プロバイダまたは ID アサーション プロバイダをコンフィグレーションする。
    クライアントのユーザ名を AquaLogic Service Bus の [セキュリティ コンフィグレーション] モジュールに追加する。
  2. SAML 資格マッピング プロバイダをコンフィグレーションする。「SAML 資格マッピングのコンフィグレーション : 主な手順」を参照。
クライアントが HTTP ヘッダ内にユーザ名とパスワードを提供し、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 証明書、カスタム認証トークンなどの他のタイプのトークンを送信することもできます。クライアントが X.509 証明書トークンまたはカスタム トークンを送信する場合は、トークンの ID を AquaLogic Service Bus セキュリティ コンテキストにマップするように ID アサーション プロバイダをコンフィグレーションする必要があります。

  2. プロキシ サービスは、ドメインの認証プロバイダ ストアにそのユーザが存在するかどうかをドメインの認証プロバイダに問い合わせます。

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

  3. プロキシ サービスのアクセス制御ポリシーによってユーザのアクセスが許可されている場合、プロキシ サービスはメッセージを処理します。ビジネス サービスへの発信要求生成の一部として、プロキシ サービスは、ビジネス サービスが要求するユーザ名とパスワードを提供するようにビジネス サービスに依頼します。

    4. ビジネス サービスは、その資格のサービス アカウントを問い合わせます。サービス アカウントのコンフィグレーション方法に応じて、次のいずれかの処理を行います。

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


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

 

管理セキュリティ

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

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

AquaLogic Service Bus のロールには、AquaLogic Service Bus のリソースのみを変更するパーミッションがあります。WebLogic Server または WebLogic Server 上の他のリソースを変更するパーミッションはありません。管理ユーザをロールに割り当てるときは、最低 1 人のユーザを WebLogic Server Admin ロールに割り当てます。WebLogic Server セキュリティ ロールについては、表 9-2 を参照してください。

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

 

アクセス制御ポリシー

アクセス制御によって、AquaLogic Service Bus のリソースにアクセスするユーザを決定します。アクセス制御ポリシーは、ユーザ、グループ、またはロールがプロキシ サービスにアクセスできるようにするための条件を指定します。たとえば、あるプロキシ サービスへのアクセスを、GoldCustomer ロールのユーザには常に許可し、SilverCustomer ロールのユーザには平日の午後 12 時以降にのみ許可するというポリシーを作成することができます。

アクセス制御ポリシーは、WebLogic リソースと、1 つまたは複数のユーザ、グループ、またはセキュリティ ロールとの間の関連付けです。セキュリティ ポリシーは、権限のないアクセスから WebLogic リソースを保護します。アクセス制御ポリシーは特定のリソースに割り当てられてたブール式です。リソースへのアクセスが試行されると、式が評価されます。式は、ロール (オペレータ) とアクセス時間 (午前 8 時から午後 5 時) など、ブール演算子で結合された 1 つまたは複数の条件で構成されます。アクセス制御ポリシーの詳細については、『WebLogic Security について』の「セキュリティの基礎概念」を参照してください。

AquaLogic Service Bus は、WebLogic Server のセキュリティ レルムを使用してリソースを保護します。各セキュリティ レルムは、コンフィグレーションされたセキュリティ プロバイダ、ユーザ、グループ、セキュリティ ロール、および (アクセス制御) セキュリティ ポリシーの集合から成ります。レルムに属するリソースにアクセスするには、「管理セキュリティ ロールと特権」に記述されているように、ユーザはそのレルムのセキュリティ ロールを割り当てられ、定義されている必要があります。ユーザが AquaLogic Service Bus リソースへのアクセスを試みると、WebLogic Server が関連するセキュリティ レルムとセキュリティ ポリシーをチェックして、ユーザに割り当てられているセキュリティ ロールを確認し、ユーザを認証および認可します。

注意 : AquaLogic Service Bus Console でセキュリティ ポリシーの定義またはセキュリティ ロールの編集を行うことができるのは、WebLogic Server 管理者だけです。

すべてのプロキシ サービスに対して、転送レベルのポリシーを作成することができます。転送レベルのポリシーでは、クライアントがプロキシ サービスとの接続を確立しようとしたときにセキュリティ チェックが適用されます。転送レベルのポリシーのリストに入っているユーザからの要求だけが続行を許可されます。

WS-Security のアクティブな仲介、またはメッセージレベルのカスタム認証を実装するプロキシ サービスの場合は、メッセージレベルのポリシーを作成することもできます。このタイプのポリシーでは、保護されているいずれかの操作をクライアントが呼び出そうとしたときにセキュリティ チェックが適用されます。メッセージレベルのポリシーのリストに入っているユーザだけが、その操作を呼び出せます。

AquaLogic Service Bus Console には、ユーザ、グループ、およびセキュリティ ロールを表示およびコンフィグレーションするための [セキュリティ コンフィグレーション] モジュールが含まれています。また、AquaLogic Service Bus Console では資格の表示とコンフィグレーションもできます。

注意 : AquaLogic Service Bus Console の [セキュリティ コンフィグレーション] モジュール内で変更を行う前に、コンフィグレーションをアクティブにする必要があります。セッションをアクティブにする方法については、『AquaLogic Service Bus Console の使い方』の「Change Center の使用」を参照してください。

プロキシ サービスのアクセス制御のコンフィグレーション

すべてのプロキシ サービスに対して転送レベルのアクセス制御をコンフィグレーションできます。また、WS-Security のアクティブな仲介プロキシ サービス、またはメッセージレベルのカスタム認証を実装するすべてのプロキシ サービスに対して、メッセージレベルでアクセス制御をコンフィグレーションすることもできます。アクセス制御をコンフィグレーションするには、転送レベルまたはメッセージレベル (あるいはその両方) でプロキシ サービスにアクセス制御ポリシーを割り当てる必要があります。

すべてのプロキシ サービスに対するデフォルトの転送レベルおよびメッセージレベルのアクセス制御ポリシーによって、すべての要求にアクセスを許可します。アクセス制御ポリシーをプロキシ サービスに割り当てて、それを保護する必要があります。

「転送レベルのアクセス ポリシーの編集」と「メッセージレベルのアクセス ポリシーの編集」の手順に従って、AquaLogic Service Bus Console で転送レベルとメッセージレベルのアクセス制御ポリシーをコンフィグレーションします。

アクセス制御ポリシーに対するライフサイクル処理の影響

アクセス制御ポリシーは認証プロバイダに保持され、AquaLogic Service Bus のセッションによって制御されるリポジトリには保持されません。したがって、サービスのアクセス制御ポリシーは関連するプロキシ サービスが作成されたセッションに依存しません。

警告 : プロキシ サービスの削除、移動、名前の変更、クローン作成 (またはプロジェクトやフォルダの削除、名前の変更、移動) の前に、関連付けられた転送レベルおよびサービスレベルのアクセス制御セキュリティ ポリシーをすべて削除してください。
警告 : これらのポリシーを削除しない場合、認可プロバイダ データベースにポリシーが残り、予期しない結果を引き起こしたり、セキュリティの脆弱性 (以前は保護されていたサービスが保護されないまま残るなど) が生じる可能性があります。
警告 : たとえば、完全パス (および操作) が孤立したポリシーのパスと一致している新しいプロキシ サービスを作成すると、プロキシはそのポリシーと暗黙的に再接続されます。
注意 : サービスのクローンを作成すると、アクセス制御ポリシーのクローンは作成されません。

プロキシ サービスを削除する場合は、以下の手順を実行します。

  1. セッションを作成していない場合は作成します。
  2. プロキシ URL に割り当てられている転送セキュリティ ポリシーをすべて削除します。
  3. プロキシおよびその操作に割り当てられているサービス セキュリティ ポリシーをすべて削除します。
  4. プロキシ サービスを削除します。
  5. セッションをアクティブ化します。

プロキシ サービスを移動または名前変更する場合は、以下の手順を実行します。

  1. セッションを作成していない場合は作成します。
  2. プロキシ サービスおよびその操作に割り当てられているサービス セキュリティ ポリシーをすべて削除します。
  3. プロキシ サービスを移動または名前変更します。
  4. セッションをアクティブにします。プロキシ サービスが移動または名前変更されます。
  5. 名前変更または移動したプロキシ サービスを指定し、手順 2 で削除したサービス セキュリティ ポリシーを再度割り当てます。

プロキシ サービスの操作を名前変更する場合は、以下の手順を実行します。

  1. セッションを作成していない場合は作成します。
  2. 名前変更する操作に割り当てられているサービス セキュリティ ポリシーをすべて削除します。
  3. 操作名を変更します。
  4. セッションをアクティブにします。
  5. 手順 2 で削除したサービス セキュリティ ポリシーを新しい操作に再度割り当てます。

 

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 証明書パス プロバイダ。チェックに基づいて信頼された認証局を使用して、証明書チェーンを作成して検証する。
    着信 HTTP、HTTPS、およびメッセージレベル認証用のカスタム認証とユーザ名/パスワード トークン
    以下のすべてが含まれる。
    • ID アサーション プロバイダ。ユーザ作成またはサードパーティ製で、トークン タイプを検証できる。このプロバイダがトークンをサポートできるようにする。『WebLogic Security について』の「セキュリティの基礎概念」にある「認証」の「ID アサーションとトークン」を参照。
    着信 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 ユーザをリモート ユーザにマップする。

  3. 必要に応じて、WebLogic Server Administration Console で 1 つ以上の ID アサーション プロバイダをコンフィグレーションして、サポートする必要がある X.509 トークン タイプ、カスタム トークン タイプなどのトークン タイプを処理します。コンフィグレーションできるすべての ID アサーション プロバイダの説明については、『WebLogic Server のセキュリティ』の「セキュリティ プロバイダ」を参照してください。
  4. 着信要求で WS-Security デジタル署名を要求するプロキシ サービスまたはビジネス サービスの作成を計画している場合は、証明書レジストリ プロバイダを有効にします。このプロバイダは、登録した証明書のリストに対して着信証明書を検証する証明書パス プロバイダです。

    5. WebLogic Server Administration オンライン ヘルプの「証明書パス プロバイダのコンフィグレーション」を参照してください。

  5. ユーザ名とパスワード トークンを要求するようにメッセージレベルのセキュリティ (着信要求または発信要求) をコンフィグレーションする場合、およびメッセージでクリアテキスト パスワードではなくパスワード ダイジェストを提供する場合は、次の操作を行います。
    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 メッセージでのパスワード ダイジェストの使用」を参照してください。

    2. 手順 2 でコンフィグレーションした各認証プロバイダに対し、WebLogic Server Administration Console で [パスワード ダイジェストを有効化] チェック ボックスを選択します。
    3. 手順 2 でコンフィグレーションした各 ID アサーション プロバイダに対し、WebLogic Server Administration Console でアクティブ トークン タイプの 1 つとして wsse:PasswordDigest を設定します。
  6. プロキシ サービス プロバイダ (発信要求でキーと証明書のペアを渡します) の作成を計画している場合は、WebLogic Server Administration Console を使用して、PKI 資格マッピング プロバイダをコンフィグレーションします。AquaLogic Service Bus をホストする任意の WebLogic Server ドメインで、最大 1 つの PKI 資格マッピング プロバイダをコンフィグレーションできます。

    7. PKI 資格マッピング プロバイダは、デジタル署名や暗号化 (Web サービス セキュリティ)、および発信 SSL 認証に使用できるキー ペアに AquaLogic Service Bus プロキシ サービス プロバイダをマップします。詳細については、『WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」にある「PKI 資格マッピング プロバイダのコンフィグレーション」を参照してください。

    PKI 資格マッピング プロバイダがキーストアで使用するキーペアを格納します。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 資格マッピング プロバイダを持つことができます。
  7. セキュリティ監査を有効にする場合は、次の操作を行います。
    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 のセキュリティ』の「コンフィグレーション監査」を参照してください。

  8. まだ実行していない場合は、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 では、WebLogic SAML ID アサーション プロバイダ V2 と WebLogic SAML 資格マッピング プロバイダ V2 をサポートします。

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

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

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

認証プロバイダのコンフィグレーション

提供される WebLogic Server 認証プロバイダを調べて、ニーズに合うものがないか確認してください。WebLogic Server には、次のようなさまざまな認証プロバイダが含まれます。

バンドルされているいずれかの認証プロバイダでニーズに対応できる場合は、WebLogic Server Administration Console でこの認証プロバイダをコンフィグレーションする方法について「認証プロバイダのコンフィグレーション」を参照してください。

WebLogic Server に含まれるどの認証プロバイダもニーズに合わない場合は、まず自分 (またはサードパーティ) がカスタムの認証プロバイダを作成し、WebLogic Server Administration Console を使用して、そのプロバイダをセキュリティ レルムに追加する必要があります。これを実行するには、以下の手順に従います。

注意 : ここでは、必要なタスクの概要についてのみ説明します。実際にタスクを実行するには WebLogic Server ドキュメントを調べる必要があります。
  1. 適切な SSPI による実行時クラスを作成します。
  2. WebLogic MBeanMaker による MBean タイプを作成します。
  3. Administration Console によるカスタム認証プロバイダをコンフィグレーションします。

詳細については、『WebLogic セキュリティ プロバイダの開発』の「認証プロバイダ」を参照してください。

カスタム認証プロバイダによる AquaLogic Service Bus リソースの保護

カスタム認証プロバイダで AquaLogic Service Bus リソースを使用できますが、これらのプロバイダが AquaLogic Service Bus リソースのタイプや形式を認識する必要があります。

AquaLogic Service Bus には、認証プロバイダが検出して処理できる必要があるリソース オブジェクトが 3 つあります。

これらのリソース オブジェクトについては、この後の節で説明します。

WebLogic 認証プロバイダの使用法について

この節では、WebLogic Server 認証プロバイダ SSPI について簡単に説明します。詳細については、『WebLogic セキュリティ プロバイダの開発』を参照してください。

リソースを保護するには、AquaLogic Service Bus Console、サードパーティ ツール、またはスクリプトによって、アクセス制御ポリシーをリソースにバインドします。WebLogic Server SSPI (Security Service Provider Interface) では、リソース SPI を実装するために AquaLogic Service Bus などのコンテナが必要です。これらの実装は具象リソースを表します。

認証プロバイダ データベースには、リソースからポリシーへのマップがあります。リソースへのアクセスが試みられると、コンテナは実行時 SSPI を呼び出してアクセス制御の判断を行います。コンテナは、アクセスされるリソースを示すリソース インスタンスを渡します。

認証プロバイダには getAccessDecision() という 1 つのメソッドがあります。getAccessDecision() メソッドは、AccessDecision SSPI の実装を取得します。AccessDecision SSPI そのものには isAccessAllowed() という 1 つのメソッドがあります。isAccessAllowed には 5 つのパラメータがあり、その 1 つは要求されるアクセスに対する Resource オブジェクトです。

isAccessAllowed は、指定のリソースへのアクセスを要求者が許可されるかどうか判断します。これを実行するには、認証プロバイダが評価のために正しいアクセス制御ポリシーを見つける必要があります。プロバイダは、渡されたリソースにバインドされたポリシーをまず検索する必要があります。検索では、検索のキーとして Resource.getId() メソッドまたは Resource.toString() メソッドを使用できます。ポリシーが見つからない場合、認証プロバイダは親リソースを取得し、再検索する必要があります。このプロセスは、ポリシーが見つかるか、親が null になるまで繰り返されます。この場合、ポリシーは見つかりません。ポリシーが見つからない場合、isAccessAllowed は false を返す必要があります。

このアルゴリズムによって、指定のプロジェクトまたはフォルダ内のすべてのプロキシ サービス、プロジェクト内のすべてのリソース、または AquaLogic Service Bus ドメイン内のすべての AquaLogic Service Bus プロキシ サービスを保護する、大まかなポリシーを作成できます。より具体的で詳細なポリシーは、大まかなポリシーより優先されます。

注意 : AquaLogic Service Bus Cnsole ユーザ インタフェースには、フォルダ、プロジェクト、またはドメイン レベルでプロキシ サービスを保護するページは用意されていません。

ALSBProxyServiceResource オブジェクト

ALSBProxyServiceResource オブジェクトは、ALSB プロキシ サービスへの転送レベルとメッセージレベルのアクセス制御で使用します。ALSBProxyServiceResource リソースは、weblogic.security.spi.Resource を実装している weblogic.security.service.ResourceBase を拡張します。

ALSBProxyServiceResource は、weblogic.security.spi.Resource に記述されるように、以下のメソッドを実装しています。

getType()

タイプを返します。ここでは、タイプは <alsb-proxy-service> です。

getKeys()

最大 4 つのキーと値のプロパティである path、proxy、action、および operation を返します。プロパティは次のように定義されます。
ALSBProxyServiceResource には 1 ～ 4 個のキーがあります。次の表は、プロキシ サービスを保護するさまざまな組み合わせについての説明です。最も具体的なポリシーが優先されます。

リソースに含まれるキー
リソースにバインドされたポリシーの保護対象
path
ポリシーは指定のパスにあるすべてのプロキシ サービスを保護する
path と proxy
ポリシーは指定のプロキシ サービスへのすべてのアクセスを保護する (転送レベルおよびメッセージ レベル)
path、proxy、および action
action="invoke" の場合
  • ポリシーは指定のプロキシの転送レベルのポリシー
action="wss-invoke" の場合
  • ポリシーは指定のプロキシのメッセージレベルのポリシー (すべての操作)
path、proxy、action="wss-invoke"、および operation
ポリシーは指定のプロキシと操作に対するメッセージレベルのポリシー

getPath()

プロキシ サービスへのパス (プロジェクトとフォルダ) を取得します。これは、AquaLogic Service Bus のコンフィグレーション フレームワーク内でプロキシ サービスが存在するパスです。

getProxyServiceName()

プロキシ サービス名を取得します。たとえば、proxy=myProxy。

getAction()

invoke または wss-invoke という 2 つの値のどちらかを取得します。たとえば、action=invoke。

getOperation()

呼び出す操作の名前を取得します。action が wss-invoke の場合のみ使用します。たとえば、operation=processPO。

makeParent()

現在の ALSBProxyServiceResource リソースの親を表す新しい ALSBProxyServiceResource オブジェクトを作成します。makeParent() はプロキシ サービスのパスを使用して親を作成します。
ALSBProxyServiceResource の例

以下の例は、ALSBProxyServiceResource オブジェクトのさまざまな使用方法です。

ProjectResourceV2 オブジェクト

ProjectResourceV2 は、指定のプロジェクトに含まれるすべての ALSBProxyServiceResource オブジェクトのルート リソースです。ProjectResourceV2 は ResourceBase を拡張します。

ProjectResourceV2 に対するアクセス制御ポリシーの設定によって、指定のプロジェクトでさらに具体的なポリシーを持たないすべてのプロキシ サービスに対して、大まかなアクセス制御ポリシーが提供されます。

ProjectResourceV2 には以下のメソッドがあります。

getType()

タイプを返します。ここでは、タイプは "<alsb-project>" です。

getKeys()

キーを返します。ここで、キーは "project-name" です。

getName()

ProjectResourceV2 オブジェクトの名前を取得します。

makeParent()

ProjectResourceV2 オブジェクトには親はありません。したがって、このメソッドは、ProjectResourceV2 オブジェクトの作成に使用されたオブジェクト名を返すか、または ProjectResourceV2 が存在しない場合は null を返します。

ConsoleResource オブジェクト

com.bea.wli.security.resource.ConsoleResource オブジェクトは、ALSB コンソールへのアクセス制御で使用します。ただし、ConsoleResource オブジェクト用のアクセス制御ポリシーを、カスタム認証プロバイダによって設定しないことをお勧めします。これは、これらのポリシーが今後の AquaLogic Service Bus リリースで変更される可能性があるためです。

代わりに、カスタム認証プロバイダを使用する必要がある場合でも、WebLogic Server XACML 認証プロバイダの使用を継続して、ConsoleResource オブジェクト用のポリシーを管理することをお勧めします。このように 2 つの認証プロバイダを使用する場合は、裁決プロバイダもコンフィグレーションする必要があります。


  ページの先頭       前  次