| Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド 11g リリース1(11.1.1.7) B56247-06 |
|
 戻る |
 次へ |
この章では次の項について説明します。
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からサービスを登録できます。
|
注意: 作成された各新規ソースには、親ソース名に |
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つ以上に分割されている場合(特に、ファイアウォールがネットワーク間に存在する場合)。
異なるドメインで実行しているOracle WSMポリシー・マネージャに(追加のWebLogicセキュリティ構成を設定せず)アクセスする場合。
WebSphere Application Serverなど、自動検出機能をサポートしないWebLogic以外のアプリケーション・サーバーで実行中の場合。
デフォルト設定をオーバーライドする場合。
Oracle Infrastructure Webサービス・ポリシーの場合、「プラットフォーム・ポリシー構成」ページで、次の操作を行えます。
「ポリシー・アクセッサ」タブでリモートJNDIプロバイダURLおよび対応するcsf-key資格証明を明示的に設定して、リモート・ドメイン内または別のプラットフォーム上のポリシー・マネージャにアクセスできます。
「 ポリシー・キャッシュ」タブでWebサービス・エンドポイントのポリシー・キャッシュの遅延の動作をチューニングして、ネットワーク・コールを回避し、リモートのOracle WSM Policy Managerからポリシーをフェッチする場合のパフォーマンスを向上できます。
リモートのOracle WSM Policy ManagerのWebサービスを構成し、ポリシー・キャッシュをチューニングする手順は、次のとおりです。
Oracle WSM Policy ManagerがWebサービス・クライアントとは異なるドメインにある場合のように、異なるドメイン内のOracle WSM Policy Managerにアクセスするには、Securing Oracle WebLogic Serverの保護のWebLogic Serverドメイン間でのクロス・ドメイン・セキュリティの有効化に関する項に従って、WebLogic Serverドメイン間でクロス・ドメイン・セキュリティを有効にします。
クロス・ドメイン・セキュリティは2つのWebLogicドメイン間の信頼性を確立します。そのためには、資格証明マッパーを使用して、これらのWebLogicドメイン間の通信を構成します。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
「ポリシー・アクセッサ」タブを選択します。
「追加」をクリックして、リモートJNDIプロバイダを定義します。
「プロパティの追加」ウィンドウで、次の値を指定します。
「名前」フィールドで、JNDIプロバイダURLプロパティをjava.naming.provider.urlとして入力します。
「値」フィールドで、リモート・ドメインのJNDIプロバイダのURLを入力ます。たとえば、t3://host:portと入力します。
これは、異なるドメインにある実行中のポリシー・マネージャの場所を指定して、そのポリシー・マネージャにアクセスできるようにします。このプロパティが指定されていないと、自動検出機能は同じドメインにあるPolicy Managerを検索しようとします。
「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リポジトリの間の接続を構成できます。
構成管理システムは、ポリシー・マネージャに定期的に接続します(たとえば、接続情報が変化する状況に対処するため)。ランタイムが再接続を試みたときにポリシー・マネージャが停止している場合は、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リポジトリ接続のチューニング・プロパティ
| プロパティ | 説明 | デフォルト |
|---|---|---|
|
|
Oracle WSMリポジトリへの接続が失敗した後に接続を再試行するまでの待機時間(ミリ秒数)。 |
600000ミリ秒(10分) |
|
|
最初のキャッシュ・リフレッシュまでの待機時間(ミリ秒数)。 |
600000ミリ秒(10分) |
|
|
次のキャッシュ・リフレッシュまでの待機時間(ミリ秒数)。 |
600000ミリ秒(10分) |
|
|
不足ドキュメントの取得を試行するまでの待機時間(ミリ秒数)。 |
15000ミリ秒 |
|
|
使用状況データを送信するまでの待機時間(ミリ秒数)。 |
30000ミリ秒 |
|
|
通信失敗後に再試行する回数。 |
2 (再試行回数) |
|
|
次の再試行までの待機時間(ミリ秒数)。デフォルトは5000ミリ秒です。 |
必要な変更を入力して、「OK」をクリックします。
必要に応じて残りのプロパティを編集し、「適用」をクリックしてプロパティの更新を適用します。
「ポリシー・インターセプタ」タブのBindingSecurityInterceptorプロパティを使用して、システム・クロック間のデフォルト・メッセージ・タイムスタンプの時間差、ポリシー・キャッシュ内のnonceメッセージの存続時間、およびメッセージの有効期限を調整することにより、セキュリティ・ポリシー強制をチューニングできます。
セキュリティ・ポリシー強制をチューニングする手順は、次のとおりです。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
「ポリシー・インターセプタ」タブを選択します。
リストでBindingSecurityInterceptorセキュリティ・プロパティを選択します。
表14-5は、Webサービス・セキュリティ・ポリシー強制をチューニングするために設定できるプロパティを示しています。
BindingSecurityInterceptorセキュリティ・プロパティを変更するには、それを選択してから「編集」をクリックします。「プロパティの編集」ウィンドウで、「値」フィールドを編集して各プロパティのデフォルト値を変更し、「OK」をクリックします。
表14-5 Webサービス・セキュリティ・ポリシー強制のチューニング・プロパティ
| プロパティ | 説明 | デフォルト |
|---|---|---|
|
|
クライアント・マシンとサーバー・マシンの間での時間差の許容範囲(秒単位)。たとえば、メッセージのタイムスタンプがタイムゾーンの異なるサービスに送信された場合に、このプロパティで指定された許容時間が許容されます。 次の場合に
|
|
|
|
SAMLトークンの生成における 注意: デフォルトでは、このプロパティはBindingSecurityInterceptorインターセプタ・プロパティの表に表示されません。プロパティ値を変更するには、表にプロパティを追加します。そのためには、「追加」をクリックし、「名前」フィールドにagent.client.clock.skewを設定し、「値」フィールドに目的の値を設定して、「OK」をクリックします。 |
|
|
|
Nonceがメッセージで送信されるときの、キャッシュ内でのNonceの合計存続時間(秒単位)。このプロパティにより、Nonceはキャッシュされ、この時間を超えるとキャッシュから削除されます。 注意: ユーザー名トークンの設定では、リプレイ攻撃を避けるために、「必要な作成時間」および「必要なNonce」の両方のプロパティを有効にする必要があります。「必要なNonce」のみが有効な場合、Nonceはリプレイ攻撃を避けるために永久にキャッシュされます。また、 |
|
|
|
メッセージが作成されてから期限切れになるまでの時間(秒単位)。このプロパティは、タイムスタンプがSOAPヘッダーで送信される場合に、タイプスタンプが期限切れかどうかを検証するために使用されます。 クライアントとサービスのクロックの間に時間差がない場合でも、サービスが受信したときにメッセージが期限切れの場合は、メッセージの有効期限を増加する必要があります。メッセージの有効期限は、agent.expiry.timeおよび受信メッセージ内の有効期限の値に基づき、2つのうちの小さい方の値になります。たとえば、サーバーのagent.expiry.timeが5分に設定されていて、受信メッセージの有効期限が6分の場合、サービス側のagent.expiry.timeを増加する必要があります。一方、サーバーのagent.expiry.timeが5分で、受信メッセージの有効期限が3分の場合は、受信メッセージ(つまり、クライアント側)の有効期限を増加する必要があります。agent.expire.timeの値が高いほど、セキュリティが脆弱になる可能性があります。 |
|
|
|
Oracle WSMがすべてのタイプのXPath変換を許容するかどうかを指定するプロパティ。デフォルトでは、Oracle WSMが(受信soapメッセージ内の)署名内で許容するXPath変換は 注意: このプロパティを有効化すると、XPathベースのDoS攻撃または他の類似のXPathベースのセキュリティ脆弱性が生じる可能性があります。 |
|
既存のプロパティを削除するには、それを選択してから「削除」をクリックします。
「適用」をクリックしてプロパティの更新を適用します。
アイデンティティ拡張タブのプロパティにより、WSDLのX509資格証明をパブリッシュしてWebサービス・ポリシーを強制するかどうかを指定できます。X509証明書を公開する必要がない場合は(たとえばSSLの場合など)、デフォルトの設定をオーバーライドして証明書を公開しないようにすることができます。さらに、X509証明書をパブリッシュする場合は、ホスト名検証機能を無視するかどうかも指定できます。
詳細は、「サービス・アイデンティティ証明拡張の使用」を参照してください。
「信頼できるSAMLクライアント」タブおよび「信頼できるSTSサーバー」タブで、SAML署名証明書の、SAMLの信頼できる発行者および信頼できる識別名(DN)のリストを定義できます。
SAML発行者を追加するには、この方法を使用することをお薦めします。ここで定義するSAML発行者のリストが、このドメイン内のすべてのWebサービスに適用されるデフォルト・リストになります。また、この方法で発行者を追加する場合、ドメインの再起動は必要ありません。
|
注意: 信頼できる発行者の決定方法は、次の順位で決められます。
|
デフォルトでは、Oracle WSMは、受信した発行者名を構成済の発行者のリストと照合してチェックし、SAML署名をOracle WSMキーストアにある構成済の証明書と照合してチェックします。また、信頼できるDNリストを定義する場合は、SAML署名がその発行者に関連付けられている特定の証明書に基づいて署名されているかどうかが検証されます。
信頼できるDNリストの構成はオプションです。詳細な制御を必要とするユーザーは、これにより各発行者を1つ以上の署名証明書のリストに関連付けることができます。信頼できる発行者のDNリストが定義されていない場合、証明書がOracle WSMキーストアに存在する証明書によって信頼されているかぎり、その証明書に基づいて署名できます。
重要な注意事項:
「信頼できるSAMLクライアント」タブおよび「信頼できるSTSサーバー」では、証明書自体ではなく、署名証明書のDNを定義します。
証明書は、Oracle WSMキーストアにインポートするか、メッセージに挿入する必要があります。証明書をメッセージに挿入する場合は、その発行者をOracle WSMキーストアにインポートする必要があります。
双方向SSLの場合は、次のようにします。
Java EEコンテナのトラスト・ストアに証明書をインポートする必要があります。
検証にはクライアントSSL証明書のDNを使用します。このDNは信頼できるDNリストに存在している必要があります。
どのような場合も、署名証明書はOWSMキーストアに存在する証明書によって信頼されている必要があります。
Fusion Middleware ControlまたはWLSTを使用して、信頼できるSAML発行者およびDNリストを定義できます。
SAML署名証明書の信頼できるDNリストを定義する手順は、次のとおりです。
「プラットフォーム・ポリシー・プロパティの構成」で説明されているように、「プラットフォーム・ポリシー構成」ページにアクセスします。
信頼できるSAMLクライアントと信頼できるSTSサーバーのどちらの信頼できるDNリストを定義するかに応じて、「信頼できるSAMLクライアント」タブまたは「信頼できるSTSサーバー」タブを選択します。(SAML送信者保証の場合は、信頼できるSAMLクライアント・リストを使用します。HOKおよびBearerの場合は、信頼できるSTSサーバー・リストを使用します。)図14-12を参照してください。
ページの「信頼できる発行者」セクションで、信頼できる発行者を1件以上追加します。
デフォルト値はwww.oracle.comです。
「追加」をクリックして、新しい信頼できる発行者を追加します。たとえば、www.yourcompany.comを追加します。
ページの「信頼できる発行者」セクションで、DNリストを定義する信頼できる発行者を選択します。
「追加」をクリックして、ページの「信頼できるSAMLクライアント」または「信頼できるSTSサーバー」領域に、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発行者に関連付けられたDNリストを構成、表示および削除する方法について説明します。
setWSMTokenIssuerTrust WLSTコマンドを使用して、信頼できるSAML発行者の信頼できるDNリストを設定できます。
setWSMTokenIssuerTrust(type, issuer, [trustedDNs])
trustedDNs引数はオプションです。この引数が設定されない場合、信頼できる発行者のみが、指定のDNリストに設定されます。trustedDNs引数に空集合([])を入力すると、発行者からDN値のリストが削除されます。
次の例では、www.yourcompany.comが信頼できる発行者として設定されます。DNリストは指定されていません。
setWSMTokenIssuerTrust("dns.sv","www.yourcompany.com")The trusted DN lists are successfully set
次の例では、CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US'およびCN=orcladmin, OU=Doc, O=Oracle, C=US'が、信頼できるSAML発行者www.oracle.comのDNリストdns.svにDNとして設定されます。
setWSMTokenIssuerTrust('dns.sv','www.oracle.com', ['CN=weblogic, OU=Orakey Test Encryption Purposes Only,
O=Oracle, C=US', 'CN=orcladmin, OU=Doc, O=Oracle, C=US'])
the trusted DN lists are successfully set
displayWSMTokenIssuerTrust WLSTコマンドを使用して、指定の発行者に関連するDNリストの名前を表示できます。
displayWSMTokenIssuerTrust(type, issuer)
issuer引数はオプションです。issuerが設定されない場合、すべての信頼できる発行者のリストが表示されます。
次の例では、信頼できる発行者www.oracle.comの、信頼できるSAML送信者保証クライアント・リストdns.sv内のDNリストが表示されます。
displayWSMTokenIssuerTrust('dns.sv', 'www.oracle.com')
Starting Operation displayWSMTokenIssuerTrust ...
CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US
CN=orcladmin, OU=Doc, O=Oracle, C=US
次の例では、信頼できるSAML送信者保証クライアント・リストdns.svに関連する、すべての信頼できるSAML発行者の名前が表示されます。
displayWSMTokenIssuerTrust('dns.sv', None)
Starting Operation displayWSMTokenIssuerTrust ...
www.oracle.com
www.yourcompany.com
deleteWSMTokenIssuerTrust WLSTコマンドを使用して、信頼できるSAML発行者およびそのDNリストを削除できます。
deleteWSMTokenIssuerTrust(issuer, type)
次の例では、発行者www.yourcompany.comと、その発行者の信頼できるSAML送信者保証クライアント・リストdns.sv内のDNリスト(ある場合)が削除されます。
deleteWSMTokenIssuerTrust('dns.sv', 'www.yourcompany.com')
特定の信頼できるユーザーで、どのユーザーおよびユーザー属性を許容したり処理するかを制御したいという要求が増え続けています。トークン属性ルールを使用すると、信頼できるSTS (Secure Token Service)サーバーおよび信頼できるSAMLクライアントの追加のセキュリティ制約を定義できます。T
トークン属性ルールは、信頼できるDNリストの先頭で定義できます。発行者に構成されたそれぞれの信頼できるDNに対して、トークン属性ルールを構成および適用できます。
各ルールには、署名証明書のDNがアサートできる、ユーザー属性の名前IDおよび属性部の2つの部分があります。名前IDおよび属性には、複数の値パターンを持つフィルタを含めることができます。手順については、次の項を参照してください。
Fusion Middleware Controlを使用してトークン属性ルールを定義するには、次の手順を実行します。
DNリストを定義します。Fusion Middleware ControlでのDNリストの定義の詳細は、「署名証明書の信頼できる発行者および信頼できるDNリストの定義」を参照してください。
トークン属性ルールを定義するには、「信頼できるSAMLクライアント」タブまたは「信頼できるSTSサーバー」タブを選択します。
図14-13に示すように、上部パネルで発行者を選択し、下部パネルでDNを選択します。
「トークン属性ルールの構成」をクリックして、図14-14に示す「トークン属性ルール」ウィンドウを表示します。
「属性」ペインで、「「追加」」をクリックしてDNの属性を追加します。
「トークン属性ルール: 属性の追加」ポップアップ・ウィンドウで、サブジェクト名IDをアサートするname-idを入力し、「OK」をクリックします。
属性を選択し、「フィルタ」ペインで「追加」をクリックし、「トークン属性ルール: フィルタ値の追加」ポップアップ・ウィンドウにフィルタ値を入力して、「OK」をクリックします。
「フィルタ」フィールドに追加する値は、図14-15に示すように、yourTrustedUserなど、完全な名前を入力できます。また、yourTrusted*のように、ワイルドカード文字(*)を使用した名前パターンを入力することもできます。
さらにフィルタを追加するには、前の手順を繰り返します。
属性フィルタの定義が終了したら、「OK」をクリックして、「トークン属性ルール」ウィンドウを閉じます、
setWSMTokenIssuerTrustAttributeFilter WLSTコマンドを使用して信頼できるDNのトークン属性ルールを定義することにより、追加のセキュリティ制約を指定できます。属性ルールは、サブジェクト名IDに適用できます。
|
注意: 最初に、 |
setWSMTokenIssuerTrustAttributeFilter(dn, attr-name, [filters])
次の例では、名前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
次の例では、信頼できるDN weblogicの信頼できるユーザーのリストが削除されます。
setWSMTokenIssuerTrustAttributeFilter('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US', 'name-id', [])
The token attribute filter are successfully set
deleteWSMTokenIssuerTrustAttributeRule WLSTコマンドを使用して、DNリストに関連するトークン属性ルールを削除できます。
deleteWSMTokenIssuerTrustAttributeRule(dn)
次の例では、信頼できるDN weblogicに関連するトークン属性ルールが削除されます。
deleteWSMTokenIssuerTrustAttributeRule('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US')
管理ポートを使用するようドメインが構成されている場合、管理者が実行するすべてのタスクはこのポートを経由する必要があります。デフォルトでは、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と入力します。
これは、管理サーバーで実行しているポリシー・マネージャの場所を指定します。
「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およびwelcome1)。
プラットフォーム・ポリシー構成の設定
プラットフォーム・ポリシーを構成するには、次の手順を実行します。
新しいデフォルト・ユーザーのアカウントで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-1は、サンプルのデプロイ・プランを示しています。WebLogicに付属のサンプルのデプロイ・プランは、ORACLE_HOME/modules/oracle.wsm.pm_11.1.1/provフォルダにあります。セクション@to_be_replaced@を新しいユーザーで変更します。
例14-1 サンプルのデプロイ・プラン
<?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-16を参照してください。
|
注意: カスタム・ユーザーは、セキュリティ・レルムに存在し、JMSリソースにアクセスするのに必要な権限を持つ必要があります。 |
WebLogic Server管理コンソールにアクセスします。Fusion Middleware Controlからアクセスするには、ナビゲータ・ペインでドメインを選択します。「WebLogicドメイン」メニューから、「WebLogic Server管理コンソール」を選択します。
必要な管理者権限を持つ有効なユーザー名とパスワードを使用して、WebLogic Server管理コンソールにログインします。
「ドメイン構造」ペインで「デプロイ」をクリックし、対応するMDB、service_AsynchRequestProcessorMDBまたはservice_AsynchResponseProcessorMDBに移動します。これらのMDB名では、serviceは、ユーザー名を変更する非同期サービスの名前です。
「チェンジ・センター」で、「ロックして編集」を選択します。
リクエストまたはレスポンスMDBのMDB名を選択します。(リクエストMDBとレスポンスMDBの両方のユーザー名を更新する必要があります。)「設定」ページで、「構成」タブを選択します。
ページの「エンタープライズBean構成」セクションで、プリンシパル名として実行フィールドにカスタム・ユーザー名を入力し、「保存」をクリックします。図14-17を参照してください。
このフィールドに入力するユーザー名は、Fusion Middleware ControlのJMSシステム・ユーザーに入力したユーザー名と一致している必要があることに注意してください。
構成の変更内容は、新しいデプロイ・プランに保存する必要があります。
「デプロイメント・プラン保存アシスタント」を使用して、新しいデプロイ・プランを保存します。
2番目のMDBに対して手順7と8を繰り返します。変更内容は新しいデプロイ・プランに自動的に保存されます。
「チェンジ・センター」で、「変更のアクティブ化」をクリックします。
アプリケーションを再デプロイします。詳細は、第5章 「Webサービス・アプリケーションのデプロイ」を参照してください。
