ユーザーズ ガイド
|
 |
 |
|
この章では、BEA AquaLogic Service Bus を使用してメッセージを保護するために必要な情報を示します。AquaLogic Service Bus では、WebLogic Server 9.0 の実証済み WebLogic Security フレームワークを利用しています。セキュリティについて完全に理解するには、BEA WebLogic Server セキュリティのドキュメントを読んでからこの章を読むことをお勧めします。
この章の対象読者は、アプリケーション設計者、セキュリティ開発者、アプリケーション開発者、サーバ管理者、およびアプリケーション管理者です。これらのロールについては、『WebLogic Security について』の「ドキュメントの対象読者」を参照してください。
AquaLogic Service Bus のコンフィグレーションは AquaLogic Service Bus Console で行います。この方法については、AquaLogic Service Bus Console のオンライン ヘルプを参照してください。
AquaLogic Service Bus はメッセージングを仲介します。そのため AquaLogic Service Bus では、WebLogic Server のセキュリティ機能を利用して、メッセージの機密性と整合性を保証し (メッセージレベルのセキュリティ)、WebLogic Server、サービス クライアント、およびビジネス サービスの間の接続を保護し (転送レベルのセキュリティ)、認証と認可 (アクセス制御) を行います。
AquaLogic Service Bus と WebLogic Server のセキュリティにはどのような関係がありますか。
AquaLogic Service Bus では WebLogic Security フレームワークを利用しています。このフレームワークの詳細については、『WebLogic Security について』の「WebLogic セキュリティ サービスのアーキテクチャ」で「WebLogic Security フレームワーク」を参照してください。AquaLogic Service Bus でセキュリティをコンフィグレーションする前に、「WebLogic Server の前提条件」および「Web サービス ポリシー」の説明に従って WebLogic Server でセキュリティをコンフィグレーションする必要があります。
AquaLogic Service Bus ではどのような WebLogic セキュリティ プロバイダがサポートされますか。
AquaLogic Service Bus では、WebLogic 認証プロバイダ、ID アサーション プロバイダ、認可プロバイダ、資格マッピング プロバイダなど、WebLogic Server に含まれるセキュリティ プロバイダがサポートされます。ただし、このリリースでは Security Assertion Markup Language (SAML) ID アサーション プロバイダはサポートされません。今後のリリースでサポートされる予定です。
詳細については、『WebLogic Security について』の「WebLogic セキュリティ サービスのアーキテクチャ」で「WebLogic セキュリティ プロバイダ」を参照してください。
Netegrity、Oracle-Oblix、RSA などのサードパーティ セキュリティ プロバイダはテストされていないため、このリリースの AquaLogic Service Bus ではサポートされません。また、Kerberos トークンなどのサードパーティ トークン ハンドラもテストされていないためサポートされません。
クライアント ID は、AquaLogic Service Bus のメッセージ フローのメッセージ コンテキストでは有効ですが、対象サービスにはクライアント ID は伝播されません。この機能は、将来のリリースで追加される予定です。メッセージ ID の詳細については、「JMS、電子メール、FTP、およびファイル転送のセキュリティ」を参照してください。
AquaLogic Service Bus でサポートされる Web サービスのセキュリティ ポリシーと資格にはどのようなものがありますか。
AquaLogic Service Bus では、デジタル署名と暗号化を使用することによって整合性ポリシーおよび機密性ポリシーをサポートします。また、ユーザ名/パスワード トークン、X.509 証明書チェーン、および信頼性のある X.509 証明書によるメッセージ送信元の認証をサポートします。AquaLogic Service Bus は WebLogic Security フレームワークを基盤に構築されています。このフレームワークでは、OASIS Web サービス セキュリティ標準、ユーザ名トークン プロファイル、および X.509 証明書トークン プロファイルが実装されます。クライアントやプロキシ サービスなどのバックエンド サービスには、必要に応じて Web サービス セキュリティ ポリシーをコンフィグレーションします。このポリシーは、BEA、IBM、Microsoft、SAP、Sonic Software、および VeriSign によって開発された Web Services Policy Framework (WS-Policy) 仕様に従ってモデル化されています。WS-Policy 仕様は完全には標準化されていないため、AquaLogic Service Bus では WebLogic Server 独自の形式をサポートしています。詳細については、「Web サービス ポリシー」を参照してください。
シングル サインオンはメッセージの保護には関係ありません。メッセージの保護に関係するのは、AquaLogic Service Bus のようなメッセージ仲介機能での ID の伝播に関連する概念です。しかし前述のように、ID の伝播はこのリリースではサポートされていません。AquaLogic Service Bus Console と WebLogic Server ではシングル サインオンがサポートされています。詳細については、『WebLogic Security について』の「セキュリティの基礎概念」で「シングル サインオン」を参照してください。
AquaLogic Service Bus では、WebLogic Security フレームワークを使用して以下のセキュリティをコンフィグレーションします。
アクセス制御 - アクセス制御セキュリティでは、リソースに対して特定のアクションを実行するためのパーミッションと権利をエンティティに付与します。AquaLogic Service Bus では、デフォルトの WebLogic 認可プロバイダによる認可をサポートしています。ロールベースの認可の場合、リソースにアクセスする権限のあるロールをセキュリティ ポリシーで定義します。AquaLogic Service Bus Console および MBean へのアクセスも組み込みのロールベース アクセス制御セキュリティ ポリシーで保護します。詳細については、「アクセス制御セキュリティ」を参照してください。
転送レベルのセキュリティ - 転送レベルのセキュリティを使用して、メッセージの転送に使用する接続を保護します。HTTPS 接続は SSL で保護します。必要に応じて、JMS 接続は T3S (T3 over SSL) で保護できます。SSL のセキュリティはポイント ツー ポイントであり、メッセージの経路に仲介機能があるとメッセージが保護されません。FTP、電子メール、およびファイルの転送も保護できます。詳細については、「転送レベルのセキュリティ」を参照してください。
メッセージレベルのセキュリティ - メッセージレベルのセキュリティでは、SSL のセキュリティ上のメリットに、柔軟性と機能が追加されます。メッセージレベルのセキュリティはエンド ツー エンドであり、転送の過程でいくつ仲介機能があっても SOAP メッセージが保護されます。接続では SOAP メッセージ自体がデジタル署名および暗号化されます。さらに、メッセージレベルのセキュリティでは、メッセージの一部だけを署名および暗号化できます。また、SSL は同期通信に対してのみ機能しますが、メッセージレベルのセキュリティは JMS などの非同期転送にも使用できます。AquaLogic Service Bus では現在、HTTP、HTTPS、および JMS でのメッセージレベルのセキュリティがサポートされています。その他の転送は今後追加される予定です。詳細については、「メッセージレベルのセキュリティ」を参照してください。
はい。詳細については、「サービスのモニタの詳細」を参照してください。
AquaLogic Service Bus では、WebLogic Security フレームワークを使用して、より高度なセキュリティ サービスを構成します。これには、認証、ID アサーション、認可、ロール マッピング、監査、および資格マッピングなどが含まれます。
AquaLogic Service Bus セキュリティは AquaLogic Service Bus Console でコンフィグレーションします (図 3-1 を参照)。このコンソールには事前定義済みのルールが用意されており、メッセージの保護、セキュアな転送プロトコルの使用、ユーザ、グループ、ロールの管理、および資格の表示や追加を簡単に行うことができます。AquaLogic Service Bus セキュリティをコンフィグレーションする前に、WebLogic Server セキュリティのいくつかの項目をコンフィグレーションする必要があります (「WebLogic Server の前提条件」を参照)。
図 3-1 AquaLogic Service Bus Console
AquaLogic Service Bus Console にアクセスする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「はじめに」で「BEA AquaLogic Service Bus Console の起動」を参照してください。
AquaLogic Service Bus では WebLogic Security フレームワークを利用しています。AquaLogic Service Bus のすべてのセキュリティ機能を最大限に活用するには、AquaLogic Service Bus でセキュリティをコンフィグレーションする前に、WebLogic Server でいくつかのセキュリティ コンフィグレーションを行う必要があります。WebLogic Server でコンフィグレーションする内容は、ビジネスの要件に応じて異なります。WebLogic Server のコンフィグレーションには、WebLogic Server Administration Console を使用します。詳細については、『WebLogic Server のセキュリティ』を参照してください。
図 3-2 WebLogic Server Administration Console
次に、AquaLogic Service Bus でセキュリティをコンフィグレーションする前に WebLogic Server でコンフィグレーションする必要があるセキュリティ プロパティをいくつか示します。これらの変更は WebLogic Server Administration Console で行います。
wsse:PasswordDigest である必要があります。詳細については、WebLogic Server 9.0 API リファレンスの「weblogic.security.spi.Interface IdentityAsserter」を参照してください。注意 : AquaLogic Service Bus では Web サービス セキュリティ (WS-Security) の監査がサポートされますが、管理上のセキュリティ アクションの監査はサポートされません。WS-Security の監査を有効にするには、以下のシステム プロパティを指定してサーバを起動します。
-Dcom.bea.wli.sb.security.AuditWebServiceSecurityErrors=true
WebserviceSecurityMBeans を使用します。BEA WebLogic Configuration Wizard を使用して AquaLogic Service Bus ドメインを作成すると、この MBean の 2 つのインスタンスが自動的にコンフィグレーションされます。__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN____SERVICE_BUS_OUTBOUND_WEB_SERVICE_SECURITY_MBEAN__これらの MBean のコンフィグレーションはカスタマイズできます。たとえば、着信メッセージまたは発信メッセージに対して X.509 ベースの WS-Security 認証 (X.509 トークン プロファイル) を有効にできます。また、ユーザ名/パスワード トークンを使用したパスワード ダイジェストを使用することもできます。これについては、次の URL にある「Web Services Security Username Token Profile 1.0」を参照してください。
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
転送レベルのセキュリティによって接続が安全であることが保証されます。クライアント アプリケーションと AquaLogic Service Bus プロキシ サービスの間、および AquaLogic Service Bus とビジネス サービスの間の転送セキュリティをコンフィグレーションできます。
接続を保護するには、さまざまな方法でユーザの ID を認証します。認証過程のいずれかで失敗すると認証全体が失敗し、メッセージが拒否されます。WebLogic Server では、認証結果に関係なく監査イベントが生成されます (セキュリティ レルムに監査プロバイダがコンフィグレーションされている場合)。各監査プロバイダは、特定のイベント タイプをフィルタするようにコンフィグレーションできます。たとえば、成功した認証イベントではなく、失敗した認証イベントだけが書き込まれるようにフィルタで指定できます。
AquaLogic Service Bus は、セッション管理、クライアント証明書の検証および認証、信頼性の管理、およびサーバの SSL キーおよび証明書のコンフィグレーションといったサーバサイド SSL の部分で WebLogic Server に依存します。AquaLogic Service Bus では現在、デフォルトの WebLogic Server (SSL) セキュア ネットワーク チャネルのみをサポートしています。AquaLogic Service Bus では、着信と発信の両方の HTTPS プロキシ エンドポイントをサポートしています。これについては、以下の節で説明します。
着信転送レベルのセキュリティは、クライアント アプリケーションと AquaLogic Service Bus プロキシ サービスの間の接続に適用されます。
AquaLogic Service Bus Console を使用してプロキシ サービスをコンフィグレーションするときに、プロキシ エンドポイントの転送レベルのセキュリティをコンフィグレーションします。この方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」を参照してください。
AquaLogic Service Bus Console では、以下のセキュリティ レベルの HTTPS プロキシ エンドポイントをコンフィグレーションできます。
基本認証もクライアント証明書認証も指定せずに HTTPS を指定した場合、一方向 SSL でメッセージが保護されます。一方向 SSL では、クライアントが接続を開始し、WebLogic Server がクライアントに証明書を送信します。つまり、クライアントが WebLogic Server を認証することになります。WebLogic Server で SSL 証明書をコンフィグレーションする方法については、「WebLogic Server の前提条件」を参照してください。
基本認証を指定して HTTPS を指定した場合、暗号化されたチャネルを使用して認証が行われるため、パスワードが保護されます。一方向 SSL 接続が確立されると、クライアントはユーザ名とパスワードを使用して WebLogic Server を認証します。WebLogic Server のセキュリティ レルムにコンフィグレーションされている認証プロバイダを使用してユーザ名とパスワードを検証することにより、信頼が確立されます。クライアントは、HTTP リクエスト ヘッダでユーザ名とパスワードを送信する必要があります。
警告 : 基本認証を必要とする HTTPS プロキシ サービスのエンドポイントを作成する場合、転送認可ポリシーは着信エンドポイント URI に自動的には関連付けられません。基本認証を強制するには、エンドポイントの転送認可ポリシーを定義する必要があります。
警告にあるように、着信エンドポイントの転送認可ポリシー (セキュリティ ポリシー) がエンドポイント URL に関連付けられていない場合は認証が行われません。サーバは、ヘッダにユーザ名とパスワードがない HTTPS リクエストを受け付け、ユーザ名とパスワードをクライアントに要求することもありません。さらに、クライアントが基本認証のユーザ名とパスワードのヘッダをリクエストに含めた場合も、認証は行われません。サーバは無効なユーザ名または無効なパスワードを持つリクエストを受け付けます。プロキシ サービス エンドポイントに対して転送認可ポリシーをコンフィグレーションした後に、クライアント側で正しい認証が行われるようになり、このアクセス制御ポリシーがサーバに適用されます。セキュリティ ポリシーについては、「アクセス制御セキュリティ ポリシー」を参照してください。
クライアント証明書認証によって最高レベルの転送セキュリティが実現します。クライアントによる WebLogic Server 認証に加えて、SSL ハンドシェーク時に WebLogic Server によるクライアント アプリケーションの認証も行われます。これは双方向 SSL とも呼ばれます。SSL の詳細については、『WebLogic Security について』の「セキュリティの基礎概念」で「セキュア ソケット レイヤ (SSL)」を参照してください。
このドキュメントの目的から外れるため着信 HTTPS のクライアント証明書認証の詳細については説明しませんが、この認証の基本は SSL エンジンによるクライアント証明書の検証です。検証では、クライアントのプライベート キーの確認 (SSL プロトコル使用)、クライアント証明書から信頼キーストアの信頼性のある CA (認証局) への信頼チェーンの確立、証明書の有効期限の確認などが行われます。SSL ハンドシェーク時に証明書の検索と検証のフレームワークを呼び出すように WebLogic Server SSL をコンフィグレーションすると、さらに別の検証を実行できます。証明書の信頼が確立されると、証明書が ID アサーション プロバイダに渡されてクライアント ID が抽出されます。
ID アサーション プロバイダも WebLogic Security フレームワークのコンポーネントの 1 つです。ID アサーション プロバイダをコンフィグレーションして、クライアント ID として使用する証明書のフィールド (通常は証明書の SubjectDistinguishedName の CN (一般名) または E (電子メール)) を抽出できます。証明書からフィールドが抽出された後、抽出されたクライアント ID は認証プロバイダの登録ユーザと比較されます。クライアント ID がユーザと一致すると、そのユーザが属するすべてのグループが認証プロバイダによって収集されます。最終的に、クライアント ID を保持する 1 つのプリンシパルとユーザが属する各グループ用の 1 つのプリンシパルを持つ署名された Java Authentication and Authorization Service (JAAS) サブジェクトが返されます。
ID アサーション プロバイダの詳細については、『WebLogic Security について』の「セキュリティの基礎概念」を参照してください。
発信転送のセキュリティは、AquaLogic Service Bus のプロキシ サービスとビジネス サービスの間の接続に適用されます。
発信エンドポイントの転送レベルのセキュリティは、[転送コンフィグレーション] ページでビジネス サービスを作成または編集するときにコンフィグレーションします。この方法については、AquaLogic Service Bus Console のオンライン ヘルプの「ビジネス サービス」を参照してください。
AquaLogic Service Bus Console では、以下のセキュリティ レベルの HTTPS 発信エンドポイントをコンフィグレーションできます。
なし、基本、およびクライアント証明書の認証では、SSL ハンドシェーク時にリモート サーバ証明書が検証されます。ホスト名検証が有効な場合、サーバ証明書の SubjectDistinguishedName がビジネス サービス URL に対して検証されます。詳細については、『WebLogic Security について』の「セキュリティの基礎概念」で「セキュア ソケット レイヤ (SSL)」の下にある「ホスト名の検証」を参照してください。
注意 : プロダクション環境ではホスト名検証を有効にする必要があります。
基本認証もクライアント証明書認証も指定せずに HTTPS を指定した場合、一方向 SSL でメッセージが保護されます。一方向 SSL では、プロキシ サービスは接続を開始しますが、ビジネス サービスに対する認証は行いません。
基本認証を指定して HTTPS を指定した場合、暗号化されたチャネルを使用して認証が行われるため、パスワードが保護されます。一方向 SSL 接続が確立されると、プロキシ サービスはユーザ名とパスワードを使用してビジネス サービスに対する認証を行います。プロキシ サービスは、ビジネス サービスに定義されたサービス アカウントに関連付けられているユーザ名とパスワードを使用します。ビジネス サービスの [HTTPS 転送コンフィグレーション] ページでサービス アカウントを指定し、[セキュリティ コンフィグレーション] モジュールの [資格] セクションでユーザ名とパスワードをサービス アカウントと関連付けます。資格とサービス アカウントの詳細については、「資格」を参照してください。
クライアント証明書認証によって最高レベルの転送セキュリティが実現します。この場合、双方向 SSL が確立されます。プロキシ サービスは、SSL ハンドシェーク時に SSL 証明書を使用してビジネス サービスに対する認証を行います。SSL プライベート キーとそれに対応する証明書 (プロキシ サービスがビジネス サービスに対する認証に使用する証明書) は、プロキシ サービスに定義されているプロキシ サービス プロバイダから取得します。つまり、クライアント証明書認証を指定する前に、プロキシ サービス プロバイダをコンフィグレーションし、SSL クライアント キー ペアをそのプロキシ サービス プロバイダと関連付ける必要があります。詳細については、「プロキシ サービス プロバイダ」を参照してください。
AquaLogic Service Bus Console では、着信エンドポイントおよび発信エンドポイントの基本認証を要求するように AquaLogic Service Bus をコンフィグレーションできます。着信基本認証では、クライアントがユーザ名とパスワードを使用して WebLogic Server を認証します。発信基本認証では、プロキシ サービスがユーザ名とパスワードを使用してビジネス サービスに対する認証を行います。HTTPS 転送レベルのセキュリティとは異なり、HTTP 使用時はビジネス サービスがプロキシ サービスに対する認証を行うことはありません。
警告 : AquaLogic Service Bus Console では HTTP 接続に基本認証を指定できますが、パスワードがクリア テキストで送信されるため推奨されていません。HTTPS では暗号化されたチャネルが提供されるため、パスワードは HTTPS で送信するのが安全です。
HTTP 発信エンドポイントの基本認証を使用する場合、サービス アカウントを指定する必要があります。このサービス アカウントにより、AquaLogic Service Bus からビジネス サービスへの接続に使用されるユーザ名とパスワードがマップされます。詳細については、「サービス アカウント」を参照してください。
また、HTTP 着信エンドポイントの基本認証を使用する場合、転送認可ポリシーをプロキシ サービス URI と関連付ける必要があります。詳細については、「基本 - 着信 HTTPS」を参照してください。
この節では、JMS、電子メール、FTP、およびファイル転送の保護について説明します。
プロキシ サービスへの着信メッセージとプロキシ サービスからの発信メッセージに対して JMS 転送セキュリティを使用するように AquaLogic Service Bus をコンフィグレーションできます。JMS サーバへの接続は T3S プロトコル (T3 over SSL) を使用して保護します。JMS メッセージングのエンド ツー エンドのセキュリティは実現されませんが、次の機能が提供されます。
T3 プロトコルについては、『WebLogic RMI プログラマーズ ガイド』の「T3 プロトコルによる WebLogic RMI の使用」を参照してください。
前述のように、着信転送では、JMS サーバへの接続に使用するプロトコルとして T3S プロトコルを指定できます。指定するには、プロキシ サービスの作成時または編集時、[JMS 転送コンフィグレーション] ページの [SSL を使用] チェック ボックスをチェックします。この方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」を参照してください。
JMS 管理者が JMS 接続プールへのアクセスを制限されている場合は、次の手順に従って、JMS サーバへの接続時に認証が行われるようにプロキシ サービスをコンフィグレーションする必要があります。
サービス アカウントのコンフィグレーション方法については、AquaLogic Service Bus Console のオンライン ヘルプの「サービス アカウント」を参照してください。
発信メッセージでは、JMS サーバへの接続に使用するプロトコルとして T3S プロトコルを指定できます。指定するには、ビジネス サービスの作成時または編集時、[JMS 転送コンフィグレーション] ページの [SSL を使用] チェック ボックスをチェックします。この方法の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「ビジネス サービス」を参照してください。
AquaLogic Service Bus では、JMS 接続プールおよび JMS 送り先 (キューまたはトピック) の JNDI エントリの両方に対するアクセス制御がサポートされています。これら 2 つのリソースのアクセス制御ポリシーはそれぞれ個別にコンフィグレーションできます。JMS 接続プールに対するアクセス制御がコンフィグレーションされている場合、AquaLogic Service Bus は JMS サーバへの接続を確立するときに認証を行う必要があります。JNDI エントリに対するアクセス制御がコンフィグレーションされている場合、AquaLogic Service Bus は JNDI ルックアップ中に認証を行う必要があります。これらのリソースにアクセスするときに認証で使用するサービス アカウントを指定する必要があります。
AquaLogic Service Bus は、ローカル JMS サーバまたは外部 JMS サーバと通信できます。
WebLogic JMS サーバおよび JNDI エントリに対してアクセス制御をコンフィグレーションする方法については、『WebLogic JMS のコンフィグレーションと管理』の「JMS システム リソースのコンフィグレーション」および『WebLogic リソースのセキュリティ』を参照してください。
JMS サーバへの接続を確立するときに認証を行うように AquaLogic Service Bus をコンフィグレーションするには、以下の手順を実行します。
JMS キューまたはトピックの JNDI エントリのルックアップ中に認証を行うように AquaLogic Service Bus をコンフィグレーションするには、以下の手順を実行します。
サービス アカウントのコンフィグレーション方法の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「サービス アカウント」を参照してください。
電子メールまたは FTP 転送では、電子メール サーバまたは FTP サーバへの接続に必要なユーザ名とパスワードを使用したセキュリティがサポートされています。
電子メールを保護するには、AquaLogic Service Bus Console で、サービス アカウントをユーザ名とパスワードのエリアスとして指定する必要があります。サービスは、このユーザ名とパスワードを使用して、SMTP サーバの認証を受けます。
FTP を保護するには、AquaLogic Service Bus Console で [外部ユーザ] を選択し、サービス アカウントをユーザ名とパスワードのエリアスとして指定する必要があります。サービスは、このユーザ名とパスワードを使用して、FTP サーバの認証を受けます。
電子メールと FTP 転送にセキュリティを追加する方法については、AquaLogic Service Bus Console のオンライン ヘルプの「ビジネス サービス」で「ビジネス サービスの追加」を参照してください。
ファイル転送では、ファイルが存在するコンピュータへのユーザ ログインを使用したセキュリティがサポートされています。
転送レベルのセキュリティは、以下のプロキシ サービス パイプライン内部から使用できます。
inbound コンテキスト変数の security 要素を使用します。security 要素の使用方法については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「inbound 変数と outbound 変数」を、メッセージ フローのコンフィグレーションについては、「プロキシ サービス」で「メッセージ フローの概要」を参照してください。
メッセージレベルのセキュリティでは、クライアント アプリケーションと Web サービスの間の SOAP メッセージに対してデジタル署名と暗号化の一方または両方を行うかどうかを指定します。また、ユーザ名トークン認証および X.509 証明書認証の指定も行います。署名によってメッセージの整合性が保持され、メッセージが改ざんされていないことが保証されます。ただし、署名によってメッセージの傍受を防げるわけではありません。メッセージの不正傍受を防ぐには、暗号化を使用します。
メッセージレベルのセキュリティには、転送レベルのセキュリティにはない柔軟性があります。送信過程に 1 つまたは複数の仲介機能がある場合でも、SOAP メッセージを保護できます。セキュリティ対策がメッセージに組み込まれているため、ポイント ツー ポイントでもエンド ツー エンドでもメッセージを保護できます。さらに、メッセージの一部のみを署名または暗号化するように指定することもできます。これは、AquaLogic Service Bus でメッセージをルーティングする場合に便利な機能です。メッセージレベルのセキュリティにより、メッセージの経路全体にわたって必要な部分の情報を保護し、機密性を確保できます。
メッセージレベルのセキュリティは、Web Service Policy (WS-Policy) の指定に従ったセキュリティ ポリシー ステートメントを使用してコンフィグレーションします。WS-Policy ステートメントは、ビジネス サービスまたはプロキシ サービスの WSDL にバインドされます。これらのポリシーは、WSDL 内部から参照される XML ドキュメントにすることも、WSDL の一部として埋め込むこともできます。WSDL には、ポリシー添付を含んだ別の WSDL をインラインまたは外部のいずれかでインポートできます。WS-Policy の詳細については、「Web サービス ポリシー」を参照してください。
Web Services Security (WS-Security) をメッセージに適用すると、新しい SOAP ヘッダがメッセージ エンベロープに追加されます。新しいヘッダには、XML-DSIG デジタル署名、セキュリティ トークン、およびその他の構成要素が含まれています。これらのセキュリティ トークンには以下の用途があります。
受信側では、セキュアなエンベロープが消費されると暗号化操作が逆の順番で行われ、セキュリティ ヘッダが削除されます。次に、メッセージがポリシーに準拠しているかどうかが検証されます。たとえば、必要なメッセージ部分が署名または暗号化 (またはその両方) されているかどうか、また必要なトークンが必要なクレームと共に存在するかどうかが受信側で確認されます。
着信 WS-Security は、クライアント アプリケーションと AquaLogic Service Bus プロキシ サービスの間のメッセージに適用されます。クライアント アプリケーションと AquaLogic Service Bus の間の要求と応答の両方に適用されます。
前述のように、WS-Policy ステートメントを使用して着信メッセージレベルのセキュリティの詳細を指定します。WS-Policy ステートメントは、WSDL 内部にインラインで埋め込まれるか、または WSDL から参照されます。AquaLogic Service Bus には、「アクティブな仲介」および「パススルー」という 2 種類の着信メッセージ セキュリティが用意されています。アクティブな仲介シナリオでは、WS-Policy ステートメントを使用してプロキシ サービスをコンフィグレーションします。パススルー シナリオでは、WS-Policy ステートメントを使用してプロキシ サービスをコンフィグレーションしますが、処理は無効化します。アクティブな仲介シナリオでは、(WSDL から) クライアントに対して WS-Policy ステートメントをパブリックにし、プロキシ サービスがヘッダを処理してポリシーを適用します。パススルー シナリオでは、クライアントに対して WS-Policy ステートメントをパブリックにしますが、AquaLogic Service Bus プロキシではなくクライアント アプリケーションがポリシーを適用します。
クライアントがプロキシ サービスに対して要求を行い、プロキシ サービスが要求に応答する場合、以下の 2 つのセキュリティ シナリオを使用できます。
着信メッセージレベルのセキュリティは、AquaLogic Service Bus プロキシ サービスの作成時または編集時にコンフィグレーションします。以下の手順をガイドラインとして使用してください。コンフィグレーションするシナリオ (アクティブな仲介またはパススルー) に応じて、実行手順が異なります。
プロキシ サービス プロバイダは、プロキシ サービスへの着信メッセージで WS-Security 暗号化を使用する場合は必須です。プロキシ サービス プロバイダによって、着信メッセージを復号化するためのキー ペアがプロキシ サービスに提供されます。
注意 : プロキシ サービス プロバイダをプロキシ サービスに割り当てるには、まずプロキシ サービス プロバイダを定義する必要があります。
発信 WS-Security は、AquaLogic Service Bus プロキシ サービスとビジネス サービスの間のセキュリティを表します。ビジネス アプリケーションとプロキシ サービスの間の要求と応答の両方が含まれます。発信 WS-Security は、SOAP-HTTP または SOAP-JMS のビジネス サービスにのみ適用されます。WSDL から (インラインまたは参照として) アタッチされた WS-Policy ステートメントを使用して、発信メッセージレベルのセキュリティの詳細を指定します。
注意 : SOAP-JMS の場合、WS-Security がサポートされているのは一方向のメッセージのみです。双方向 (要求/応答) のメッセージングではサポートされていません。
着信 WS-Security と同様に、発信 WS-Security にもアクティブな仲介シナリオとパススルー シナリオの両方があります。
プロキシ サービスがビジネス サービスに対して要求を行い、ビジネス サービスが要求に応答する場合、以下の 2 つのセキュリティ シナリオを使用できます。
発信メッセージレベルのセキュリティは、ビジネス サービスの作成時または編集時にコンフィグレーションします。以下の手順をガイドラインとして使用してください。コンフィグレーションするシナリオ (アクティブな仲介またはパススルー) に応じて、実行手順が異なります。
<service-url>?WSDL を指定すると、実行中のサーバから WSDL を取得できます。WSDL 参照の解決方法については、AquaLogic Service Bus Console のオンライン ヘルプの「WSDL」で「未解決の WSDL 参照の解決」を参照してください。security 要素に doOutBoundWSS フラグを設定します。doOutboundWSS フラグを明示的に true に設定すると、プロキシ サービスはセキュリティ ポリシーを適用する (アクティブな仲介シナリオ)。 doOutboundWSS フラグを明示的に false に設定すると、WS-Policy ステートメントでコンフィグレーションされている場合でも、プロキシ サービスはメッセージを処理しない (パススルー シナリオ)。doOutboundWSS を明示的に true または false のいずれにも設定しないと、対象サービスに WS-Policy ポリシーがある場合に、プロキシ サービスはメッセージにポリシーを適用する。security 要素および doOutboundWSS フラグのコンフィグレーションについては、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「inbound 変数と outbound 変数」を参照してください。
注意 : ビジネス サービスの WS-Policy でメッセージの暗号化が要求される場合、暗号化証明書を持つビジネス サービスのポリシーが WSDL のインラインに埋め込まれている必要があります。AquaLogic Service Bus Console でビジネス サービスを定義するときに、この WSDL を参照する必要があります。この参照がないと、AquaLogic Service Bus はビジネス サービスへのメッセージの暗号化に使用するパブリック キーを取得できません。
Web サービス ポリシー (WS-Policy) は、XML ベースの拡張フレームワークです。Web サービスのコンフィグレーションにドメイン固有のアサーションを拡張し、Web サービスの要件、期待される条件、および機能を指定します。AquaLogic Service Bus では、WS-Policy のセキュリティ ポリシー ステートメントを使用して、プロキシ サービスおよびビジネス サービスのメッセージレベルのセキュリティをコンフィグレーションします。この仕様は完全には標準化されていないため、AquaLogic Service Bus では WebLogic Server 独自の形式をサポートしています。詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」を参照してください。
WS-Policy ステートメントを使用すると、署名、暗号化、およびセキュリティ アルゴリズムと認証メカニズムの適用により、メッセージの整合性および機密性を確保し、メッセージ送信元の認証を確実に行うことができます。WS-Policy ステートメントには、セキュリティと、信頼性の高いメッセージング アサーションとの両方を含めることができます。現在のところ、AquaLogic Service Bus ではセキュリティ アサーションをサポートしていますが、信頼性の高いメッセージング アサーションはサポートしていません。
WS-Policy ステートメントは XML ドキュメントであり、WSDL ではインラインに埋め込むことも参照することもできます。WSDL には、ポリシー添付を含んだ別の WSDL をインラインまたは参照によってインポートできます。異なる WSDL 構成要素に 1 つまたは複数の WS-Policy ステートメントを関連付けることができます。これについては、この章で後述します。
AquaLogic Service Bus では、WS-Policy に以下のネームスペースの wsu:Id 属性が必要です。
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
この属性の値は、同じ AquaLogic Service Bus リポジトリ内にあるすべての WS-Policy ステートメントについてユニークである必要があります。WS-Policy スキーマでは、この属性は省略可能とされています。
コードリスト 3-1 は、SOAP 本体の暗号化を指定するセキュリティ ポリシー アサーションを持つ WS-Policy を示します。
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="encryptWithX509Token">
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts>wsp:GetBody(.)</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken TokenType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wssp:KeyInfo>
</wssp:Confidentiality>
</wsp:Policy>
AquaLogic Service Bus Console で WS-Policy を使用する方法については、AquaLogic Service Bus Console のオンライン ヘルプの以下の項目を参照してください。
WS-Policy の添付では、ポリシーを Web サービスに割り当てるメカニズムを定義します。WebLogic Server 9.0 とそれに続く AquaLogic Service Bus では、WSDL ポリシーの添付のみが実装されます。ポリシー ステートメントを WSDL ドキュメントのインラインに埋め込むには、<wsp:Policy> 要素を <wsdl:definition> 要素の子として追加します。インライン ポリシーの参照には XML フラグメント識別子が使用されます。
参照 WS-Policy ステートメントを Web サービスと関連付けるには、以下の 1 つまたは複数のポリシー URI 属性またはポリシー参照要素を WSDL 要素に追加します (この種類は WSDL スキーマに応じて異なります)。
PolicyURIs - URI のリストを値に持つグローバル属性。各 URI は単一のポリシー参照です。属性の拡張のみが可能な WSDL 要素に使用します。PolicyReference - URI 属性を持つグローバル要素。ダイジェストとダイジェスト アルゴリズムも含まれます。URI はポリシーへの参照です。要素の拡張のみが可能な WSDL 要素に使用します。PolicyURIs または PolicyReference を使用して、1 つまたは複数のポリシーを参照できます。WSDL ドキュメントのローカル ポリシー (フラグメント URI) または外部ポリシーを参照できます。
WS-Policy の添付では、<wsp:UsingPolicy/> 要素も定義します。この要素は、WSDL にポリシーの添付がある場合は常に <wsdl:definitions> 要素の子として存在する必要があります。プロキシ サービスとビジネス サービスでポリシーの添付が確実に処理されるように、この要素を必須の拡張 (wsdl:required="true") として WSDL 内にマークすることができます。
警告 : WSDL に UsingPolicy タグがないと、AquaLogic Service Bus では WSDL にあるすべての WS-Policy が無視されます。
コードリスト 3-2 は、2 つのインライン ポリシーを持つ WSDL を示します。インライン ポリシー policy1 は、フラグメント識別子を使用した policyURIs 構文によって portType Sample の doFoo 操作の入力部分から参照されます。もう 1 つのインライン ポリシー policy2 は、ネストされた PolicyReference 構文によってバインディング SampleBinding の doFoo 操作から参照されます。
コードリスト 3-2 インライン ポリシーへのポリシー参照を持つ WSDL
<definitions
...
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:UsingPolicy
wsdl:Required="true"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"/>
<wsp:Policy wsu:Id="policy1">...</wsp:Policy>
<wsp:Policy wsu:Id="policy2">...</wsp:Policy>
...
<portType name="Sample">
<operation name="doFoo" parameterOrder="data">
<input message="tns:foo" wsp:PolicyURIs="#policy1"/>
<output message="tns:fooResponse"/>
</operation>
</portType>
<binding name="SampleBinding" type="tns:Sample">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="doFoo">
<wsp:Policy>
<wsp:PolicyReference URI="#policy2"/>
</wsp:Policy>
<soap:operation
soapAction="http://com.bea.samples/sample/doFoo" style="document"/>
<input>
<soap:body namespace="http://com.bea.samples/sample" use="literal"/>
</input>
<output>
<soap:body namespace="http://com.bea.samples/sample" use="literal"/>
</output>
</operation>
</binding>
...
</definitions>
WS-Policy ステートメントは、さまざまなポリシー サブジェクトと関連付けることができます。ポリシー サブジェクトは、サービス、エンドポイント、操作、メッセージなどのエンティティであり、これにポリシーを関連付けることができます。ポリシー スコープは、ポリシーが適用されるポリシー サブジェクトの集合です。たとえば、wsdl:binding/wsdl:operation/wsdl:input にアタッチされたポリシーが適用されるポリシー スコープは、入力メッセージ、操作、エンドポイント、およびサービスです。
特定のポリシー サブジェクトの有効ポリシーは、スコープにそのポリシー サブジェクトを含むすべてのポリシーを結合したものになります。つまり、ポリシー スコープは、ポリシーが適用されるポリシー サブジェクトの集合です。たとえば、バインディング操作の入力メッセージの有効ポリシーは、以下のポリシーを結合したものになります。
注意 : バインディングからプロキシ サービスを定義した場合、サービスまたはポートにアタッチされた WS-Policy はすべて無視されます。
以下の図に示すように、WS-Policy ステートメントを使用してプロキシ サービスまたはビジネス サービスをコンフィグレーションした場合、AquaLogic Service Bus Console に有効ポリシーが表示されます (読み込み専用)。
WebLogic Server には、3 つの WS-Policy ステートメントが用意されています。ほとんどの場合、これらのポリシーを組み合わせれば、要件を満たすポリシーを作成できます。ただし、独自の WS-Policy を作成して AquaLogic Service Bus にインポートし、WSDL から参照することもできます。
用意されているポリシーを使用するには、policyURIs="policy:Auth.xml" のように URI を使用して任意の WSDL からポリシーを参照します。WebLogic Server には以下のポリシーが含まれています。
Auth.xml - Web サービスを呼び出すクライアント アプリケーションが自身を認証する必要があることを指定します。受け付けるセキュリティ トークンの種類は指定しません。受け付ける種類はサーバのコンフィグレーションに応じて異なり、特に WebserviceSecurityMBean インスタンスに依存します。詳細については、「WebLogic Server の前提条件」を参照してください。Encrypt.xml - SOAP 本体を 3DES-CBC で暗号化する必要があります。キー ラップ アルゴリズムは RSA 1.5 です。Triple DES (Data Encryption Standard) の対称キーはクライアントが生成し、受信者用に RSA 1.5 で暗号化します。Sign.xml - このポリシーはメッセージの整合性を保証します。クライアントに対して、SOAP 本体に署名して、署名したタイムスタンプをクライアント側の WS-Security エンジンが wsse:Security ヘッダに追加するよう要求します。この署名により、特定のリプレイ攻撃を防止できます。システム ヘッダもすべて署名されます。デジタル署名アルゴリズムは RSA-SHA1 です。Exclusive XML Canonicalization が使用されます。 用意されているポリシーは BEA_HOME/weblogic90/server/lib/weblogic.jar にあります。BEA_HOME は BEA Products のインストール ディレクトリです。これらのポリシーの詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」で「メッセージレベルのセキュリティ コンフィグレーションでの WS-Policy ファイルの使用」を参照してください。
コードリスト 3-3 は、用意されている 2 つのポリシーへの参照を持つ WSDL を示します。
コードリスト 3-3 用意されているポリシーへのポリシー参照を持つ WSDL
<definitions
...
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:UsingPolicy
wsdl:Required="true"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"/>
...
<portType name="Sample">
<operation name="doFoo" parameterOrder="data">
<input message="tns:foo" wsp:PolicyURIs="#policy1"/>
<output message="tns:fooResponse"/>
</operation>
</portType>
<binding name="SampleBinding" type="tns:Sample">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="doFoo">
<wsp:Policy>
<wsp:PolicyReference URI="policy:Sign"/>
<wsp:PolicyReference URI="policy:Auth"/>
</wsp:Policy>
...
</operation>
</binding>
...
</definitions>
アクセス制御によって、AquaLogic Service Bus のリソースにアクセスするユーザを決定します。AquaLogic Service Bus では、WebLogic Server のセキュリティ レルムに基づいてリソースを保護します。各セキュリティ レルムは、コンフィグレーションされたセキュリティ プロバイダ、ユーザ、グループ、セキュリティ ロール、および (アクセス制御) セキュリティ ポリシーの集合から成ります。ユーザがレルムに属するリソースにアクセスするには、セキュリティ ロールが割り当てられており、そのレルムに定義されている必要があります。ユーザが AquaLogic Service Bus リソースへのアクセスを試みると、WebLogic Server が関連するセキュリティ レルムとセキュリティ ポリシーをチェックして、ユーザに割り当てられているセキュリティ ロールを確認し、ユーザを認証および認可します。
注意 : AquaLogic Service Bus Console でセキュリティ ポリシーの定義またはセキュリティ ロールの編集を行うことができるのは、WebLogic Server 管理者だけです。
AquaLogic Service Bus Console および MBean へのアクセスは、組み込みのロールベース アクセス制御セキュリティ ポリシーで保護します。これらのセキュリティ ポリシーは WS-Policy ステートメントではありません。このリリースでは MBean のアクセス制御をコンフィグレーションできません。メッセージ フローを制御する場合も、プロキシ サービスに対してセキュリティ ポリシーをコンフィグレーションします。詳細については、「アクセス制御セキュリティ ポリシー」を参照してください。
AquaLogic Service Bus Console には、ユーザ、グループ、およびセキュリティ ロールを表示およびコンフィグレーションするための [セキュリティ コンフィグレーション] モジュールが含まれています。また、AquaLogic Service Bus Console では資格の表示とコンフィグレーションもできます。セキュリティ ポリシーは WebLogic Server Administration Console でコンフィグレーションします。
警告 : AquaLogic Service Bus Console の [セキュリティ コンフィグレーション] モジュール内で変更を行う前に、コンフィグレーションをアクティブにする必要があります。セッションをアクティブにする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「Change Center の使用」を参照してください。
ユーザは、セキュリティ レルムで認証可能なエンティティです。ユーザになれるのは、アプリケーションのエンドユーザなどの人、クライアント アプリケーションなどのソフトウェア エンティティ、または WebLogic Server の他のインスタンスです。認証の結果として、ユーザには ID つまりプリンシパルが割り当てられます。各ユーザに、セキュリティ レルム内でユニークな ID が与えられます。ユーザは、セキュリティ ロールに関連付けられたグループに入れることも、セキュリティ ロールに直接関連付けることもできます。
ユーザをグループ化すると、簡単に管理できます。グループは論理的に整理されたユーザの集合であり、一般に何らかの共通点を持ちます。多数のユーザを個別に管理するよりも、グループを管理する方が効率的です。たとえば、管理者はユーザをグループに所属させ、グループにセキュリティ ロールを割り当ててから、そのセキュリティ ロールをセキュリティ ポリシーを介して WebLogic リソースに関連付けることで、複数のユーザのパーミッションを一度に指定できます。すべてのユーザ名とグループ名はセキュリティ レルム内でユニークでなければなりません。
AquaLogic Service Bus では、以下のグループがあらかじめ定義されています。
前述のように、AquaLogic Service Bus では、WebLogic Security フレームワークを使用したロールベースの認可がサポートされています。認可では、リソースに対して特定のアクションを実行するためのパーミッションと権利がエンティティに与えられます。ロールベースの認可の場合、リソースにアクセスする権限のあるロールはセキュリティ ポリシーで定義されます。
グループは管理者が割り当てる静的な ID ですが、セキュリティ ロール内のメンバシップはユーザ名、グループ メンバシップ、時刻などに基づき動的に計算されます。この点がグループとセキュリティ ロールの違いです。セキュリティ ロールは個々のユーザまたはグループに付与できます。
AquaLogic Service Bus には、特定の管理特権とモニタ特権に関連付けられている以下のロールが組み込まれています。
ユーザおよびグループのコンフィグレーション方法については、AquaLogic Service Bus Console のオンライン ヘルプの「セキュリティ コンフィグレーション」を参照してください。
セキュリティ ロールの詳細については、『WebLogic リソースのセキュリティ』の「ユーザ、グループ、およびセキュリティ ロール」を参照してください。
AquaLogic Service Bus がクライアントおよびビジネス サービスと安全に対話するために必要な資格を指定して、AquaLogic Service Bus をコンフィグレーションできます。AquaLogic Service Bus の資格は WebLogic Security フレームワークを基盤に構築されています。資格を設定するには、AquaLogic Service Bus Console の [セキュリティ コンフィグレーション] モジュールの [資格] セクションを使用します。Console を使用して資格をコンフィグレーションする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「セキュリティ コンフィグレーション」を参照してください。AquaLogic Service Bus では以下の資格がサポートされています。
サービス アカウントとは、ユーザ名とパスワードのエリアス リソースです。AquaLogic Service Bus では、ビジネス サービスやサーバに接続するときに、サービス アカウントを使用して認証が行われます。たとえば、ビジネス サービスの FTP 転送レベルのセキュリティをコンフィグレーションするときには、FTP サーバの認証を受けるためにユーザ名とパスワードを提示する必要がある場合があります。
サービス アカウントは、ビジネス サービスの転送プロトコルをコンフィグレーションするときに使用します。ビジネス サービスをコンフィグレーションする前に、サービス アカウントを定義する必要があります。複数の目的に対して同じサービス アカウントを使用できます。サービス アカウントを定義したら、AquaLogic Service Bus Console の [セキュリティ コンフィグレーション] モジュールの [資格] セクションを使用して、サービス アカウントに関連するユーザ名とパスワードを指定できます。詳細については、「資格のコンフィグレーション」を参照してください。
サービス アカウントの作成方法については、AquaLogic Service Bus Console のオンライン ヘルプの「サービス アカウント」を参照してください。
プロキシ サービスのセキュリティをコンフィグレーションするには、プロキシ サービス プロバイダを指定する必要があります。プロキシ サービス プロバイダによって、プロキシ サービスからの着信メッセージと発信メッセージの資格が提供されます。プロキシ サービス プロバイダを使用する場合、セキュリティ レルムに PKI 資格マッパーをコンフィグレーションする必要があります。詳細については、『WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」で「PKI 資格マッピング プロバイダのコンフィグレーション」を参照してください。
警告 : PKI 資格マッパーなどのセキュリティ プロバイダを追加または削除した後、セキュリティの変更を有効にするには、サーバを再起動する必要があります。
プロキシ サービスは、プロキシ サービス プロバイダから必要な PKI 資格を取得します。たとえば、クライアント証明書認証を使用して HTTPS 接続を開く場合、プロキシ サービスは指定されたプロキシ サービス プロバイダから取得したキー ペアを使用して SSL 認証を行います。複数のプロキシ サービスが同じプロキシ サービス プロバイダを使用することもできます。1 つのプロキシ サービス プロバイダに対して異なる目的の異なる PKI 資格 (プライベート キーと証明書のペアなど) を割り当てることができます。プロキシ サービス プロバイダによって以下のセキュリティが提供されます。
プロキシ サービスのセキュリティをコンフィグレーションする前に、まずプロキシ サービス プロバイダを作成する必要があります。作成すると、プロキシ サービスのコンフィグレーション時にプロキシ サービス プロバイダを指定できるようになります。AquaLogic Service Bus Console でプロキシ サービスをアクティブにしたら、[セキュリティ コンフィグレーション] モジュールの [資格] セクションを使用して PKI 資格をプロキシ サービス プロバイダと関連付けることができます。詳細については、「資格のコンフィグレーション」を参照してください。
プロキシ サービス プロバイダの作成方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス プロバイダ」を参照してください。資格マッピング プロバイダについては、『WebLogic Security について』の「セキュリティ プロバイダ」と、「WebLogic Server の前提条件」を参照してください。
資格はセキュリティ プロバイダに保持され、AquaLogic Service Bus のセッションによって制御されるリポジトリには保持されません。つまり資格は、関連するサービス アカウントまたはプロキシ サービス プロバイダが作成されたセッションに依存しません。以下のガイドラインに従ってください。
この節で説明した手順の実行方法については、AquaLogic Service Bus Console のオンライン ヘルプの「サービス アカウント」、「プロキシ サービス プロバイダ」、および「Change Center の使用」を参照してください。
(アクセス制御) セキュリティ ポリシーは、WebLogic リソースと、1 つまたは複数のユーザ、グループ、またはセキュリティ ロールとの間の関連付けです。セキュリティ ポリシーは、権限のないアクセスから WebLogic リソースを保護します。セキュリティ ポリシーは特定のリソースに割り当てられてたブール式です。リソースへのアクセスが試行されると、式が評価されます。式は、ロール (オペレータ) とアクセス時間 (午前 8 時から午後 5 時) など、ブール演算子で結合された 1 つまたは複数の条件で構成されます。セキュリティ ポリシーの詳細については、『WebLogic Security について』の「セキュリティの基礎概念」および『WebLogic リソースのセキュリティ』の「セキュリティ ポリシーの構成要素 : ポリシー条件、式、および文」を参照してください。
セキュリティ ポリシーは WebLogic Server Administration Console でコンフィグレーションします。詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」および WebLogic Server Administration Console のオンライン ヘルプの「セキュリティ ポリシーの管理」を参照してください。
セキュリティ ポリシーはセキュリティ プロバイダに保持され、AquaLogic Service Bus のセッションによって制御されるリポジトリには保持されません。そのため、セキュリティ ポリシーは関連するプロキシ サービスが作成されたセッションに依存しません。プロキシ サービスを変更する場合、以下のガイドラインに従ってください。
プロキシ サービスを削除する場合は、以下の手順を実行します。
プロキシ サービスを移動または名前変更する場合は、以下の手順を実行します。
プロキシ サービス URL を変更する場合は、以下の手順を実行します。
プロキシ サービスの操作を名前変更する場合は、以下の手順を実行します。
AquaLogic Service Bus インストールをプロダクション用に準備する場合、セキュリティ要件に特に注意する必要があります。ここでは、必要な作業のいくつかを簡単に説明します。
sbconfig ディレクトリです。例を示します。C:\bea\user_projects\domains\base_domain\sbconfig
|
|
|