セキュリティ ガイド

Oracle Service Bus セキュリティについて

Oracle Service Bus では、通信の整合性とプライバシを保証し、認可されたユーザだけが Oracle Service Bus ドメインのリソースにアクセスできるようにするために、オープンな業界標準をサポートしています。また、セキュリティ サービスの構成要素として、基になっている WebLogic セキュリティ フレームワークを使用します。

WebLogic セキュリティ フレームワークでは、ドメインを保護するための作業が認証、認可、資格マッピング、監査などの複数のコンポーネント (プロバイダ) に分かれています。特定の Oracle Service Bus ドメインに対して、必要なプロバイダのみをコンフィグレーションします。

以下の節では、Oracle Service Bus のセキュリティ モデルとその機能について説明します。

着信セキュリティ

着信セキュリティによって、Oracle Service Bus プロキシ サービスは認可されたクライアントから出された要求のみを処理できます (デフォルトでは、すべての匿名ユーザまたは認証ユーザがプロキシ サービスに接続できます)。また、クライアントからデータが送信されたときに、認可されていないユーザがそのデータを参照または変更していないことが保証されます。

プロキシ サービスは、サービス コンシューマと他のプロキシ サービスという 2 つのタイプのクライアントを持つことができます。図 2-1 に、プロキシ サービスとそのクライアント間の通信が着信セキュリティによって保護され、一方プロキシ サービスとビジネス サービス間の通信が発信セキュリティによって保護されることを示します。

着信セキュリティはプロキシ サービスの作成時に設定し、ニーズの変化に応じて変更できます。外向きのプロキシ サービス (サービス コンシューマから要求を受信します) の場合は、双方向 SSL over HTTPS などの厳密なセキュリティ要件の設定を検討します。他の Oracle Service Bus プロキシ サービスからのみ要求を受信することが保証されているプロキシ サービスの場合は、これよりセキュリティの低いプロトコルを使用できます。

プロキシ サービスで、デジタル署名、暗号化、または SSL 認証に対して公開鍵インフラストラクチャ (PKI) テクノロジを使用する場合は、証明書とペアのプライベート キーを提供するサービス キー プロバイダを作成します。詳細については、『Oracle Service Bus Console の使い方』の「サービス キー プロバイダ」を参照してください。

各プロキシ サービスに対し、次の着信セキュリティ チェックをコンフィグレーションできます。

発信セキュリティ

発信セキュリティは、プロキシ サービスとビジネス サービス間の通信を保護します。発信セキュリティのために行うタスクのほとんどは、ビジネス サービスで指定される転送レベルまたはメッセージレベルのセキュリティ要件に準拠するためのプロキシ サービスのコンフィグレーションのためのものです。

たとえば、ビジネス サービスでユーザ名とパスワード トークンを要求する場合は、サービス アカウントを作成します。このサービス アカウントは、ユーザ名とパスワードを直接含み、発信要求に含まれていたユーザ名とパスワードを渡すか、または発信要求に含まれていたユーザ名に応じてユーザ名とパスワードを提供します。詳細については、『Oracle Service Bus Console の使い方』の「サービス アカウント」を参照してください。

ビジネス サービスでデジタル署名または SSL 認証のために PKI テクノロジを使用する必要がある場合は、証明書とペアのプライベート キーを提供するサービス キー プロバイダを作成します。詳細については、『Oracle Service Bus Console の使い方』の「サービス キー プロバイダ」を参照してください。

ID の伝播のオプション

Oracle Service Bus のセキュリティの設計時に決定する必要がある主な項目の 1 つは、クライアントが提供する ID の処理 (伝播) 方法です。Oracle Service Bus のコンフィグレーションによって、次のことを実行できます。

表 2-1 は、Oracle Service Bus がクライアント ID をビジネス サービスに伝播する方法に影響するオプションについての説明です。

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

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

着信 Tuxedo 要求の場合は、次のセキュリティ要件をコンフィグレーションできます。

Oracle Service Bus での Tuxedo の使用については、『Tuxedo の相互運用性ソリューション』を参照してください。

例 : ユーザ名トークンによる認証

図 2-2 に、Oracle Service Bus を次のようにコンフィグレーションしたときの、Oracle Service Bus 全体のユーザ ID の流れを示します。

この図は、着信要求で開始され、発信要求で終了します。

管理セキュリティ

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

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

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

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

アクセス制御ポリシー

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

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

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

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

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

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

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

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

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

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

アクセス制御ポリシーの管理

アクセス制御ポリシーは認証プロバイダに保持されます。ただし、ALSB 3.0 では、ALSB リポジトリにアクセス制御ポリシーへの参照が含まれていました。

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、アプリケーション、WebLogic Server インスタンス、データ ソースなど) は、WebLogic Server コンソールから管理する必要があります。

プロキシ サービスの削除

プロキシ サービスを削除すると、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 に含まれています。次に、プロジェクトをターゲット システムにインポートする場合、リソースの処理方法は、そのリソースがターゲット システムに既に存在しているかどうかによって異なります。

以下の 3 つのインポート チェック ボックスを使用して、インポート時に、セキュリティ コンフィグレーションのどの要素 (ある場合) を保持するかを決定できます。

これらのチェック ボックスについては、以降の節で詳しく説明します。

[セキュリティおよびポリシーのコンフィグレーションを保持] チェック ボックス

[セキュリティおよびポリシーのコンフィグレーションを保持] チェック ボックスが設定されている場合 (デフォルト)、以下のコンフィグレーション パラメータが保持されます。

[資格を保持] チェック ボックス

[資格を保持] チェック ボックスが設定されている場合 (デフォルト)、インポート プロセス時に以下の資格が保持されます。

[アクセス制御ポリシーを保持] チェックボックス

[アクセス制御ポリシーを保持] チェックボックスが設定されている場合 (デフォルト)、インポート プロセス時に、インポートされるプロキシ サービスのすべてのアクセス制御ポリシーが保持されます。

WebLogic Security フレームワークのコンフィグレーション : 主な手順

Oracle Service Bus セキュリティの初期コンフィグレーション タスクの多くでは、WebLogic Security フレームワークのコンフィグレーションのために WebLogic Server Administration Console で作業する必要があります。これらの初期タスクの後は、ほとんどのセキュリティ タスクを Oracle Service Bus Console から実行できます。

Oracle Service Bus に対して WebLogic Security フレームワークをコンフィグレーションするには

コンテキスト プロパティがセキュリティ プロバイダに渡される

コンテキスト プロパティは、WebLogic Security フレームワークに追加情報を提供する手段 (ContextHandler インタフェース) として使用でき、特定のプロバイダ メソッドに対して引数で渡される以上のコンテキスト依存の情報をセキュリティ プロバイダが取得できるようになります。ContextHandler は、コンテキストとコンテナ固有の追加情報を取得する高パフォーマンスの WebLogic クラスです。

Oracle Service Bus は、ContextHandler インタフェースを利用して、転送レベルとメッセージ レベルの認証、転送レベルとメッセージ レベルのアクセス制御、および資格マッピング用にセキュリティ フレームワークにいくつかのコンテキスト プロパティを渡します。

この節では、Oracle Service Bus 固有のコンテキスト プロパティが使用される状況について説明します。

HTTP 転送レベル認証用のコンテキスト プロパティ

HTTP プロキシ サービスで認証がコンフィグレーションされている場合、HTTP 転送プロバイダは WebLogic Server ContextHandler の Oracle Service Bus 実装を渡します。この機能ではユーザのコンフィグレーションは必要ありません。

以下の条件で、実行時に表 2-5 の ContextHandler プロパティが渡されます。

アクセス制御およびメッセージレベルのカスタム認証用の ContextHandler プロパティ

以下の条件で、実行時に表 2-6 に示されている ContextHandler プロパティが渡されます。

その他の転送固有のコンテキスト プロパティ

表 2-6 に示されているプロパティに加えて、その他の転送固有のプロパティが存在する場合があります。転送要求ヘッダ (転送 SDK を参照) ごとに、以下の名前を持つプロパティが存在します。

com.bea.contextelement.alsb.router.inbound.request.headers.<provider-id>.<header-name>

ここで、provider-id は転送プロバイダの ID、header-name はプロバイダのスキーマ ファイルで宣言されている要求ヘッダの 1 つです。

これらのプロパティの型およびセマンティクスは転送固有です。HTTP プロキシ サービスの場合、表 2-7 に示すプロパティも使用できます。

管理者が提供するメッセージレベル認証用のコンテキスト プロパティ

カスタム ユーザ名/パスワード認証とカスタム トークン認証の両方を使用すると、ユーザ (IntegrationAdmin ロールまたは IntegrationDeployer ロールを持つユーザ) は [セキュリティ] タブの [コンテキスト プロパティ] フィールドで追加のコンテキスト情報をセキュリティ プロバイダに渡すことができます。

追加のコンテキスト プロパティをコンフィグレーションするには、[プロパティ名] をリテラル文字列で入力し、[値セレクタ] に有効な XPath 式を入力します (XPath 式にリテラル文字列を使用することも可能です)。

XPath 式は、カスタム トークンまたはカスタム ユーザ名/パスワードで使用されているのと同じメッセージ部に対して実行時に評価されます。つまり、[値セレクタ] XPath 式は、SOAP ベースのプロキシ サービスの場合はヘッダに対して評価され、非 SOAP ベースのプロキシ サービスの場合は本体に対して評価されます。

セキュリティ プロバイダはプロパティ名を認識している必要がある

ContextHandler は名前と値のリストであるため、セキュリティ プロバイダが検索対象の名前を認識している必要があります。したがって、転送レベルおよびメッセージレベルのカスタム認証で XPath 式が評価されるのは、認証プロバイダまたは ID アサーション プロバイダがいずれかのプロパティの値を要求する場合のみです。

つまり、コンフィグレーションされた認証プロバイダまたは ID アサーション プロバイダは、ContextHandler.getValue(propertyName) メソッドで要求するプロパティ名を明確に知っている必要があります。この要件に対応する唯一の方法は、ユーザまたはサード パーティがカスタム認証プロバイダまたは ID アサーション プロバイダを記述することです。

たとえば、コード リスト 2-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 式は評価されません。

WebLogic Server 管理チャネルがサポートされている

Oracle Service Bus のこのリリースでは、WebLogic Server 管理チャネルを使用できます。

「ネットワーク チャネルについて」で説明されているように、WebLogic Server ネットワーク チャネルは、WebLogic Server へのネットワーク接続の属性を定義する、コンフィグレーション可能なリソースです。

管理チャネルと呼ばれる特定の種類のネットワーク チャネルをコンフィグレーションして、WebLogic ドメインで「管理」およびアプリケーション (「ビジネス」) トラフィックを分離することができます。管理チャネルは、SSL 接続のみを受け入れる、セキュリティで保護されたチャネルです。

Oracle Service Bus では、ビジネス トラフィックは、Oracle Service Bus のプロキシ サービスおよびビジネス サービスで送受信されるすべてのメッセージで構成されています。SSL ビジネス トラフィックは、デフォルトの WebLogic Server セキュア ネットワーク チャネルを使用する必要があります。

管理トラフィックは、WebLogic Server Administration Console、Oracle Service Bus Administration Console とのすべての通信、クラスタ内の内部トラフィック、および管理スクリプトと管理サーバまたは管理対象サーバとの間のトラフィックで構成されています。

ドメインで管理チャネルが有効になっている場合、そのドメイン内のすべての管理トラフィックがそのチャネルを通過します。それ以外の場合、管理トラフィックは、デフォルトの WebLogic Server セキュア ネットワーク チャネルも使用します。

管理チャネルの使用 : 主な手順

サポートされる標準とセキュリティ プロバイダ

Oracle Service Bus の今回のリリースでは、次の標準がサポートされます。

WebLogic Server でサポートされる標準については、WebLogic Server リリース ノートの「WebLogic Server の新機能」にある「標準のサポート」を参照してください。

WebLogic セキュリティ プロバイダのサポート

Oracle Service Bus では、WebLogic 認証プロバイダ、ID アサーション プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、資格マッピング プロバイダ、証明書検索と検証 (CLV) プロバイダなど、WebLogic Server に含まれるセキュリティ プロバイダをサポートします。さらに、Oracle Service Bus では、WebLogic SAML ID アサーション プロバイダ V2 と WebLogic SAML 資格マッピング プロバイダ V2 をサポートします。

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

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

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

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

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

これらの認証プロバイダのパフォーマンスを向上させるためのガイダンスについては、WebLogic 認証プロバイダと LDAP 認証プロバイダのパフォーマンスの向上を参照してください。

「デフォルト セキュリティ コンフィグレーションをカスタマイズする理由」で説明されているように、WebLogic Server の組み込みの LDAP サーバ以外のデータベースにアクセスする認証プロバイダを使用することもできます。たとえば、大多数のユーザ アカウントに別の認証プロバイダを使用し、Oracle Service Bus および WebLogic Server の管理ユーザ アカウントにはデフォルトの認証プロバイダ (組み込みの LDAP) を引き続き使用することができます。

すべての WebLogic Server および Oracle Service Bus の管理ユーザ アカウントに WebLogic 認証プロバイダを使用することで、ネットワークまたはデータベースに問題が発生した場合に、信頼性の高いアクセスが提供されます。そのため、すべての WebLogic Server および Oracle Service Bus の管理ユーザ アカウントにデフォルトの WebLogic 認証プロバイダを使用することをお勧めします。

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

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

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

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

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

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

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

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

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

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

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

Oracle Service BusProxyServiceResource オブジェクト

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

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

getType()

getKeys()

getPath()

getProxyServiceName()

getAction()

getOperation()

makeParent()

ALSBProxyServiceResource の例

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

ProjectResourceV2 オブジェクト

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

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

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

getType()

getKeys()

getName()

makeParent()

ConsoleResource オブジェクト

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

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