ユーザーズ ガイド
|
 |
 |
|
この章では、BEA AquaLogic Service Bus を使用してメッセージを保護するために必要な情報を示します。AquaLogic Service Bus では、WebLogic Server 9.1 の実証済み WebLogic Security フレームワークを利用しています。セキュリティについて完全に理解するには、BEA WebLogic Server セキュリティのドキュメントを読んでからこの章を読むことをお勧めします。
この章の対象読者は、アプリケーション設計者、セキュリティ開発者、アプリケーション開発者、サーバ管理者、およびアプリケーション管理者です。これらの役割については、『WebLogic Security について』の「対象読者」を参照してください。
AquaLogic Service Bus のコンフィグレーションは AquaLogic Service Bus Console で行います。この方法については、『AquaLogic Service Bus Console の使い方』を参照してください。
AquaLogic Service Bus はメッセージングを仲介します。そこで、AquaLogic Service Bus のセキュリティ機能では、メッセージの機密性と整合性の保証 (Web サービス セキュリティによるメッセージレベルのセキュリティ)、WebLogic Server、サービス クライアント、およびビジネス サービスの間の接続の保護 (転送レベルのセキュリティ)、認証と認可 (アクセス制御) が行われます。
AquaLogic Service Bus と WebLogic Server のセキュリティにはどのような関係がありますか。
AquaLogic Service Bus では WebLogic Security フレームワークを利用しています。このフレームワークの詳細については、『WebLogic Security について』の「WebLogic Security サービスのアーキテクチャ」で「WebLogic Security フレームワーク」を参照してください。AquaLogic Service Bus でセキュリティをコンフィグレーションする前に、「WebLogic Server の前提条件」の説明に従って、WebLogic Server で WebLogic Server セキュリティ レルムやその他のサーバのコンフィグレーション (SSL など) を行う必要があります。
転送レベルのセキュリティは、メッセージの転送に使用する接続を保護する転送プロトコルを指します。転送レベルのセキュリティの例として、HTTPS (HTTP over SSL) があります。SSL のセキュリティはポイント ツー ポイントですが、メッセージの経路に仲介者がいるとメッセージが保護されません。詳細については、「転送レベルのセキュリティ」を参照してください。
Web サービス セキュリティ (WS-Security) は OASIS 標準の 1 つです。SOAP メッセージにメッセージレベルのセキュリティを組み込むための相互運用可能なメカニズムを定義しています。WS-Security は、メッセージの整合性と機密性をサポートします。また、SOAP エンベロープにセキュリティ トークンを含める拡張モデルや、SOAP エンベロープ内からセキュリティ トークンを参照するモデルも定義しています。WS-Security トークン プロファイルは、コアの WS-Security 仕様内での特定のトークン タイプの使用方法を指定しています。メッセージの整合性は XML デジタル署名を使用することで確保され、メッセージの機密性は XML 暗号化を使用するとこで確保されます。WS-Security では、SOAP メッセージのどの部分をデジタル署名または暗号化するかを指定できます。AquaLogic Service Bus は、HTTP、HTTPS、および一方向 JMS による WS-Security をサポートします。WS-Security の詳細については、以下の URL にある「Web Service Security: SOAP Message Security 1.0 (WS-Security 2004)」を参照してください。
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
AquaLogic Service Bus ではどの WS-Security トークン プロファイルがサポートされますか。
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)
Web Services Security X.509 Token Profile 1.0 (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf)
Web Services Security SAML Token Profile 1.0 (http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf)
Web サービス ポリシー フレームワーク (WS-Policy) は、Web サービスのポリシーを記述して通信するための汎用モデルとその構文を提供します。WS-Policy は、さまざまなサービスの要件、環境設定、および機能を記述するための一連の基本構成要素を定義しています。これは、他の Web サービス仕様によって使用および拡張できます。詳細については、「Web サービス ポリシー」を参照してください。
Web Services Policy Assertions Language (WS-PolicyAssertions) は、セキュリティ ポリシー内で指定できる一連の共通メッセージ ポリシー アサーションを指定しています。この仕様は、WS-Policy で使用する一般的なメッセージング関連のアサーションを定義しています。個別の仕様で、セキュリティ アサーションと信頼性の高いメッセージング アサーションについて、ドメイン固有のアサーションの構文とセマンティクスを記述します。
AquaLogic Service Bus でメッセージレベルのセキュリティをコンフィグレーションするために WS-Policy で使用するポリシー アサーションは、Web Services Security Policy Language (WS-SecurityPolicy) 仕様の 2002 年 12 月 18 日バージョンに記述されたアサーションに基づいています。これは、AquaLogic Service Bus のアサーションの構文や用途は、仕様と厳密に同じというわけではありませんが、仕様に記述されているアサーションと意味の上では同様であるということです。AquaLogic Service Bus 2.1 のアサーションは、仕様の最新版 (2005 年 7 月 13 日) をベースにしていません。AquaLogic Service Bus で使用されているポリシー アサーションは、WebLogic Server 9.0 および 9.1 の Web サービスで使用されているポリシー アサーションと完全に互換性があります。
いいえ。アクセス制御ポリシーは、特定のリソース (プロキシ サービス、Web アプリケーション、EJB など) へのアクセスの要求の承認および拒否を決定するブール式です。通常、アクセス制御ポリシーは要求側のロールに基づいています。WS-Policy は、Web サービス定義 (WSDL) を補完する、Web サービスについてのメタデータです。WS-Policy は、「すべての要求はクライアントのデジタル署名が必要である」などの、すべてのサービス クライアントが満たすべき要件を表すために使用できます。
WS-Security パススルー シナリオでは、クライアントが要求メッセージまたは応答メッセージに WS-Security を適用します。プロキシ サービスは、セキュリティ ヘッダを処理しません。保護された要求メッセージをそのままビジネス サービスに渡します。AquaLogic Service Bus はメッセージに WS-Security を適用せずに、ヘッダの値に基づいてメッセージをルーティングします。ビジネス サービスは、メッセージを受け取った後にセキュリティ ヘッダを処理し、要求に応答します。ビジネス サービスには、WS-Policy セキュリティ ステートメントがコンフィグレーションされている必要があります。保護された応答メッセージがそのままクライアントに渡されます。たとえば、クライアントはメッセージを暗号化および署名して、プロキシ サービスに送信します。プロキシ サービスはメッセージの復号化やデジタル署名の検証を行わず、単にメッセージをビジネス サービスにルーティングします。ビジネス サービスは、メッセージを復号化し、デジタル署名を検証してから、要求を処理します。応答パスでも同様です。このようなプロキシは受動的仲介者とも呼ばれます。
能動的仲介者のシナリオでは、クライアントが要求メッセージと応答メッセージに WS-Security を適用します。プロキシ サービスが、セキュリティ ヘッダを処理して WS-Security ポリシーを適用します。たとえば、クライアントがメッセージを暗号化および署名してプロキシ サービスに送信し、プロキシ サービスがメッセージを復号化してデジタル署名を検証してから、メッセージをルーティングします。プロキシ サービスは、応答をクライアントに返信する前に、メッセージに署名して暗号化します。クライアントは、メッセージを復号化してプロキシのデジタル署名を検証します。
発信 WS-Security は、AquaLogic Service Bus プロキシ サービスとビジネス サービスの間のセキュリティを表します。ビジネス アプリケーションとプロキシ サービスの間の要求と応答の両方が含まれます。詳細については、「発信 Web サービス セキュリティについて」を参照してください。
SAML (Security Assertion Markup Language) は、OASIS 標準ベースの拡張可能な XML フレームワークです。認証および認可情報を交換することによって、最新のネットワーク環境でのシングル サインオンを可能にします。
AquaLogic Service Bus ではどのような WebLogic セキュリティ プロバイダがサポートされますか。
AquaLogic Service Bus では、WebLogic 認証プロバイダ、ID アサーション プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、資格マッピング プロバイダ、証明書検索および検証 (CLV) プロバイダなど、WebLogic Server に付属のセキュリティ プロバイダがサポートされます。さらに、AquaLogic Service Bus 2.1 では、WebLogic SAML ID アサーション プロバイダ V2 および WebLogic SAML 資格マッピング プロバイダ V2 のサポートが追加されています。
AquaLogic Service Bus 2.1 では、新しい WebLogic XACML 認可プロバイダがサポートされています。デフォルトでは、AquaLogic Service Bus 2.1 ドメインには、WebLogic XACML 認可プロバイダのみが含まれていますが、必要に応じて、XACML プロバイダをこのリリースでサポートされている WebLogic デフォルト認可プロバイダに置換できます。XACML プロバイダの使用をお勧めします。詳細については、『WebLogic Security について』の「WebLogic Security サービスのアーキテクチャ」で「WebLogic セキュリティ プロバイダ」を参照してください。
AquaLogic Service Bus には、XACML 認可プロバイダと WebLogic 認可プロバイダの両方が含まれています。デフォルトでは、新規作成したドメインのセキュリティ レルムには XACML 認可プロバイダが含まれています。XACML 認可プロバイダは、XACML (eXtensible Access Control Markup Language) を使用します。
重要 : 独自のポリシー言語を使用する、DefaultAuthorizer という名前の WebLogic 認可プロバイダは、デフォルトの認可プロバイダではなくなりました。
AquaLogic Service Bus 2.1 では、Netegrity、Oracle-Oblix、RSA などのサードパーティ セキュリティ プロバイダはテストされていないため、動作が確認されていません。ただし、AquaLogic Service Bus セキュリティ アーキテクチャでは、サードパーティの認証、認可、およびロール マッピング プロバイダの使用がサポートされています。AquaLogic Service Bus 2.1 でのサードパーティ セキュリティ プロバイダのサポートについては、BEA カスタマ サポートにお問い合わせください。
証明書検索および検証 (CLV) プロパイダは、証明書のパスを完成させて X509 証明書チェーンを検証します。CLV プロバイダには次の 2 種類があります。
CertPath Builder - Web サービスまたはアプリケーション コードから証明書、証明書チェーン、または証明書の参照情報 (チェーンの最後の証明書または証明書のサブジェクト DN) を受け取ります。このプロバイダは、チェーンの証明書を検索して検証します。
CertPath Validator — SSL プロトコル、Web サービス、またはアプリケーション コードから証明書チェーンを受け取り、失効チェックなどの追加検証を行います。
少なくとも CertPath Builder と CertPath Validator を 1 つずつ、セキュリティ レルムにコンフィグレーションする必要があります。1 つのセキュリティ レルムに複数の CertPath Validator をコンフィグレーションすることができます。複数のプロバイダをコンフィグレーションした場合、証明書または証明書チェーンは、すべての CertPath Validator の検証をパスしないと有効になりません。WebLogic Server では、WebLogic CertPath プロバイダと証明書レジストリで CLV プロバイダの機能を使用できます。詳細については、『WebLogic Security について』の「WebLogic Security サービスのアーキテクチャ」で「証明書の検索と検証のプロセス」を参照してください。
はい。AquaLogic Service Bus は、「Web Service Security: SAML Token Profile 1.0」の仕様に準拠する SAML 1.1 アサーションを生成することで、ID の伝播をサポートしています (http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf)。これは、プロキシがルーティングする先のビジネス サービスで SAML holder-of-key または sender-vouches の WS-Policy を設定することで実行されます。
プロキシ サービスへの着信メッセージに転送レベルの認証とメッセージレベルの認証の両方が存在する場合、どちらの ID が伝播されますか。
デフォルトでは、発信 SAML トークン内のサブジェクト ID は、着信ユーザ名と同じです。サブジェクト ID の形式は、カスタムの SAML 名前マッパー プロバイダを記述することでカスタマイズできます。詳細については、『WebLogic Server のセキュリティ』の「SAML 資格マッピング プロバイダのコンフィグレーション」を参照してください。
厳密に言えば、AquaLogic Service Bus メッセージング シナリオでは、シングル サインオン (SSO) はさまざまな理由で使用できません。まず、AquaLogic Service Bus はステートレスであるため、セッションの概念や複数のパーティ間での会話がありません。次に、AquaLogic Service Bus のクライアントは、通常は他のエンタープライズ ソフトウェア アプリケーションであり、Web ブラウザを使用するユーザではありません。そのため、このようなクライアントが要求ごとにユーザ名とパスワードなどの資格情報を送信する必要があっても、通信が SSL や WS-Security などの方法で保護される限り、許容されます。ただし、AquaLogic Service Bus Console と WebLogic Server Administration Console の間の SSO はサポートされています。詳細については、『WebLogic Security について』の「セキュリティの基礎概念」で「シングル サインオン (SSO)」を参照してください。
WS-Security エラーのみが、AquaLogic Service Bus モニタ フレームワークによってモニタされます。SSL ハンドシェーク エラー、転送レベルの認証、転送レベルのアクセス制御などの転送レベルのセキュリティ エラーは、このリリースではモニタされません。詳細については、「サービスのモニタの詳細」を参照してください。ただし、監査プロバイダをコンフィグレーションして、転送レベルの認証と認可を監査することができます。
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 のセキュリティ』を参照してください。
AquaLogic Service Bus ドメインに WebLogic セキュリティをコンフィグレーションする主な手順は以下のとおりです。
次に、プロバイダの詳細と、「AquaLogic Service Bus ドメインの保護の主な手順」に示したプロバイダ以外に、AquaLogic Service Bus でセキュリティをコンフィグレーションする前に必要に応じて WebLogic Server でコンフィグレーションできるセキュリティ プロバイダを示します。これらの変更は WebLogic Server Administration Console で行います。
wsse:PasswordDigest である必要があります。詳細については、『WebLogic Security について』の「WebLogic Security サービスのアーキテクチャ」で「WebLogic ID アサーション プロバイダ」を参照してください。注意 : WS-Security デジタル署名を使用する場合は必ず証明書レジストリを使用することを強くお勧めします。信頼性のある署名検証証明書を証明書レジストリにロードする必要があります。詳細については、『WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」にある「資格検索および検証フレームワークのコンフィグレーション」および BEA WebLogic Server の『Administration Console オンライン ヘルプ』の「証明書レジストリ : 管理」を参照してください。
注意 : 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
詳細については、BEA WebLogic Server の『Administration Console オンライン ヘルプ』の「X.509 証明書を使用した ID の証明」および「SOAP メッセージでのパスワード ダイジェストの使用」を参照してください。
転送レベルのセキュリティによって接続が安全であることが保証されます。クライアント アプリケーションと AquaLogic Service Bus プロキシ サービスの間、および AquaLogic Service Bus とビジネス サービスの間の転送セキュリティをコンフィグレーションできます。
AquaLogic Service Bus は、HTTPS プロキシ サービスと HTTPS ビジネス サービスをサポートします。HTTPS プロキシ サービスは、HTTPS プロトコルでクライアント要求を受信します。同じ HTTPS 接続で、クライアントへの応答を送信します。このドキュメントでは、これを着信 HTTPS と呼びます。
プロキシ サービスは、メッセージを HTTPS プロトコルで HTTPS ビジネス サービスにルーティングします。この場合、プロキシ サービスは HTTPS クライアントとして動作し、ビジネス サービスへの HTTPS 接続を開きます。同じ HTTPS 接続で、ビジネス サービスからの応答を受信します。このドキュメントでは、これを発信 HTTPS と呼びます。
注意 : AquaLogic Service Bus は、SSL ネットワーク チャネルを 1 つだけサポートします。これは、デフォルトは WebLogic Server (SSL) セキュア ネットワーク チャネルと呼ばれます。
着信転送レベルのセキュリティは、クライアント アプリケーションと AquaLogic Service Bus プロキシ サービスの間の接続に適用されます。
AquaLogic Service Bus Console を使用してプロキシ サービスをコンフィグレーションするときに、プロキシ エンドポイントの転送レベルのセキュリティをコンフィグレーションします。この方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」を参照してください。
AquaLogic Service Bus Console では、以下のセキュリティ レベルの HTTPS プロキシ エンドポイントをコンフィグレーションできます。
BASIC 認証も CLIENT CERT 認証も指定せずに HTTPS を指定した場合、一方向 SSL でメッセージが保護されます。一方向 SSL では、クライアントが接続を開始し、WebLogic Server がクライアントに証明書を送信します。つまり、クライアントが WebLogic Server を認証することになります。WebLogic Server で SSL 証明書をコンフィグレーションする方法については、「WebLogic Server の前提条件」を参照してください。
BASIC 認証を指定して HTTPS を指定した場合、暗号化されたチャネルを使用して認証が行われるため、パスワードが保護されます。一方向 SSL 接続が確立されると、クライアントはユーザ名とパスワードを使用して WebLogic Server を認証します。WebLogic Server のセキュリティ レルムにコンフィグレーションされている認証プロバイダを使用してユーザ名とパスワードを検証することにより、信頼が確立されます。クライアントは、HTTP 要求ヘッダでユーザ名とパスワードを送信する必要があります。
警告 : HTTPS プロキシ サービスのエンドポイントを作成すると、最初の転送アクセス制御ポリシーでは、すべての要求に対するアクセスが許可されます。BASIC 認証を強制するには、エンドポイントの転送認可ポリシーを定義する必要があります。
警告にあるように、着信エンドポイントの転送認可ポリシー (セキュリティ ポリシー) がエンドポイント URL に関連付けられていない場合は認証が行われません。サーバは、ヘッダにユーザ名とパスワードがない HTTPS 要求を受け付け、ユーザ名とパスワードをクライアントに要求することもありません。さらに、クライアントが BASIC 認証のユーザ名とパスワードのヘッダを要求に含めた場合も、認証は行われません。サーバは無効なユーザ名または無効なパスワードを持つ要求を受け付けます。プロキシ サービス エンドポイントに対して転送認可ポリシーをコンフィグレーションした後に、クライアント側で正しい認証が行われるようになり、このアクセス制御ポリシーがサーバに適用されます。セキュリティ ポリシーの詳細については、「プロキシ サービスのアクセス制御のコンフィグレーション」を参照してください。
クライアント証明書認証によって最高レベルの転送セキュリティが実現します。クライアントによる WebLogic Server 認証に加えて、SSL ハンドシェーク時に WebLogic Server によるクライアント アプリケーションの認証も行われます。これは双方向 SSL とも呼ばれます。SSL の詳細については、『WebLogic Security について』の「セキュリティの基礎概念」で「セキュア ソケット レイヤ (SSL)」を参照してください。
このドキュメントの目的から外れるため着信 HTTPS の CLIENT CERT 認証の詳細については説明しませんが、この認証の基本は 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) サブジェクトが返されます。
注意 : サーバに [クライアント証明書を要求 (強制しない)] で双方向 SSL をコンフィグレーションしており、プロキシ サービスに転送レベルのアクセス制御ポリシーを割り当てていない場合は、プロキシ サービスは HTTPS を介した要求を「クライアント証明書なしで」受け入れます。プロキシ サービスに転送レベルのアクセス制御ポリシーを割り当てる必要があります。
ID アサーション プロバイダの詳細については、『WebLogic Security について』の「セキュリティの基礎概念」を参照してください。
発信転送のセキュリティは、AquaLogic Service Bus のプロキシ サービスとビジネス サービスの間の接続に適用されます。
発信エンドポイントの転送レベルのセキュリティは、[転送コンフィグレーション] ページでビジネス サービスを作成または編集するときにコンフィグレーションします。この方法については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」を参照してください。
AquaLogic Service Bus Console では、以下のセキュリティ レベルの HTTPS 発信エンドポイントをコンフィグレーションできます。
なし、基本、およびクライアント証明書の認証では、SSL ハンドシェーク時にリモート サーバ証明書が検証されます。ホスト名検証が有効な場合、サーバ証明書の SubjectDistinguishedName がビジネス サービス URL に対して検証されます。詳細については、『WebLogic Security について』の「セキュリティの基礎概念」で「セキュア ソケット レイヤ (SSL)」の下にある「ホスト名検証」を参照してください。
注意 : プロダクション環境ではホスト名検証を有効にする必要があります。
BASIC 認証も CLIENT CERT 認証も指定せずに HTTPS を指定した場合、一方向 SSL でメッセージが保護されます。一方向 SSL では、プロキシ サービスは接続を開始しますが、ビジネス サービスに対する認証は行いません。
BASIC 認証を指定して HTTPS を指定した場合、暗号化されたチャネルを使用して認証が行われるため、パスワードが保護されます。一方向 SSL 接続が確立されると、プロキシ サービスはユーザ名とパスワードを使用してビジネス サービスに対する認証を行います。プロキシ サービスは、ビジネス サービスに定義されたサービス アカウントに関連付けられているユーザ名とパスワードを使用します。ビジネス サービスの [HTTPS 転送コンフィグレーション] ページでサービス アカウントを指定し、[セキュリティ コンフィグレーション] モジュールの [資格] セクションでユーザ名とパスワードをサービス アカウントと関連付けます。資格とサービス アカウントの詳細については、「資格」を参照してください。
クライアント証明書認証によって最高レベルの転送セキュリティが実現します。この場合、双方向 SSL が確立されます。プロキシ サービスは、SSL ハンドシェーク時に SSL 証明書を使用してビジネス サービスに対する認証を行います。SSL プライベート キーとそれに対応する証明書 (プロキシ サービスがビジネス サービスに対する認証に使用する証明書) は、プロキシ サービスに定義されているプロキシ サービス プロバイダから取得します。つまり、CLIENT CERT 認証を指定する前に、プロキシ サービス プロバイダをコンフィグレーションし、SSL クライアント キー ペアをそのプロキシ サービス プロバイダと関連付ける必要があります。詳細については、「プロキシ サービス プロバイダ」を参照してください。
AquaLogic Service Bus Console では、着信エンドポイントおよび発信エンドポイントの BASIC 認証を要求するように AquaLogic Service Bus をコンフィグレーションできます。着信 BASIC 認証では、クライアントがユーザ名とパスワードを使用して WebLogic Server を認証します。発信 BASIC 認証では、プロキシ サービスがユーザ名とパスワードを使用してビジネス サービスに対する認証を行います。HTTPS 転送レベルのセキュリティとは異なり、HTTP 使用時はビジネス サービスがプロキシ サービスに対する認証を行うことはありません。
警告 : AquaLogic Service Bus Console では HTTP 接続に BASIC 認証を指定できますが、パスワードがクリア テキストで送信されるため推奨されていません。HTTPS では暗号化されたチャネルが提供されるため、パスワードは HTTPS で送信するのが安全です。
HTTP 発信エンドポイントの BASIC 認証を使用する場合、サービス アカウントを指定する必要があります。このサービス アカウントにより、AquaLogic Service Bus からビジネス サービスへの接続に使用されるユーザ名とパスワードがマップされます。詳細については、「サービス アカウント」を参照してください。
また、HTTP 着信エンドポイントの BASIC 認証を使用する場合、転送認可ポリシーをプロキシ サービス URI と関連付ける必要があります。詳細については、「基本 - 着信 HTTPS」を参照してください。
この節では、JMS、電子メール、FTP、およびファイル転送の保護について説明します。
プロキシ サービスへの着信メッセージとプロキシ サービスからの発信メッセージに対して JMS 転送セキュリティを使用するように AquaLogic Service Bus をコンフィグレーションできます。JMS サーバへの接続は T3S プロトコル (T3 over SSL) を使用して保護することができます。JMS メッセージングのエンド ツー エンドのセキュリティは実現されませんが、次の機能が提供されます。
T3 プロトコルについては、『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI での T3 プロトコルの使い方」を参照してください。
前述のように、着信転送では、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 の使い方』の「サービス アカウント」を参照してください。
警告 : サービス アカウントを発信 JMS 転送での認証に使用している場合、そのサービス アカウントに対する (つまり、ポリシーに対する) 変更がサーバ上で有効になるまで、最長で 60 秒かかることがあります。
警告 : デフォルトでは、WebLogic Server JMS は各送り先の ACL を 60 秒間隔でチェックします。このデフォルト時間を変更するか、JMS リソースに対して send、receive、および getEnumeration アクションが実行されるたびに JMS リソースのセキュリティ チェックが行われるように設定できます。これを行うには、weblogic.jms.securityCheckInterval 属性を設定します。この属性の値を 0 に設定すると、JMS リソースに対して send、receive、および getEnumeration アクションが実行されるたびに、JMS リソースのセキュリティ チェックが行われます。
警告 : アプリケーションの保護の詳細については、『プロダクション環境の保護』の「プロダクション環境のセキュリティの確保」を参照してください。
電子メールまたは FTP 転送では、電子メール サーバまたは FTP サーバへの接続に必要なユーザ名とパスワードを使用したセキュリティがサポートされています。
電子メールを保護するには、AquaLogic Service Bus Console で、サービス アカウントをユーザ名とパスワードのエリアスとして指定する必要があります。サービスは、このユーザ名とパスワードを使用して、SMTP サーバの認証を受けます。
FTP を保護するには、AquaLogic Service Bus Console で [外部ユーザ] を選択し、サービス アカウントをユーザ名とパスワードのエリアスとして指定する必要があります。サービスは、このユーザ名とパスワードを使用して、FTP サーバの認証を受けます。
電子メールと FTP 転送にセキュリティを追加する方法については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」で「ビジネス サービスの追加」を参照してください。
ファイル転送では、ファイルが存在するコンピュータへのユーザ ログインを使用したセキュリティがサポートされています。
転送レベルのセキュリティは、以下のプロキシ サービス パイプライン内部から使用できます。
![[JMS 転送コンフィグレーション] ページ](wwimages/jms_jndi_accounts.gif "[JMS 転送コンフィグレーション] ページ")
inbound コンテキスト変数の security 要素を使用します。security 要素の使用方法については、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」で「inbound 変数と outbound 変数」を、メッセージ フローのコンフィグレーションについては、「プロキシ サービス」で「メッセージ フロー」を参照してください。
Web サービス セキュリティ (WS-Security) は OASIS 標準の 1 つです。SOAP メッセージにメッセージレベルのセキュリティを組み込むための相互運用可能なメカニズムを定義しています。WS-Security は、メッセージの整合性と機密性をサポートします。また、SOAP エンベロープにセキュリティ トークンを含める拡張モデルや、SOAP エンベロープ内からセキュリティ トークンを参照するモデルも定義しています。WS-Security トークン プロファイルは、コアの WS-Security 仕様内での特定のトークン タイプの使用方法を指定しています。メッセージの整合性は、XML デジタル署名を使用することで確保されます。メッセージの機密性は、XML 暗号化を使用するとこで確保されます。WS-Security では、SOAP メッセージのどの部分をデジタル署名または暗号化するかを指定できます。AquaLogic Service Bus は、HTTP、HTTPS、および一方向 JMS による W サービス セキュリティをサポートします。AquaLogic Service Bus は、WS-Security バージョン 1.0 をサポートしています。WS-Security の詳細については、以下の URL にある「Web Service Security: SOAP Message Security 1.0 (WS-Security 2004)」を参照してください。
AquaLogic Service Bus では、以下の WS-Security トークン プロファイルがサポートされます。
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf)http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf)http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf)メッセージレベルのセキュリティには、転送レベルのセキュリティにはない柔軟性があります。送信過程に 1 つまたは複数の仲介者がいる場合でも、SOAP メッセージを保護できます。セキュリティ対策がメッセージに組み込まれているため、ポイント ツー ポイントでもエンド ツー エンドでもメッセージを保護できます。メッセージのどの部分を署名または暗号化するかを指定する機能は、AquaLogic Service Bus でメッセージをルーティングする場合に便利な機能です。メッセージレベルのセキュリティにより、メッセージの経路全体にわたって必要な部分の情報を保護し、機密性を確保できます。
メッセージレベルのセキュリティは、Web Service Policy (WS-Policy) の指定に従ったセキュリティ ポリシー ステートメントを使用してコンフィグレーションします。WS-Policy ステートメントは、ビジネス サービスまたはプロキシ サービスにバインドされます。ポリシーをサービスにバインドするメカニズムを WS-PolicyAttachment と呼びます。このメカニズムには、WSDL ドキュメントにポリシー参照を追加することでポリシーをバインドする方法が記述されています。これらのポリシー参照は、WSDL ドキュメントに含まれるポリシーを参照する場合と、外部ポリシーへの URL の参照である場合があります。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 種類の着信メッセージ セキュリティが用意されています。
注意 : SOAP-JMS の場合、WS-Security がサポートされているのは一方向のメッセージのみです。双方向 (要求/応答) のメッセージングではサポートされていません。
クライアントがプロキシ サービスに対して要求を行い、プロキシ サービスが要求に応答する場合、以下の 2 つのセキュリティ シナリオを使用できます。
注意 : どちらのシナリオでも、プロキシ サービスに WS-Policy ステートメントがコンフィグレーションされている必要があります。これらの WS-Policy ステートメントは、クライアントが (動的 WSDL から) 取得できます。
警告 : 着信応答メッセージの暗号化 : プロキシ サービスの応答ポリシーで暗号化が指定されている場合、クライアントは要求で証明書をプロキシ サービスに送信する必要があります。プロキシ サービスは、クライアントの公開鍵を使用して応答を暗号化します。クライアント証明書は、プロキシ サービスの暗号化証明書とは異なる必要があります。クライアントを、プロキシ サービスと同じ暗号化資格を使用するようにコンフィグレーションすることはできません。
以下に、WS-Security のパススルー シナリオをコンフィグレーションする基本手順を示します。一部の手順は省略可能です。
以下に、Web サービス セキュリティのパススルー シナリオをコンフィグレーションする基本手順を示します。一部の手順は省略可能です。
__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__ という名前の WebserviceSecurityMBean の UseX509ForIdentity プロパティを有効にする必要があります。詳細については、「WebLogic Server の前提条件」の「ドメイン全体の Web サービス セキュリティ コンフィグレーション」を参照してください。発信 WS-Security は、AquaLogic Service Bus プロキシ サービスとビジネス サービスの間のセキュリティを表します。ビジネス アプリケーションとプロキシ サービスの間の要求と応答の両方が含まれます。発信 WS-Security は、SOAP-HTTP または SOAP-JMS のビジネス サービスにのみ適用されます。ビジネス サービスの WSDL から (インラインまたは参照として) 添付された WS-Policy ステートメントを使用して、発信のメッセージレベルのセキュリティの詳細を指定します。
注意 : SOAP-JMS の場合、WS-Security がサポートされているのは一方向のメッセージのみです。双方向 (要求/応答) のメッセージングではサポートされていません。
警告 : バックエンド応答メッセージの暗号化 : ビジネス サービスの応答ポリシーで暗号化が指定されている場合、プロキシ サービスは要求で暗号化証明書をビジネス サービスに送信する必要があります。ビジネス サービスは、プロキシ サービスの公開鍵を使用して応答を暗号化します。プロキシ サービスの暗号化資格は、ビジネス サービスの暗号化資格とは異なる必要があります。
この節では、発信 Web サービス セキュリティ シナリオをコンフィグレーションする基本手順を示します。一部の手順は省略可能です。
注意 : ビジネス サービスの WS-Policy でメッセージの暗号化が要求される場合、暗号化証明書を持つビジネス サービスのポリシーが WSDL のインラインに埋め込まれている必要があります。さらに、AquaLogic Service Bus Console でビジネス サービスを定義するときに、この WSDL を参照する必要があります。ビジネス サービスが WebLogic Server 9.0 または 9.1 Web サービスであるか、AquaLogic Service Bus プロキシ サービスである場合、ブラウザに <service-url>?WSDL を指定すると WSDL を取得できます。WebLogic Server は、自動的に Web サービス ポリシーを WSDL のインラインに埋め込みます。また、ポリシーで要求の暗号化が指定されている場合は、暗号化証明書は自動的に WSDL に埋め込まれます。コード リスト 3-1 は、インライン ポリシーを持ち、暗号化証明書が埋め込まれた WSDL の例を示します。特に、ポリシー内の KeyInfo 要素と SecurityTokenReference に注目してください。BinarySecurityToken 要素の値は、base-64 でエンコードされた暗号化証明書です (この例では値が切り捨てられています)。証明書が PEM 形式の場合、PEM ファイル (PEM プレフィックスおよびサフィックスなし) のコンテンツは、証明書の base-64 エンコード表現です。暗号化証明書が JDK キーストアに格納されている場合、簡単に PEM ファイルにエクスポートできます。
コード リスト 3-1 インライン ポリシーを持ち、暗号化証明書が埋め込まれた WSDL の例
<definitions name="WssServiceDefinitions"
targetNamespace="http://com.bea.alsb/tests/wss"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
...
>
<wsp:UsingPolicy xmlns:n1="http://schemas.xmlsoap.org/wsdl/" n1:Required="true"/>
<wsp:Policy wsu:Id="Encrypt.xml">
<wssp:Confidentiality xmlns:wssp="http://www.bea.com/wls90/security/policy">
<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 Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</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:SecurityTokenReference>
<wssp:Embedded>
<wsse:BinarySecurityToken
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
MIICfjCCAeegAwIBAgIQV/PDyj3...
</wsse:BinarySecurityToken>
</wssp:Embedded>
</wssp:SecurityTokenReference>
</wssp:KeyInfo>
</wssp:Confidentiality>
</wsp:Policy>
<binding name="WssServiceSoapBinding" type="tns:WssService">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getPurchaseOrder">
<soap:operation soapAction="" style="document"/>
<input>
<soap:body parts="parameters" use="literal"/>
<wsp:Policy>
<wsp:PolicyReference URI="#Encrypt.xml"/>
</wsp:Policy>
</input>
<output>
<soap:body parts="parameters" use="literal"/>
</output>
</operation>
</binding>
...
</definitions>
メッセージ コンテキストの security 要素の doOutBoundWSS プロパティは、発信 WS-Security を制御します。doOutboundWss が true の場合、プロキシ サービスは、ターゲット サービスの WS-Policy に従って発信メッセージに WS-Security を適用します (つまり、署名、暗号化、セキュリティ トークンの追加などを行います)。doOutboundWss が false の場合、プロキシ サービスは発信メッセージに WS-Security を適用しません。
WS-Security パススルー シナリオでは、プロキシ サービスは、クライアントによって WS-Security が適用された要求を受け取りますが、WS-Security ペイロードを処理しません。プロキシ サービスはこの要求をバックエンド サービスにルーティングするだけです。これは受動的仲介者のシナリオとも呼ばれます。プロキシ サービスが受動的仲介者である場合、保護された着信メッセージは AquaLogic Service Bus メッセージ フローで署名/暗号化されたままになります。したがって、発信時にメッセージを再署名または再暗号化する必要がありません。
ルート ノードは、ルーティングまたはパブリッシュ時にルーティングの送り先を設定するときにこのプロパティを自動的に初期化します。doOutboundWss のデフォルト値は、プロキシおよびターゲット サービスの両方の WS-Security コンフィグレーションに応じて次のように異なります。
doOutboundWss は false に設定される。doOutboundWss は false に設定される。doOutboundWss 要素の値は、ルーティング (またはパブリッシュ) の発信要求アクションでは変更できます。
Web サービス ポリシー (WS-Policy) は、XML ベースの拡張フレームワークです。Web サービスのコンフィグレーションにドメイン固有のアサーションを拡張し、Web サービスの要件、期待される条件、および機能を指定します。AquaLogic Service Bus では、WS-Policy のセキュリティ ポリシー ステートメントを使用して、ビジネス サービスおよびプロキシ サービスのメッセージレベルのセキュリティをコンフィグレーションします。詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」を参照してください。
注意 : AquaLogic Service Bus でメッセージレベルのセキュリティをコンフィグレーションするために WS-Policy で使用するポリシー アサーションは、Web Services Security Policy Language (WS-SecurityPolicy) 仕様の 2002 年 12 月 18 日バージョンに記述されたアサーションに基づいています。これは、AquaLogic Service Bus のアサーションの構文や用途は、仕様と厳密に同じというわけではありませんが、仕様に記述されているアサーションと意味の上では同様であるということです。このリリースの AquaLogic Service Bus のアサーションは、仕様の最新版 (2005 年 7 月 13 日) をベースにしていません。AquaLogic Service Bus で使用されているポリシー アサーションは、WebLogic Server 9.0 および 9.1 の 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-2 は、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」および「未解決の WSDL 参照の解決」を参照してください。
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-3 は、2 つのインライン ポリシーを持つ WSDL を示します。インライン ポリシー policy1 は、フラグメント識別子を使用した policyURIs 構文によって portType Sample の doFoo 操作の入力部分から参照されます。もう 1 つのインライン ポリシー policy2 は、ネストされた PolicyReference 構文によってバインディング SampleBinding の doFoo 操作から参照されます。
コード リスト 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/"/>
<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-4 は、用意されている 2 つのポリシーへの参照を持つ WSDL を示します。
コード リスト 3-4 用意されているポリシーへのポリシー参照を持つ 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 では、オンラインのビジネス パートナ間で情報を交換するためのフレームワークを定義する Security Assertion Markup Language (SAML) がサポートされています。SAML の概要については、次の URL にある OASIS 技術概要を参照してください。
http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf
SAML 仕様の完全なドキュメント セットは、次の URL にあります。
http://www.oasis-open.org/committees/download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.zip
AquaLogic Service Bus は、実装技術として SAML を使用し、ID の伝播をサポートします。ID の伝播により、AquaLogic Service Bus クライアントの ID を、プロキシ サービスがルーティングする先のビジネス サービスへ運ぶセキュアな通路が規定されます。ID は、SOAP メッセージに含まれる WS-Security セキュリティ ヘッダ内の SAML トークンによって伝播されます。次の図は、ID の伝播をグラフィカルに表現しています。
クライアント要求に、クライアントをバックエンド サービスに対して認証する SAML トークンが含まれています。メッセージは、AquaLogic Service Bus プロキシ サービスによってルーティングされます。ただし、プロキシ サービスでの WS-Security 処理は無効です。
このようなタイプの ID の伝播は、以下を前提にしています。
クライアントは、サポートされている認証メカニズムの 1 つによって AquaLogic Service Bus に対する認証を行い、プロキシ サービスはクライアント ID をバックエンド サービスへ伝播します。AquaLogic Service Bus はアサーティング パーティとして動作します。以下の認証メカニズムが使用される可能性があります。
発信要求で、プロキシ サービスは、バックエンド サービスへのメッセージ内の WS-Security ヘッダに SAML トークンを含めることで、クライアントの代わりに SAML アサーションを生成します。バックエンド サービスは、リライイング パーティとして動作し、AquaLogic Service Bus との信頼関係が必要です。バックエンド サービスは、WS-Security ヘッダを処理する際に、SAML アサーションを検証します。SAML アサーションの ID に対してセキュリティ コンテキストが作成され、Web サービスはこのセキュリティ コンテキストで呼び出されます。
注意 : ターゲット URL は通常、ビジネス サービスの最初のアドレスの絶対 URL です。ただし、プロキシ サービスが動的ルーティングを行う場合、$outbound の URI 要素を指定することで、ターゲット URL はメッセージ コンテキストで指定された動的アドレスになります。アサーションに署名する場合、証明書をコンフィグレーションする必要があります。詳細については、『WebLogic Server のセキュリティ』の「SAML 資格マッピング プロバイダのコンフィグレーション」を参照してください。
注意 : クライアント要求に WS-Security セキュリティ ヘッダが含まれる場合、プロキシ サービスはメッセージの着信側でこのヘッダを処理する必要があります。これは、WebLogic Server WS-Security ランタイムが、1 つの SOAP エンベロープ内に複数の WS-Security ヘッダがあるケースや既存のセキュリティ ヘッダへのセキュリティ トークンの追加をサポートしないためです。
このようなタイプの ID の伝播は、以下を前提にしています。
クライアント要求は、WS-Security SAML トークン プロファイルを使用してプロキシ サービスに対してクライアントを認証します。クライアント要求は WS-Security ヘッダに SAML トークンを含め、プロキシ サービスは、要求のセキュリティ ヘッダを処理する際にクライアント ID のアサーションを行います。このシナリオは、能動的仲介者のシナリオです。この点で、パススルーでの ID の伝播とは異なります。
このようなタイプの ID の伝播は、以下を前提にしています。
能動的仲介プロキシ サービスに SAML を指定する WS-Policy がある場合、WebLogic Server Administration Console を使用して、SAML アサーティング パーティに WebLogic SAML ID アサーション プロバイダ V2 をコンフィグレーションします。WS-Policy からの確認メソッドは、SAML アサーティング パーティの SAML プロファイルと一致する必要があります。詳細については、『WebLogic Server のセキュリティ』の「SAML ID アサーション プロバイダのコンフィグレーション」を参照してください。アサーティング パーティのターゲット URL は、プロキシの相対 URL であり、プロトコルとホストの情報は含まれません。アサーションに署名する場合は、証明書を ID アサーション プロバイダのレジストリに追加します。
質問 : 着信転送 ID を送り先のビジネス サービスに伝播しようとしていますが、何度試しても「Unable to add security token for identity」というエラーが発生します。これはどういう意味ですか。
回答 : このエラーの原因はさまざまです。通常は、以下のいずれかの問題によります。
$security メッセージ コンテキスト変数を調べることで確認できます。質問 : SAML holder-of-key を使用して着信転送 ID を送り先のビジネス サービスに伝播しようとしていますが、何度試しても「Failure to add signature」というエラーが発生します。これはどういう意味ですか。
回答 : このエラーの原因はさまざまですが、一般的にはビジネス サービスのプロキシ サービス プロバイダに資格がコンフィグレーションされていないことがあげられます。AquaLogic Service Bus は、発信 holder-of-key アサーションを生成するときに、通常はメッセージ コンテンツに対するデジタル署名も生成します。これによって、受信側で、メッセージが特定のユーザから送信されていることを検証するだけでなく、メッセージが改ざんされていないことも検証できます。署名を生成するには、ビジネス サービスに、デジタル署名資格のあるプロキシ サービス プロバイダが関連付けられている必要があります。資格のコンフィグレーションの詳細については、『AquaLogic Service Bus Console の使い方』の「セキュリティ コンフィグレーション」で「資格の追加」を参照してください。
質問 : SAML ID トークンを受信する能動的仲介プロキシ サービスをコンフィグレーションしようとしていますが、何度試しても「The SAML token is not valid」というエラーが発生します。このエラーはどのように修正できますか。
回答 : これは通常、プロキシに、SAML ID アサーション プロバイダまたは SAML ID アサーション プロバイダ アサーティング パーティがコンフィグレーションされていないことが原因です。プロキシ サービスが能動的仲介モードで SAML アサーションを受け取るには、SAML ID アサーション プロバイダがコンフィグレーションされている必要があります。詳細については、『WebLogic Server のセキュリティ』の「SAML ID アサーション プロバイダのコンフィグレーション」を参照してください。
アクセス制御によって、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 には、表 3-1 に示すように、事前定義済みのグループがあります。
表 3-1 AquaLogic Service Bus のグループ
前述のように、AquaLogic Service Bus では、WebLogic Security フレームワークを使用したロールベースの認可がサポートされています。認可では、リソースに対して特定のアクションを実行するためのパーミッションと権利がエンティティに与えられます。ロールベースの認可の場合、リソースにアクセスする権限のあるロールはセキュリティ ポリシーで定義されます。
グループは管理者が割り当てる静的な ID ですが、セキュリティ ロール内のメンバシップはユーザ名、グループ メンバシップ、時刻などに基づき動的に計算されます。この点がグループとセキュリティ ロールの違いです。セキュリティ ロールは個々のユーザまたはグループに付与できます。
AquaLogic Service Bus には、表 3-2 に示すように、特定の管理特権とモニタ特権に関連付けられているロールが組み込まれています。
表 3-2 AquaLogic Service Bus のセキュリティ ロール
|
|
||
|
|
||
ユーザおよびグループのコンフィグレーション方法については、『AquaLogic Service Bus Console の使い方』の「セキュリティ コンフィグレーション」を参照してください。
セキュリティ ロールの詳細については、『WebLogic リソースのセキュリティ』の「ユーザ、グループ、セキュリティ ロール」を参照してください。
表 3-4 に、各種ロールのユーザが Console モジュールで実行できるアクションの一覧を示します。
表 3-3 AquaLogic Service Bus のロールとタイプ
注意 : この表の「ロール タイプ」カラムにあるチェック マーク (
) は、そのアクションの実行パーミッションがあることを示しています。
この表の [セキュリティ コンフィグレーション] のセクションで、ユーザ、グループ、ロールの作成、編集、削除と、資格およびアクセス制御ポリシーの作成、編集、表示、削除にチェック マークがありません。これは、これらの機能を使用できるのが WLS の Administrators のみであるためです。WLS の Administrator ロールは、IntegrationAdministrator ロールとは異なります。
表 3-4 AquaLogic Service Bus Console でのロールベースのアクセス権
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 サーバの認証を受けるためにユーザ名とパスワードを提示する必要がある場合があります。
サービス アカウントは、ビジネス サービスの転送プロトコルをコンフィグレーションするときに使用します。発信 Web サービス セキュリティ ユーザ名トークン認証にも使用されます。ビジネス サービスをコンフィグレーションする前に、サービス アカウントを定義する必要があります。複数の目的に対して同じサービス アカウントを使用できます。サービス アカウントを定義したら、AquaLogic Service Bus Console の [セキュリティ コンフィグレーション] モジュールの [資格] セクションを使用して、サービス アカウントに関連するユーザ名とパスワードを指定できます。詳細については、「資格のコンフィグレーション」を参照してください。
サービス アカウントの作成方法については、『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照してください。
セキュリティ シナリオによっては、PKI キーペア資格を使用する必要があります。キーペア資格は、プライベート キーと証明書のペアです。証明書には、プライベート キーに対応する公開鍵が含まれます。プロキシ サービスが PKI キーペアを使用する必要がある場合は、必ずプロキシにプロキシ サービスを割り当てる必要があります。プロキシ サービス プロバイダを使用する前に、セキュリティ レルムに PKI 資格マッパーをコンフィグレーションする必要があります。PKI 資格マッピング プロバイダは、ALSB 2.1 ドメインにあらかじめコンフィグレーションされていません。詳細については、『WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」で「PKI 資格マッピング プロバイダのコンフィグレーション」を参照してください。
警告 : PKI 資格マッパーなどのセキュリティ プロバイダを追加または削除した後、セキュリティの変更を有効にするには、サーバを再起動する必要があります。
プロキシ サービスは、必要に応じてプロキシ サービス プロバイダから PKI 資格を取得します。たとえば、クライアント証明書認証を使用して HTTPS 接続を開く場合、プロキシ サービスはプロキシ サービス プロバイダから SSL クライアント キー ペアを取得します。複数のプロキシ サービスが同じプロキシ サービス プロバイダを使用することもできます。用途ごとに異なる PKI キーペア資格をプロキシ サービス プロバイダに割り当てることができます。プロキシ サービス プロバイダは、以下の用途のために資格を提供します。
プロキシ サービスのセキュリティをコンフィグレーションする前に、まずプロキシ サービス プロバイダを作成する必要があります。作成すると、プロキシ サービスのコンフィグレーション時にプロキシ サービス プロバイダを指定できるようになります。AquaLogic Service Bus Console でプロキシ サービスをアクティブにしたら、[セキュリティ コンフィグレーション] モジュールの [資格] セクションを使用して PKI 資格をプロキシ サービス プロバイダと関連付けることができます。詳細については、「資格のコンフィグレーション」を参照してください。
プロキシ サービス プロバイダの作成方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス プロバイダ」を参照してください。資格マッピング プロバイダについては、『WebLogic Security について』の「セキュリティ プロバイダ」と、「WebLogic Server の前提条件」を参照してください。
資格はセキュリティ プロバイダに保持され、AquaLogic Service Bus のセッションによって制御されるリポジトリには保持されません。つまり資格は、関連するサービス アカウントまたはプロキシ サービス プロバイダが作成されたセッションに依存しません。以下のガイドラインに従ってください。
この節で説明した手順の実行方法については、『AquaLogic Service Bus Console の使い方』の「サービス アカウント」、「プロキシ サービス プロバイダ」、および「Change Center の使用」を参照してください。
HTTP と HTTPS プロキシ サービスに転送レベルのアクセス制御をコンフィグレーションできます。WS-Security の能動的仲介プロキシ サービスには、メッセージレベルのアクセス制御もコンフィグレーションできます。アクセス制御をコンフィグレーションするには、プロキシ サービスに転送レベルまたはメッセージレベルのいずれかで (または両方で) アクセス制御ポリシーを割り当てる必要があります。
すべてのプロキシ サービスのデフォルトの転送レベルおよびメッセージレベルのアクセス制御ポリシーでは、すべての要求へのアクセスが許可されます。プロキシ サービスにアクセス制御ポリシーを割り当てて、プロキシ サービスを保護する必要があります。
注意 : JMS、FTP、電子メール、またはファイル転送のプロキシ サービスでは、アクセス制御はサポートされません。これらのプロトコルには、基になるリソースを保護するための、プロトコルに依存しないメカニズムがあります。
アクセス制御ポリシーは、WebLogic リソースと、1 つまたは複数のユーザ、グループ、またはセキュリティ ロールの間の関係を表します。セキュリティ ポリシーは、権限のないアクセスから WebLogic リソースを保護します。アクセス制御ポリシーは、特定のリソースに割り当てられてたブール式です。リソースへのアクセスが試行されると、式が評価されます。式は、ロール (オペレータ) とアクセス時間 (午前 8 時から午後 5 時) など、ブール演算子で結合された 1 つまたは複数の条件で構成されます。アクセス制御ポリシーの詳細については、『WebLogic Security について』の「セキュリティの基礎概念」および『WebLogic リソースのセキュリティ』の「セキュリティ ポリシーの構成要素 : ポリシー条件、式、および文」を参照してください。
AquaLogic Service Bus Console で、転送レベルとメッセージレベルのアクセス制御ポリシーをコンフィグレーションします。また、WebLogic Server Administration Console で、WebLogic リソースにアクセス制御ポリシーを割り当てることができます。詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」および WebLogic Server の『Administration Console オンライン ヘルプ』の「セキュリティ ポリシーの管理」を参照してください。
アクセス制御ポリシーは認可プロバイダに保持され、AquaLogic Service Bus のセッションによって制御されるリポジトリには保持されません。そのため、プロキシ サービスのアクセス制御ポリシーは、対応するプロキシ サービスが作成されたセッションに依存しません。プロキシ サービスを変更する場合、以下のガイドラインに従ってください。
プロキシ サービスを削除する場合は、以下の手順を実行します。
プロキシ サービスを移動または名前変更する場合は、以下の手順を実行します。
プロキシ サービス URL を変更する場合は、以下の手順を実行します。
プロキシ サービスの操作を名前変更する場合は、以下の手順を実行します。
AquaLogic Service Bus インストールをプロダクション用に準備する場合、セキュリティ要件に特に注意する必要があります。ここでは、必要な作業のいくつかを簡単に説明します。
sbconfig ディレクトリです。例を示します。C:\bea\user_projects\domains\base_domain\sbconfig
|
|
|