| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.2.1.2.0) E82661-02 |
|
 前 |
 次 |
この章では、Service Busのセキュリティ・モデルの概要とその機能(インバウンド・セキュリティおよびアウトバウンド・セキュリティを含む)について説明します。
Service Busでは、通信の整合性とプライバシを保証し、認可されたユーザーのみがService Busドメインのリソースにアクセスできるようにするために、オープンな業界標準をサポートしています。また、セキュリティ・サービスの構成要素として、基になっているWebLogicセキュリティ・フレームワークを使用します。
Service Busでは、Oracle Platform Security Services (OPSS)およびOracle Web Services Manager (OWSM)を使用して、より高度なセキュリティ・サービスを構成します。これには、認証、IDアサーション、認可、ロール・マッピング、監査、資格証明マッピングなどが含まれます。Service Busアクセス・セキュリティを構成するには、最初にOracle WebLogic Serverセキュリティを構成する必要があります。Service BusでOWSMを使用すると、組織全体で一貫性のあるWebサービスの管理と保護のためのポリシー・フレームワークが提供されます。
注意:
Oracle Web Services Manager (OWSM)は、Oracle Service Busで使用されるWebサービス・セキュリティ・メカニズムです。ビジネス・サービスやプロキシ・サービスなどの新規作成されたすべてのリソースでは、セキュリティにOWSMポリシーを使用します。WLS 9ポリシーは非推奨になったため、新しいService Busリソースのセキュリティの構成には使用できません。
ただし、WLS 9ポリシーですでに構成されたリソースをService Busプロジェクトにインポートできます。これらのWLS 9ポリシーの編集または変更はできませんが、OWSMポリシーに置き換えることができます。
この章の内容は次のとおりです。
デフォルトでは、すべての匿名ユーザーまたは認証ユーザーがプロキシ・サービスに接続できます。インバウンド・セキュリティによって、Service Busプロキシ・サービスは認可されたクライアントから出されたリクエストのみを処理できますまた、クライアントからデータが送信されたときに、認可されていないユーザーがそのデータを参照または変更していないことが保証されます。
プロキシ・サービスは、サービス・コンシューマと他のプロキシ・サービスという2つのタイプのクライアントを持つことができます。図47-1に、プロキシ・サービスとそのクライアント間の通信がインバウンド・セキュリティによって保護され、一方プロキシ・サービスとビジネス・サービス間の通信がアウトバウンド・セキュリティによって保護されることを示します。
インバウンド・セキュリティはプロキシ・サービスの作成時に設定し、ニーズの変化に応じて変更できます。外向きのプロキシ・サービス(サービス・コンシューマからリクエストを受信します)の場合は、双方向SSL over HTTPSなどの厳密なセキュリティ要件の設定を検討します。
プロキシ・サービスで、デジタル署名、暗号化、またはSSL認証に対して公開鍵インフラストラクチャ(PKI)テクノロジを使用する場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成します。詳細は、「サービス・キー・プロバイダの操作」を参照してください。
各プロキシ・サービスに対し、次のインバウンド・セキュリティ・チェックを構成できます。
トランスポートレベルのセキュリティは、クライアントとプロキシ・サービス間の接続確立の一部としてセキュリティ・チェックを適用します。トランスポート・レベルのセキュリティによって適用できるセキュリティ要件は、プロキシ・サービスで使用するように構成するプロトコルによって異なります。
たとえば、HTTPプロトコル経由で通信するプロキシ・サービスの場合、Fusion Middleware Controlで作成したユーザーのデータベースに対してすべてのクライアントが認証するように要求できます。次に、認証されたユーザーに対してプロキシ・サービスへのアクセスを認可する条件を指定するためのアクセス制御ポリシーを作成します。
Service Busは、トランスポート・レベルのインバウンド・リクエストでクライアント指定のカスタム認証トークンをサポートします。
サポートされる各プロトコルに対するトランスポート・レベルのセキュリティの構成については、「トランスポート・レベルのセキュリティの構成」.を参照してください。
メッセージレベルのセキュリティでのカスタム認証。Service Busは、トランスポート・レベルおよびメッセージ・レベルのインバウンド・リクエストでクライアント指定のカスタム認証資格証明をサポートします。カスタム認証資格証明は、カスタム・トークン、またはユーザー名とパスワードの形式になります。
カスタム認証によるトランスポートレベルおよびメッセージレベルのセキュリティの構成は、「カスタム認証の構成」を参照してください。
メッセージ・レベルのセキュリティ(Webサービスであるプロキシ・サービス用)は、WS-Security仕様の一部です。メッセージ・レベルのセキュリティでは、SOAPメッセージまたはSOAPメッセージの特定の部分を処理する前にセキュリティ・チェックを適用します。
メッセージ・レベルでのセキュリティの構成部分は、Webサービスと関連付けられたWSDLドキュメントおよびWS-Policyドキュメントに埋め込むことができます。これらのドキュメントでは、SOAPメッセージをデジタル署名したり暗号化したりする必要があるかどうか、および認可されたユーザーのみが呼び出すことができるWebサービス操作を指定します。
メッセージを保護するには、メッセージの機密保持の場合はメッセージを暗号化し、メッセージ整合性の場合はメッセージに署名する必要があります。OWSM事前定義済ポリシー、およびいずれかのメッセージ保護アサーション・テンプレートを使用して作成したポリシーにより、メッセージの機密保持またはメッセージ整合性(あるいはその両方)のオプションが提供されます。
プロキシ・サービスまたはビジネス・サービスがWS-Policy文を使用して操作へのアクセスを保護する場合、および(パススルー・サービスとは対照的に)アクティブな仲介としてサービスを構成する場合は、Oracle Service Busコンソールを使用してメッセージ・レベルのアクセス制御ポリシーを作成します。ポリシーでは、保護された操作を呼び出すためにユーザー、グループ、またはセキュリティ・ロールを認可する条件を指定します。
メッセージレベルでのセキュリティの構成の詳細は、「Webサービスのメッセージレベルでのセキュリティの構成」を参照してください。
アウトバウンド・セキュリティは、プロキシ・サービスとビジネス・サービス間の通信を保護します。アウトバウンド・セキュリティのために行うタスクのほとんどは、ビジネス・サービスで指定されるトランスポート・レベルまたはメッセージ・レベルのセキュリティ要件に準拠するためのプロキシ・サービスの構成のためのものです。
たとえば、ビジネス・サービスでユーザー名とパスワード・トークンが必要な場合は、サービス・アカウントを作成します。このサービス・アカウントは、ユーザー名とパスワードを直接含み、アウトバウンド・リクエストに含まれていたユーザー名とパスワードを渡すか、またはアウトバウンド・リクエストに含まれていたユーザー名に応じてユーザー名とパスワードを提供します。詳細は、「サービス・アカウントの操作」を参照してください。
ビジネス・サービスでデジタル署名またはSSL認証のためにPKIテクノロジを使用する必要がある場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成します。詳細は、「サービス・キー・プロバイダの操作」を参照してください。
Service Busのセキュリティの設計時に決定する必要がある主な項目の1つは、クライアントが提供するIDの処理(伝播)方法です。
Service Busの構成によって、次のことを実行できます。
クライアントが提供する資格証明を認証します。
認可チェックを実行します
クライアント資格証明を変更せずにビジネス・サービスに渡します。
ビジネス・サービスが認証および認可できる別の資格証明にクライアント資格証明をマップします。
セキュリティ・テクノロジ間を橋渡しします。
表47-1は、Service BusがクライアントIDをビジネス・サービスに伝播する方法に影響するオプションについての説明です。
表47-1 IDの伝播のオプション
| デシジョン | 説明 |
|---|---|
クライアントが提供する必要があるのはどのタイプの資格証明か。 |
トランスポート・レベルのセキュリティの場合、Service Busは既存のセキュリティ要件に合わせます。Service Busのクライアントは、ユーザー名とパスワード・トークン、SSL証明書または構成したIDアサーション・プロバイダによってサポートされる他のタイプのカスタム認証トークンを提供できます。 メッセージ・レベルのセキュリティの場合、Service Busではユーザー名トークン、X.509トークン、構成した認証プロバイダまたはIDアサーション・プロバイダによってサポートされるその他のカスタム認証トークンおよびSAMLトークン・プロファイルをサポートします(「セキュリティ・プロバイダの使用」を参照)。 Webサービス・セキュリティを使用する新しいビジネス・サービス用のセキュリティ要件を確立する場合は、SAMLトークンを提供するようクライアントに要求することを推奨します。SAMLは、Webサービス内でユーザーIDを伝播するための新しい標準です。「Oracle Service BusでのSAMLの使用」を参照してください。 |
Service Busでクライアントを認証するように要求するかまたはクライアントが提供する資格証明をそのまま認証のためにビジネス・サービスに渡すか。 |
Service Busでクライアントに認証を要求するときは、新たなセキュリティのレイヤーを追加します。通常、追加するセキュリティ・レイヤーが多いほど、ドメインの安全性が高くなります。 Service Busでユーザーを認証できるようにするには、Fusion Middleware Controlでユーザー・アカウントを作成する必要があります。ユーザーの集合が非常に大きい場合は、ユーザー・アカウントの大規模なデータベースを保守する価値があるかどうかを検討する必要があります。 |
X.509トークンまたはSAMLトークンを提供するクライアントをService Busで認証する場合は、どのService Busユーザーがトークンにマップされるか。 |
Service Busで認証するようにクライアントに要求し、特定の認証されたユーザーのみがプロキシ・サービスにアクセスできる(認可される)ように、デフォルトのアクセス制御ポリシーを変更することをお薦めします。 X.509証明書、SAMLトークンまたはユーザー名とパスワード以外の別のタイプの資格証明を提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。 |
カスタム認証トークンを提供するクライアントをService Busで認証する場合は、どのService Busユーザーがトークンにマップされるか。 |
Service Busで認証するようにクライアントに要求し、特定の認証されたユーザーのみがプロキシ・サービスにアクセスできるように、デフォルトのアクセス制御ポリシーを変更することをお薦めします。 ユーザー名とパスワード以外のカスタム認証トークンを提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。 |
ユーザー名とパスワード・トークンを提供するクライアントをService Busで認証する場合は、次の処理を行うかどうか。
|
「カスタム認証トークンの理解」の説明のように、カスタム・ユーザー名/パスワード・トークンが使用される場合、カスタム・トークンのユーザー名とパスワードをアウトバウンドHTTP基本認証またはアウトバウンドWS-Securityユーザー名トークン認証で使用できます(パススルー・サービス・アカウントが使用される場合)。 クライアントが提供するユーザー名とパスワードをビジネス・サービスに渡す場合、クライアントはビジネス・サービスが要求する資格証明を保守する責任があります。ビジネス・サービスがセキュリティ要件を変更する場合は、対応する変更を行うように各クライアントに通知する必要があります。 ビジネス・サービスが要件を頻繁に変更する可能性がある場合は、クライアントの提供する資格証明からビジネス・サービスの要求する資格証明へのマッピングについて検討します。ビジネス・サービスのクライアントが増えると、この資格証明マッピングを保守するために必要な作業が多くなります。 |
表47-2は、インバウンドおよびアウトバウンドのトランスポートレベルのセキュリティに対して適用できる要件のすべての組合せについての説明です。
表47-2 トランスポートレベルのセキュリティ要件の組合せ
| インバウンド要件 | 組合せ可能なアウトバウンド要件 | 構成方法 |
|---|---|---|
クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Service Busがクライアントを認証します。 |
クライアントの資格証明をHTTPヘッダーで渡します。 |
必ず パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。 |
前述の要件と同じです。 |
クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をHTTPヘッダーで渡します。 |
必ず ユーザーマッピング ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。 |
クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Service Busはクライアントを認証しません。 |
クライアントの資格証明をHTTPヘッダーで渡します。 |
必ず、HTTP基本認証またはHTTPS(一方向SSL、基本認証)でビジネス・サービスを構成します。 また、 パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付します。 |
クライアントがHTTPヘッダー内にカスタム認証トークンを提供します。Service Busはクライアントを認証します。 |
クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をHTTPヘッダーで渡します。 |
必ず ユーザーマッピング ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。 |
あらゆる形式のローカル認証(HTTPまたはHTTPSの基本、あるいは資格証明マッピングによるHTTPSクライアント証明書) |
クライアントの資格証明をEJB over RMIに渡します。EJBコンテナでユーザーを認証します。 |
パススルー・サービス・アカウントを作成し、そのアカウントをビジネス・サービスに添付します。「サービス・アカウントの操作」を参照してください。 |
表47-3は、インバウンドおよびアウトバウンドのメッセージレベルのセキュリティに対して適用できる要件のすべての組合せについての説明です。場合によっては、トランスポートレベルのセキュリティのインバウンド要件が、アウトバウンドのメッセージレベル・セキュリティに適用できる要件に影響します。
表47-3 メッセージレベルのセキュリティ要件の組合せ
| インバウンド要件 | 組合せ可能なアウトバウンド要件 | 構成方法 |
|---|---|---|
クライアントがHTTPヘッダー内にユーザー名とパスワードまたはカスタム認証トークンを提供し、Service Busがクライアントを認証します。 |
クライアントの資格証明をSOAPヘッダーで渡します。 |
|
前述の要件と同じです。 |
クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をSOAPヘッダーで渡します。 |
|
前述の要件と同じです。 |
クライアント資格証明をSAMLトークンにマップします。Service BusがユーザーIDアサーションを行います。 |
|
クライアントがメッセージ・ヘッダーまたはメッセージ本体内にユーザー名とパスワードまたはカスタム認証トークンを提供し、Service Busがクライアントを認証します。 |
クライアントの資格証明をSOAPヘッダーで渡します。 |
|
前述の要件と同じです。 |
クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をSOAPヘッダーで渡します。 |
|
前述の要件と同じです。 |
クライアント資格証明をSAMLトークンにマップします。Service BusがユーザーIDアサーションを行います。 |
|
クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Service Busはクライアントを認証しません。 |
クライアントの資格証明をSOAPヘッダーで渡します。 |
必ず、HTTP基本認証またはHTTPS(一方向SSL、基本認証)でビジネス・サービスを構成します。 また、 パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付します。 |
クライアントがHTTPSクライアント証明書認証(双方向SSL)の一部として証明書を提供し、Service Busがクライアントを認証します。 |
クライアント資格証明をSAMLトークンにマップします。Service BusがユーザーIDアサーションを行います。 |
|
アクティブな仲介プロキシ・サービスが、ユーザー名トークン・プロファイルによるWebサービス・セキュリティを強制します。 |
SOAPメッセージのユーザー名とパスワード・トークンとして資格証明をコード化します。 |
パスワード(パスワード・ダイジェストではない)を要求するWS-Policy文でアクティブな仲介プロキシ・サービスを作成します。「アクティブな仲介プロキシ・サービスの作成: 主な手順」を参照してください。 |
前述の要件と同じです。 |
SOAPメッセージのSAMLトークンとして資格証明をコード化します。 |
|
アクティブな仲介プロキシ・サービスが、X.509トークン・プロファイルによるWebサービス・セキュリティを強制します。 |
SOAPメッセージのSAMLトークンとして資格証明をコード化します。 |
|
アクティブな仲介プロキシ・サービスが、SAMLトークン・プロファイルによるWebサービス・セキュリティを強制します。 |
アウトバウンドSOAPメッセージに新しいSAMLトークンを生成します。 |
|
ユーザー名とパスワード、X.509トークン、またはSAMLトークンを渡すことができるパススルー・プロキシ・サービス。 |
ユーザー名トークン・プロファイル、X.509トークン・プロファイル、またはSAMLトークン・プロファイルを使用するビジネス・サービス。 |
|
インバウンドTuxedoリクエストの場合は、次のセキュリティ要件を構成できます。
Tuxedoサービスのアウトバウンド呼出しでクライアントの資格証明をコード化します。
ユーザー名トークンまたはSAMLトークンとしてアウトバウンドSOAPメッセージでクライアントの資格証明をコード化します。
クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をアウトバウンドHTTPヘッダーで渡します。
クライアントの資格証明を別のService Busユーザーにマップし、新しい資格証明をEJB over RMIに渡します。EJBコンテナでユーザーを認証します。
Service BusでのTuxedoの使用方法の詳細は、「Tuxedoトランスポートの使用」を参照してください。
即時利用可能な次のOWSMポリシーでは、サービス・アカウントの使用がサポートされます。
oracle/**_username_token_**_client_policy
oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy
oracle/**_saml*_**_client_policy (subject.precedenceプロパティはfalseに設定すること)
即時利用可能な次のOWSMポリシー・アサーションでは、サービス・アカウントがサポートされます。
oracle/**_username_token_**_client_template
oracle/**_saml*_**_client_template (subject.precedenceプロパティはfalseに設定すること)
図47-2に、Service Busを次のように構成したときの、Service Bus全体のユーザーIDの流れを示します。
リクエストでユーザー名とパスワードを提供するようにクライアントに要求する
トランスポート・レベル、メッセージ・レベル、または両方のレベルで資格証明を提供するようにWebサービス・クライアントに要求できます。両方のレベルで資格証明を提供するようにクライアントに要求する場合、Service BusはIDの伝播および資格証明マッピングに対してメッセージ・レベルの資格証明を使用します。
クライアントを認証する
この図は、インバウンド・リクエストで開始され、アウトバウンド・リクエストで終了します。
あるクライアントがプロキシ・サービスにリクエストを送信します。リクエストには、ユーザー名とパスワード資格証明が含まれます。
クライアントは、認証のためにX.509証明書、カスタム認証トークンなどの他のタイプのトークンを送信することもできます。X.509証明書、SAMLトークンまたはユーザー名とパスワード以外の別のタイプの資格証明を提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。
プロキシ・サービスは、ドメインの認証プロバイダ・ストアにそのユーザーが存在するかどうかをドメインの認証プロバイダに問い合せます。
ユーザーが存在する場合、プロキシ・サービス用に構成したアクセス制御ポリシーを評価するように、プロキシ・サービスがドメインの認可プロバイダに依頼します。
プロキシ・サービスのアクセス制御ポリシーによってユーザーのアクセスが許可されている場合、プロキシ・サービスはメッセージを処理します。ビジネス・サービスへのアウトバウンド・リクエスト生成の一部として、プロキシ・サービスは、ビジネス・サービスが要求するユーザー名とパスワードを提供するようにビジネス・サービスに依頼します。
ビジネス・サービスは、その資格証明のサービス・アカウントを問い合せます。サービス・アカウントの構成方法に応じて、次のいずれかの処理を行います。
特定の(静的な)ユーザー名とパスワードをコード化するようにプロキシ・サービスに要求します。
クライアントが提供するユーザー名とパスワードを渡すようにプロキシ・サービスに要求します。
認証プロバイダから返されたユーザー名を別の(リモート)ユーザー名にマップし、このリモート・ユーザー名をコード化するようにプロキシ・サービスに要求します。
プロキシ・サービスは、サービス・アカウントから返されたユーザー名とパスワードと共にアウトバウンド・リクエストを送信します。
プロキシ・サービスやビジネス・サービスの作成など、管理機能へのアクセスを保護するために、Service Busには、事前定義されたアクセス権限を持つセキュリティ・ロールが用意されています。
これらのロールの詳細は、『Oracle Service Busの管理』のOracle Service Busアプリケーション・セキュリティの理解に関する項を参照してください。
セキュリティ・ロールとは、実行時にユーザーやグループに動的に与えることができるIDです。これらの管理セキュリティ・ロールのアクセス権限は変更できませんが、それらのロールのいずれかにユーザーまたはグループを入れるための条件は変更できます。
Service Busのロールには、Service Busのリソースのみを変更する権限があります。WebLogic ServerまたはWebLogic Server上の他のリソースを変更する権限はありません。管理ユーザーをロールに割り当てるときは、最低1人のユーザーをWebLogic Server Adminロールに割り当てます。WebLogic Serverのセキュリティ・ロールについては、『Oracle Service Busの管理』のロールに関する項で説明されています。
アクセス制御によって、Service Busのリソースにアクセスするユーザーを決定します。アクセス制御ポリシーは、ユーザー、グループ、またはロールがプロキシ・サービスにアクセスできるようにするための条件を指定します。
たとえば、あるプロキシ・サービスへのアクセスを、GoldCustomerロールのユーザーには常に許可し、SilverCustomerロールのユーザーには平日の午後12時以降にのみ許可するというポリシーを作成することができます。
アクセス制御ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間の関連付けです。セキュリティ・ポリシーは、権限のないアクセスからWebLogicリソースを保護します。アクセス制御ポリシーは特定のリソースに割り当てられてたブール式です。リソースへのアクセスが試行されると、式が評価されます。式は、ロール(オペレータ)とアクセス時間(午前8時から午後5時)など、ブール演算子で結合された1つまたは複数の条件で構成されます。アクセス制御ポリシーの詳細は、『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基本に関する項を参照してください。
Service Busは、WebLogic Serverのセキュリティ・レルムを使用してそのリソースを保護します。各セキュリティ・レルムは、構成されたセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、および(アクセス制御)セキュリティ・ポリシーの集合から成ります。レルムに属するリソースにアクセスするには、『Oracle Service Busの管理』のOracle Service Bus管理セキュリティの構成に関する項に記述されているように、ユーザーにはそのレルムで定義されているセキュリティ・ロールが割り当てられている必要があります。ユーザーがService Busリソースへのアクセスを試みると、WebLogic Serverが関連するセキュリティ・レルムとセキュリティ・ポリシーをチェックして、ユーザーに割り当てられているセキュリティ・ロールを確認し、ユーザーを認証および認可します。
注意:
WebLogic Server管理者のみがFusion Middleware Controlでセキュリティ・ポリシーの定義またはセキュリティ・ロールの編集を実行できます。
すべてのプロキシ・サービスに対して、トランスポート・レベルのポリシーを作成することができます。トランスポート・レベルのポリシーでは、クライアントがプロキシ・サービスとの接続を確立しようとしたときにセキュリティ・チェックが適用されます。トランスポート・レベルのポリシーのリストに入っているユーザーからのリクエストだけが続行を許可されます。
WS-Securityのアクティブな仲介、またはメッセージ・レベルのカスタム認証を実装するプロキシ・サービスの場合は、メッセージ・レベルのポリシーを作成することもできます。このタイプのポリシーでは、保護されているいずれかの操作をクライアントが呼び出そうとしたときにセキュリティ・チェックが適用されます。メッセージ・レベルのポリシーのリストに入っているユーザーだけが、その操作を呼び出せます。
Fusion Middleware Controlでは、ユーザー、グループおよびロールのセキュリティを表示および構成できます。
すべてのプロキシ・サービスに対してトランスポート・レベルのアクセス制御を構成できます。また、WS-Securityのアクティブな仲介プロキシ・サービス、またはメッセージ・レベルのカスタム認証を実装するすべてのプロキシ・サービスに対して、メッセージ・レベルでアクセス制御を構成することもできます。アクセス制御を構成するには、トランスポート・レベルまたはメッセージ・レベル(あるいはその両方)でプロキシ・サービスにアクセス制御ポリシーを割り当てる必要があります。
すべてのプロキシ・サービスに対するデフォルトのトランスポート・レベルおよびメッセージ・レベルのアクセス制御ポリシーによって、すべてのリクエストにアクセスを許可します。アクセス制御ポリシーをプロキシ・サービスに割り当てて、それを保護する必要があります。
「Service Busクライアント・アクセス・セキュリティの構成」の説明に従って、トランスポートレベルおよびメッセージレベルのアクセス制御ポリシーを構成します。
アクセス制御ポリシーは認可プロバイダに保持されます。また、Service Busリポジトリにもこれらへの参照があります。
3.0以前のリリースの場合と同様に、アクセス制御ポリシーは、セッション外ではなく、Service Bus設計セッション内で管理されます。変更がセッション内で行われるため、他のリソースと同じように変更をコミットまたは破棄できます。
Oracle Service BusコンソールでACLを管理できますが、Service Busの外でもポリシーを変更できます。ただし、Service Busの外でポリシーを変更するとService Busの参照が期限切れになり、無効になる場合があります。
そのため、一貫した管理には、Service Busセッション外(認可プロバイダMBeansまたはサード・パーティの認可プロバイダ・ツールを使用)でACLを完全に管理するかまたはService Busセッション内でACLを完全に管理します。2つの方法を組み合せると、ポリシー表示の一貫性が失われる場合があります。
Service Busは、プロキシ・サービスのアクセス制御ポリシーのみを管理します。他のサーバー・リソース(JMSキュー、JNDIエントリ、EJB、アプリケーション、WebLogic Serverインスタンス、データ・ソースなど)のアクセス制御ポリシー管理は、Oracle WebLogic Server管理コンソールから管理する必要があります。
注意:
セッションでサービスのクローンを作成すると、ACLのクローンも作成されます。ユーザーがセッションをコミットすると、サービスのACLが認可プロバイダにコミットされます。そのため、サービスのクローンを作成するときは、クローンが元のACLと同じACLを持つようにするかどうかを決定する必要があります。同じACLを持たないようにする場合は、必ずクローンのACLを編集してください。
プロキシ・サービスを削除すると、Service Busが制御するリポジトリ、および適切な認可プロバイダから、プロキシにより参照されるすべてのACLが削除されます。
サービスを削除せずに、サービスに割り当てられているアクセス制御ポリシーを削除することもできます。手順は次のとおりです。
プロキシ・サービスの名前を適切に変更すると、すべてのポリシーが移動されます。サービスの名前の変更または移動は、Service Busセッション内でのみ行う必要があります。
操作の名前を変更すると、既存の操作が透過的に削除され、新しい操作が作成されます。
ただし、WSDLファイルを変更することで操作の名前が変更された場合、Service Busは、古い操作のポリシーを無効と見なし、Service Busリポジトリから参照を削除し、該当する認可プロバイダからポリシーを削除します。
この場合、Service Busは、古い操作が新しい操作に名前が変更されたことを認識せず、新しい操作には新しく追加を行いません。つまり、Service Busは、この新しい操作にはポリシーがないものとみなします。
新しい操作に、適切なポリシーを手動で追加する必要があります。これは、操作の名前の変更が完了した後に、名前変更と同じセッションで行えます。
Service Busセキュリティの初期構成タスクの多くでは、WebLogicセキュリティ・フレームワークの構成のためにOracle WebLogic Server管理コンソールで作業する必要があります。これらの初期タスクの後は、ほとんどのセキュリティ・タスクをOracle Service Busコンソールから実行できます。
Service Busに対してWebLogicセキュリティ・フレームワークを構成するには:
トランスポート・レベルのセキュリティの一部としてSSLの使用を計画している場合は、次の処理を行います。
Oracle WebLogic Server管理コンソールではIDと信頼を構成します。『Oracle WebLogic Serverセキュリティの管理』のIDと信頼の構成に関する項とドメイン間セキュリティ・サポートの重要事項に関する項を参照してください。
Oracle WebLogic Server管理コンソールでSSLを構成します。『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください
SSL構成に対して次のことを実行するようお薦めします。
双方向SSLを構成する場合は、「クライアント証明書をリクエスト(強制しない)」モードか、「クライアント証明書をリクエスト(強制する)」モードのいずれかを選択する必要があります。可能なかぎり、「クライアント証明書をリクエスト(強制する)」モードを選択することをお薦めします。詳細は、『Oracle WebLogic Serverセキュリティの理解』のSecure Sockets Layer (SSL)に関する項を参照してください。
本番環境では、「ホスト名の検証」が有効になっていることを確認します。『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項のホスト名の使用方法を参照してください。
Oracle WebLogic Server管理コンソールで、プロキシ・サービスがインバウンド・セキュリティに対して使用する認証プロバイダを構成します。
表47-4は、Service Busで通常構成する認証プロバイダについての説明です。構成できるすべての認証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの管理』のセキュリティ・プロバイダに関する項を参照してください。
表47-4 認証プロバイダ
| クライアントに提供を要求するもの | 構成 |
|---|---|
単純なユーザー名とパスワード |
WebLogic認証プロバイダ。Fusion Middleware Controlを使用して、アクセスを許可するクライアントのユーザー名とパスワードを入力します。 注意: 「認証プロバイダの構成」で説明されているように、すべてのWebLogic ServerおよびService Busの管理アカウントにデフォルトのWebLogic認証プロバイダを使用することをお薦めします。 『Oracle Service Busの管理』のOracle Service Busユーザーの作成に関する項を参照してください。 |
インバウンドHTTPSと双方向SSL認証用のX.509トークン |
次のすべてが含まれます。
|
インバウンドHTTPおよびメッセージ・レベル認証用のカスタム認証とユーザー名/パスワード・トークン |
トークン・タイプを検証できるIDアサーション・プロバイダ(ユーザー作成またはサードパーティ)。このプロバイダがトークンをサポートすることを確認してください。 |
インバウンドWebサービス・セキュリティX.509トークン認証用のX.509トークン |
プロキシ・サービスまたはビジネス・サービスのいずれかが抽象WS-Policy文を使用するWebサービスである場合は、次も構成する必要があります。
|
SAMLトークン |
次のすべてが含まれます。
|
必要に応じて、Oracle WebLogic Server管理コンソールで1つ以上のIDアサーション・プロバイダを構成して、サポートする必要があるトークン・タイプ(X.509トークン・タイプやカスタム・トークン・タイプなど)を処理します。構成できるすべてのIDアサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの管理』のセキュリティ・プロバイダに関する項を参照してください。
インバウンド・リクエストでWS-Securityデジタル署名を要求するプロキシ・サービスまたはビジネス・サービスの作成を計画している場合は、証明書レジストリ・プロバイダを有効にします。このプロバイダは、登録した証明書のリストに対してインバウンド証明書を検証する証明書パス・プロバイダです。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの証明書パス・プロバイダの構成に関する項を参照してください。
ユーザー名とパスワード・トークンをリクエストするようにメッセージ・レベルのセキュリティ(インバウンド・リクエストまたはアウトバウンド・リクエスト)を構成する場合、およびメッセージでクリア・テキスト・パスワードではなくパスワード・ダイジェストを提供する場合は、次の操作を行います。
Oracle WebLogic Server管理コンソールで、Service Busによって提供される2つのWebサービス・セキュリティ構成を探し、UsePasswordDigestプロパティの値をtrueに設定します。
Service Bus Webサービス・セキュリティ構成の名前は次のとおりです。
__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__
__SERVICE_BUS_OUTBOUND_WEB_SERVICE_SECURITY_MBEAN__
Webサービス・セキュリティ構成での値の設定の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSOAPメッセージでのパスワード・ダイジェストの使用に関する項を参照してください。
構成した各認証プロバイダに対し、Oracle WebLogic Server管理コンソールでパスワード・ダイジェストの有効化チェック・ボックスを選択します。
構成した各IDアサーション・プロバイダに対し、Oracle WebLogic Server管理コンソールでwsse:PasswordDigestをアクティブ・トークン・タイプの1つとして設定します。
サービス・キー・プロバイダ(アウトバウンド・リクエストで鍵と証明書のペアを渡します)の作成を計画している場合は、Oracle WebLogic Server管理コンソールを使用して、PKI資格証明マッピング・プロバイダを構成します。Service Busをホストする任意のWebLogic Serverドメインで、最大1つのPKI資格証明マッピング・プロバイダを構成できます。
PKI資格証明マッピング・プロバイダは、デジタル署名や暗号化(Webサービス・セキュリティ用)およびアウトバウンドSSL認証に使用できる鍵ペアにService Busサービス・キー・プロバイダをマップします。詳細は、『Oracle WebLogic Serverセキュリティの管理』のPKI資格証明マッピング・プロバイダの構成に関する項を参照してください。
PKI資格証明マッピング・プロバイダがキーストアで使用する鍵ペアを格納します。PKI資格証明マッピングは、WebLogic ServerのIDキーストアまたは別のキーストアに格納できます。各WebLogic Serverインスタンスがそれぞれ独自の各キー・ストア・コピーにアクセスするように構成します。PKI資格証明マッパーで参照されるすべてのエントリがすべてのキーストアに存在する必要があります(同じ別名を使用した同じエントリ)。WebLogic Serverでのキーストアの構成の詳細は、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。
注意:
Service Busドメインを作成すると、デフォルトでドメインにユーザー名/パスワード資格証明マッピング・プロバイダが含まれ、ユーザー名とパスワード用の資格証明マッピングが必要な場合に使用できます。このユーザー名/パスワード資格証明マッピング・プロバイダの他に、1つのPKI資格証明マッピング・プロバイダを追加できます。Service Busドメインは、最大1つのユーザー名/パスワード資格証明マッピング・プロバイダ、1つのPKI資格証明マッピング・プロバイダおよび複数のSAML資格証明マッピング・プロバイダを持つことができます。
セキュリティ監査を有効にする場合は、次の操作を行います。
Oracle WebLogic Server管理コンソールで監査プロバイダを構成します。Oracle WebLogic Serverセキュリティの管理のWebLogic監査プロバイダの構成を参照してください。
WS-Securityに関連したイベントの監査を有効にするには、各Service Busサーバーの起動時に、サーバーの起動コマンドで次のJavaオプションを指定します。
-Dcom.bea.wli.sb.security.AuditWebServiceSecurityErrors=true
Service Busはセキュリティ・イベントの監査をサポートしますが、構成監査をサポートしません。構成監査では、ユーザーがドメイン内のリソースの構成を変更したり、ドメイン内のリソースに対して管理操作を呼び出したりすると、ログ・メッセージが出されて監査イベントが生成されます。Oracle WebLogic Serverセキュリティの管理の構成監査の有効化を参照してください。
まだ実行していない場合は、Oracle WebLogic Server管理コンソールで変更をアクティブ化します。WebLogic Serverの再起動が必要になる変更を行った場合は、Administration Consoleに再起動が必要であることが表示されます。このようなメッセージが表示された場合は、Service BusをホストするすべてのWebLogic Serverインスタンスを再起動して、セキュリティ・プロバイダに対する変更が残りの構成手順に対して有効になるようにします。
コンテキスト・プロパティは、WebLogicセキュリティ・フレームワークに追加情報を提供する手段(ContextHandlerインタフェース)として使用でき、特定のプロバイダ・メソッドに対して引数で渡される以上のコンテキスト依存の情報をセキュリティ・プロバイダが取得できるようになります。
ContextHandlerは、コンテキストとコンテナ固有の追加情報を取得する高パフォーマンスのWebLogicクラスです。
Service Busは、ContextHandlerインタフェースを利用して、トランスポート・レベルとメッセージ・レベルの認証、トランスポート・レベルとメッセージ・レベルのアクセス制御および資格証明マッピング用にセキュリティ・フレームワークにいくつかのコンテキスト・プロパティを渡します。
この項では、Service Bus固有のコンテキスト・プロパティが使用される状況について説明します。
HTTPプロキシ・サービスで認証が構成されている場合、HTTPトランスポート・プロバイダはWebLogic Server ContextHandlerのService Bus実装を渡します。この機能ではユーザーの構成は必要ありません。
以下の条件で、実行時に表47-5のContextHandlerプロパティが渡されます。
プロキシでHTTP基本認証が構成されている場合、認証プロバイダに渡されます。
プロキシでクライアント証明書IDアサーションが構成されている場合、IDアサーション・プロバイダに渡されます。
プロキシでHTTPカスタム・トークンIDアサーションが構成されている場合、IDアサーション・プロバイダに渡されます。
表47-5 HTTP転送認証用のContextHandlerプロパティ
| プロパティ名 | タイプ | プロパティ値 |
|---|---|---|
com.bea.contextelement.alsb.service-info |
com.bea.wli.sb.services.ServiceInfo |
プロキシ・サービスに関する情報が含まれる |
com.bea.contextelement.alsb.transport.endpoint |
com.bea.wli.sb.transports.TransportEndPoint |
HTTPまたはHTTPSエンドポイント。 |
com.bea.contextelement.alsb.transport.http.http-request |
javax.servlet.http.HttpServletRequest |
|
com.bea.contextelement.alsb.transport.http.http-response |
javax.servlet.http.HttpServletResponse |
|
アクセス制御およびメッセージ・レベルのカスタム認証用のContextHandlerプロパティは、次の条件で実行時に渡されます。
メッセージ・レベルのカスタム・ユーザー名/パスワード認証を実行する場合、認証プロバイダに渡されます。
メッセージ・レベルのカスタム・トークンIDアサーションを実行する場合、IDアサーション・プロバイダに渡されます。
トランスポート・レベルまたはメッセージ・レベルのアクセス制御を実行する場合、認可プロバイダに渡されます。
表47-6 カスタム認証およびアクセス制御用のContextHandlerプロパティ
| プロパティ名 | タイプ | プロパティ値 |
|---|---|---|
com.bea.contextelement.alsb.router.ProxyService |
java.lang.String |
サービス名(完全な名前。 |
com.bea.contextelement.alsb.router.ServiceUri |
java.net.URI |
メッセージの受信元のベースURI。 |
com.bea.contextelement.alsb.router.inbound.TransportProvider |
java.lang.String |
このメッセージを受信したトランスポート・プロバイダのID。 |
com.bea.contextelement.alsb.router.inbound.request.MessageId |
java.lang.String |
トランスポート・プロバイダ固有のメッセージIDです。理想としては、Service Busランタイムを通過するその他のメッセージ間でメッセージを一意に識別できる必要があります。ただし、Service Busは、メッセージIDがユニークであることには依存しません。メッセージIDはメッセージ・コンテキストに追加されるため、パイプラインに示されます。 |
com.bea.contextelement.alsb.router.inbound.request.CharacterEncoding |
java.lang.String |
メッセージ・ペイロードで使用される文字エンコーディング、またはnull。 |
com.bea.contextelement.wli.Message |
java.io.InputStream |
入力ストリームとしてのリクエスト・メッセージ。 |
表47-7に示されているプロパティに加えて、トランスポート固有のその他のプロパティが存在する場合があります。トランスポート・リクエスト・ヘッダー(トランスポートSDKを参照)ごとに、次の名前を持つプロパティが存在します。
com.bea.contextelement.alsb.router.inbound.request.headers.
<provider-id>.<header-name>
ここで、provider-idはトランスポート・プロバイダのID、header-nameはプロバイダのスキーマ・ファイルで宣言されているリクエスト・ヘッダーの1つです。これらのプロパティの型およびセマンティクスはトランスポート固有です。HTTPプロキシ・サービスの場合、表47-3に示すメッセージ・レベルのセキュリティ・プロパティも使用できます。
表47-7 HTTPプロキシ・サービスのその他のContextHandlerプロパティ
| プロパティ名 | タイプ | プロパティ値 |
|---|---|---|
com.bea.contextelement.alsb.router.inbound.request.metadata.http.relative-URI |
java.lang.String |
リクエストの相対URI。 |
com.bea.contextelement.alsb.router.inbound.request.metadata.http.query-string |
java.lang.String |
リクエストURLでパスの後に含まれる問合せ文字列。 |
com.bea.contextelement.alsb.router.inbound.request.metadata.http.client-host |
java.lang.String |
リクエストを送信するクライアントの完全修飾名。 |
com.bea.contextelement.alsb.router.inbound.request.metadata.http.client-address |
java.lang.String |
リクエストを送信するクライアントのIP (Internet Protocol)アドレス。 |
カスタム・ユーザー名/パスワード認証とカスタム・トークン認証の両方を使用すると、ユーザー(IntegrationAdminロールまたはIntegrationDeployerロールを持つユーザー)は「セキュリティ」タブの「コンテキスト・プロパティ」フィールドで追加のコンテキスト情報をセキュリティ・プロバイダに渡すことができます。
追加のコンテキスト・プロパティを構成するには、「プロパティ名」をリテラル文字列で入力し、「値セレクタ」に有効なXPath式を入力します(XPath式にリテラル文字列を使用することも可能です)。
XPath式は、カスタム・トークンまたはカスタム・ユーザー名/パスワードで使用されているのと同じメッセージ部に対して実行時に評価されます。つまり、「値セレクタ」のXPath式は、SOAPベースのプロキシ・サービスの場合はヘッダーに対して評価され、非SOAPベースのプロキシ・サービスの場合は本体に対して評価されます。
ContextHandlerは名前と値のリストであるため、セキュリティ・プロバイダが検索対象の名前を認識している必要があります。したがって、トランスポート・レベルおよびメッセージ・レベルのカスタム認証でXPath式が評価されるのは、認証プロバイダまたはIDアサーション・プロバイダがいずれかのプロパティの値を要求する場合のみです。
つまり、構成された認証プロバイダまたはIDアサーション・プロバイダは、ContextHandler.getValue(propertyName)メソッドでリクエストするプロパティ名を明確に知っている必要があります。この要件に対応する唯一の方法は、ユーザーまたはサード・パーティがカスタム認証プロバイダまたはIDアサーション・プロバイダを記述することです。
次の例は、記述するプロバイダからHttpServletRequestプロパティを取得する方法を示しています。
例 - HttpServletRequestプロパティの取得
:
Object requestValue = handler.getValue("com.bea.contextelement.alsb.transport.http.http-request");
if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest)))
return;
HttpServletRequest request = (HttpServletRequest) requestValue;
log.println(" " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod());
log.println(" " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL());
log.println(" " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI());
return;
セキュリティ・プロバイダがユーザー定義プロパティの値を必要としない場合、XPath式は評価されません。
このリリースのService Busでは、WebLogic Server管理チャネルを使用できます。
『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項で説明されているように、WebLogic Serverネットワーク・チャネルは、WebLogic Serverへのネットワーク接続の属性を定義する構成可能なリソースです。
管理チャネルと呼ばれる特定の種類のネットワーク・チャネルを構成して、WebLogicドメインで管理トラフィックとアプリケーション(ビジネス)トラフィックを分離することができます。管理チャネルは、SSL接続のみを受け入れる、セキュリティで保護されたチャネルです。
Service Busでは、ビジネス・トラフィックは、Service Busのプロキシ・サービスおよびビジネス・サービスで送受信されるすべてのメッセージで構成されています。SSLビジネス・トラフィックは、デフォルトのWebLogic Serverセキュア・ネットワーク・チャネルを使用する必要があります。
管理トラフィックは、Oracle WebLogic Server管理コンソール、Oracle Service Busコンソールとのすべての通信、クラスタ内の内部トラフィックおよび管理スクリプトと管理サーバーまたは管理対象サーバーとの間のトラフィックで構成されています。
ドメインで管理チャネルが有効になっている場合、そのドメイン内のすべての管理トラフィックがそのチャネルを通過します。それ以外の場合、管理トラフィックは、デフォルトのWebLogic Serverセキュア・ネットワーク・チャネルも使用します。
「管理チャネルの使用:主な手順」では、管理チャネルの使用について説明します。
ここでは、Service Busでのセキュリティ・プロバイダの使用方法について説明します。
この項の内容は次のとおりです。
提供されるWebLogic Server認証プロバイダを調べて、ニーズに合うものがないか確認してください。WebLogic Serverには、次のようなさまざまな認証プロバイダが含まれます。
WebLogic認証プロバイダは、WebLogic Serverの埋め込まれたLDAPサーバーにあるユーザーとグループ情報にアクセスする。これは即時利用可能なデフォルトの認証プロバイダです。このプロバイダは、非常に多くのユーザーでの使用には最適化されていません。
LDAP認証プロバイダでは、外部のLDAPストアにアクセスします。LDAP認証プロバイダを使用すると、任意のLDAPサーバーにアクセスできます。WebLogic Serverには、Open LDAP、Oracle Directory Server Enterprise Edition、Microsoft Active DirectoryおよびNovell NDS LDAPサーバー用のLDAP認証プロバイダがすでに構成されています。
RDBMS認証プロバイダでは、外部リレーショナル・データベースにアクセスします。WebLogic Serverには、SQL認証プロバイダ、読取り専用SQL認証プロバイダ、カスタムRDBMS認証プロバイダという3種類のRDBMS認証プロバイダが用意されています。
SAML認証プロバイダ - Security Assertion Markup Language 1.1 (SAML)アサーションに基づいてユーザーを認証します。
これらの認証プロバイダのパフォーマンスを向上させる方法は、『Oracle WebLogic Serverセキュリティの管理』のWebLogicおよびLDAP認証プロバイダのパフォーマンスの向上に関する項を参照してください。
Oracle WebLogic Serverセキュリティの管理のデフォルト・セキュリティ構成をカスタマイズする理由に関する項で説明されているように、WebLogic Serverの組込みのLDAPサーバー以外のデータベースにアクセスする認証プロバイダを使用することもできます。たとえば、大多数のユーザー・アカウントに別の認証プロバイダを使用し、Service BusおよびWebLogic Serverの管理ユーザー・アカウントにはデフォルトの認証プロバイダ(組込みのLDAP)を引続き使用できます。
すべてのWebLogic ServerおよびService Busの管理ユーザー・アカウントにWebLogic認証プロバイダを使用することで、ネットワークまたはデータベースに問題が発生した場合に、信頼性の高いアクセスが提供されます。そのため、すべてのWebLogic ServerおよびService Busの管理ユーザー・アカウントにデフォルトのWebLogic認証プロバイダを使用することをお薦めします。
組込みの認証プロバイダのいずれかがニーズに合う場合は、その認証プロバイダをOracle WebLogic Server管理コンソールで構成する手順を『Oracle WebLogic Serverセキュリティの管理』の認証プロバイダの構成に関する項で参照してください。
WebLogic Serverに組み込まれている認証プロバイダがニーズに合わない場合は、まずユーザー自身(またはサード・パーティ)がカスタム認証プロバイダを作成し、次の手順に従い、Oracle WebLogic Server管理コンソールを使用してそのプロバイダをセキュリティ・レルムに追加する必要があります。
注意:
ここでは、必要なタスクの概要についてのみ説明します。実際にタスクを実行するにはWebLogic Serverドキュメントを調べる必要があります。
セキュリティ・レルムにプロバイダを追加するには:
カスタム認可プロバイダでService Busリソースを使用できますが、これらのプロバイダがService Busリソースのタイプや形式を認識する必要があります。
Service Busには、認可プロバイダが検出して処理できる必要があるリソース・オブジェクトが3つあります。
これらのリソース・オブジェクトについては、この後の項で説明します。
この項では、WebLogic Server認証プロバイダSSPIについて簡単に説明します。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の認可プロバイダに関する項を参照してください。
リソースを保護するには、Oracle Service Busコンソール、サードパーティ・ツールまたはスクリプトを使用して、アクセス制御ポリシーをリソースにバインドします。WebLogic Server SSPI (Security Service Provider Interface)では、リソースSPIを実装するためにService Busなどのコンテナが必要です。これらの実装は具象リソースを表します。
認可プロバイダ・データベースには、リソースからポリシーへのマップがあります。リソースへのアクセスが試みられると、コンテナは実行時SSPIを呼び出してアクセス制御の判断を行います。コンテナは、アクセスされるリソースを示すリソース・インスタンスを渡します。
認可プロバイダにはgetAccessDecision()という1つのメソッドがあります。getAccessDecision()メソッドは、AccessDecision SSPIの実装を取得します。AccessDecision SSPIそのものにはisAccessAllowed()という1つのメソッドがあります。isAccessAllowedには5つのパラメータがあり、その1つはリクエストされるアクセスに対するResourceオブジェクトです。
isAccessAllowedは、指定のリソースへのアクセスがリクエスト側に許可されるかどうか判断します。これを実行するには、認可プロバイダが評価のために正しいアクセス制御ポリシーを見つける必要があります。プロバイダは、渡されたリソースにバインドされたポリシーをまず検索する必要があります。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のセキュリティ・プロバイダのランタイム・クラスでのWebLogicリソースのルックアップに関する項で説明されるように、検索では検索のキーとしてgetId()メソッドまたはtoString()メソッドを使用できます。ポリシーが見つからない場合、認可プロバイダは親リソースを取得し、再検索する必要があります。このプロセスは、ポリシーが見つかるか、親がnullになるまで繰り返されます。この場合、ポリシーは見つかりません。ポリシーが見つからない場合、isAccessAllowedはfalseを返す必要があります。
このアルゴリズムによって、指定のプロジェクトまたはフォルダ内のすべてのプロキシ・サービス、プロジェクト内のすべてのリソースまたはService Busドメイン内のすべてのService Busプロキシ・サービスを保護する、大まかなポリシーを作成できます。より具体的で詳細なポリシーは、大まかなポリシーより優先されます。
注意:
Oracle Service Busコンソール・ユーザー・インタフェースには、フォルダ、プロジェクトまたはドメイン・レベルでプロキシ・サービスを保護するページは用意されていません。
ALSBProxyServiceResourceオブジェクトは、Service Busプロキシ・サービスへのトランスポート・レベルとメッセージ・レベルのアクセス制御で使用します。ALSBProxyServiceResourceリソースは、weblogic.security.spi.Resourceを実装しているweblogic.security.service.ResourceBaseを拡張します。
ALSBProxyServiceResourceは、weblogic.security.spi.Resourceに記述されるように、次のメソッドを実装しています。
getType() - タイプを返します。ここでは、タイプは<alsb-proxy-service>です。
getKeys() - 最大4つのキーと値のプロパティであるpath、proxy、actionおよびoperationを返します。プロパティは次のように定義されます。
pathはプロキシ・サービスの完全名。たとえば、path=project/folder1/folder2です。
proxyはプロキシ・サービスの名前。たとえば、proxy=myProxyです
actionは、invokeまたはwss-invokeという2つの値のいずれかです。たとえば、action=invokeです
action属性は、トランスポートレベルとメッセージレベルのアクセス制御を区別するために使用されます。invokeは、トランスポートレベルのアクセス制御で使用されます。wss-invokeはメッセージレベルのアクセス制御(つまり、カスタムのメッセージレベル認証を含む、WS-Securityのアクティブな仲介またはプロキシに対するアクセス制御)で使用されます。operation属性は、actionがwss-invokeの場合のみ使用できます。
operationは呼び出す操作の名前で、actionがwss-invokeの場合のみ使用されます。たとえば、operation=processPOです。operation属性は、actionがwss-invokeの場合のみ有効です。
ALSBProxyServiceResourceには1から4個のキーがあります。次の表は、プロキシ・サービスを保護する様々な組合せについての説明です。最も具体的なポリシーが優先されます。
| リソースに含まれるキー | リソースにバインドされたポリシーの保護対象 |
|---|---|
path |
ポリシーは指定のパスにあるすべてのプロキシ・サービスを保護します |
pathおよびproxy |
ポリシーは指定のプロキシ・サービスへのすべてのアクセスを保護します(トランスポート・レベルおよびメッセージ・レベル) |
path、proxy、およびaction |
action="invoke"の場合 ポリシーは指定のプロキシのトランスポート・レベルのポリシー action="wss-invoke"の場合 ポリシーは指定のプロキシのメッセージ・レベルのポリシー(すべての操作) |
path、proxy、action="wss-invoke"、およびoperation |
ポリシーは指定のプロキシと操作に対するメッセージ・レベルのポリシー |
getPath() - プロキシ・サービスへのパス(プロジェクトとフォルダ)を取得します。これは、Service Busの構成フレームワーク内でプロキシ・サービスが存在するパスです。
getProxyServiceName() - プロキシ・サービス名を取得します。たとえば、proxy=myProxyです。
getAction() - invokeまたはwss-invokeという2つの値のどちらかを取得します。たとえば、action=invokeです。
getOperation() - 呼び出す操作の名前を取得します。actionがwss-invokeの場合のみ使用します。たとえば、operation=processPOです。
makeParent() - 現在のALSBProxyServiceResourceリソースの親を表す新しいALSBProxyServiceResourceオブジェクトを作成します。makeParent()はプロキシ・サービスのパスを使用して親を作成します。
次の例は、ALSBProxyServiceResourceオブジェクトの様々な使用方法です。
プロキシproject/folder/myProxyでのトランスポート・レベルのアクセス制御に対するALSBProxyServiceResourceの使用
type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=invoke
プロキシproject/folder/myProxyでの操作processPOのメッセージレベルのアクセス制御に対するALSBProxyServiceResourceの使用
type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=wss-invoke, operation=processPO
ALSBProxyServiceResourceに対する様々な詳細度の親子階層の使用
type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke, operation=foo type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy type=<alsb-proxy-service>, path=myProject/f1/f2 type=<alsb-proxy-service>, path=myProject/f1 type=<alsb-proxy-service>, path=myProject type=<alsb-project>, project-name=myProject type=<alsb-proxy-service>
ProjectResourceV2は、指定のプロジェクトに含まれるすべてのALSBProxyServiceResourceオブジェクトのルート・リソースです。ProjectResourceV2はResourceBaseを拡張します。
ProjectResourceV2に対するアクセス制御ポリシーの設定によって、指定のプロジェクトでさらに具体的なポリシーを持たないすべてのプロキシ・サービスに対して、大まかなアクセス制御ポリシーが提供されます。
ProjectResourceV2には次のメソッドがあります。
getType() - タイプを返します。ここでは、タイプは"<alsb-project>"です。
getKeys() - キーを返します。ここで、キーは"project-name"です。
getName() - ProjectResourceV2オブジェクトの名前を取得します。
makeParent() - ProjectResourceV2オブジェクトには、親はありません。したがって、このメソッドは、ProjectResourceV2オブジェクトの作成に使用されたオブジェクト名を返すか、またはProjectResourceV2が存在しない場合はnullを返します。
com.bea.wli.security.resource.ConsoleResourceオブジェクトは、Oracle Service Busコンソールへのアクセス制御で使用します。ただし、ConsoleResourceオブジェクト用のアクセス制御ポリシーを、カスタム認証プロバイダを使用して設定しないことをお薦めします。これは、これらのポリシーが今後のService Busリリースで変更される可能性があるためです。
代わりに、カスタム認証プロバイダを使用する必要がある場合でも、WebLogic Server XACML認証プロバイダの使用を継続して、ConsoleResourceオブジェクト用のポリシーを管理することをお勧めします。このように2つの認可プロバイダを使用する場合は、裁決プロバイダも構成する必要があります。
WebLogic Serverでプラグイン・セキュリティ・プロバイダを使用して、Service Busで使用するためのポリシーを格納する場合、Service Busでは必要なポリシーを利用できるかどうかを判断できないことを伝えるエラーが生じる場合があります。
このようなエラー・メッセージが表示されても、ポリシーが存在しないことや、セキュリティ・プロバイダの接続上または構成上の問題が発生したことを意味するとはかぎりません。Service Busでは、WebLogic Server SSPIを使用して、セキュリティ・プロバイダが実装できるポリシーを読み取ります。ただし、SSPIの読取り機能はオプションです。セキュリティ・プロバイダでこのSSPIを実装せずに読取りアクセスを許可しないことも可能です。このような場合、Service Busでは、必要なポリシーがセキュリティ・プロバイダに実際に存在していても、必要なポリシーがセキュリティ・プロバイダに含まれているかどうかを確実に判断できません。
このような警告が本当の問題を示しているかどうかを判断するには、Oracle Service Busコンソールでリソースの作成または変更を試みます。また、アクセス制御ポリシーでプロキシ・サービスを保護し、テストします。プロキシ・サービスに対するアクセス制御ポリシーの構成の詳細は、「Service Busクライアント・アクセス・セキュリティの構成」を参照してください。セキュリティ・プロバイダを使用しながら、リソースの作成または操作、およびセキュアなプロキシ・サービスのテストに成功した場合、そのセキュリティ・プロバイダは正しく構成されており、エラー・メッセージは無視しても問題ありません。
