| Oracle® Fusion Middleware Oracle Service Bus開発者ガイド 11gリリース1 (11.1.1.7) B61435-08 |
|
 前 |
 次 |
この章では、Oracle Service Busのセキュリティ・モデルの概要とその機能(インバウンド・セキュリティおよびアウトバウンド・セキュリティを含む)について説明します。
Oracle Service Busでは、通信の整合性とプライバシを保証し、認可されたユーザーだけがOracle Service Busドメインのリソースにアクセスできるようにするために、オープンな業界標準をサポートしています。また、セキュリティ・サービスの構成要素として、基になっているWebLogicセキュリティ・フレームワークを使用します。
Oracle WebLogicセキュリティ・フレームワークでは、ドメインを保護するための作業が認証、認可、資格証明マッピング、監査などの複数のコンポーネント(プロバイダ)に分かれています。特定のOracle Service Busドメインに対して、必要なプロバイダのみを構成します。
この章の内容は次のとおりです。
インバウンド・セキュリティによって、Oracle Service Busプロキシ・サービスは認可されたクライアントから出されたリクエストのみを処理できます(デフォルトでは、すべての匿名ユーザーまたは認証ユーザーがプロキシ・サービスに接続できます)。また、クライアントからデータが送信されたときに、認可されていないユーザーがそのデータを参照または変更していないことが保証されます。
プロキシ・サービスは、サービス・コンシューマと他のプロキシ・サービスという2つのタイプのクライアントを持つことができます。図45-1に、プロキシ・サービスとそのクライアント間の通信がインバウンド・セキュリティによって保護され、一方プロキシ・サービスとビジネス・サービス間の通信がアウトバウンド・セキュリティによって保護されることを示します。
インバウンド・セキュリティはプロキシ・サービスの作成時に設定し、ニーズの変化に応じて変更できます。外向きのプロキシ・サービス(サービス・コンシューマからリクエストを受信します)の場合は、双方向SSL over HTTPSなどの厳密なセキュリティ要件の設定を検討します。他のOracle Service Busプロキシ・サービスからのみリクエストを受信することが保証されているプロキシ・サービスの場合は、これよりセキュリティの低いプロトコルを使用できます。
プロキシ・サービスで、デジタル署名、暗号化、またはSSL認証に対して公開鍵インフラストラクチャ(PKI)テクノロジを使用する場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成します。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス・キー・プロバイダに関する項を参照してください。
各プロキシ・サービスに対し、次のインバウンド・セキュリティ・チェックを構成できます。
トランスポートレベルのセキュリティは、クライアントとプロキシ・サービス間の接続確立の一部としてセキュリティ・チェックを適用します。トランスポートレベルのセキュリティによって適用できるセキュリティ要件は、プロキシ・サービスで使用するように構成するプロトコルによって異なります。
たとえば、HTTPプロトコル経由で通信するプロキシ・サービスの場合、Oracle Service Bus管理コンソールの「セキュリティ構成」モジュールで作成したユーザーのデータベースに対してすべてのクライアントが認証するように要求できます。次に、認証されたユーザーに対してプロキシ・サービスへのアクセスを認可する条件を指定するためのアクセス制御ポリシーを作成します。
Oracle Service Busは、トランスポート・レベルのインバウンド・リクエストでクライアント指定のカスタム認証トークンをサポートします。
サポートされる各プロトコルに対するトランスポートレベルのセキュリティの構成は、第49章「トランスポートレベルのセキュリティの構成」を参照してください。
メッセージレベルのセキュリティでのカスタム認証。Oracle Service Busは、トランスポートレベルおよびメッセージレベルのインバウンド・リクエストでクライアント指定のカスタム認証資格証明をサポートします。カスタム認証の資格証明は、カスタム・トークン、またはユーザー名とパスワードの形式になります。
カスタム認証によるトランスポートレベルおよびメッセージレベルのセキュリティの構成は、第54章「カスタム認証の構成」を参照してください。
メッセージレベルのセキュリティ(Webサービスであるプロキシ・サービス用)は、WS-Security仕様の一部です。メッセージレベルのセキュリティでは、SOAPメッセージまたはSOAPメッセージの特定の部分を処理する前にセキュリティ・チェックを適用します。
メッセージ・レベルでのセキュリティの構成部分は、Webサービスと関連付けられたWSDLドキュメントおよびWS-Policyドキュメントに埋め込むことができます。これらのドキュメントでは、SOAPメッセージをデジタル署名したり暗号化したりする必要があるかどうか、および認可されたユーザーのみが呼び出すことができるWebサービスの操作を指定します。
WS-Policyをサービスにバインドする別の方法もあります。「WS-Policy」ページを使用して、ポリシーをサービス全体、サービスの個々の操作、または個々の操作のリクエスト・メッセージあるいはレスポンス・メッセージにバインドできます。
プロキシ・サービスまたはビジネス・サービスがWS-Policy文を使用して1つ以上の操作へのアクセスを保護する場合、および(パススルー・サービスとは対照的に)アクティブな仲介としてサービスを構成する場合は、Oracle Service Bus管理コンソールを使用してメッセージ・レベルのアクセス制御ポリシーを作成します。ポリシーでは、保護された操作を呼び出すためにユーザー、グループ、またはセキュリティ・ロールを認可する条件を指定します。
メッセージレベルでのセキュリティの構成の詳細は、第52章「Webサービスのメッセージレベルでのセキュリティの構成」を参照してください。
アウトバウンド・セキュリティは、プロキシ・サービスとビジネス・サービス間の通信を保護します。アウトバウンド・セキュリティのために行うタスクのほとんどは、ビジネス・サービスで指定されるトランスポート・レベルまたはメッセージ・レベルのセキュリティ要件に準拠するためのプロキシ・サービスの構成のためのものです。
たとえば、ビジネス・サービスでユーザー名とパスワード・トークンが必要な場合は、サービス・アカウントを作成します。このサービス・アカウントは、ユーザー名とパスワードを直接含み、アウトバウンド・リクエストに含まれていたユーザー名とパスワードを渡すか、またはアウトバウンド・リクエストに含まれていたユーザー名に応じてユーザー名とパスワードを提供します。詳細は、2.1.15項「サービス・アカウント・リソースの作成」を参照してください。
ビジネス・サービスでデジタル署名またはSSL認証のためにPKIテクノロジを使用する必要がある場合は、証明書とペアの秘密鍵を提供するサービス・キー・プロバイダを作成します。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス・キー・プロバイダに関する項を参照してください。
Oracle Service Busのセキュリティの設計時に決定する必要がある主な項目の1つは、クライアントが提供するIDの処理(伝播)方法です。Oracle Service Busの構成によって、次のことを実行できます。
クライアントが提供する資格証明を認証します。
認可チェックを実行します。
クライアント資格証明を変更せずにビジネス・サービスに渡します。
ビジネス・サービスが認証および認可できる別の資格証明にクライアント資格証明をマップします。
セキュリティ・テクノロジ間を橋渡しします。
表45-1は、Oracle Service BusがクライアントIDをビジネス・サービスに伝播する方法に影響するオプションについての説明です。
表45-1 IDの伝播のオプション
| オプション | 説明 |
|---|---|
|
クライアントが提供する必要があるのはどのタイプの資格証明か。 |
トランスポート・レベルのセキュリティの場合、Oracle Service Busは既存のセキュリティ要件に合わせます。Oracle Service Busのクライアントは、ユーザー名とパスワード・トークン、SSL証明書、または構成したIDアサーション・プロバイダによってサポートされる他のタイプのカスタム認証トークンを提供できます。 メッセージレベルのセキュリティの場合、Oracle Service Busではユーザー名トークン、X.509トークン、構成した認証プロバイダまたはIDアサーション・プロバイダによってサポートされるその他のカスタム認証トークン、およびSAMLトークン・プロファイルをサポートします(45.9項「セキュリティ・プロバイダの使用」を参照)。 Webサービス・セキュリティを使用する新しいビジネス・サービス用のセキュリティ要件を確立する場合は、SAMLトークンを提供するようクライアントに要求することを推奨します。SAMLは、Webサービス内でユーザーIDを伝播するための新しい標準です。第53章「Oracle Service BusでのSAMLの使用」を参照してください。 |
|
Oracle Service Busでクライアントを認証するように要求するか、またはクライアントが提供する資格証明をそのまま認証のためにビジネス・サービスに渡すか。 |
Oracle Service Busでクライアントに認証を要求するときは、新たなセキュリティのレイヤーを追加します。通常、追加するセキュリティ・レイヤーが多いほど、ドメインの安全性が高くなります。 Oracle Service Busでユーザーを認証するには、Oracle Service Bus管理コンソールでユーザー・アカウントを作成する必要があります。ユーザーの集合が非常に大きい場合は、Oracle Service Bus管理コンソールでユーザー・アカウントの大規模なデータベースを保守するだけの価値があるかどうかを検討する必要があります。 |
|
X.509トークンまたはSAMLトークンを提供するクライアントをOracle Service Busで認証する場合は、どのOracle Service Busユーザーがトークンにマップされるか。 |
Oracle Service Busで認証するようにクライアントに要求し、特定の認証されたユーザーのみがプロキシ・サービスにアクセスできるように、デフォルトのアクセス制御ポリシーを変更することを推奨します。 X.509証明書、SAMLトークン、またはユーザー名とパスワード以外の別のタイプの資格証明を提供するクライアントの認証と認可を行うには、クライアントの資格証明をOracle Service BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Oracle Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。 |
|
カスタム認証トークンを提供するクライアントをOracle Service Busで認証する場合は、どのOracle Service Busユーザーがトークンにマップされるか。 |
Oracle Service Busで認証するようにクライアントに要求し、特定の認証されたユーザーのみがプロキシ・サービスにアクセスできるように、デフォルトのアクセス制御ポリシーを変更することを推奨します。 ユーザー名とパスワード以外のカスタム認証トークンを提供するクライアントの認証と認可を行うには、クライアントの資格証明をOracle Service BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Oracle Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。 |
|
ユーザー名とパスワード・トークンを提供するクライアントをOracle Service Busで認証する場合は、次の処理を行うかどうか。
|
54.1項「カスタム認証トークンとは」の説明のように、カスタム・ユーザー名/パスワード・トークンが使用されると場合、カスタム・トークンのユーザー名とパスワードをアウトバウンドHTTP BASICまたはアウトバウンドWS-Security Username Token認証で使用できます(パススルー・サービス・アカウントが使用される場合)。 クライアントが提供するユーザー名とパスワードをビジネス・サービスに渡す場合、クライアントはビジネス・サービスが要求する資格証明を保守する責任があります。ビジネス・サービスがセキュリティ要件を変更する場合は、対応する変更を行うように各クライアントに通知する必要があります。 ビジネス・サービスが要件を頻繁に変更する可能性がある場合は、クライアントの提供する資格証明からビジネス・サービスの要求する資格証明へのマッピングについて検討します。ビジネス・サービスのクライアントが増えると、この資格証明マッピングを保守するために必要な作業が多くなります。 |
表45-2は、インバウンドおよびアウトバウンドのトランスポートレベルのセキュリティに対して適用できる要件のすべての組合せについての説明です。
表45-2 トランスポートレベルのセキュリティ要件の組合せ
| インバウンド要件 | 組合せ可能なアウトバウンド要件 | 構成方法 |
|---|---|---|
|
クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Oracle Service Busがクライアントを認証します。 |
クライアントの資格証明をHTTPヘッダーで渡します。 |
必ず パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。 |
|
前述の要件と同じです。 |
クライアントの資格証明を別のOracle Service Busユーザーにマップし、新しい資格証明をHTTPヘッダーで渡します。 |
必ず ユーザーマッピング ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。 |
|
クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Oracle Service Busはクライアントを認証しません。 |
クライアントの資格証明をHTTPヘッダーで渡します。 |
HTTP (BASIC認証)またはHTTPS(一方向SSL、BASIC認証)でビジネス・サービスを構成するようにします。 また、 パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付します。 |
|
クライアントがHTTPヘッダー内にカスタム認証トークンを提供します。Oracle Service Busはクライアントを認証します。 |
クライアントの資格証明を別のOracle Service Busユーザーにマップし、新しい資格証明をHTTPヘッダーで渡します。 |
必ず ユーザーマッピング ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付するようにします。 |
|
あらゆる形のローカル認証(HTTPまたはHTTPS基本、あるいは資格証明マッピングによるHTTPSクライアント証明書)。 |
クライアントの資格証明をEJB over RMIに渡します。EJBコンテナでユーザーを認証します。 |
パススルー・サービス・アカウントを作成し、そのアカウントをビジネス・サービスに添付します。2.1.15項「サービス・アカウント・リソースの作成」を参照してください。 |
表45-3は、インバウンドおよびアウトバウンドのメッセージレベルのセキュリティに対して適用できる要件のすべての組合せについての説明です。場合によっては、トランスポートレベルのセキュリティのインバウンド要件が、アウトバウンドのメッセージレベル・セキュリティに適用できる要件に影響します。
表45-3 メッセージレベルのセキュリティ要件の組合せ
| インバウンド要件 | 組合せ可能なアウトバウンド要件 | 構成方法 |
|---|---|---|
|
クライアントがHTTPヘッダー内にユーザー名とパスワード、またはカスタム認証トークンを提供し、Oracle Service Busがクライアントを認証します。 |
クライアントの資格証明をSOAPヘッダーで渡します。 |
|
|
前述の要件と同じです。 |
クライアントの資格証明を別のOracle Service Busユーザーにマップし、新しい資格証明をSOAPヘッダーで渡します。 |
|
|
前述の要件と同じです。 |
クライアント資格証明をSAMLトークンにマップします。Oracle Service BusがユーザーIDアサーションを行います。 |
|
|
クライアントがメッセージ・ヘッダーまたはメッセージ本体内にユーザー名とパスワード、またはカスタム認証トークンを提供し、Oracle Service Busがクライアントを認証します。 |
クライアントの資格証明をSOAPヘッダーで渡します。 |
|
|
前述の要件と同じです。 |
クライアントの資格証明を別のOracle Service Busユーザーにマップし、新しい資格証明をSOAPヘッダーで渡します。 |
|
|
前述の要件と同じです。 |
クライアント資格証明をSAMLトークンにマップします。Oracle Service BusがユーザーIDアサーションを行います。 |
|
|
クライアントがHTTPヘッダー内にユーザー名とパスワードを提供し、Oracle Service Busはクライアントを認証しません。 |
クライアントの資格証明をSOAPヘッダーで渡します。 |
HTTP (BASIC認証)またはHTTPS(一方向SSL、BASIC認証)でビジネス・サービスを構成するようにします。 また、 パススルー ・サービス・アカウントを作成し、そのアカウントをビジネス・サーバーに添付します。 |
|
クライアントがHTTPSクライアント証明書認証(双方向SSL)の一部として証明書を提供し、Oracle Service Busがクライアントを認証します。 |
クライアント資格証明をSAMLトークンにマップします。Oracle Service BusがユーザーIDアサーションを行います。 |
|
|
アクティブな仲介プロキシ・サービスが、ユーザー名トークン・プロファイルによるWebサービス・セキュリティを強制します。 |
SOAPメッセージのユーザー名とパスワード・トークンとして資格証明をコード化します。 |
パスワード(パスワード・ダイジェストではない)を要求するWS-Policy文でアクティブな仲介プロキシ・サービスを作成します。52.3.1項「アクティブな仲介プロキシ・サービスの作成: 主な手順」を参照してください。 |
|
前述の要件と同じです。 |
SOAPメッセージのSAMLトークンとして資格証明をコード化します。 |
|
|
アクティブな仲介プロキシ・サービスが、X.509トークン・プロファイルによるWebサービス・セキュリティを強制します。 |
SOAPメッセージのSAMLトークンとして資格証明をコード化します。 |
|
|
アクティブな仲介プロキシ・サービスが、SAMLトークン・プロファイルによるWebサービス・セキュリティを強制します。 |
アウトバウンドSOAPメッセージに新しいSAMLトークンを生成します。 |
|
|
ユーザー名とパスワード、X.509トークン、またはSAMLトークンを渡すことができるパススルー・プロキシ・サービス。 |
ユーザー名トークン・プロファイル、X.509トークン・プロファイル、またはSAMLトークン・プロファイルを使用するビジネス・サービス。 |
|
インバウンドTuxedoリクエストの場合は、次のセキュリティ要件を構成できます。
Tuxedoサービスのアウトバウンド呼出しでクライアントの資格証明をコード化します。
ユーザー名トークンまたはSAMLトークンとしてアウトバウンドSOAPメッセージでクライアントの資格証明をコード化します。
クライアントの資格証明を別のOracle Service Busユーザーにマップし、新しい資格証明をアウトバウンドHTTPヘッダーで渡します。
クライアントの資格証明を別のOracle Service Busユーザーにマップし、新しい資格証明をEJB over RMIに渡します。EJBコンテナでユーザーを認証します。
Oracle Service BusでのTuxedoの使用方法の詳細は、第35章「Tuxedoトランスポート」を参照してください。
図45-2に、Oracle Service Busを次のように構成したときの、Oracle Service Bus全体のユーザーIDの流れを示します。
リクエストでユーザー名とパスワードを提供するようにクライアントに要求する
トランスポート・レベル、メッセージ・レベル、または両方のレベルで資格証明を提供するようにWebサービス・クライアントに要求できます。両方のレベルで資格証明を提供するようにクライアントに要求する場合、Oracle Service BusはIDの伝播および資格証明マッピングに対してメッセージ・レベルの資格証明を使用します。
クライアントを認証します。
この図は、インバウンド・リクエストで開始され、アウトバウンド・リクエストで終了します。
あるクライアントがプロキシ・サービスにリクエストを送信します。リクエストには、ユーザー名とパスワード資格証明が含まれます。
クライアントは、認証のためにX.509証明書、カスタム認証トークンなどの他のタイプのトークンを送信することもできます。クライアントがX.509証明書トークンまたはカスタム・トークンを送信する場合は、トークンのIDをOracle Service Busセキュリティ・コンテキストにマップするようにIDアサーション・プロバイダを構成する必要があります。
プロキシ・サービスは、ドメインの認証プロバイダ・ストアにそのユーザーが存在するかどうかをドメインの認証プロバイダに問い合せます。
ユーザーが存在する場合、プロキシ・サービス用に構成したアクセス制御ポリシーを評価するように、プロキシ・サービスがドメインの認可プロバイダに依頼します。
プロキシ・サービスのアクセス制御ポリシーによってユーザーのアクセスが許可されている場合、プロキシ・サービスはメッセージを処理します。ビジネス・サービスへのアウトバウンド・リクエスト生成の一部として、プロキシ・サービスは、ビジネス・サービスが要求するユーザー名とパスワードを提供するようにビジネス・サービスに依頼します。
ビジネス・サービスは、その資格証明のサービス・アカウントを問い合せます。サービス・アカウントの構成方法に応じて、次のいずれかの処理を行います。
特定の(静的な)ユーザー名とパスワードをコード化するようにプロキシ・サービスに要求します。
クライアントが提供するユーザー名とパスワードを渡すようにプロキシ・サービスに要求します。
認証プロバイダから返されたユーザー名を別の(リモート)ユーザー名にマップし、このリモート・ユーザー名をコード化するようにプロキシ・サービスに要求します。
プロキシ・サービスは、サービス・アカウントから返されたユーザー名とパスワードと共にアウトバウンド・リクエストを送信します。
プロキシ・サービスやビジネス・サービスの作成など、管理機能へのアクセスを保護するため、Oracle Service Busには、事前定義されたアクセス権限を持つ4つのセキュリティ・ロールが用意されています。
IntegrationAdmin
IntegrationDeployer
IntegrationMonitor
IntegrationOperator
セキュリティ・ロールとは、実行時にユーザーやグループに動的に与えることができるIDです。これらの管理セキュリティ・ロールのアクセス権限は変更できませんが、それらのロールのいずれかにユーザーまたはグループを入れるための条件は変更できます。
Oracle Service Busのロールには、Oracle Service Busのリソースのみを変更する権限があります。Oracle WebLogic ServerまたはOracle WebLogic Server上の他のリソースを変更する権限はありません。管理ユーザーをロールに割り当てるときは、最低1人のユーザーをOracle WebLogic Server Adminロールに割り当てます。Oracle WebLogic Serverセキュリティ・ロールの詳細は、表47-2を参照してください。
詳細は、第47章「管理セキュリティの構成」を参照してください。
アクセス制御によって、Oracle Service Busのリソースにアクセスするユーザーを決定します。アクセス制御ポリシーは、ユーザー、グループ、またはロールがプロキシ・サービスにアクセスできるようにするための条件を指定します。たとえば、あるプロキシ・サービスへのアクセスを、GoldCustomerロールのユーザーには常に許可し、SilverCustomerロールのユーザーには平日の午後12時以降にのみ許可するというポリシーを作成することができます。
アクセス制御ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間の関連付けです。セキュリティ・ポリシーは、権限のないアクセスからWebLogicリソースを保護します。アクセス制御ポリシーは特定のリソースに割り当てられてたブール式です。リソースへのアクセスが試行されると、式が評価されます。式は、ロール(オペレータ)とアクセス時間(午前8時から午後5時)など、ブール演算子で結合された1つまたは複数の条件で構成されます。アクセス制御ポリシーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のセキュリティの基本に関する項を参照してください。
Oracle Service Busは、Oracle WebLogic Serverのセキュリティ・レルムを使用してリソースを保護します。各セキュリティ・レルムは、構成されたセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、および(アクセス制御)セキュリティ・ポリシーの集合から成ります。レルムに属するリソースにアクセスするには、47.1項「管理セキュリティ・ロールと権限」に記述されているように、ユーザーはそのレルムで定義されているセキュリティ・ロールを割り当てられている必要があります。ユーザーがOracle Service Busリソースへのアクセスを試みると、Oracle WebLogic Serverが関連するセキュリティ・レルムとセキュリティ・ポリシーをチェックして、ユーザーに割り当てられているセキュリティ・ロールを確認し、ユーザーを認証および認可します。
|
注意: Oracle Service Bus管理コンソールでセキュリティ・ポリシーの定義またはセキュリティ・ロールの編集を行うことができるのは、Oracle WebLogic Server管理者のみです。 |
すべてのプロキシ・サービスに対して、トランスポート・レベルのポリシーを作成することができます。トランスポート・レベルのポリシーでは、クライアントがプロキシ・サービスとの接続を確立しようとしたときにセキュリティ・チェックが適用されます。トランスポート・レベルのポリシーのリストに入っているユーザーからのリクエストだけが続行を許可されます。
WS-Securityのアクティブな仲介、またはメッセージ・レベルのカスタム認証を実装するプロキシ・サービスの場合は、メッセージ・レベルのポリシーを作成することもできます。このタイプのポリシーでは、保護されているいずれかの操作をクライアントが呼び出そうとしたときにセキュリティ・チェックが適用されます。メッセージ・レベルのポリシーのリストに入っているユーザーだけが、その操作を呼び出せます。
Oracle Service Bus管理コンソールには、ユーザー、グループ、セキュリティ・ロールを表示および構成するための「セキュリティ構成」モジュールが含まれます。また、Oracle Service Bus管理コンソールでは資格証明の表示と構成もできます。
すべてのプロキシ・サービスに対してトランスポート・レベルのアクセス制御を構成できます。また、WS-Securityのアクティブな仲介プロキシ・サービス、またはメッセージ・レベルのカスタム認証を実装するすべてのプロキシ・サービスに対して、メッセージ・レベルでアクセス制御を構成することもできます。アクセス制御を構成するには、トランスポート・レベルまたはメッセージ・レベル(あるいはその両方)でプロキシ・サービスにアクセス制御ポリシーを割り当てる必要があります。
すべてのプロキシ・サービスに対するデフォルトのトランスポート・レベルおよびメッセージ・レベルのアクセス制御ポリシーによって、すべてのリクエストにアクセスを許可します。アクセス制御ポリシーをプロキシ・サービスに割り当てて、それを保護する必要があります。
トランスポートレベルのアクセス・ポリシーの編集に関する項とメッセージレベルのアクセス・ポリシーの編集に関する項の手順に従って、Oracle Service Bus管理コンソールでトランスポートレベルとメッセージレベルのアクセス制御ポリシーを構成します。
アクセス制御ポリシーは認可プロバイダに保持されます。また、Oracle Service Busリポジトリにもこれらへの参照があります。
3.0以前のリリースの場合と同様に、アクセス制御ポリシーは、セッション外ではなく、Oracle Service Bus設計セッション内で管理されます。変更がセッション内で行われるため、他のリソースと同じように変更をコミットまたは破棄できます。
Oracle Service Bus管理コンソールでACLを管理できますが、Oracle Service Busの外でもポリシーを変更できます。ただし、Oracle Service Busの外でポリシーを変更するとOracle Service Busの参照が期限切れになり、無効になる場合があります。
そのため、一貫した管理には、Oracle Service Busセッション外(認可プロバイダMBeansまたはサード・パーティの認可プロバイダ・ツールを使用)でACLを完全に管理するか、またはOracle Service Busセッション内でACLを完全に管理します。2つの方法を組み合せると、ポリシー表示の一貫性が失われる場合があります。
Oracle Service Busは、プロキシ・サービスのアクセス制御ポリシーのみを管理します。他のサーバー・リソース(JMSキュー、JNDIエントリ、EJB、アプリケーション、Oracle WebLogic Serverインスタンス、データ・ソースなど)のアクセス制御ポリシーは、Oracle WebLogic Server管理コンソールから管理する必要があります。
|
注意: セッションでサービスのクローンを作成すると、ACLのクローンも作成されます。ユーザーがセッションをコミットすると、サービスのACLが認可プロバイダにコミットされます。そのため、サービスのクローンを作成するときは、クローンが元のACLと同じACLを持つようにするかどうかを決定する必要があります。同じACLを持たないようにする場合は、必ずクローンのACLを編集してください。 |
プロキシ・サービスを削除すると、Oracle Service Busがコントロールするリポジトリから、および適切な認可プロバイダから参照された全てのACLのプロキシが削除されます。
サービスを削除せずに、サービスに割り当てられているアクセス制御ポリシーを削除することもできます。これを行うには:
セッションを作成します。
「プロキシ・サービスの表示」→「セキュリティ」タブを選択し、「トランスポート・アクセス制御」オプションを編集してポリシーを削除します。
セッションをコミットします。
プロキシ・サービスの名前を適切に変更すると、すべてのポリシーが移動されます。サービスの名前の変更または移動は、Oracle Service Busセッション内でのみ行う必要があります。
操作の名前を変更すると、既存の操作が透過的に削除され、新しい操作が作成されます。
ただし、WSDLを変更することで操作の名前が変更された場合、Oracle Service Busは、古い操作のポリシーを無効と見なし、Oracle Service Busリポジトリから参照を削除し、該当する認可プロバイダからポリシーを削除します。
この場合、Oracle Service Busは、古い操作が新しい操作に名前が変更されたことを認識せず、新しい操作には新しく追加を 行いません 。つまり、Oracle Service Busは、この新しい操作にはポリシーがないものとみなします。
新しい操作に、適切なポリシーを手動で追加する必要があります。これは、操作の名前の変更が完了した後に、名前変更と同じセッションで行えます。
Oracle Service Busの今回のリリースでは、関連付けられているセキュリティ構成データを失うことなく、Oracle Service Busリソースをエクスポートまたはインポートできます。
Oracle Service Busには、インポート・チェック・ボックスがあり、これを使用して、既存のセキュリティ構成を保持するか、または上書きするかを決定できます。
たとえば、資格証明をステージング領域で構成し、この資格証明を含むプロジェクトをエクスポートして、プロダクション環境でそのプロジェクトをインポートするとします。プロジェクトをエクスポートする場合、セキュリティ構成は、Oracle Service Busの 構成jarに含まれています。次に、プロジェクトをターゲット・システムにインポートする場合、リソースの処理方法は、そのリソースがターゲット・システムに既に存在しているかどうかによって異なります。
新しいリソースがjarファイルのみに存在する場合は、常にjarファイルのセキュリティ構成を使用します。
jarファイルのみでなくインポートのターゲット・サーバーにもリソースが存在する場合は、新しいインポート・チェック・ボックスを使用して、既存のセキュリティ構成を保持するか、またはjarファイルの構成で上書きするかを決定できます。
次の3つのインポート・チェック・ボックスを使用して、インポート時に、セキュリティ構成のどの要素(ある場合)を保持するかを決定できます。
セキュリティおよびポリシーの構成を保持
「資格証明の保持」
アクセス制御ポリシーを保持
|
注意: これらのチェック・ボックスは、プロジェクト・レベルのエクスポート用および個々のリソースのエクスポート用に作成されたOracle Service Bus構成ファイルのいずれでも同様に機能します。 |
これらのチェック・ボックスについては、以降の項で詳しく説明します。
「セキュリティおよびポリシーの構成を保持」チェック・ボックスが設定されている場合(デフォルト)、次の構成パラメータが保持されます。
プロキシ・サービスのセキュリティおよびポリシーの構成:
サービス・キー・プロバイダへの参照。
「ポリシー」タブを使用してサービスに直接バインドされているWS-Policyのセット。
|
注意: サービスでWSDLベースのポリシーを使用している場合、そのポリシーはこのチェック・ボックスでは保持されません。これは、WSDL自体が更新される可能性があり、サービスはWSDLを反映する必要があるためです。 |
このコントロールは、WS-Policyのバインディングのタイプである、カスタム(「ポリシー」タブを使用)またはWSDLベースも保持します。
「WS-Securityヘッダーの処理」オプションの状態。
メッセージ・レベルのカスタム認証の構成。
プロキシ・サービスのトランスポート固有のセキュリティ構成:
HTTPの場合は、HTTPSフラグおよび認証モード(匿名、基本、クライアント証明書、またはカスタム・トークン)。
JMSの場合は、JMSおよびJNDIサービス・アカウント。
電子メールおよびFTPの場合は、サービス・アカウント参照。
SFTP認証の構成。
ビジネス・サービスのセキュリティおよびポリシーの構成:
「サービスのWS-Policyのバインド」
「呼出し元のサブジェクトを渡す」の設定
アウトバウンドWS-Securityのサービス・アカウントへの参照。
ビジネス・サービスのトランスポート固有のセキュリティ構成:
HTTPの場合は、認証モード(匿名、基本、またはクライアント証明書)およびサービス・アカウント参照。
JMSの場合は、JMSおよびJNDIサービス・アカウントへの参照。
FTP、EJB、Tuxedo、およびDSPの場合は、サービス・アカウント参照。
SFTP認証の構成。
「資格証明を保持」チェック・ボックスが設定されている場合(デフォルト)、インポート・プロセス時に次の資格証明が保持されます。
サービス・キー・プロバイダのPKI資格証明。
PKI資格証明マッピング・プロバイダは、デジタル署名や暗号化(Webサービス・セキュリティ用)、およびアウトバウンドSSL認証に使用できる鍵ペアにOracle Service Busサービス・キー・プロバイダをマップします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のPKI資格証明マッピング・プロバイダの構成に関する項を参照してください。
サービス・アカウントのユーザー名およびパスワード。
SMTPサーバー、JNDIプロバイダ、およびUDDIレジストリのユーザー名とパスワード。
Oracle Service Busセキュリティの初期構成タスクの多くでは、WebLogicセキュリティ・フレームワークの構成のためにOracle WebLogic Server管理コンソールで作業する必要があります。これらの初期タスクの後は、ほとんどのセキュリティ・タスクをOracle Service Bus管理コンソールから実行できます。
Oracle Service Busに対してWebLogicセキュリティ・フレームワークを構成するには:
トランスポート・レベルのセキュリティの一部としてSSLの使用を計画している場合は、次の処理を行います。
Oracle WebLogic Server管理コンソールではIDと信頼を構成します。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDと信頼に関する項とドメイン間セキュリティ・サポートの重要事項に関する項を参照してください。
Oracle WebLogic Server管理コンソールでSSLを構成します。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。
SSL構成に対して次のことを実行するようお薦めします。
双方向SSLを構成する場合は、「クライアント証明書をリクエスト(強制しない)」モードか、「クライアント証明書をリクエスト(強制する)」モードのいずれかを選択する必要があります。可能なかぎり、「クライアント証明書をリクエスト(強制する)」モードを選択することをお薦めします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のSecure Sockets Layer (SSL)に関する項を参照してください。
本番環境では、「ホスト名の検証」が有効になっていることを確認します。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の「SSLの構成」のホスト名検証の使用に関する項を参照してください。
Oracle WebLogic Server管理コンソールで、プロキシ・サービスがインバウンド・セキュリティに対して使用する認証プロバイダを構成します。
表45-4は、Oracle Service Busで通常構成する認証プロバイダについての説明です。構成できるすべての認証プロバイダの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のセキュリティ・プロバイダに関する項を参照してください。
表45-4 認証プロバイダ
| クライアントに提供を要求するもの | 構成 |
|---|---|
|
単純なユーザー名とパスワード |
WebLogic認証プロバイダ。Oracle Service Bus管理コンソールを使用して、アクセスを許可するクライアントのユーザー名とパスワードを入力します。 注意: 45.9.1項「認証プロバイダの構成」で説明されているように、すべてのOracle WebLogic ServerおよびOracle Service Busの管理アカウントにデフォルトのWebLogic認証プロバイダを使用することが推奨されます。 『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Serverの保護』のセキュリティ・プロバイダに関する項を参照してください。
インバウンド・リクエストでWS-Securityデジタル署名を要求するプロキシ・サービスまたはビジネス・サービスの作成を計画している場合は、証明書レジストリ・プロバイダを有効にします。このプロバイダは、登録した証明書のリストに対してインバウンド証明書を検証する証明書パス・プロバイダです。
Oracle Fusion MiddlewareのOracle WebLogic Server管理コンソール・オンライン・ヘルプの証明書パス・プロバイダの構成に関する項を参照してください。
ユーザー名とパスワード・トークンをリクエストするようにメッセージ・レベルのセキュリティ(インバウンド・リクエストまたはアウトバウンド・リクエスト)を構成する場合、およびメッセージでクリア・テキスト・パスワードではなくパスワード・ダイジェストを提供する場合は、次の操作を行います。
Oracle WebLogic Server管理コンソールで、Oracle Service Busによって提供される2つのWebサービス・セキュリティ構成を探し、UsePasswordDigestプロパティの値をtrueに設定します。
Oracle Service Bus Webサービス・セキュリティ構成の名前は次のとおりです。
__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__
__SERVICE_BUS_OUTBOUND_WEB_SERVICE_SECURITY_MBEAN__
Webサービス・セキュリティ構成での値設定の詳細は、Oracle Fusion MiddlewareのOracle WebLogic Server管理コンソール・オンライン・ヘルプのSOAPメッセージでのパスワード・ダイジェストの使用に関する項を参照してください。
構成した各認証プロバイダに対し、Oracle WebLogic Server管理コンソールでパスワード・ダイジェストの有効化チェック・ボックスを選択します。
構成した各IDアサーション・プロバイダに対し、Oracle WebLogic Server管理コンソールでアクティブ・トークン・タイプの1つとしてwsse:PasswordDigestを設定します。
サービス・キー・プロバイダ(アウトバウンド・リクエストで鍵と証明書のペアを渡します)の作成を計画している場合は、Oracle WebLogic Server管理コンソールを使用して、PKI資格証明マッピング・プロバイダを構成します。Oracle Service Busをホストする任意のOracle WebLogic Serverドメインで、最大1つのPKI資格証明マッピング・プロバイダを構成できます。
PKI資格証明マッピング・プロバイダは、デジタル署名や暗号化(Webサービス・セキュリティ用)、およびアウトバウンドSSL認証に使用できる鍵ペアにOracle Service Busサービス・キー・プロバイダをマップします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のPKI資格証明マッピング・プロバイダの構成に関する項を参照してください。
PKI資格証明マッピング・プロバイダがキーストアで使用する鍵ペアを格納します。PKI資格証明マッピングは、Oracle WebLogic Serverが使用するIDキーストアまたは別のキーストアに格納できます。各Oracle WebLogic Serverインスタンスがそれぞれ独自の各キーストア・コピーにアクセスするように構成します。PKI資格証明マッパーで参照されるすべてのエントリがすべてのキーストアに存在する必要があります(同じ別名を使用した同じエントリ)。Oracle WebLogic Serverでのキーストアの構成は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。
|
注意: Oracle Service Busドメインを作成すると、デフォルトでドメインにユーザー名/パスワード資格証明マッピング・プロバイダが含まれ、ユーザー名とパスワード用の資格証明マッピングが必要な場合に使用できます。このユーザー名/パスワード資格証明マッピング・プロバイダの他に、1つのPKI資格証明マッピング・プロバイダを追加できます。Oracle Service Busドメインは、最大1つのユーザー名/パスワード資格証明マッピング・プロバイダ、1つのPKI資格証明マッピング・プロバイダ、および複数のSAML資格証明マッピング・プロバイダを持つことができます。 |
セキュリティ監査を有効にする場合は、次を行います:
Oracle WebLogic Server管理コンソールで監査プロバイダを構成します。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogic監査プロバイダの構成に関する項を参照してください。
WS-Securityに関連したイベントの監査を有効にするには、各Oracle Service Busサーバーの起動時に、サーバーの起動コマンドで次のJavaオプションを指定します。
-Dcom.bea.wli.sb.security.AuditWebServiceSecurityErrors=true
Oracle Service Busはセキュリティ・イベントの監査をサポートしますが、構成監査をサポートしません。構成監査では、ユーザーがドメイン内のリソースの構成を変更したり、ドメイン内のリソースに対して管理操作を呼び出したりすると、ログ・メッセージが出されて監査イベントが生成されます。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の構成監査の有効化に関する項を参照してください。
まだ実行していない場合は、Oracle WebLogic Server管理コンソールで変更をアクティブ化します。Oracle WebLogic Serverの再起動が必要になる変更を行った場合は、管理コンソールに再起動が必要であることが表示されます。このようなメッセージが表示された場合は、Oracle Service BusをホストするすべてのOracle WebLogic Serverインスタンスを再起動して、セキュリティ・プロバイダに対する変更が残りの構成手順に対して有効になるようにします。
コンテキスト・プロパティは、WebLogicセキュリティ・フレームワークに追加情報を提供する手段(ContextHandlerインタフェース)として使用でき、特定のプロバイダ・メソッドに対して引数で渡される以上のコンテキスト依存の情報をセキュリティ・プロバイダが取得できるようになります。ContextHandlerは、コンテキストとコンテナ固有の追加情報を取得する高パフォーマンスのWebLogicクラスです。
Oracle Service Busは、ContextHandlerインタフェースを利用して、トランスポート・レベルとメッセージ・レベルの認証、トランスポート・レベルとメッセージ・レベルのアクセス制御、および資格証明マッピング用にセキュリティ・フレームワークにいくつかのコンテキスト・プロパティを渡します。
この項では、Oracle Service Bus固有のコンテキスト・プロパティが使用される状況について説明します。
HTTPプロキシ・サービスで認証が構成されている場合、HTTPトランスポート・プロバイダはOracle WebLogic Server ContextHandlerのOracle Service Bus実装を渡します。この機能ではユーザーの構成は必要ありません。
次の条件で、実行時に表45-5のContextHandlerプロパティが渡されます。
プロキシでHTTP基本認証が構成されている場合、認証プロバイダに渡されます。
プロキシでCLIENT-CERT IDアサーションが構成されている場合、IDアサーション・プロバイダに渡されます。
プロキシでHTTPカスタム・トークンIDアサーションが構成されている場合、IDアサーション・プロバイダに渡されます。
表45-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 |
|
次の条件で、実行時に表45-6に示されているContextHandlerプロパティが渡されます。
メッセージ・レベルのカスタム・ユーザー名/パスワード認証を実行する場合、認証プロバイダに渡されます。
メッセージ・レベルのカスタム・トークンIDアサーションを実行する場合、IDアサーション・プロバイダに渡されます。
トランスポート・レベルまたはメッセージ・レベルのアクセス制御を実行する場合、認可プロバイダに渡されます。
表45-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です。理想としては、Oracle Service Busランタイムを通過するその他のメッセージからメッセージをユニークに識別できることが必要です。ただし、Oracle Service Busは、メッセージIDがユニークであることには依存しません。メッセージIDはメッセージ・コンテキストに追加されるため、パイプラインに示されます。 |
com.bea.contextelement.alsb.router.inbound.request.CharacterEncoding |
java.lang.String |
メッセージ・ペイロードで使用される文字エンコーディング、またはnull。 |
com.bea.contextelement.wli.Message |
java.io.InputStream |
入力ストリームとしてのリクエスト・メッセージ。 |
表45-7に示されているプロパティに加えて、トランスポート固有のその他のプロパティが存在する場合があります。トランスポート・リクエスト・ヘッダー(トランスポートSDKを参照)ごとに、次の名前を持つプロパティが存在します。
com.bea.contextelement.alsb.router.inbound.request.headers.<provider-id>.<header-name>
ここで、provider-idはトランスポート・プロバイダのID、header-nameはプロバイダのスキーマ・ファイルで宣言されているリクエスト・ヘッダーの1つです。
これらのプロパティの型およびセマンティクスはトランスポート固有です。HTTPプロキシ・サービスの場合、表45-3に示すプロパティも使用できます。
表45-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アサーション・プロバイダを記述することです。
たとえば、例45-1は記述するプロバイダからHttpServletRequestプロパティを取得する方法です。
例45-1 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式は評価されません。
Oracle Service Busのこのリリースでは、Oracle WebLogic Server管理チャネルを使用できます。
『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のネットワーク・チャネルの概要に関する項で説明されているように、Oracle WebLogic Serverネットワーク・チャネルは、Oracle WebLogic Serverへのネットワーク接続の属性を定義する構成可能なリソースです。
管理チャネルと呼ばれる特定の種類のネットワーク・チャネルを構成して、WebLogicドメインで管理トラフィックとアプリケーション(ビジネス)トラフィックを分離することができます。管理チャネルは、SSL接続のみを受け入れる、セキュリティで保護されたチャネルです。
Oracle Service Busでは、ビジネス・トラフィックは、Oracle Service Busのプロキシ・サービスおよびビジネス・サービスで送受信されるすべてのメッセージで構成されています。SSLビジネス・トラフィックは、デフォルトのOracle WebLogic Serverセキュア・ネットワーク・チャネルを使用する必要があります。
管理トラフィックは、Oracle WebLogic Server管理コンソール、Oracle Service Bus管理コンソールとのすべての通信、クラスタ内の内部トラフィック、および管理スクリプトと管理サーバーまたは管理対象サーバーとの間のトラフィックで構成されています。
ドメインで管理チャネルが有効になっている場合、そのドメイン内のすべての管理トラフィックがそのチャネルを通過します。それ以外の場合、管理トラフィックは、デフォルトのOracle WebLogic Serverセキュア・ネットワーク・チャネルも使用します。
管理チャネルの使用: 主な手順
ドメインのOracle Service Bus管理コンソールに対するブラウザの接続を切断します。
Oracle WebLogic Serverで管理チャネルをアクティブ化するとすぐに、ドメインのOracle Service Bus管理コンソールは現在のURLでアクセスできなくなります。ヘルプ・システムも使用できなくなります。
Oracle WebLogic Server管理コンソールでドメイン全体の管理ポートを有効にする(これにより、管理チャネルが構成される)か、管理チャネルを明示的に作成します。これら両方の操作は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。
ドメイン全体の管理ポートのコントロールは、「ドメイン」>「構成」の「全般」ページにあります。デフォルトの管理ポートは9002です。
必ず、変更をアクティブ化してください。
ドメインのOracle Service Bus管理コンソールの新しいURLへのブラウザ接続を開きます。
ドメイン全体の管理ポートを有効にして、デフォルトのポート番号を受け入れた場合、URLはhttps://hostname:9002/sbconsoleです。
古いURLを参照する起動スクリプトを修正します。Windowsグラフィカル・インタフェースを使用してドメインのOracle Service Bus管理コンソールを起動する場合は、新しいURLを反映するようにショートカットのプロパティを修正してください。
ここでは、Oracle Service Busでのセキュリティ・プロバイダの使用方法について説明します。
この項の内容は次のとおりです。
提供されるOracle WebLogic Server認証プロバイダを調べて、ニーズを満たすものがあるかどうかを確認します。Oracle WebLogic Serverには次のような多様な認証プロバイダが含まれます。
WebLogic認証プロバイダは、Oracle WebLogic Serverの埋め込まれたLDAPサーバーにあるユーザーとグループ情報にアクセスします。これは用意されているデフォルトの認証プロバイダです。このプロバイダは、非常に多くのユーザーでの使用には最適化されていません。
LDAP認証プロバイダでは、外部のLDAPストアにアクセスします。LDAP認証プロバイダを使用すると、任意のLDAPサーバーにアクセスできます。Oracle WebLogic Serverには、Open LDAP、Oracle Directory Server Enterprise Edition、Microsoft Active DirectoryおよびNovell NDS LDAPサーバー用のLDAP認証プロバイダが構成されています。
RDBMS認証プロバイダでは、外部リレーショナル・データベースにアクセスします。Oracle WebLogic Serverには、SQLオーセンティケータ、読取り専用SQLオーセンティケータ、カスタムRDBMSオーセンティケータという3種類のRDBMSオーセンティケータが用意されています。
SAML認証プロバイダ。このプロバイダでは、Security Assertion Markup Language 1.1 (SAML)アサーションに基づいてユーザーを認証します。
これらの認証プロバイダのパフォーマンスを向上させる方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicおよびLDAP認証プロバイダのパフォーマンスの向上に関する項を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のデフォルト・セキュリティ構成をカスタマイズする理由に関する項で説明されているように、WebLogic Serverの組込みのLDAPサーバー以外のデータベースにアクセスする認証プロバイダを使用することもできます。たとえば、大多数のユーザー・アカウントに別の認証プロバイダを使用し、Oracle Service BusおよびWebLogic Serverの管理ユーザー・アカウントにはデフォルトの認証プロバイダ(組込みのLDAP)を引続き使用することができます。
すべてのOracle WebLogic ServerおよびOracle Service Busの管理ユーザー・アカウントにWebLogic認証プロバイダを使用することで、ネットワークまたはデータベースに問題が発生した場合に、信頼性の高いアクセスが提供されます。そのため、すべてのOracle WebLogic ServerおよびOracle Service Busの管理ユーザー・アカウントにデフォルトのWebLogic認証プロバイダを使用することをお薦めします。
組込みの認証プロバイダのいずれかがニーズに合う場合は、その認証プロバイダをOracle WebLogic Server管理コンソールで構成する手順を『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項で参照してください。
Oracle WebLogic Serverに組み込まれている認証プロバイダがニーズに合わない場合は、まずユーザー自身(またはサードパーティ)がカスタム認証プロバイダを作成し、次に示すように、Oracle WebLogic Server管理コンソールを使用してそのプロバイダをセキュリティ・レルムに追加する必要があります。
|
注意: ここでは、必要なタスクの概要についてのみ説明します。実際にタスクを実行するにはOracle WebLogic Serverドキュメントを調べる必要があります。 |
セキュリティ・レルムへのプロバイダの追加
適切なSSPIを使用してランタイム・クラスを作成します(『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』)。
WebLogic MBeanMakerを使用してMBeanタイプを生成します。
管理コンソールを使用してカスタム認証プロバイダを構成します。
カスタム認可プロバイダでOracle Service Busリソースを使用できますが、これらのプロバイダがOracle Service Busリソースのタイプや形式を認識する必要があります。
Oracle Service Busには、認可プロバイダが検出して処理できる必要があるリソース・オブジェクトが3つあります。
これらのリソース・オブジェクトについては、この後の項で説明します。
ここでは、Oracle WebLogic Server認可プロバイダSSPIについて簡単に説明します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の認可プロバイダに関する項を参照してください。
リソースを保護するには、Oracle Service Bus管理コンソール、サードパーティ・ツールまたはスクリプトによって、アクセス制御ポリシーをリソースにバインドします。Oracle WebLogic Server SSPI (Security Service Provider Interface)では、リソースSPIを実装するためにOracle Service Busなどのコンテナが必要です。これらの実装は具象リソースを表します。
認可プロバイダ・データベースには、リソースからポリシーへのマップがあります。リソースへのアクセスが試みられると、コンテナは実行時SSPIを呼び出してアクセス制御の判断を行います。コンテナは、アクセスされるリソースを示すリソース・インスタンスを渡します。
認可プロバイダにはgetAccessDecision()という1つのメソッドがあります。getAccessDecision()メソッドは、AccessDecision SSPIの実装を取得します。AccessDecision SSPIそのものにはisAccessAllowed()という1つのメソッドがあります。isAccessAllowedには5つのパラメータがあり、その1つはリクエストされるアクセスに対するResourceオブジェクトです。
isAccessAllowedは、指定のリソースへのアクセスがリクエスト側に許可されるかどうか判断します。これを実行するには、認可プロバイダが評価のために正しいアクセス制御ポリシーを見つける必要があります。プロバイダは、渡されたリソースにバインドされたポリシーをまず検索する必要があります。『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』のセキュリティ・プロバイダのランタイム・クラスでのWebLogicリソースのルックアップに関する項で説明されるように、検索では検索のキーとしてgetId()メソッドまたはtoString()メソッドを使用できます。ポリシーが見つからない場合、認可プロバイダは親リソースを取得し、再検索する必要があります。このプロセスは、ポリシーが見つかるか、親がnullになるまで繰り返されます。この場合、ポリシーは見つかりません。ポリシーが見つからない場合、isAccessAllowedはfalseを返す必要があります。
このアルゴリズムによって、指定のプロジェクトまたはフォルダ内のすべてのプロキシ・サービス、プロジェクト内のすべてのリソース、またはOracle Service Busドメイン内のすべてのOracle Service Busプロキシ・サービスを保護する、大まかなポリシーを作成できます。より具体的で詳細なポリシーは、大まかなポリシーより優先されます。
|
注意: Oracle Service Bus管理コンソールのユーザー・インタフェースには、フォルダ、プロジェクトまたはドメイン・レベルでプロキシ・サービスを保護するページは用意されていません。 |
ALSBProxyServiceResourceオブジェクトは、Oracle 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() - プロキシ・サービスへのパス(プロジェクトとフォルダ)を取得します。これは、Oracle 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オブジェクト用のアクセス制御ポリシーを、カスタム認可プロバイダによって設定しないことをお薦めします。これは、これらのポリシーが今後のOracle Service Busリリースで変更される可能性があるためです。
かわりに、カスタム認可プロバイダを使用する必要がある場合でも、Oracle WebLogic Server XACML認可プロバイダの使用を継続して、ConsoleResourceオブジェクト用のポリシーを管理することをお薦めします。このように2つの認可プロバイダを使用する場合は、裁決プロバイダも構成する必要があります。
Oracle WebLogic Serverでプラグイン・セキュリティ・プロバイダを使用して、Oracle Service Busで使用するポリシーを格納している場合、必要なポリシーを使用できるかどうかをOracle Service Busで確認できないというエラーが発生することがあります(たとえば、Oracle Fusion Middleware Oracle Service Busメッセージに説明されているエラーBEA-387896など)。
このようなエラー・メッセージが表示されても、ポリシーが存在しないことや、セキュリティ・プロバイダの接続上または構成上の問題が発生したことを意味するとはかぎりません。Oracle Service Busでは、Oracle WebLogic Server SSPIを使用して、セキュリティ・プロバイダが実装できるポリシーを読み取ります。ただし、SSPIの読取り機能はオプションです。セキュリティ・プロバイダでこのSSPIを実装せずに読取りアクセスを許可しないことも可能です。この場合、Oracle Service Busでは、必要なポリシーがセキュリティ・プロバイダに実際に存在していても、必要なポリシーがセキュリティ・プロバイダに含まれているかどうかを確実に判断することができません。
このような警告が本当の問題を示しているかどうかを判断するには、Oracle Service Bus管理コンソールでリソースの作成または変更を試みます。また、アクセス制御ポリシーでプロキシ・サービスを保護し、テストします。プロキシ・サービスのアクセス制御ポリシーを構成する方法の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のメッセージ・レベルのアクセス・ポリシーの編集に関する項を参照してください。セキュリティ・プロバイダを使用しながら、リソースの作成または操作、およびセキュアなプロキシ・サービスのテストに成功した場合、そのセキュリティ・プロバイダは正しく構成されており、エラー・メッセージは無視しても問題ありません。
