この章では次の項について説明します。
Webサービス・モデルの主要な機能は、Webサービスを幅広く使用可能かつ検出可能にする機能です。UDDIは、ビジネスとレジストリ内のサービスの情報を集中管理するWebサービスをパブリッシュおよび検出する方法の1つです。新しい別の標準として、Web Services Inspection Language(WSIL)仕様があります。
Oracle Enterprise Manager Fusion Middleware Controlは、WSILドキュメントおよびUDDI v3レジストリでパブリッシュされたWebサービスの登録をサポートします。WSILドキュメントまたはUDDI v3レジストリで使用できる任意のサービスをEnterprise Manager内に登録できます。
Enterprise Manager内の登録済サービスをサービスのソースで管理しやすくするために、メタ情報またはプロファイルを登録することもできます。ソースを登録してそれに論理名を割り当てておくと、その後はWSDLのURLなどの接続情報を指定する必要がなくなります。ドメインは複数の登録済ソースを持つことができ、各登録済ソースが複数の登録済サービスを持つことができます。ソースを登録しておくと、そのソースに登録できるサービスを簡単に検索できるようになります。
サービス名と対応するWSDLは、単一の登録済ソース内で一意である必要があります。あるサービスを登録すると、それと同じ名前の別のサービス、または名前は異なるが同じWSDL URLの別のサービスを登録しようとすると無効になります。
Webサービスを登録しておくと、Enterprise Manager内の選択リストから簡単にサービスを参照できるようになります。たとえば、「Webサービスのテスト」の説明に従ってWebサービスをテストする場合、WSDLを指定するかわりに「検索」アイコンをクリックして、図14-1に示すような登録済サービスのリストからWSDLを選択できます。
Universal Description Discovery & Integration(UDDI)は、ビジネスを迅速、簡単、かつ動的に検索し、そして相互の取引を実行可能にすることを目指す業界イニシアティブです。組み込まれるUDDIレジストリには、ビジネスに関するカタログ化された情報、その企業が提供するサービス、および取引の際に使用する通信規格とインタフェースが格納されます。
Webサービスのオーナーは、それらをUDDIレジストリにパブリッシュします。パブリッシュされると、Webサービスの説明およびサービスに対するポインタがUDDIレジストリに保持されます。UDDIにより、クライアントはこのレジストリを検索し、目的のサービスを見つけてその詳細を取得できます。これらの詳細には、サービスの起動ポイントを始め、サービスやその機能性を確認するための情報が含まれます。
WSILでは、Webサービスの説明の参照にExtensible Markup Language(XML)形式が定義されます。これらの参照はWSILドキュメントに含まれ、Webサービスの説明(WSDLファイルなど)およびWebサービスの他の集合(別のWSILドキュメントまたはUDDIレジストリなど)を参照します。
WSILドキュメントは、通常Webサービス・プロバイダによって配布されます。これらのドキュメントには、プロバイダのWebサイトで使用できるWebサービスを調べる方法が記載されています。このため、WSIL標準ではWebサービス・コンシューマ向けにWSILドキュメントを使用可能にするルールも定義されます。
WSILモデルは、Webサービスの検出を分散化します。複数のビジネス・エンティティおよびサービスに関する情報を集中管理するUDDIレジストリとは対照的に、WSILはWebサービスの記述情報をどの場所からでも提供できるようにします。UDDIとは異なり、WSILはビジネス・エンティティ情報には関係せず、特定のサービス記述形式を必要としません。ユーザーがサービス・プロバイダを理解していることが前提であり、WSDLなど、他の規格のWebサービス記述を使用します。
この項の手順に従って登録済ソースとWebサービスを表示および編集します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、登録済ソースとWebサービスを表示するドメインを表示します。
ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「Webサービス」→「登録済サービス」を選択します。図14-2に示すように、登録済ソースとサービスページが表示されます。
「ソース」表には、各登録済ソースに関する次の情報が表示されます。
名前: ソースの論理名
説明: ソースの説明
ソースURL: URL形式のソースの場所
タイプ - ソース・タイプ: UDDI v3レジストリ・インポート、ファイルからのWSILインポート、URLからのWSILインポート
ユーザーID: 外部ソースのユーザーID
「表示」メニューを使用して、表示される情報をカスタマイズできます。ページのこのセクションから、新しいソースの追加および編集、ソースの削除、ソースのWebサービスの登録、そしてソースから事前定義済UDDIレジストリへのWebサービスのパブリッシュを行うこともできます。
「ソース」表でソースを選択します。
各登録済ソースは複数の登録済サービスを持つことができます。「サービス」表には、選択したソース場所からインポートされた登録済サービスに関する次の情報が表示されます。
名前: 登録済サービスの名前
説明: サービスの説明
サービス場所: URL形式でのサービスの場所
「表示」メニューを使用して、表示される情報をカスタマイズできます。選択したサービスのWSDLを表示して、選択したWebサービスをテストすることもできます。
次のタイプのWebサービス・ソースを登録できます。
UDDI v3レジストリ・インポート
URLからのWSILインポート
ファイルからのWSILインポート
この項の手順に従ってソースを登録します。
ソースを登録する手順
ナビゲータ・ペインで「WebLogicドメイン」を開き、Webサービスのソースを登録するドメインを表示します。
ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「Webサービス」→「登録済サービス」を選択します。図14-2に示すように、登録済ソースとサービスページが表示されます。
「追加」をクリックして新しいソースを登録します。図14-3に示すように、「新規ソースの登録」ページが表示されます。
新しいソースに関する次の情報を入力します。
名前: ソースの論理名。
説明: ソースの説明。
タイプ: UDDI v3レジストリ・インポート、URLからのWSILインポート、ファイルからのWSILインポートの3つのオプションからいずれかを選択します。
入力する必要がある追加情報は、選択したオプションによって異なります。
UDDI v3レジストリ・インポートを選択した場合は、次の情報を入力します。
「ソースURL」フィールドに、UDDI照会URL、たとえばhttp://somehost/uddi/inquiry
を入力します。
サービスをUDDIソース(外部UDDIレジストリ)にパブリッシュできるようにするには、「有効化」ボックスを選択してフィールドに次のように入力します。
パブリッシュURLフィールドで、サービスのパブリッシュ先となるレジストリのURLロケーションを入力します。
「セキュリティURL」フィールドに、レジストリにアクセスするために必要なセキュリティ・ポートのURLロケーションを入力します。
「ユーザーID」および「パスワード」フィールドに、レジストリにアクセスするために必要なセキュリティ資格証明を入力します。
「URLからのWSILインポート」を選択した場合は、次の情報を入力します。
「ソースURL」フィールドに、WSILの場所をURL形式で入力します。
WSILにアクセスするためにユーザー名とパスワードが必要な場合は、Basic認証フィールドで「有効化」ボックスを選択します。「ユーザーID」および「パスワード」フィールドに、ユーザー名とパスワードを入力します。
「ファイルからのWSILインポート」を選択した場合は、「参照」(「WSILファイル」フィールドの横)をクリックしてインポートするWSILファイルを選択します。
「OK」をクリックしてソースを登録します。
登録済UDDIソースからWebサービスを登録するには、この項の手順に従います。
ナビゲータ・ペインで「WebLogicドメイン」を開き、Webサービスを登録するドメインを表示します。
ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「Webサービス」→「登録済サービス」を選択します。図14-1に示すように、「登録済ソース」ページが表示されます。
サービスの登録元となるUDDIソースを選択します。UDDIソースの「タイプ」は、UDDI v3レジストリ・インポートとして指定することに注意してください。
Webサービスの登録を選択します。
図14-4に示すように、「新規サービスの登録」ページが表示されます。
「新規サービスの登録」ページには、読取り専用形式のソース情報、および登録できるUDDIで使用可能なサービスのリストが表示されます。
サービス名および「サービス・キー」フィールドを使用して、表示される使用可能なサービスのリストをフィルタできます。たとえば、電卓(calculator)サービスを検索するには、サービス名
フィールドにcalcと入力します。電卓(calculator)サービスなど、文字列calc
を含むサービスのみが表示されます。検索では大文字と小文字は区別されません。
ページのUDDIで使用可能なサービスセクションで、サービス詳細の表示アイコンをクリックして、表内の各サービスのサービス詳細をUDDIから表示できます。UDDIからのサービス詳細ウィンドウには、特にサービス名、サービスの説明、サービスのWSDL、サービス・キー、ビジネス・キー、およびサービス場所などのサービスに関する情報が表示されます。
「編集」アイコンをクリックして、サービスの詳細を編集できます。これにより、選択したサービスの名前と説明を変更できます。
ページのUDDIで使用可能なサービスセクションで、ソースから登録する1つ以上のサービスを選択し、「登録」をクリックします。
サービスが正常に登録されたことを示す確認メッセージが表示されます。
登録済WSILソースからWebサービスを登録するには、この項の手順に従います。
ナビゲータ・ペインで「WebLogicドメイン」を開き、Webサービスを登録するドメインを表示します。
ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「Webサービス」→「登録済サービス」を選択します。図14-1に示すように、登録済ソースとサービスページが表示されます。
サービスの登録元となるWSILソースを選択します。WSILソースの「タイプ」は、「ファイルからのWSILインポート」または「URLからのWSILインポート」として指定することに注意してください。
Webサービスの登録を選択します。
図14-5に示すように、「新規サービスの登録」ページが表示されます。
「新規サービスの登録」ページには、読取り専用形式のソース情報、およびWSILで使用可能なサービス表に示すように、登録できるWSILで使用可能なサービスのリスト(あれば)が表示されます。WSILにWSIL参照がある場合は、それらが「WSILで使用可能な参照」表にリストされます。
WSILで使用可能なサービス表で、「編集」アイコンをクリックして、サービスの詳細を編集できます。これにより、選択したサービスの名前と説明を変更できます。
現在のWSILから使用可能なサービスを登録するには、WSILで使用可能名サービス表でサービスを選択して、「登録」をクリックします。
サービスが正常に登録されたことを示す確認メッセージが表示されます。
現在のWSILが別のWSIL URLや参照も参照している場合は、「WSILで使用可能な参照」を開いて表示します。参照されているWebサービスも登録できます。
現在のWSILのかわりに参照されているWSILからサービスを登録するには、「WSILで使用可能な参照」表でその参照の「プロセス」アイコンをクリックします。
WSILが正常に解析されると、新しいソースが登録され、現在のWSILソースが参照されているWSILに置き換えられます。参照されているWSILソースで使用可能なサービスが、WSILで使用可能なサービス表にリストされます。これで参照されているWSILからサービスを登録できます。
注意: 作成された各新規ソースには、親ソース名に_n を付加した名前が付けられます。たとえば、親ソース名がwsil_file_1 の場合、参照されている新規ソースの名前は、ソース・タイプWSIL URLを含むwsil_file_1 _1 、wsil_file_1 _2 )になります。新しいソースは、登録済ソースとサービスページの「ソース」表にリストされます。 |
WSILが正常に解析されなかった場合は、エラー・メッセージが表示されます。通常そのような場合でも、選択されたWSIL参照に対して新しいソースは正常に登録されます。ただし、システムがWSILドキュメントを解析できなかったために、エラー・メッセージが表示されます。エラー・ダイアログを閉じて、「OK」をクリックして登録済ソースとサービスページに戻ります。
WSIL解析は、参照が不適切であるか認可証明書が必要な場合には失敗します。[ソースの登録]で説明されているように、WSILソースの認可を有効化できます。
注意: 接続やその他の不具合が原因で、システムが登録済ソースからのWebサービスの取得に失敗した場合は、「新規サービスの登録」ページにソースの読取り専用情報が表示されますが、Webサービスは表示されません。このような場合は、エラー・ダイアログが表示されている場合は、エラー・ダイアログで「OK」をクリックし、それから「新規サービスの登録」ページで「OK」をクリックして、ソースとサービスの登録ページに戻ります。問題解決方法として、他の方法により登録済ソースを表示します。たとえば、ソースのタイプに応じて、次の方法を実行します。
また、関連するEnterprise Managerエラー・ログを確認することもできます。 |
この項の手順に従ってWebサービスまたはWebサービス・ソースを削除します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、Webサービスを削除するドメインを表示します。
ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「Webサービス」→「登録済サービス」を選択します。図14-2に示すように、登録済ソースとサービスページが表示されます。
次のいずれかを実行します。
ソースを削除するには、「ソース」表からソースを選択し、「削除」をクリックします。
確認メッセージが表示されます。「OK」をクリックしてソースを削除します。
サービスをソースから削除するには、「ソース」表からソースを選択します。
「サービス」表に登録済Webサービスが表示されます。
削除するサービスを「サービス」表から選択し、「削除」をクリックします。
確認メッセージが表示されます。「OK」をクリックしてサービスを削除します。
登録済のUDDIソースから、あるいはADF、WebCenter、Java EEの各アプリケーションのWebサービスのサマリー・ページから、UDDIにWebサービスをパブリッシュできます。登録済UDDIソースは、登録済ソースとサービスページにリストされます。これにはドメインに登録されているすべてのソースとサービスが含まれます。「Webサービスのサマリー」ページには、アプリケーション内のWebサービスがリストされます。
注意: サービスをUDDIにパブリッシュするには、プロキシを使用する必要があります。これはファイアウォールより外側のURLにアクセスする必要があるためです。必要なプロキシ設定の詳細は、「UDDIのプロキシ・サーバーの構成」を参照してください。サービスがすでにOracle Enterprise Repository(OER)に存在する場合、OER交換ユーティリティを使用してそれらのサービスをOracle Service Registryにパブリッシュする必要があります。 |
次の手順では、WebサービスをUDDIにパブリッシュする方法について説明します。
Webサービスを登録済ソースからUDDIにパブリッシュする手順
「登録済ソースとWebサービスの表示」の説明に従って、登録済ソースとサービスページに移動します。
「ソース」表でソース行を選択してから、「UDDIにパブリッシュ」を選択します。
サービスをUDDIにパブリッシュウィンドウで、パブリッシュするサービスに関する情報を入力します。
「サービス名」は、UDDIレジストリにパブリッシュされるWebサービスの名前です。これは必須フィールドです。
「サービスの説明」は、選択したWebサービスの説明です。
サービス定義の場所は、サービス定義のURLロケーションです。これは必須フィールドです。
UDDIソースは、サービスの登録元となるUDDIソースの名前です。これは読取り専用フィールドです。
「ビジネス名」は、UDDIレジストリ内のデータ構造の名前です。ビジネスがすでにUDDIに登録されていることが前提です。リストからビジネス名を選択します。これは必須フィールドです。
サービスをUDDIにパブリッシュウィンドウで「OK」をクリックします。
システムにより、指定されたサービスが有効なWSDLを持つこと、そしてUDDIレジストリが新しいエントリを受け入れたか既存のエントリを更新したことが検証されます。正常であれば、確認メッセージが表示され、サービスがレジストリにパブリッシュされます。サービスがUDDIにパブリッシュされると、「UDDIソースからのWebサービスの登録」の説明に従って、そのサービスをソースに登録できるようになります
操作中にエラーが発生すると、エラー・メッセージが出力されます。
ソースに登録できるのは、一意のWSDLを使用しているサービスのみであることに注意してください。
WebサービスをアプリケーションからUDDIにパブリッシュする手順
「アプリケーションの「Webサービスのサマリー」ページへの移動」の説明に従って、「Webサービスのサマリー」ページに移動します。
ページの「Webサービスの詳細」セクションで、パブリッシュするサービスを選択します。
「アクション」→「UDDIにパブリッシュ」を選択します。図14-8を参照してください。
サービスをUDDIにパブリッシュダイアログ・ボックス(図14-9)で、パブリッシュするサービスに関する情報を入力します。
「サービス名」は、UDDIレジストリにパブリッシュされるWebサービスの名前です。これは必須フィールドです。
「サービスの説明」は、選択したWebサービスの説明です。
サービス定義の場所は、サービス定義のURLロケーションにより事前に入力されています(これは読取り専用フィールドです)。
UDDIソースは、UDDIレジストリ・ソースの論理名です。リストからUDDIソースを選択します。これは必須フィールドです。
「ビジネス名」は、UDDIレジストリ内のデータ構造の名前です。ビジネスがすでにUDDIに登録されていることが前提です。リストからビジネス名を選択します。これは必須フィールドです。
「OK」をクリックして外部のUDDIレジストリに接続し、Webサービスを登録します。
サービスが正常に登録されると、確認メッセージが表示されます。操作中にエラーが発生すると、エラー・メッセージが出力されます。
サービスをUDDIにパブリッシュするには、ファイアウォールより外側のURLにアクセスするため、プロキシを使用する必要があります。
Oracle WebLogicを起動する前に、表14-1に定義されているJavaシステム・プロパティを設定する必要があります。これらは環境変数として設定するか、Oracle WebLogic起動ファイルの中で設定します。
表14-1 UDDIのプロキシ・サーバーを指定するために使用されるJavaシステム・プロパティ
プロパティ | 説明 |
---|---|
proxySet=true |
WebLogicプロキシ・プロパティを使用するかどうかを指定するフラグ。 |
http.proxyHost=proxyHost |
プロキシ・サーバーを実行しているホスト・コンピュータの名前。 |
http.proxyPort=proxyPort |
プロキシ・サーバーがリスニングしているポート。 |
http.nonProxyHosts=hostname | hostname | ... |
プロキシを回避して直接到達する必要のあるホストのリスト。各ホスト名を「|」記号で区切ります。 |
たとえば、次のようにします。
set PROXY_SETTINGS="-DproxySet=true -Dhttp.proxyHost=www-proxy.example.com -Dhttp.proxyPort=80 -Dhttp.nonProxyHosts=localhost|${HOST}|*.example.com"
監査は、セキュリティ・イベントおよびそれらのイベントの結果に関する情報の収集および格納のプロセスを説明します。監査では、選択したシステムのアクティビティに関する電子的証跡が提供されます。
監査ポリシーでは、実行時に取得されるイベントのタイプおよびスコープが定義されます。操作中は非常に大きなシステムおよびユーザー・イベントの配列が発生しますが、実際に監査されるイベントは、実行時に有効な監査ポリシーによって異なります。コンポーネント固有またはアプリケーション固有のポリシーを定義するか、個々のユーザーを監査できます。
監査ポリシーページを使用して、Webサービスおよびドメイン・レベルのアプリケーションなどの、システム・コンポーネントの監査を構成できます。SOA、ADFおよびWebCenterサービスを監査できます。
ページ中央の監査ポリシーの表には、現在有効な監査が表示されます。表には、次の情報が含まれます。
名前: 監査できるシステム・コンポーネントおよびアプリケーションの名前。
監査の有効化: 現在監査が有効にされているコンポーネントおよびアプリケーションを識別します。
フィルタ: 現在有効な任意のフィルタを指定します。
次の表では、Webサービスおよび関連するコンポーネントで監査できるイベントがまとめられています。
表14-2 Webサービスのイベントの監査
監査を有効にするWebサービスのイベント | 使用するシステム・コンポーネント |
---|---|
|
Oracle Web Services Manager: エージェント |
|
Oracle Webサービス |
|
Oracle Web Services Manager: ポリシー・マネージャ 注意: ポリシー・マネージャは、直接ポリシー添付とポリシー・セットのグローバル・ポリシー添付の両方を監査します。 |
|
Oracle Web Services Manager: ポリシー添付 注意: ポリシー添付は、直接ポリシー添付のみを監査します。 |
また、管理者によるすべてのイベントを監査するなど、特定ユーザーのイベントを監査できます。
監査ポリシーの構成の詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドの監査の構成および管理に関する項を参照してください。
次の項では、監査ポリシーを定義し監査データを表示する方法を説明します。
この項の手順に従って監査ポリシーを構成します。
ナビゲータ・ペインで「WebLogicドメイン」を開きます。
アサーション・テンプレートを管理するドメインをクリックします。
「WebLogicドメイン」メニューから、「セキュリティ」→「監査ポリシー」を選択します。
「監査ポリシー設定」ページが表示されます。
「監査レベル」メニューから監査レベルを選択します。
有効な監査レベルは次のとおりです。
なし: 監査を無効にします。
低: 小さいスコープのイベントを監査します。イベントのサブセットは、各コンポーネントについて個別に事前定義されます。たとえば、あるコンポーネントに「低」を指定すると、認証および認可イベントのみが収集されます。
中: 中程度のスコープのイベント(「低」レベルで収集されたイベントのスーパーセット)を監査します。たとえば、あるコンポーネントに「中」を指定すると、認証、認可およびポリシー認可イベントが収集されます。
カスタム: カスタム監査ポリシーを使用できるようになります。
監査ポリシー・リストの各レベルで、監査に対して選択したコンポーネントおよびアプリケーションを表示できます。「カスタム」以外のすべての監査レベルで、監査ポリシー・リストの情報はグレーで表示され、他の監査レベル設定はカスタマイズできなくなっています。
「カスタム」監査レベルを選択した場合は、次のいずれかの手順を実行します。
「監査の有効化」列で、関連するチェック・ボックスを選択して、監査する情報を選択します。
コンポーネントのすべてのイベント、コンポーネント・イベント・グループ内のすべてのイベント、個々のイベント、または個々のイベントの特定の結果(成功または失敗など)などの粒度のレベルで監査できます。
イベントの結果レベルで編集フィルタを指定できます。フィルタはルールベースの式で、戻りイベントを制御するように定義できます。たとえば、ポリシーが特定のユーザーによって作成、変更または削除された場合に、ポリシー管理操作を追跡するフィルタとしてイニシエータを指定できます。結果レベルでフィルタを定義するには、適切な列で「フィルタの編集」アイコンをクリックし、フィルタ属性を指定して「OK」をクリックします。フィルタ定義は「フィルタ」列に表示されます。
サブコンポーネントの監査をカスタマイズするには、より高いレベルのコンポーネントのチェック・ボックスを選択解除します。すべてのコンポーネントとアプリケーションを選択するには、列名に隣接するチェック・ボックスを選択します。
すべてのシステム・コンポーネントおよびアプリケーションの障害のみを監査するには、「障害のみ選択」を使用します。
選択すると、「監査の有効化」列のすべてのチェック・ボックスが選択解除されます。
必要に応じて、常に監査するユーザーボックスに、ユーザーをカンマで区切って入力します。
指定されたユーザーは、監査が有効または無効にされているか、またはどのレベルの監査が設定されているかにかかわらず常に監査されます。
「適用」をクリックします。
現在のセッション中に行ったすべての変更を戻すには、「元に戻す」をクリックします。
監査情報のデータの収集および格納を管理するには、次のタスクを実行する必要があります。
監査データ・リポジトリの設定および管理。
ファイルまたはデータベースのいずれかのリポジトリ・モードを使用して、レコードを格納できます。データベース・リポジトリ・モードの使用をお薦めします。Oracle Business Intelligence Publisherベースの監査レポートは、データベース・リポジトリ・モードでのみ機能します。
監査イベント収集の設定。
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドの監査ストアの管理に関する項を参照してください。
データベース・リポジトリの場合、データはOracle Business Intelligence Publisherで事前定義されたレポートを介して公開されます。
認証および認可の履歴、Oracle WSMポリシー強制および管理など、多くの事前定義済レポートを使用できます。Oracle Business Intelligence Publisherによる監査レポートの生成および表示の詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドの監査分析の使用およびレポートに関する項を参照してください。
ファイルベース・リポジトリの場合、テキスト・エディタを使用してバスストップ・ファイルを表示し、独自のカスタム問合せを作成できます。
WebサービスWSDLを一般に公開したくない場合もあります。「Webサービス・エンドポイント」ページから、WSDLへのパブリック・アクセスを有効または無効にできます。
注意: 起動中に、Webサービス・クライアントからWSDLへのアクセスが必要な場合もあります。WSDLへのパブリック・アクセスを無効にすると、クライアントにはWSDLのローカル・コピーが必要になります。 |
WSDLを管理する手順
「Webサービス・エンドポイントの構成」で説明されているように、Webサービスのエンドポイント構成ページに移動します。
「構成」タブで、「WSDL対応」フィールドを「TRUE」または「FALSE」に設定して、WSDLへのパブリック・アクセスを有効または無効にします。
「適用」をクリックします。
セキュリティ・ポリシーは、Oracle Enterprise Manager Fusion Middleware Controlを使用して、実行中のクライアントに添付できます。クライアントへのポリシーの添付または解除を実行するために、クライアント・アプリケーションを再デプロイする必要はありません。Fusion Middleware Controlを使用したポリシーの添付方法の詳細は、第8章「Webサービスへのポリシーの添付」を参照してください。
次のコンポーネントのプロパティは、「プラットフォーム・ポリシー構成」ページから管理できます。
ポリシー・アクセッサ
ポリシー・キャッシュ
ポリシー・インターセプタ
アイデンティティ拡張
信頼できるSAMLクライアント
信頼できるSTSサーバー
ポリシー・アクセッサ、ポリシー・キャッシュ、ポリシー・インターセプタ、およびアイデンティティ拡張プロパティを管理する手順
ナビゲータ・ペインで「WebLogicドメイン」を開いてドメインを表示します。
プロパティを管理するドメインを選択します。
「WebLogicドメイン」→「Webサービス」→「プラットフォーム・ポリシー構成」を選択します。
図14-11に示すように、「プラットフォーム・ポリシー構成」ページが表示されます。
プロパティを定義するコンポーネントに対応するタブを選択します。
デフォルトでは、Oracle Web Services Manager (WSM)は自動検出機能をサポートしており、この機能を使用して同じWebLogicドメイン内のOracle WSM Policy Managerを検索してこれに接続します。シナリオによっては、自動検出が期待通りに機能しない場合があります。
注意: SSLを使用するよう構成されているサーバーにOracle WSM Policy Managerがデプロイされると、自動検出メカニズムは、他のSSL構成サーバー上のポリシー・マネージャへの接続のみを試みます。安全な接続を保持するために、SSLに対応するよう構成されていないサーバーにデプロイされたポリシー・マネージャは無視されます。 |
たとえば次の場合には、自動検出機能を無効にできます。
ドメインのネットワークが2つ以上に分割されている場合(特に、ファイアウォールがネットワーク間に存在する場合)。
WebSphere Application Serverなど、自動検出機能をサポートしないWebLogic以外のアプリケーション・サーバーで実行中の場合。
デフォルト設定をオーバーライドする場合。
Oracle Infrastructure Webサービス・ポリシーの場合、「プラットフォーム・ポリシー構成」ページで、次の操作を行えます。
「ポリシー・アクセッサ」タブでは、ポリシー・マネージャにアクセスするための代替ポリシー・マネージャURLおよび対応する資格証明を指定できます。
「ポリシー・キャッシュ」タブでは、Webサービス・エンドポイントのポリシー・キャッシュ遅延の動作をチューニングすることにより、ネットワーク・コールを回避し、ポリシー・マネージャからポリシーをフェッチする際のパフォーマンスを向上できます。
ポリシー・マネージャの接続を構成し、ポリシー・キャッシュをチューニングする手順は、次のとおりです。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
「ポリシー・アクセッサ」タブを選択します。
「追加」をクリックして、JNDIプロバイダを定義します。
「プロパティの追加」ウィンドウで、次の値を指定します。
「名前」フィールドで、JNDIプロバイダURLプロパティをjava.naming.provider.url
として入力します。
「値」フィールドに、JNDIプロバイダのURL (例: t3://
host
:
port
)を入力します。
「OK」をクリックします。
「追加」をクリックして、対応するcsf-key資格証明プロパティを定義します。「プロパティの追加」ウィンドウで、次の値を指定します。
「名前」フィールドで、JNDIプロバイダのcsf-key資格証明プロパティの名前をjndi.lookup.csf.key
として入力します。
「値」フィールドで、csf-key資格証明を入力します。
Policy Managerはセキュリティが有効なため、JNDI URLを使用してPolicy Managerを検索するときに、csf-keyはjava.naming.security.principal
およびjava.naming.security.credentials
を指定します。
「OK」をクリックします。
資格証明の格納、取得および削除の詳細は、「資格証明ストアへの鍵およびユーザー資格証明の追加」を参照してください。
「ポリシー・キャッシュ」タブを選択します。
Webサービス・エンドポイントのポリシー・キャッシュ・プロパティを変更するには、目的のプロパティを選択して「編集」をクリックします。「プロパティの編集」ウィンドウで、「値」フィールドを編集して各プロパティのデフォルト値を変更できます。
cache.tolerance
: ポリシー・キャッシュのリフレッシュ間隔(ミリ秒単位)。この設定により、Webサービス・エンドポイント・ポリシー・キャッシュから最新バージョンのポリシー・セットが取得されるようになります(つまり、cache.tolerance
値を超えません)。ポリシー・セットが失効していると判断された場合は、Oracle WSM Policy Managerから最新のポリシー・セットがWebサービス・エンドポイント・ポリシー・キャッシュに取得され、リフレッシュされます。デフォルトは60000ミリ秒(1分)です。
注意: Webサービスのエンドポイントのリフレッシュ間隔の遅延時間は、Oracle WSM Policy Managerの「ポリシー・アクセッサ」
タブのcache.refresh.repeatプロパティの値とともに集計されます。したがって、cache.refresh.repeat
の時間と組み合せた場合に、この追加の値によって必要なリフレッシュの遅延が発生するかどうかを検証する必要があります。詳細は、「WSMリポジトリ接続のチューニング」を参照してください。
別のプロパティを追加するには、「追加」をクリックし、「プロパティの追加」ウィンドウで、必要な値を指定します。
「OK」をクリックします。
既存のプロパティを変更するには、それを選択してから「編集」をクリックします。
既存のプロパティを削除するには、それを選択してから「削除」をクリックします。
「適用」をクリックしてプロパティの更新を適用します。
「ポリシー・アクセッサ」タブでは、リポジトリからのOracle WebLogic Webサービス・ポリシーの取得を構成することもできます。これには、リポジトリの場所(JAR、ディレクトリ、またはホストとポート)およびアカウント情報の指定が含まれます。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
「ポリシー・アクセッサ」タブを選択します。
「追加」をクリックして、ポリシー取得のプロパティを追加します。
次の表を使用して、「新規構成プロパティの追加」ウィンドウでプロパティの名前と値を指定します。
表14-3 「プロパティの追加」ウィンドウのプロパティ
要素 | 説明 |
---|---|
java.naming.provider.url |
実行中のOracle WSM Policy Managerの場所を指定するJNDI URL(例: |
jndi.lookup.csf.key |
Oracle WSMポリシー・マネージャの場所を 次の場合には、このプロパティを構成する必要があります。
デフォルト・ユーザーの変更の詳細は、「デフォルト・ユーザーの変更」を参照してください。 |
既存のプロパティを変更するには、それを選択してから「編集」をクリックします。
既存のプロパティを削除するには、それを選択してから「削除」をクリックします。
「適用」をクリックしてプロパティの更新を適用します。
「ポリシー・アクセッサ」タブのプロパティを使用すると、(高可用性のための)再試行ロジックやキャッシュ・リフレッシュ率など、エージェントとOracle WSM Policy Managerの間の接続を構成することもできます。
構成管理システムは、ポリシー・マネージャに定期的に接続します(たとえば、接続情報が変化する状況に対処するため)。ランタイムが再接続を試みたときにポリシー・マネージャが停止している場合は、connect.retry.delay
プロパティの値を使用して、再試行のタイミングが決まります。
初期接続が行われてもOracle WSMリポジトリが正常に動作していない場合、サービスは非操作状態で開始します。failure.retry.count
プロパティおよびfailure.retry.delay
プロパティの値を調整して、エージェントがポリシー・マネージャとの通信を試みてリポジトリにアクセスする回数と、再試行の間隔を決定できます。リポジトリが使用可能になると、サービスは操作可能になります。
cache.refresh.initial
プロパティおよびcache.refresh.repeat
プロパティを調整して、エージェントがキャッシュ済のドキュメントをリフレッシュするためにポリシー・マネージャへのアクセスを試みる頻度を変更できます。missing.retry.delay
プロパティは、エージェントが取得できなかったドキュメントを取得するためにポリシー・マネージャへの接続を試みる頻度を指定します。ポリシー・マネージャとの通信が失敗したために(たとえば、ポリシー・マネージャの停止が原因)、ドキュメントまたは関連ドキュメントのグループ(ポリシー・セットなど)を取得できなかった場合、missing.retry.delay
プロパティは、ポリシー・マネージャが修正されるまで、ポリシー・マネージャとの通信を試みる頻度に引き続き影響します。
これらのプロパティの設定を表示および変更する手順は、次のとおりです。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
「ポリシー・アクセッサ」タブを選択します。
表内のプロパティを選択して、「編集」をクリックします。
表14-4は、使用可能なプロパティとそのデフォルト設定を示しています。
表14-4 WSMリポジトリ接続のチューニング・プロパティ
プロパティ | 説明 | デフォルト |
---|---|---|
|
ポリシー・マネージャへの接続が失敗した後に接続を再試行するまでの待機時間(ミリ秒数)。 |
600000ミリ秒(10分) |
|
最初のキャッシュ・リフレッシュまでの待機時間(ミリ秒数)。 |
600000ミリ秒(10分) |
|
次のキャッシュ・リフレッシュまでの待機時間(ミリ秒数)。 |
600000ミリ秒(10分) |
|
不足ドキュメントの取得を試行するまでの待機時間(ミリ秒数)。 |
15000ミリ秒 |
|
使用状況データを送信するまでの待機時間(ミリ秒数)。 |
30000ミリ秒 |
|
通信失敗後に再試行する回数。 |
2 (再試行回数) |
|
次の再試行までの待機時間(ミリ秒数)。デフォルトは5000ミリ秒です。 |
必要な変更を入力して、「OK」をクリックします。
必要に応じて残りのプロパティを編集し、「適用」をクリックしてプロパティの更新を適用します。
「ポリシー・インターセプタ」
タブのBindingSecurityInterceptorプロパティを使用して、システム・クロック間のデフォルト・メッセージ・タイムスタンプの時間差、ポリシー・キャッシュ内のnonceメッセージの存続時間、およびメッセージの有効期限を調整することにより、セキュリティ・ポリシー強制をチューニングできます。
セキュリティ・ポリシー強制をチューニングする手順は、次のとおりです。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
「ポリシー・インターセプタ」タブを選択します。
リストでBindingSecurityInterceptor
セキュリティ・プロパティを選択します。
表14-5は、Webサービス・セキュリティ・ポリシー強制をチューニングするために設定できるプロパティを示しています。
BindingSecurityInterceptor
セキュリティ・プロパティを変更するには、それを選択してから「編集」をクリックします。「プロパティの編集」ウィンドウで、「値」フィールドを編集して各プロパティのデフォルト値を変更し、「OK」をクリックします。
表14-5 Webサービス・セキュリティ・ポリシー強制のチューニング・プロパティ
プロパティ | 説明 | デフォルト |
---|---|---|
|
クライアント・マシンとサーバー・マシンの間での時間差の許容範囲(秒単位)。たとえば、メッセージのタイムスタンプがタイムゾーンの異なるサービスに送信された場合に、このプロパティで指定された許容時間が許容されます。 次の場合に
|
|
|
SAMLまたはJWTトークンを生成するための 注意: デフォルトでは、このプロパティはBindingSecurityInterceptorインターセプタ・プロパティの表に表示されません。プロパティ値を変更するには、表にプロパティを追加します。そのためには、「追加」をクリックし、「名前」フィールドにagent.client.clock.skewを設定し、「値」フィールドに目的の値を設定して、「OK」をクリックします。 |
|
|
Nonceがメッセージで送信されるときの、キャッシュ内でのNonceの合計存続時間(秒単位)。このプロパティにより、Nonceはキャッシュされ、この時間を超えるとキャッシュから削除されます。 注意: ユーザー名トークンの設定では、リプレイ攻撃を避けるために、「必要な作成時間」および「必要なNonce」の両方のプロパティを有効にする必要があります。「必要なNonce」のみが有効な場合、Nonceはリプレイ攻撃を避けるために永久にキャッシュされます。また、 |
|
|
メッセージが作成されてから期限切れになるまでの時間(秒単位)。このプロパティは、タイムスタンプがSOAPヘッダーで送信される場合に、タイプスタンプが期限切れかどうかを検証するために使用されます。 クライアントとサービスのクロックの間に時間差がない場合でも、サービスが受信したときにメッセージが期限切れの場合は、メッセージの有効期限を増加する必要があります。メッセージの有効期限は、 |
|
|
Oracle WSMがすべてのタイプのXPath変換を許容するかどうかを指定するプロパティ。デフォルトでは、Oracle WSMが(受信soapメッセージ内の)署名内で許容するXPath変換は 注意: このプロパティを有効化すると、XPathベースのサービス拒否攻撃または他の類似のXPathベースのセキュリティ脆弱性が生じる可能性があります。 |
|
既存のプロパティを削除するには、それを選択してから「削除」をクリックします。
「適用」をクリックしてプロパティの更新を適用します。
アイデンティティ拡張タブのプロパティにより、WSDLのX509資格証明をパブリッシュしてWebサービス・ポリシーを強制するかどうかを指定できます。X509証明書を公開する必要がない場合は(たとえばSSLの場合など)、デフォルトの設定をオーバーライドして証明書を公開しないようにすることができます。さらに、X509証明書をパブリッシュする場合は、ホスト名検証機能を無視するかどうかも指定できます。
詳細は、「サービス・アイデンティティ証明拡張の使用」を参照してください。
Fusion Middleware Controlの「信頼できるSAMLクライアント」タブ、「信頼できるJWTクライアント」タブおよび「信頼できるSTSサーバー」タブで、SAMLおよびJWT署名証明書に対して、SAMLおよびJWTの信頼できる発行者および信頼できる識別名(DN)のリストを定義できます。
注意: SAMLおよびJWTの信頼できる発行者は、WLSTを使用して定義する(「WLSTを使用した信頼される発行者の定義とDNリストの管理」を参照)、またはREST APIを使用して定義できます(『Oracle Web Services Managerでの資格証明およびキーストアの管理のためのREST API』の信頼構成の管理に関する項を参照)。 |
信頼できる発行者を追加するには、この方法を使用することをお薦めします。ここで定義する信頼できる発行者のリストが、このドメイン内のすべてのWebサービスに適用されるデフォルト・リストになります。また、この方法で発行者を追加する場合、ドメインの再起動は必要ありません。
注意: 信頼できる発行者の決定方法は、次の順位で決められます。
|
デフォルトでは、Oracle WSMは、構成済発行者のリストに対して受信発行者名をチェックし、Oracle WSMキーストア内の構成済証明書に対してSAMLおよびJWTの署名をチェックします。また、信頼できるDNリストを定義する場合は、SAMLおよびJWT署名がその発行者に関連付けられている特定の証明書に基づいて署名されているかどうかも検証されます。
信頼できるDNリストの構成はオプションです。詳細な制御を必要とするユーザーは、これにより各発行者を1つ以上の署名証明書のリストに関連付けることができます。信頼できる発行者のDNリストが定義されていない場合、証明書がOracle WSMキーストアに存在する証明書によって信頼されているかぎり、その証明書に基づいて署名できます。
重要な注意事項:
「信頼できるSAMLクライアント」タブ、「信頼できるSTSサーバー」タブ、「信頼できるJWTクライアント」タブまたは関連するWLSTコマンドを使用して、証明書自体ではなく署名証明書のDNを定義します。
証明書は、Oracle WSMキーストアにインポートするか、メッセージに挿入する必要があります。証明書をメッセージに挿入する場合は、その発行者をOracle WSMキーストアにインポートする必要があります。
双方向SSLの場合は、次のようにします。
Java EEコンテナのトラスト・ストアに証明書をインポートする必要があります。
検証にはクライアントSSL証明書のDNを使用します。このDNは信頼できるDNリストに存在している必要があります。
どのような場合も、署名証明書はOWSMキーストアに存在する証明書によって信頼されている必要があります。
Fusion Middleware ControlまたはWLSTを使用して、信頼できる発行者およびDNリストを定義できます。
SAML署名証明書の信頼できるDNリストを定義する手順は、次のとおりです。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
信頼できるSAMLクライアント(SAML送信者保証)、信頼できるSTSサーバー(SAML HOKおよびSAMLベアラー)または信頼できるJWTクライアント(JWT発行者)の信頼できるDNリストを定義するかどうかに応じて、「信頼できるSAMLクライアント」タブ、「信頼できるSTSサーバー」タブまたは「信頼できるJWTクライアント」タブを選択します。図14-12を参照してください。
ページの「信頼できる発行者」セクションで、信頼できる発行者を1件以上追加します。
デフォルト値はwww.oracle.com
です。
「追加」をクリックして、新しい信頼できる発行者を追加します。たとえば、www.example.com
です。
ページの「信頼できる発行者」セクションで、DNリストを定義する信頼できる発行者を選択します。
「追加」をクリックして、ページの「信頼できるSAMLクライアント」、「信頼できるSTSサーバー」または「信頼できるJWTクライアント」領域に、1つ以上の信頼できるDNを追加します。RFC 2253に準拠する文字列を使用してください。たとえば、信頼できる発行者www.oracle.com
に対して、CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US
を指定します。
RFC 2253の詳細は、http://www.ietf.org/rfc/rfc2253.txt
を参照してください。
次の各項では、WLSTコマンドを使用してSAML署名証明書およびJWTトークンに対して信頼できる発行者と信頼できる識別名(DN)リストを定義する方法と、信頼できる発行者に関連付けられたリストを表示および管理する方法について説明します。
これらのWLSTコマンドの詳細は、『WebLogic Scripting Toolコマンド・リファレンス』のWebサービスのカスタムWLSTコマンドに関する項を参照してください。
WLSTを使用して信頼できる発行者およびDNリストを構成する手順は次のとおりです。
「WebサービスのカスタムWLSTコマンドへのアクセス」の説明に従って、信頼できる発行者を構成するドメイン内のサーバーの実行中のインスタンスに接続します。
setWSMTokenIssuerTrust
コマンドを使用して、信頼できる発行者を追加し、信頼できるキーまたは信頼できるDNリストを定義します。
setWSMTokenIssuerTrust(type, issuer, [trustedKeyIds=None])
各項目の意味は次のとおりです。
type
は、発行者が発行したトークンのタイプと、trustedKeyIds
で発行者署名証明書を識別する方法を示します。サポートされるタイプ値を次の表に示します。
このタイプ値の場合... | このトークン・タイプの場合... | このキー・タイプの場合... | キー識別タイプ |
---|---|---|---|
dns.sv |
SAML SV | X509証明書 | DN |
dns.hok |
SAML HOKまたはベアラー | X509証明書 | DN |
dns.jwt |
JWT | X509証明書 | DN |
issuer
は、信頼できる発行者の名前です(www.oracle.com
など)。
trustedKeyIds
はオプションの引数で、信頼できるキー識別子、つまり発行者のDNリストを指定するときに使用します。
このコマンドは次のように動作します。
指定されたタイプに対して信頼できる発行者がすでに存在する場合、trustedKeyIds
引数にDNのリストを指定すると、以前のリストが新しいリストで置き換えられます。trustedKeyIds
引数に空集合([]
)を入力すると、発行者のDN値のリストが削除されます。
指定されたタイプに対して信頼できる発行者が存在しない場合、trustedKeyIds
引数に値を指定すると、関連するDNリストで発行者が作成されます。trustedKeyIds
引数を設定しない場合は、空のDNリストで新しい発行者が作成されます。
例14-1では、www.example.com
がSAML SVトークン・タイプに対する信頼できる発行者として設定されます。DNリストは指定されていません。
例14-1 WLSTを使用したSAML送信者保証に対する信頼できる発行者の設定
wls:/base_domain/serverConfig> setWSMTokenIssuerTrust("dns.sv","www.example.com",[])
the trusted DN lists are successfully set
例14-2では、信頼できるSAML発行者www.oracle.com
のDNリストdns.sv
で、CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US'
およびCN=orcladmin, OU=Doc, O=Oracle, C=US'
がDNとして設定されます。
例14-2 WLSTを使用したSAMLの信頼できる発行者に対するDNの設定
wls:/base_domain/serverConfig> setWSMTokenIssuerTrust('dns.sv','www.oracle.com', ['CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle', 'CN=orcladmin, OU=Doc, O=Oracle, C=US']) the trusted DN lists are successfully set
例14-3では、www.example.com
がJWTトークン・タイプの信頼できる発行者として設定され、信頼できるDNがCN=weblogic1, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US'
として設定されます。
オプションで、信頼できるDNにトークン属性ルールを定義して、さらにセキュリティ制約を追加できます。詳細は、「WLSTを使用した信頼できる発行者のトークン属性ルールの構成」を参照してください。
WLSTを使用して信頼できる発行者およびDNリストを表示する手順は次のとおりです。
「WebサービスのカスタムWLSTコマンドへのアクセス」の説明に従って、信頼できる発行者を表示するドメイン内のサーバーの実行中のインスタンスに接続します。
displayWSMTokenIssuerTrust
コマンドを使用して、信頼できる発行者およびDNリストを表示します。
displayWSMTokenIssuerTrust(type, issuer=None)
type
引数とissuer
引数の値を指定すると、発行者のDNリストが表示されます。発行者名を指定しないと、指定されたタイプのすべての信頼できる発行者がリストされます。type
引数でサポートされている値は、dns.sv
、dns.hok
およびdns.jwt
です。
たとえば、タイプdns.sv
のすべての信頼できる発行者を表示する場合は、次のようにします。
wls:/base_domain/serverConfig> displayWSMTokenIssuerTrust('dns.sv')
Starting Operation displayWSMTokenIssuerTrust ...
www.example.com
www.oracle.com
タイプdns.sv
の信頼できる発行者www.oracle.com
のDNリストを表示する場合は、次のようにします。
wls:/base_domain/serverConfig> displayWSMTokenIssuerTrust('dns.sv', 'www.oracle.com')
Starting Operation displayWSMTokenIssuerTrust ...
CN=weblogic, OU=Orakey Test Encryption purposes only, O=OracleCN=orcladmin, OU=Doc, O=Oracle, C=US
deleteWSMTokenIssuerTrust
WLSTコマンドを使用して、信頼できる発行者およびそのDNリストを削除できます。
deleteWSMTokenIssuerTrust(issuer, type)
type
引数でサポートされている値は、dns.sv
、dns.hok
およびdns.jwt
です。
次の例では、発行者www.example.com
と、その発行者の信頼できるSAML送信者保証クライアント・リストdns.sv
内のDNリスト(ある場合)が削除されます。
wls:/base_domain/serverConfig> deleteWSMTokenIssuerTrust('dns.sv', 'www.example.com')
importWSMTokenIssuerTrustMetadata
WLSTコマンドを使用して、すべての信頼できる発行者のすべての信頼の構成(発行者、DNおよびトークン属性ルール)をXMLファイルからインポートできます。
importWSMTokenIssuerTrustMetadata(trustFile)
次の例では、指定したXMLファイルからすべての信頼できる構成をインポートします。
wls:/base_domain/serverConfig> importWSMTokenIssuerTrustMetadata(trustFile='/tmp/trustData.xml') Starting Operation importWSMTokenIssuerTrustMetadata ... Configuration for trusted issuers successfully imported.
exportWSMTokenIssuerTrustMetadata
WLSTコマンドを使用して、すべての信頼できる発行者のすべての信頼の構成(発行者、DNおよびトークン属性ルール)をXMLファイルにエクスポートできます。
exportWSMTokenIssuerTrustMetadata(trustFile,excludeIssuers=None)
除外リストに指定された発行者の信頼構成はエクスポートされません。引数を渡さない場合、すべての信頼できる発行者の信頼構成がエクスポートされます。
次の例では、除外されたwww.oracle.com
とwww.example.com
を除くすべての信頼できる発行者の構成が指定したXMLファイルにエクスポートされます。
wls:/base_domain/serverConfig> exportWSMTokenIssuerTrustMetadata(trustFile='/tmp/trustData.xml',['www.oracle.com','www.myissuer.com']) Starting Operation exportWSMTokenIssuerTrustMetadata ... Configuration for trusted issuers successfully exported.
revokeWSMTokenIssuerTrust
WLSTコマンドを使用して、すべての信頼できる発行者および関連する構成(DNおよびトークン属性ルール)を削除できます。
revokeWSMTokenIssuerTrust(excludeIssuers=None))
オプションの除外リストに指定された発行者は削除されません。引数を渡さない場合、すべての信頼できる発行者および関連する構成が削除されます。
次の例では、除外されたwww.oracle.com
とwww.example.com
を除くすべての信頼できる発行者の構成が削除されます。
revokeWSMTokenIssuerTrust(['www.oracle.com','www.example.com']) Starting Operation revokeWSMTokenIssuerTrust ... Configuration for trusted issuers successfully removed.
特定の信頼できるユーザーで、どのユーザーおよびユーザー属性を許容したり処理するかを制御したいという要求が増え続けています。トークン属性ルールを使用すると、信頼できるSTS (Secure Token Service)サーバーおよび信頼できるSAMLまたはJWTクライアントの追加のセキュリティ制約を定義できます。
トークン属性ルールは、信頼できるDNリストの先頭で定義できます。発行者に構成されたそれぞれの信頼できるDNに対して、トークン属性ルールを構成および適用できます。
各ルールは、名前IDと、SAMLアサーションに関連付けられた属性の属性部分という2つの部分で構成されます。名前IDおよび各属性には、複数の値パターンを持つフィルタを含めることができます。トークン内のユーザー件名ID (mail
など)と、同じユーザーを認証するためのユーザー属性(uid
など)とが異なるフェデレーテッド環境では、オプションのトークン属性マッピング機能もあります。
手順については、次の項を参照してください。
Fusion Middleware Controlを使用してトークン属性ルールを構成する手順は次のとおりです。
DNリストを定義します。Fusion Middleware ControlでのDNリストの定義の詳細は、「署名証明書の信頼できる発行者および信頼できるDNリストの定義」を参照してください。
トークン属性ルールを定義するには、「信頼できるSAMLクライアント」タブ、「信頼できるSTSサーバー」タブまたは「信頼できるJWTクライアント」タブを選択します。
図14-13に示すように、上部パネルで発行者を選択し、下部パネルでDNを選択します。
「トークン属性ルールの構成」をクリックして、図14-14に示す「トークン属性ルール」ウィンドウを表示します。
「属性」ペインで、「「追加」」をクリックしてDNの属性を追加します。
「トークン属性ルール: 属性の追加」ポップアップ・ウィンドウで、サブジェクト名IDをアサートするためにname-id
を入力し、「OK」をクリックします。
属性を選択し、「フィルタ」ペインで「追加」をクリックし、「トークン属性ルール: フィルタ値の追加」ポップアップ・ウィンドウにフィルタ値を入力して、「OK」をクリックします。
「フィルタ」フィールドに追加する値は、図14-15
に示すように、yourTrustedUserなど、完全な名前を入力できます。また、yourTrusted*
のように、ワイルドカード文字(*
)を使用した名前パターンを入力することもできます。
さらにフィルタを追加するには、前の手順を繰り返します。
オプションで、name-id
属性の「属性マッピング」フィールドを使用して、サブジェクト名IDのローカル・ユーザー属性をローカル・ユーザーの属性にマップして、信頼できるユーザーを認証できます。
注意: サブジェクトがSAMLポリシーで定義されている場合に、ユーザー属性マッピング機能を使用するには、添付ポリシーでsubject.precedence をtrueに設定する必要があります。 |
ユーザー属性 - 件名IDに対応するローカル・アイデンティティ・ストア内のユーザー属性のローカル名(mail
など)。
ユーザー属性マッピング - 認証用に件名IDがマップされるローカル・アイデンティティ・ストア内のユーザー属性のローカル名の値(uid
など)。
属性フィルタの定義が終了したら、「OK」をクリックして、「トークン属性ルール」ウィンドウを閉じます、
setWSMTokenIssuerTrustAttributeFilter
およびsetTokenIssuerTrustAttributeMapping
WLSTコマンドを使用して、信頼できるDNのトークン属性ルールを定義することにより、追加のセキュリティ制約を指定できます。属性ルールは、サブジェクト名IDに適用できます。
注意: 最初に、setWSMTokenIssuerTrust コマンドを使用して、発行者の信頼できるDN名のリストを構成する必要があります。「WLSTを使用した発行者およびそのDNリストの構成」を参照してください。 |
setWSMTokenIssuerTrustAttributeFilter
コマンドでは、名前IDおよび属性に、複数の値パターンを持つフィルタを含めることができます。
setWSMTokenIssuerTrustAttributeFilter(dn, attr-name, [filters])
setTokenIssuerTrustAttributeMapping
コマンドでは、ユーザー属性を別のユーザーIDにマップできます。
setTokenIssuerTrustAttributeMapping('DN', 'attr-name', 'mapping', 'user-attribute', 'user-mapping-attribute')
ユースケース例
次の例では、名前ID yourTrustedUser
が、信頼できるDN weblogic
の信頼できるユーザーとして設定されます。
setWSMTokenIssuerTrustAttributeFilter('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US','name-id', ['yourTrustedUser']) Starting Operation setWSMTokenIssuerTrustAttributeFilter ... The token attribute filter are successfully set
次の例では、サブジェクト名ID jdoe
を、信頼できるDN weblogic
の信頼できるユーザーのリストに追加します。
setWSMTokenIssuerTrustAttributeFilter('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US','name-id', ['yourTrustedUser', 'jdoe']) Starting Operation setWSMTokenIssuerTrustAttributeFilter ... The token attribute filter are successfully set
次の例では、トークン内のサブジェクトIDのmail
属性をuid
属性にマップします。
setTokenIssuerTrustAttributeMapping('CN=weblogic, OU=Orakey Test Encryption Purposes Only,O=Oracle, C=US','name-id','mail','uid') Starting Operation setWSMTokenIssuerTrustAttributeMapping ... The token attribute mapping are successfully set
これらのWLSTコマンドの詳細は、『WebLogic Scripting Toolコマンド・リファレンス』のWebサービスのカスタムWLSTコマンドに関する項を参照してください。
deleteWSMTokenIssuerTrustAttributeRule
WLSTコマンドを使用して、DNリストに関連するトークン属性ルールを削除できます。
deleteWSMTokenIssuerTrustAttributeRule(dn)
次の例では、信頼できるDN weblogic
に関連するトークン属性ルールが削除されます。
deleteWSMTokenIssuerTrustAttributeRule('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US')
これらのWLSTコマンドの詳細は、『WebLogic Scripting Toolコマンド・リファレンス』のWebサービスのカスタムWLSTコマンドに関する項を参照してください。
SAMLまたはJWTトークンを使用したユーザーアイデンティティ伝播のためにクライアント側のアイデンティティまたは属性マッピングをサポートするトークン属性ルールを作成できます。
電子メールなどの一般的なユーザー属性をトークンのサブジェクトとしてより簡単に使用できる可能性のある、クロス・アイデンティティ・ドメイン・ユースケースを検討してください。これには、認証済サブジェクト・プリンシパルをユーザー属性にマッピングしてトークンを作成する必要があります。そのために、各種ターゲットのマッピングを指定して管理するトークン属性ルールを作成します。
次の条件が該当する場合、ユーザー・アイデンティティ・マッピングは、SOAPまたはREST用のSAMLまたはJWTトークンを使用するすべてのクライアント・ポリシーに対してエンド・ユーザーのアイデンティティ伝播のためにサポートされます。
認証済ユーザー・サブジェクトが使用可能である。
プロパティがsubject.precedence=true
である。
クライアント・アイデンティティ・マッピングを構成するには、setWSMTokenIssuerTrustAttributeMapping
WLSTコマンドを使用します。このWLSTコマンドの詳細は、『WebLogic Scripting Toolコマンド・リファレンス』のWebサービスのカスタムWLSTコマンドに関する項を参照してください。
setWSMTokenIssuerTrustAttributeMapping('http://oracle.com', 'name-id', ’', ’mail')
この場合:
http://oracle.com
は、変更が行われるトークン属性ルールに対するルールの識別子(URLパターン)です。
name-id
は、マッピングが宛先に向かうSAMLまたはJWTトークンのサブジェクトname id
に適用されることを示しています。
空白。オプション。属性の値に対応するローカル・ユーザー属性の名前。
mail
は、マップ先のローカル・ユーザー属性の名前です。
識別子はURLパターンです。サービスURLを指定すると、トークン属性ルールの識別子がサービスURLの一部である場合、ルールがサービスURLに適用されます。
http(s)://host; http(s)://host/<root path>
マッピング・ルールは、ターゲット・サービスURLがルートとして識別子を持つすべてのWebサービス呼出しに適用されます。
次の場合、URL u1
は、URL u2
の一部であるとみなされます。
u1
とu2
のプロトコルが一致する。
u1
とu2
のホストが一致する。
u1
のパスが使用可能な場合、u2
のパスがu1
のパスで始まる。
複数のルール(rule-1、rule-2、…、rule-n)がサービスURLに適用される場合、他のすべてのルールの識別子を含む識別子を持つルールが、他のルールよりも優先されます。
マッピング・ルールの例
次の2つのルールがあるとします。
Rule 1: setWSMTokenIssuerTrustAttributeMapping('http://oracle.com', 'name-id', ' ', 'mail') Rule2: setWSMTokenIssuerTrustAttributeMapping('http://oracle.com/root1', 'name-id', ' ', 'uid')
サービスURL = http://oracle.com/root1/service1
を使用するWebサービス・コールの場合、Rule 1
とRule 2
の両方がサービスに適用されます。ただし、Rule 2
が優先され、実行時に適用されます。
管理ポートを使用するようドメインが構成されている場合、管理者が実行するすべてのタスクはこのポートを経由する必要があります。デフォルトでは、Oracle WSM Policy Managerのターゲットは管理対象サーバーです。管理ポートでポリシー・マネージャを使用するには、ポリシー・マネージャのターゲットを管理対象サーバーおよび管理サーバーにする必要があります。
管理ポートの詳細は、次のトピックを参照してください。
Oracle WebLogic Serverサーバー環境の構成のネットワーク・チャネルの概要に関する項。
Oracle WebLogic Server管理コンソールのヘルプのドメイン全体の管理ポートの構成に関する項。
ドメイン全体の管理ポートでOracle WSMを構成する手順は、次の2つに大きく分けられます。
手順1:WebLogic管理コンソールを使用して、ポリシー・マネージャのターゲットに管理サーバーを指定します。
「Oracle WebLogic管理コンソールへのアクセス」の説明に従って、Weblogic管理コンソールにアクセスします。
または、Fusion Middleware Controlで、WebLogicドメインのホーム・ページからWebLogic管理コンソールにアクセスすることもできます。その手順は、次のとおりです。
「Oracle Enterprise Manager Fusion Middleware Controlへのアクセス」の説明に従って、Fusion Middleware Controlにログインします。
ナビゲータ・ペインで「WebLogicドメイン」を開き、管理コンソールにアクセスする対象のドメインを選択します。
WebLogicドメインのホーム・ページが表示されます。
「WebLogicドメイン」メニューから、「WebLogic Server管理コンソール」を選択します。または、ページの「サマリー」セクションにある「Oracle WebLogic Server管理コンソール」リンクをクリックします。
「ようこそ」ページで、有効なユーザー名とパスワードを使用してログインします。
管理コンソールの左ペインで、「デプロイメント」をクリックします。すべてのデプロイ済みのエンタープライズ・アプリケーションとアプリケーション・モジュールを示す表が右ペインに表示されます。
この表で、ターゲットの再指定を行うwsm-pmアプリケーションを見つけて、その名前をクリックします。アプリケーションを見つけるには、「次」を数回クリックする必要がある場合があります。
アプリケーションの「設定」ページが表示されます。
「ターゲット」タブをクリックします。
表の「現在のターゲット」列に、ポリシー・マネージャ・アプリケーションのターゲットであるサーバーが表示されます。
wsm-pmアプリケーションのターゲットをAdminServerにするには、「ターゲットの変更」をクリックします。
「サーバー」ボックスで、「AdminServer」がまだ選択されていない場合はこれを選択し、「はい」をクリックします。
変更は自動的にアクティブ化されます。
手順2:Fusion Middleware Controlを使用して、管理サーバー上のポリシー・マネージャのポリシー・アクセッサURLを指定します。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
「ポリシー・アクセッサ」タブを選択します。
「追加」をクリックして、管理サーバーのJNDIプロバイダURLを指定します。
「プロパティの追加」ウィンドウで、次の値を指定します。
「名前」フィールドで、JNDIプロバイダURLプロパティをjava.naming.provider.url
として入力します。
「値」フィールドで、管理サーバーのJNDIプロバイダのURLを入力ます。たとえば、t3s://
host
:
admin_port
/wsm-pm
と入力します。
たとえば、t3s://localhost:9002/wsm-pm
と入力します。
管理サーバーのオーバーライド・ポートが構成されている場合は、次を使用します。
t3s://
admin_server
:
admin_server_override_port
これは、管理サーバー上で実行中のポリシー・マネージャの場所を指定します。
注意: オーバーライド・ポートを使用する場合、ポリシー・マネージャのバリデータ・ページは、オーバーライド・ポートではなく、https://
admin_server_host
:normal_https_port
/wsm-pm
に配置されます。詳細は、「Oracle WSM Policy Managerでの問題の診断」を参照してください。
「OK」をクリックします。
リプレイ攻撃から保護するために、ポリシーwss_username_token_client_policy
およびwss_username_token_service_policy
には、ユーザー名トークンにNonceを必要とするオプションがあります。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。
Nonceは再使用を防ぐためにキャッシュされます。ただし、クラスタ環境では、このキャッシュを管理対象サーバー間で同期化する手順が必要になります。そうしないと、Webサービスに送信されて1つのサーバーで実行中のリクエストが、リプレイされて別の管理対象サーバーに送信され、そこで処理される可能性があります。Oracle WSMは、Javaオブジェクト・キャッシュ(JOC)のインスタンスを使用してNonceをキャッシュします。
PythonスクリプトORACLE_HOME/bin/configure-joc.pyを使用して、分散モードのすべての管理対象サーバーでJOCを構成します。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが起動されて実行中であることが必要です。
注意: Javaオブジェクト・キャッシュの構成後、構成を反映するために影響を受けるすべての管理対象サーバーを再起動してください。 |
分散モードでJOCを有効にするには、次の手順を実行します。
コマンドラインのOracle WebLogic Scripting Tool(WLST)を使用して、管理サーバーに接続します。たとえば、次のようにします。
ORACLE_HOME/oracle_common/common/bin/wlst.sh $ connect()
プロンプトが表示されたら、Oracle WebLogic管理サーバーのユーザー名とパスワードを入力します。
WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。たとえば、次のようにします。
wls:/mydomain/serverConfig>execfile('ORACLE_HOME/bin/configure-joc.py')
指定されたクラスタのすべての管理対象サーバーに対してJOCを構成します。
スクリプトにより、クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら「y」と入力し、さらにプロンプトが表示されたらクラスタ名と検出ポートを指定します。これにより、指定されたクラスタのすべての管理対象サーバーが検出され、各管理対象サーバーに対してJOCが構成されます。検出ポートは、クラスタ内のJOC構成全体で共通です。たとえば、次のようにします。
Do you want to specify a cluster name (y/n) <y> Enter Cluster Name : Spaces_Cluster Enter Discover Port : 9988
ここに、HA環境でのconfigure-joc.pyの使用例を1行ずつ順に記載します。
execfile('ORACLE_HOME/bin/configure-joc.py') . Enter Hostnames (eg host1,host2) : SOAHOST1, SOAHOST2 . Do you want to specify a cluster name (y/n) <y>y . Enter Cluster Name : Spaces_Cluster . Enter Discover Port : 9988 . Enter Distribute Mode (true|false) <true> : true . Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
スクリプトを使用して、次のJOC構成を実行することもできます。
指定されたすべての管理対象サーバーに対してJOCを構成します。
スクリプトにより、クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら「y」と入力し、そしてプロンプトが表示されたらクラスタ名と検出ポートも指定します。たとえば、次のようにします。
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (eg WLS_Spaces1:9988, WLS_Spaces2:9988) : WLS_Spaces1:9988,WLS_Spaces2:9988
特定の管理対象サーバーのJOC構成を除外します。
スクリプトにより、JOC構成「DistributeMode」を「false」に設定する管理対象サーバーのリストを指定できます。スクリプトにより特定のサーバーをJOC構成から除外するかどうかを尋ねるプロンプトが表示されたら「y」と入力し、そしてプロンプトが表示されたら除外する管理対象サーバー名を入力します。たとえば、次のようにします。
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WLS_Spaces1,WLS_Spaces3
すべての管理対象サーバーに対して分散モードを無効にします。
スクリプトにより、指定されたクラスタのすべての管理対象サーバーに対して分散を無効化できます。スクリプトにより分散モードに対するプロンプトが表示されたら、「false」を指定します。デフォルトでは、分散モードは「true」に設定されます。
CacheWatcherユーティリティを使用してJOC構成を検証します。詳細は、『Oracle Fusion Middleware高可用性ガイド』のCacheWatcherの実行に関する項を参照してください。
『Oracle Fusion Middleware高可用性ガイド』の「HAパワー・ツールの使用」で説明されているように、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成できます。
Oracle WSMエージェント・ランタイムは、デフォルトではOracleSystemUserアカウントを使用して、サーバーとの通信を行います。
異なるデフォルト・ユーザーを構成するには、次の各手順を実行します。
認証プロバイダの構成
認証プロバイダを構成するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する項の説明に従って、認証プロバイダを構成します。
構成しているレルムの名前を選択します(たとえば、myrealm)。
「新しい認証プロバイダの作成」ページで、認証プロバイダの名前を入力し(たとえば、OID)、タイプとしてOracle Internet Directoryオーセンティケータを選択します。
「設定」セクションで、「制御フラグ」を「オプション」に設定します。
「プロバイダ固有」タブで、次の情報を入力します。
ホスト: LDAPプロバイダURL
ポート: ポート番号
プリンシパル: 管理ユーザーの詳細(新しいデフォルト・ユーザー)
例: CN=orcladmin,CN=Users,DC=us,DC=oracle,DC=com
資格証明: LDAPのパスワード
資格証明の確認: LDAPのパスワード
ユーザー・ベースDN
例: CN=Users,DC=us,DC=oracle,DC=com
グループ・ベースDN
例: CN=Groups,DC=us,DC=oracle,DC=com
WebLogic Serverを再起動します。
資格証明ストア・プロバイダの構成
「資格証明ストアへの鍵およびユーザー資格証明の追加」の説明に従って、次のパラメータを使用して、資格証明ストア・プロバイダを構成します。
マップがまだない場合は、「マップの作成」を選択し、マップ名oracle.wsm.security
を入力します。
「資格証明ストア・プロバイダ」表で、oracle.wsm.security
を選択します。
「キーの作成」ダイアログで、適切なキーを入力します(たとえば、OID
)。新しいデフォルト・ユーザーのユーザー名とパスワードを入力します(この例では、orcladmin
およびpassword)。
プラットフォーム・ポリシー構成の設定
プラットフォーム・ポリシーを構成するには、次の手順を実行します。
新しいデフォルト・ユーザーのアカウントでFusion Middleware Controlにログインします。
ナビゲータ・ペインで 「WebLogicドメイン」 を開いてドメインを表示します。
プロパティを管理するドメインを選択します。
「WebLogicドメイン」→「Webサービス」→「プラットフォーム・ポリシー構成」を選択します。
「プラットフォーム・ポリシー構成」ページが表示されます。
「ポリシー・アクセッサ」タブを選択します。
「ポリシー・アクセッサ・プロパティ」セクションで、「追加」をクリックします。
「新規構成プロパティの追加」ダイアログで、次の情報を入力します。
名前をjndi.lookup.csf.keyと入力します。このプロパティは、資格証明の構成(java.naming.security.principalおよびjava.naming.security.credentials)を指定し、LDAPディレクトリ内のアカウントが、Oracle WSM Policy Managerを使用して接続するよう構成されている場合に使用されます。
値を入力します(この例では、OID)。
注意: この手順で指定するcsf-keyは、資格証明ストア内でポリシー・マネージャの管理ユーザー用に指定されているcsf-keyに一致する必要があります。詳細は、「資格証明ストア・プロバイダの構成」を参照してください。 |
「OK」をクリックします。
「適用」をクリックして、WebLogic Serverを再起動します。
ユーザーのグループまたはロールの変更
Oracle WSM Policy Managerでは、論理ロール(policy.Accessor)を使用して、Oracle WSMエージェント・ランタイムがポリシーにアクセスするためにアクセスするEJBを保護します。デフォルトでは、policy.AccessorロールはOracleSystemGroupグループとAdministratorsグループにマップされます。Oracle WSMエージェント・ランタイムは、OracleSystemUserアイデンティティを使用してwsm-pmにアクセスします。新しいデフォルト・ユーザーは、AdministratorまたはOracleSystemGroupグループに含まれるか(グループが存在する場合)、論理ロールのpolicy.Accessorにマップされる必要があります(AdministratorまたはOracleSystemGroupグループが存在しない場合)。
ユーザーに必要なロールがあることを確認するには、次の手順を実行します。
AdministratorまたはOracleSystemGroupグループがLDAPまたはアイデンティティ・ストアに存在する場合は、次の手順を実行します。
LDAPで、デフォルトの管理ユーザーとして使用するユーザーを追加します。
WebLogic Server管理コンソールで、ユーザーがAdministratorグループに存在することを確認します。詳細は、Oracle WebLogic Server管理コンソールのヘルプのユーザーとグループの管理に関する項を参照してください。
AdministratorまたはOracleSystemGroupグループがLDAPまたはアイデンティティ・ストアに存在しない場合は、新しいユーザーを必要な論理ロールにマップし、変更されたデプロイ・プランを使用してwsm-pmアプリケーションを再デプロイします。新しいユーザーまたは既存のユーザー(AdministratorまたはOracleSystemGroup以外のグループに属する)をマップするには、次の手順を実行します。
wsm_pm.earをデプロイするデプロイ・プランを作成します。例14-4は、サンプルのデプロイ・プランを示しています。WebLogicに付属のサンプルのデプロイ・プランは、ORACLE_HOME/modules/oracle.wsm.pm_11.1.1/provフォルダにあります。セクション@to_be_replaced@
を新しいユーザーで変更します。
例14-4 サンプル・デプロイメント・プラン
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan
http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
<application-name>oracle.wsm.pm_11.1.1</application-name>
<variable-definition>
<variable>
<name>SecurityRoleAssignment_ejbRole_PrincipalName</name>
<value>@to_be_replaced@</value>
</variable>
</variable-definition>
<module-override>
<module-name>wsm-pmserver-wls.jar</module-name>
<module-type>ejb</module-type>
<module-descriptor external="false">
<root-element>weblogic-ejb-jar</root-element>
<uri>META-INF/weblogic-ejb-jar.xml</uri>
<variable-assignment>
<name>SecurityRoleAssignment_ejbRole_PrincipalName</name>
<xpath>/weblogic-ejb-jar/security-role-assignment/[role-name="policy.Accessor"]
/principal-name</xpath>
<operation>replace</operation>
</variable-assignment>
</module-descriptor>
</module-override>
</deployment-plan>
EARを再デプロイします。
詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのデプロイ・プランによるアプリケーションのデプロイに関する項を参照してください。
デフォルトでは、JMSシステム・ユーザーはOracleSystemUserとして設定されます。大多数のユーザーにとっては、このデフォルト値で十分です。ただし、この値をセキュリティ・レルム内のカスタム・ユーザーに変更する必要がある場合は、次の手順に従ってOracle Enterprise Manager Fusion Middleware ControlおよびWebLogic Server管理コンソールでユーザーの値を変更することにより、これを行うことができます。
JMSシステム・ユーザーを変更する手順
「非同期Webサービスの構成」で説明されているように、非同期Webサービスの「Webサービス・エンドポイント」ページで「構成」タブにアクセスします。
JMSシステム・ユーザーフィールドにカスタム・ユーザーの名前を入力し、「適用」をクリックします。図14-17を参照してください。
注意: カスタム・ユーザーは、セキュリティ・レルムに存在し、JMSリソースにアクセスするのに必要な権限を持つ必要があります。 |
WebLogic Server管理コンソールにアクセスします。Fusion Middleware Controlからアクセスするには、ナビゲータ・ペインでドメインを選択します。「WebLogicドメイン」メニューから、「WebLogic Server管理コンソール」を選択します。
必要な管理者権限を持つ有効なユーザー名とパスワードを使用して、WebLogic Server管理コンソールにログインします。
「ドメイン構造」ペインで「デプロイ」をクリックし、対応するMDB、service
_AsynchRequestProcessorMDB
またはservice
_AsynchResponseProcessorMDB
に移動します。これらのMDB名では、service
は、ユーザー名を変更する非同期サービスの名前です。
「チェンジ・センター」で、「ロックして編集」を選択します。
リクエストまたはレスポンスMDBのMDB名を選択します。(リクエストMDBとレスポンスMDBの両方のユーザー名を更新する必要があります。)「設定」ページで、「構成」タブを選択します。
ページの「エンタープライズBean構成」セクションで、プリンシパル名として実行フィールドにカスタム・ユーザー名を入力し、「保存」をクリックします。図14-18を参照してください。
このフィールドに入力するユーザー名は、Fusion Middleware ControlのJMSシステム・ユーザーに入力したユーザー名と一致している必要があることに注意してください。
構成の変更内容は、新しいデプロイ・プランに保存する必要があります。
「デプロイメント・プラン保存アシスタント」を使用して、新しいデプロイ・プランを保存します。
2番目のMDBに対して手順7と8を繰り返します。変更内容は新しいデプロイ・プランに自動的に保存されます。
「チェンジ・センター」で、「変更のアクティブ化」をクリックします。
アプリケーションを再デプロイします。詳細は、第5章 「Webサービス・アプリケーションのデプロイ」を参照してください。