| Oracle® Fusion Middleware Oracle WebCenter Content: Imagingの管理 11gリリース1 (11.1.1) B72420-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Content: Imagingの管理 11gリリース1 (11.1.1) B72420-07 |
|
前 |
次 |
この項ではOracle WebCenter Content: Imagingのセキュリティ・モデルおよびシステム・レベルのセキュリティについて説明します。
Imagingへのアクセス権は、使用可能なOracle WebLogic Serverプロバイダを使用してOracle WebLogic Serverドメイン内で管理される構成済の資格証明ストアによって付与されます。Imagingへのアクセス権が付与された後、Imaging内の特定の機能を使用するには、特定の機能に対する権限を付与するように指定されたImaging管理者またはユーザーによって割り当てられたセキュリティ権限が必要です。
この項の内容は次のとおりです。
初期インストール後、最初にImagingにログインしたユーザーには、企業のニーズに合わせてImagingソリューションを適切に設定するために、すべての機能に対する完全な権限が付与されます。システムを適切に設定した後、必要に応じて、セキュリティ権限の変更や取消しを行うことができます。また、設定中に資格証明ストアを変更した場合は、初期のセキュリティ権限をリセットできます。詳細は、第2.1.2項「インストール・セキュリティの初期化」を参照してください。
|
注意: Imagingを最初にデプロイしたときに、IPMSYS_ADMINというロールがContent Server内に作成されます。このロールによって、ImagingとContent Serverが連携して動作するために必要な、特殊なセキュリティ権限が提供されます。IPMSYS_ADMINロールは、一般に使用されるものではありません。このロールは、Imagingシステムによってプログラムで作成および管理されます。このロールに割り当てられているセキュリティ権限を変更したり、このロールに関連付けられているユーザーの追加や削除を行うと、ImagingとContent Server両方の動作に悪影響が生じます。このような悪影響の1つとして、このロールに追加されたすべてのユーザーがContent Serverシステムから削除されます。 |
Oracle WebLogic Serverドメイン内で実行される管理対象サーバーであるImagingとそのリポジトリに対するユーザーおよびグループのアクセスは、Oracle WebLogic Serverによって制御されます。システム・セキュリティの構成およびSSL接続の構成は、Oracle WebLogic Serverコンソールを使用して行います。Oracle Internet Directoryや、Oracle Access Managerを使用したシングル・サインオンなどの追加サービスが必要な場合は、Oracle WebLogic Serverのコントロールを使用して、Imagingを管理するWebLogic Serverドメインにリンクできます。
|
注意: Oracle Access Managerで使用するようにImagingを構成する場合は、/imaging/facesディレクトリを保護する必要があります。保護しなかった場合、Imagingビューアにはアクセスできません。 |
Webサービスを介したImagingへのアクセスは、Oracle Web Services Manager (OWSM)ポリシーによって制御されます。ポリシーを構成するには、Oracle WebLogic Serverコンソールを使用します。一部のポリシーについては、キーストアを定義する必要があります。たとえば、ワークフロー・サーバーと通信する場合やSSLを使用する場合、Imagingでは、資格証明ストア・フレームワーク(CSF)に保存されているアクセス資格証明を使用する必要があります。キーストアを定義するには、Java Development KitのKeytoolを使用します。定義したキーストアに資格証明を追加するには、WebLogic Scripting Tool (WLST)を使用します。
|
注意: Imagingで使用されるContent ServerリポジトリでContent Serverアカウントおよびコラボレーション・セキュリティを有効にすることはできますが、Imagingでは、Imagingドキュメントでのそれらの使用はサポートされていません。 |
追加情報については、次のドキュメントを参照してください。
初期インストール後、最初にImagingにログインしたユーザーには、企業のニーズに合わせてImagingソリューションを適切に設定するために、すべての機能に対する完全な権限が付与されます。
Oracle WebLogic Serverのインストール時に、資格証明ストアがデフォルトとして定義されます。Imagingでは、このデフォルトの資格証明ストアがセキュリティに使用されます。最初のImagingユーザーがログインした後で資格証明ストアを変更した場合は、システム・セキュリティをリセットする必要があります。たとえば、Oracle Internet Directory (OID)プロバイダまたはMicrosoft Active Directoryプロバイダを指すようにセキュリティ構成を変更した場合は、Imagingのシステム・セキュリティをリセットする必要があります。
システム・セキュリティをリセットする手順は次のとおりです。
ポリシー・ストアに関連付けられている管理ツールを使用して、ユーザーおよびグループを作成するか、新しいポリシー・ストアに移行します。
Imagingの管理対象サーバーが管理サーバーとは別のドメイン・ホームにある場合は、WebLogic Scripting Tool (WLST)からgrantIPMCredAccess() MBeanコマンドを実行します。これにより、Imagingに資格証明ストアから資格証明を読み取る権限が付与されます。
WLSTを使用してMBeanコマンドを実行する方法の詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool コマンド・リファレンス』を参照してください。
Oracle Internet Directory (OID)やMicrosoft Active DirectoryなどのOracle WebLogic Serverセキュリティ・プロバイダを構成する方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』を参照してください。
ユーザーまたはグループが認証され、Imagingへのアクセス権が付与されると、Imagingの定義に対するセキュリティ権限が与えられます。
Imagingの定義には次のものが含まれます。
アプリケーション
入力
検索
接続
ソリューション
|
注意: ドキュメント・セキュリティは、アプリケーション内で定義されます。ドキュメントに関連付けられた注釈に対するセキュリティ権限も含まれます。第2.2.3項「ドキュメント・セキュリティの操作」および第2.2.4項「注釈セキュリティの操作」を参照してください。 |
ユーザーがImagingへのアクセスを認証されていても、Imagingの定義または定義管理に対するセキュリティ権限をまだ付与されていない場合、ホームページは表示されますが、ナビゲータ・ペインにナビゲーション・リンクが表示されません。
Imagingソリューションを適切に管理するには、定義管理権限と定義権限を区別する必要があります。
定義管理セキュリティ権限では、定義(アプリケーション、入力、検索、接続およびソリューション)を作成または管理する権限がユーザーに付与されます。
定義権限では、特定の定義(Invoices_USという名前のアプリケーションやUS Purchase Ordersという名前の検索など)の表示、変更、削除またはアクセス権の管理を行う権限がユーザーに付与されます。
Imagingの定義管理セキュリティ権限および定義セキュリティ権限は、Imagingユーザー・インタフェース内で管理されます。
定義管理セキュリティは、ナビゲータ・ペインの「セキュリティの管理」パネルからアクセスする定義管理セキュリティ・ページを使用して定義します。定義管理権限には、次の2つのレベルのセキュリティがあります。
| セキュリティ権限 | 説明 |
|---|---|
| 管理者 | 定義管理に対する完全な権限をユーザーまたはグループに付与します。「管理者」権限や「作成」権限を他のユーザーまたはグループに割り当てる権限も含まれます。 |
| 作成 | 新しい定義を作成する権限を付与します。定義を作成したユーザーには、デフォルトで、その定義に対するすべての定義権限が自動的に割り当てられます。 |
「管理者」権限
「管理者」権限は企業全体の定義の完全な制御を許可するため、通常は少数のユーザーに割り当てられます。「管理者」権限は定義に固有で、ドキュメント権限には適用されません。したがって、定義の「管理者」権限を持っていても、アプリケーション内のドキュメント・セキュリティを変更することはできません。
これは、定義管理に対する「管理者」権限を持っているユーザーが定義を変更することで、制限されているドキュメントにアクセスできるようになることを防ぐためです。このため、特定の定義にアクセスするためには、すべてのセキュリティ・レイヤーに対するアクセス権がユーザーに付与されている必要があります。このアプローチは、ビジネス部門を分離する必要性に基づいています。たとえば、特定のビジネス部門のContent Serverを設定してサーバー上のコンテンツへのアクセスを制限する場合、そのContent Serverにアプリケーションを配置する権限もContent Server内のドキュメントを検索する権限も他のビジネス部門には付与しないようにします。
|
注意: ソリューション・セキュリティは、ソリューションがImagingの外部で構成されるという点で独特です。ソリューション・エディタへのアクセス権を持つ管理者は、デフォルトで、使用可能なすべてのソリューションを編集できます。詳細は、『Oracle Fusion Middleware Oracle WebCenterアプリケーション・アダプタの管理』を参照してください。 |
例
次に、割り当てられたセキュリティ権限で一般従業員が実行できる操作の例を示します。
IT部門のSasha
XYZカンパニーのIT部門の従業員であるSashaは、アプリケーションおよび検索の定義に対する「作成」権限を持っています。そのため、Sashaは他の部門についても、新しいアプリケーションを作成したり、作成したアプリケーションおよび検索の定義に対する権限を付与できます。ただし、すべてのアプリケーションに対する権限を付与することはできません。
売掛管理部門のTheo
Theoは、売掛管理部門に新しく配属された従業員です。検索を作成できるとともに、顧客のクレジット・カード情報が記載されているオーダーを含め、売掛管理部門内のすべてのドキュメントにアクセスできる必要があります。クレジット・カード情報を保護するために、米国のオーダーはすべてOrders_USアプリケーションにアップロードされ、Imagingに接続された特定のリポジトリに保存されます。Sashaは、このリポジトリにはアクセスできません。
Sashaは、定義管理セキュリティ・ページを使用してTheoをユーザーとして追加し、検索に対する「作成」権限を付与できるほか、売掛管理部門のほとんどのアプリケーションにTheoをユーザーとして追加できます。ただし、Sashaは、Orders_USアプリケーションで定義されている接続に対する「表示」権限を持っていないため、そのアプリケーションにTheoをユーザーとして追加することはできません。
システム・アクセスを管理し、Imagingの特定の定義管理権限を持っていないSasha以外の従業員が、検索に対する「作成」権限を持つグループにTheoを追加します。このグループは、Orders_USアプリケーションで、そのアプリケーション内のドキュメントへのアクセス権を持つグループとしてすでに定義されています。アクセス制御を分離し、接続へのアクセスを制限することによって、SashaがOrders_USアプリケーションを変更して自分をユーザーとして追加し、その結果、顧客のクレジット・カード・データにアクセスできるようになることを防ぐことができます。
HR部門のBob
Bobは、人事管理部門に新しく配属された従業員です。社会保障番号、給与および健康関連のドキュメントなど、従業員の個人情報を含む、HR部門のすべてのドキュメントを検索する権限が必要です。このようなドキュメントは、HR_Confidentialアプリケーションを使用してImagingに保存され、Private Employee Information検索を使用して取得されます。
Sashaは、HR_Confidentialアプリケーションに対する「表示」権限を持っていないため、Private Employee Information検索を変更してBobにアクセス権を付与することはできません。Theoの場合と同様に、システム・アクセスを管理する、Imagingの特定の定義管理権限を持っていないSasha以外の従業員が、必要な検索ですでに定義されているグループにBobを追加する方法が一般的です。
「作成」権限
「作成」権限は通常、Imagingにアップロードされるドキュメントに関連するビジネス・プロセスを把握している、企業全体のビジネス・マネージャに付与されます。「作成」権限は、ビジネス・ニーズに固有のアプリケーション、検索、入力および接続の定義の作成と変更をマネージャに許可します。さらに、ドキュメントの保存に使用されるリポジトリ接続へのアクセスを制御することによって、個々のビジネス部門を分離し、ドキュメントを保護できます。
例
Theoは、XYZカンパニーの米国地区の新しい会計担当ディレクターであるとします。人事管理部門のBobから、従業員が会社の製品を注文する際に給与から引き落とせるようにする新しい従業員プログラムを同社で実装するという話を聞きました。
Theoは最初に、Orders_USアプリケーションだけでなく、HR_Confidentialアプリケーションでも未完了のオーダーを検索するように、Pending Orders検索を変更したいと考えました。また、新しいオーダー・フォームに入力された社会保障情報と突き合せて検索結果の社会保障情報を確認することによって、注文している人物が現在の従業員であることを確認したいとも考えました。ただし、Theoは、HR_Confidentialアプリケーションにドキュメントを保存するために使用されるリポジトリ接続に対するアクセス権を持っていません。
TheoがBobに連絡してアクセス権を要求したところ、法律上の理由で、Theoはオーダー・フォームの社会保障情報を取得することも、人事管理部門のそのような情報にアクセスすることもできないという説明を受けました。かわりに、Theoがアクセスできるドキュメントで使用可能な従業員の電子メール・アドレスを一意の識別子として使用してはどうかと提案されました。
この例では、Theoは、実現しようとしているビジネス・ニーズは把握していましたが、領域外の業務慣行に関する知識が限られていました。Imagingで実装されるセキュリティによって、プライバシを侵害することなく、ビジネス・ニーズを満たすことができました。
定義セキュリティは、ナビゲータ・ペインの該当するパネルを使用して定義を作成および管理する際にセキュリティ・トレイン・ストップで定義します。たとえば、アプリケーション定義のセキュリティはアプリケーション・セキュリティ・ページで定義し、検索定義のセキュリティは検索セキュリティ・ページで定義します。定義権限には、次の4つのレベルのセキュリティがあります。
| セキュリティ権限 | 説明 |
|---|---|
| 表示 | デフォルトで有効になっています。定義を表示する権限をユーザーまたはグループに付与します。 |
| 変更 | セキュリティ権限の付与を除く、定義のすべての要素を変更する権限をユーザーまたはグループに付与します。 |
| 削除 | 定義を削除する権限をユーザーまたはグループに付与します。 |
| アクセス権の付与 | 定義のセキュリティ権限を他のユーザーやグループに付与する権限をユーザーまたはグループに付与します。このセキュリティ・レベルのみが付与されているユーザーは、定義のセキュリティ情報のみを変更できます。 |
定義権限は、作成された各定義に固有です。他の定義タイプを使用して定義にアクセスする必要があるユーザーは、少なくともその特定の定義に対する「表示」権限を持っている必要があります。たとえば、Invoices_USアプリケーションに対する検索定義を作成または変更する必要があるXYZカンパニーのユーザーは、少なくともそのアプリケーション定義に対する「表示」権限を持っている必要があります。米国の会計部門のディレクターであるTheoは、Invoices_USアプリケーションに対する「表示」権限に加えて、ビジネス・ニーズの絞込みまたは変更に合わせて検索を絞り込むまたは変更するために、All US Invoices検索に対するすべての権限を持っています。また、繁忙期に雇用する個々の契約従業員に「表示」権限を付与するために、その検索に対する「アクセス権の付与」権限も持っています。
定義管理権限および定義権限は、Oracle Internet Directory (OID)など、Oracle WebLogic Serverの別個のセキュリティ・プロバイダによって管理される個々のユーザーまたはユーザー・グループについて定義されます。ユーザーまたはグループには、Imagingユーザー・インタフェースを使用して、定義および定義管理に対する様々なレベルのアクセス権が付与されます。たとえば、アプリケーション定義を作成する場合、アプリケーション・セキュリティ・ページを使用してユーザーまたはグループを追加する際に、アプリケーションに対する「表示」権限をユーザーまたはグループに付与します。その後、必要に応じて追加の権限を指定します。
グループを使用すると、同じアクセス・ニーズを持つ組織内の多数のユーザーにセキュリティ権限を効率的に割り当てることができます。たとえば、Resumesアプリケーション内のドキュメントに対する「表示」権限を必要とする企業全体のマネージャをManagersグループに追加できます。HR_Managersグループには、Imagingに対して履歴書をアップロードおよび削除したり、新しい従業員を雇用する際に手伝ってもらう可能性がある個々の従業員にResumesアプリケーションおよび関連する検索に対するアクセス権を付与するために、そのアプリケーションに対する「書込み」、「削除」および「アクセス権の付与」ドキュメント権限を付与できます。
|
注意: グループ・メンバーシップは、ユーザーがImagingにログインしたときにロードされ、ユーザーがログアウトするまで、セッションを通してアクティブな状態になります。ユーザーがログインしている間にグループから削除されても、ユーザーがログアウトするか、またはセッションが終了するまで、そのユーザーはグループの完全な権限を保持します。新しいユーザー権限は、次にログインしたときに有効になります。 |
|
注意: イメージングでは「認証済」と呼ばれるデフォルト・グループを提供します。このグループはセキュリティ権限を認証済ユーザーのグループに割り当てる際に役立つ場合があります。たとえば、「認証済」グループに、「インボイス」アプリケーションのドキュメントに対する「表示」権限と、それらインボイスの関連検索にアクセスする「表示」権限を割り当てることができます。これにより、すべての認証済ユーザーは、「インボイス」アプリケーション内に存在するドキュメントの検索および表示にアクセスできます。 |
ドキュメント・セキュリティはアプリケーションの定義時に割り当てられ、グループ・レベルでのみセキュリティ権限を割り当てることができます。
定義セキュリティおよび定義管理セキュリティは、Imagingユーザー・インタフェースを使用して管理します。この項の内容は次のとおりです。
定義管理セキュリティは、ナビゲータ・ペインの「セキュリティの管理」パネルからアクセスする定義管理セキュリティ・ページを使用して管理します。アプリケーション、入力、検索または接続に対するユーザーおよびグループの権限の付与、取消しまたはコピーを行う手順は次のとおりです。
定義に対するユーザーおよびグループの既存の権限の変更
ナビゲータ・ペインの「セキュリティの管理」をクリックしてペインを開き、管理する定義タイプを表示します。
管理する定義タイプをクリックします。
アプリケーション
入力
検索
接続
ソリューション
その定義タイプの定義管理セキュリティ・ページが表示されます。
「変更」をクリックします。セキュリティ・メンバーのリストの上部にツールバーが表示され、「作成」および「管理者」セキュリティ権限の列がアクティブになります。
変更するセキュリティ・メンバーの横にある権限を有効または無効にし、「送信」をクリックします。変更ツールバーが閉じ、定義管理セキュリティが変更されます。
定義に対するユーザーおよびグループの既存のセキュリティ権限の取消し
セキュリティの管理ページを表示し、「変更」をクリックします。
「セキュリティ・メンバー」列で、削除するユーザーまたはグループを選択します。
「削除」をクリックします。ユーザーまたはグループがリストから削除され、その定義タイプの定義管理権限が取り消されます。
ユーザーおよびグループへの定義に対する権限の付与
セキュリティの管理ページを表示し、「変更」をクリックします。
「追加」をクリックするか、ユーザーまたはグループを選択して「コピー」をクリックし、選択したアイテムのセキュリティ・オプションをコピーします。セキュリティ・メンバーの追加ページが表示されます。
選択リストから「グループの検索」または「ユーザーの検索」を選択し、検索条件を入力して、「検索」をクリックします。条件を入力しなかった場合、すべてのユーザーまたはグループのリストが表示されます。
「セキュリティ・メンバー」列で、権限を付与するユーザーまたはグループを選択します。キーボードの[Shift]キーを押しながら一連のメンバーをクリックするか、[Ctrl]キーを押しながら不連続のメンバーをクリックすると、複数のメンバーを選択できます。
「追加」をクリックします。セキュリティ・メンバーの追加ページが閉じ、セキュリティ・ページの「セキュリティ・メンバー」列にユーザーまたはグループが表示されます。
追加するセキュリティ・メンバーの横にある権限を有効または無効にし、「送信」をクリックします。変更ツールバーが閉じ、定義管理セキュリティが変更されます。
定義セキュリティは、ナビゲータ・ペインの該当するパネルを使用して定義を作成および管理する際に定義します。たとえば、検索を管理するには、ナビゲータ・ペインの「検索の管理」パネルを使用します。
定義セキュリティの管理については、このガイドの各定義に関する項で詳しく説明します。
|
注意: 定義に対する「管理者」セキュリティ権限を持つすべてのユーザーが定義にアクセスし、変更できます。変更中に定義をロックすることはできません。そのため、異なるユーザーが同じ定義を同時に変更している場合、最後に送信された変更のみが保存されます。 |
アプリケーション定義セキュリティとドキュメント・セキュリティは異なりますが、ドキュメント・セキュリティは、アプリケーションの作成時にアプリケーションで定義します。ドキュメント・セキュリティ権限はグループにのみ適用可能で、アプリケーションを定義するときにアプリケーション・ドキュメント・セキュリティ・ページを使用してグループごとに指定します。つまり、アプリケーションでドキュメント・セキュリティ権限を変更した場合、そのアプリケーション内のすべてのドキュメントに影響します。次のドキュメント権限を有効にすることができます。
| セキュリティ権限 | 説明 |
|---|---|
| 表示 | 特定のアプリケーション内のドキュメントを表示する権限をユーザー・グループに付与します。ユーザーが少なくともドキュメントに対する「表示」権限を持っていなければ、検索を実行しても、そのドキュメントは検索結果に表示されません。 |
| 書込み | 特定のアプリケーション内のドキュメントおよびドキュメント・メタデータをアップロード、更新およびコピーするための権限を、ユーザー・グループに付与します。ユーザーに1つ以上のアプリケーションのドキュメントに対する「書込み」セキュリティ権限がない場合、「アップロード」ツールはナビゲータ・ペインの「ツール」パネルに表示されません。 |
| 削除 | 特定のドキュメントをアプリケーションから削除する権限をユーザー・グループに付与します。あるアプリケーションに対する「削除」権限と別のアプリケーションに対する「書込み」セキュリティ権限をユーザーが持っている場合、最初のアプリケーションから2つ目のアプリケーションにドキュメントを移動できます。「削除」権限を持つユーザーには、「書込み」権限が自動的に割り当てられます。 |
| アクセス権の付与 | ドキュメント権限を他のユーザー・グループに割り当てる権限を、ユーザー・グループに付与します。「アクセス権の付与」権限を持つユーザーには、「削除」および「書込み」セキュリティ権限が自動的に割り当てられます。 |
| 管理者のロック | アプリケーション内のロックされているドキュメントをロック解除する権限をユーザー・グループに付与します。 |
ドキュメントを表示する権限を持っているユーザーはすべて、標準および制限付き注釈を表示する権限も持っています。注釈は、注釈を配置する権限を持っているユーザーがドキュメントに配置しますが、注釈を変更する権限を持っていないユーザーが表示した場合、ドキュメントのTIFFバージョンがレンダリングされ、注釈が書き込まれた状態で表示されます。そのため、改訂やその他の必要な注釈がある場合にドキュメントが保護されます。注釈を作成、変更または非表示にするには、注釈セキュリティ権限がユーザーに付与されている必要があります。
アプリケーションを定義する際、グループに付与されているセキュリティ権限に基づいて、すべてまたは一部の注釈を書き込んだり、非表示にすることができます。たとえば、ユーザーが「標準の注釈付け」権限を持っており、標準、制限付きおよび非表示の注釈がドキュメントに含まれている場合、ドキュメントのTIFFイメージが表示されます。制限付き注釈は書き込まれ、標準注釈は最上部に配置され、非表示注釈は表示されません。
注釈は個々のドキュメントに固有ですが、注釈セキュリティ権限は、アプリケーション・ドキュメント・セキュリティ・ページでドキュメント・セキュリティを指定する際にアプリケーションで定義します。注釈セキュリティ権限は、アプリケーション内のすべてのドキュメントに適用されます。アプリケーションでグループの注釈セキュリティ権限を変更すると、アプリケーション内のドキュメント上のすべての注釈に対するアクセス権に影響します。注釈はリポジトリ内の各ドキュメントに関連付けられ、各ドキュメントに固有ですが、元のドキュメントを保護するために、別々に保存されます。
注釈はドキュメントの最上部に配置されるため、テキスト・データを含むドキュメントが注釈の下に移動する場合があります。改訂の注釈が上に配置されているテキストやイメージが移動して、ドキュメント上に表示されてしまった場合、問題になることがあります。これは、不適切なセキュリティ権限に関する問題ではありません。ドキュメントのアップロード時にレンダリング・エンジンで使用できないフォントを使用してドキュメントが作成されている場合に発生する可能性があります。その場合、レンダリング・エンジンによってフォントが置換され、テキストが移動したり、ページ区切りが変更されることがあります。この問題を回避する方法の詳細は、第11.6項「フォント・エラー」を参照してください。
Imagingビューアは、サーバー上でリポジトリの外部にドキュメントをキャッシュできるため、ドキュメントがクライアント・マシンで表示される前に、より効率的にレンダリングできます。事前キャッシュが有効な場合、表示される前にドキュメントのレンダリングが完了するため、大きいドキュメントについては効率が大幅に向上します。ビューアのキャッシングを有効にするには、第3.8.3項「WLSTを使用したMBeanの変更」または第3.8.4項「Enterprise Managerを使用したMBean値の設定」に記載されている方法を使用して、ドキュメントをキャッシュする場所にViewerCachePath MBeanを設定します。ドキュメントは注釈なしでビューア・キャッシュに保存されるため、制限付き注釈が作成されている場合に、ユーザーがそれらのドキュメントに直接アクセスできないようにするには、ViewerCacheEnableEncryption Mbeanをtrueに設定して、ドキュメントがサーバー上で暗号化され、注釈なしのドキュメントにユーザーがアクセスできないようにする必要があります。ビューア・キャッシュに保存されているドキュメントを暗号化する方法の詳細は、第3.4.2項「キャッシュされたドキュメントの暗号化」を参照してください。ビューア・キャッシュ・オプションを構成する方法の詳細は、第3.4項「ビューア・キャッシュ・オプションの構成」を参照してください。
|
注意: ViewerCacheEnableEncryption Mbeanは、ビューア・キャッシュ・オプションを使用している場合にのみ適用されます。 |
特定のアプリケーション内のドキュメント注釈には、次の3つのレベルのセキュリティが適用されます。
| セキュリティ権限 | 説明 |
|---|---|
| 標準の注釈付け | 「制限付き」または「非表示」として明示的に指定されていない、アプリケーション内のすべての注釈に対する表示、作成、変更および削除セキュリティ権限を付与します。 |
| 制限の注釈付け | アプリケーション内の注釈を「制限付き」として指定するセキュリティ権限、および他のユーザーによって「制限付き」として指定されている注釈を作成、変更または削除するセキュリティ権限を付与します。すべてのユーザーが制限付き注釈を表示する権限を持っていますが、それらを作成、変更または削除するには、「制限の注釈付け」権限が必要です。 |
| 非表示の注釈付け | アプリケーション内の注釈を「非表示」として指定するセキュリティ権限、および他のユーザーによって「非表示」として指定されている注釈を作成、変更または削除するセキュリティ権限を付与します。非表示注釈を表示するには、「非表示の注釈付け」権限が必要です。 |
|
注意: OnlyCreatorCanModifyAnnotation構成MBeanがTrueに設定されている場合、注釈を作成したユーザーとアプリケーションに対する「管理者」権限を持っているユーザーのみが注釈を変更できます。 |
Maya、Sasha、John、BobおよびLouisはXYZカンパニーの従業員です。それぞれ次のビジネス・ロールを割り当てられており、次の部門およびグループのメンバーです。
| 名前 | 部門 | ロール | グループ |
|---|---|---|---|
| Maya | IT | XYZカンパニーの情報テクノロジ担当ディレクターです。インストール後、最初にImagingにログインし、すべての定義、定義セキュリティ権限および定義管理セキュリティ権限を設定しました。企業全体のImagingのすべてに対する完全な管理者アクセス権を持っていますが、日常的には使用しません。 | IT_Director |
| Sasha | IT | XYZカンパニーのImagingの管理者です。アクセス権を持っていない一部のリポジトリ接続に分離されている従業員の機密情報を除き、企業全体のImagingのすべてに対する完全なアクセス権を持っています。 | IT_Admin |
| John | HR | 部門全体のImaging管理者です。HR部門の管理者であるため、HRに関連するImagingのすべての操作に対するセキュリティ権限が必要ですが、売掛管理部門などに関連する操作に対するセキュリティ権限は必要ありません。人事管理部門のアプリケーション、検索、入力および接続の定義の作成と変更を許可されている唯一のユーザーです。 | HR_IT |
| Bob | HR | 新しい従業員の候補に提示する給与を決定して従業員の候補に提示し、承諾されると、ドキュメントを受け取ります。社外の参照を使用して、提示する給与を決定しますが、提示した給与が承諾されると、給与承諾ドキュメントをImagingシステムにアップロードしてOffersというアプリケーションに保存し、承諾済のスタンプを使用して注釈を付けます。ドキュメントをアップロードし、スタンプを付けて保存すると、ワークフロー・プロセスが開始されて、スタンプが付いた給与承諾ドキュメントを格納するHR新規従業員ファイルが作成されます。そのため、Offersというドキュメントを表示、作成および変更するセキュリティ権限が必要です。 | HR_Managers |
| Louis | HR | 管理アシスタントです。従業員の個人情報のデータベースを更新します。Offersドキュメント内の給与に関する個人情報を仕事で使用することはないため、ImagingでOffersドキュメントに対するアクセス、検索またはアップロードを行うためのセキュリティ権限はありません。 | HR_Users |
定義管理セキュリティ権限
ImagingのHR_ManagersおよびHR_Usersグループ内で、BobとLouisは、定義を定義するためのセキュリティ権限を持っていません。アプリケーション、入力、検索および接続の作成や管理を行わないためです。BobとLouisはそれらを使用するのみです。
一方、Maya、SashaおよびJohnには、特定の職務のニーズに従って、次の定義管理セキュリティ権限が付与されています。
| セキュリティ権限 | アプリケーション | 入力 | 検索 | 接続 |
|---|---|---|---|---|
| 管理者 | Maya、Sasha | Maya、Sasha | Maya、Sasha | Maya、Sasha |
| 作成 | John | John | John | John |
定義セキュリティ権限
5人のうちの4人がOffers定義に対する特定のレベルのセキュリティ権限を必要としています。Johnは、それらの定義を管理する必要があります。Mayaは、それらを管理したり、Johnがいない場合や対応できない場合にそれらを管理する権限を他の従業員に割り当てることができる必要があります。Bobには、アップロード、注釈付け(給与情報を承認および改訂するため)、検索、表示を行うほか、新しい従業員のファイルを作成するワークフロー・プロセスを開始するための完全な権限が必要です。Louisには、個人情報を更新するためにドキュメントを検索および表示する権限が必要ですが、改訂された給与情報を表示する権限は必要ありません。Sashaは機密情報の管理は行わないため、給与や個人情報などの機密情報が保存されているリポジトリ接続に対する権限を持っていません。
それぞれ、特定の職務のニーズに従って、次の定義セキュリティ権限が付与されています。
| セキュリティ権限 | Offersアプリケーション | Offers入力 | Offers検索 | ワークフロー接続 |
|---|---|---|---|---|
| 表示 | Maya、John、Bob、Louis | Maya、Bob | Maya、John、Bob、Louis | Maya、John |
| 変更 | Maya、John | Maya、John | Maya、John | Maya、John |
| 削除 | Maya、John | Maya、John | Maya、John | Maya、John |
| アクセス権の付与 | Maya、John | Maya、John | Maya、John | Maya、John |
ドキュメント・セキュリティ権限
Offersアプリケーションに保存されているドキュメントを操作するのはBobとLouisのみなので、Offersアプリケーションを定義したときに、アプリケーション・ドキュメント・セキュリティ・ページでHR_ManagersおよびHR_Usersグループのみが追加されています。MayaとJohnは、アプリケーション定義セキュリティ権限によってアプリケーション定義を表示および変更するためのアクセス権が付与されていても、アプリケーション内のドキュメントにアクセスすることはできません。
BobとLouisには、特定の職務に従って、次のドキュメント・セキュリティ権限が付与されています。
| セキュリティ権限 | ドキュメント | グループ・メンバー |
|---|---|---|
| 表示 | HR_Managers、HR_Users | Bob、Louis |
| 書込み | HR_Managers | Bob |
| 削除 | HR_Managers | Bob |
| 管理者のロック | HR_Managers | Bob |
| アクセス権の付与 | HR_Managers | Bob |
| 標準の注釈付け | HR_Managers、HR_Users | Bob、Louis |
| 制限の注釈付け | HR_Managers | Bob |
| 非表示の注釈付け | HR_Managers | Bob |
これらの権限によって、Bobは、ドキュメントをOffersアプリケーションにアップロードし、給与情報を改訂できます。Louisは、Offersアプリケーションでドキュメントを検索して表示し、更新された個人情報を取得できます。ただし、改訂を変更したり、給与情報を表示することはできません。
Imagingは、Oracle WebLogic Serverドメイン内で管理対象サーバーとして実行されます。ImagingおよびContent Serverリポジトリへのアクセスは、Oracle WebLogic Serverによって制御されます。SSLなどのシステム・セキュリティの構成は、Oracle WebLogic Serverコンソールを使用して行います。この項の内容は次のとおりです。
詳細は、次を参照してください。
| タスク | 情報参照先 |
|---|---|
| Oracle WebLogic Serverの管理 | 『Oracle Fusion Middleware管理者ガイド』 |
| Oracle WebLogic ServerのSSLの構成 | 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の第12章「SSLの構成」 |
Oracle Fusion Middlewareを構成し、Oracle Fusion Middlewareのコンポーネント間の通信をSSLで保護することができます。SSLは通信を保護するための業界標準です。Oracle Fusion Middlewareでは、SSLバージョン3とTLSバージョン1がサポートされています。
表2-2 SSLに関するドキュメント
| 目的 | 参照ガイド |
|---|---|
|
Oracle Fusion MiddlewareでのSSLの構成: Web層、中間層およびデータ層 |
『Oracle Fusion Middleware管理者ガイド』: 第 6章、「Oracle Fusion MiddlewareでのSSLの構成」 |
SSLを使用してContent Serverリポジトリに接続するには、次の手順を実行する必要があります。
Content Server接続のContent Server設定ページでSSLを有効にします。
Content ServerのSSL受信ソケット・プロバイダを追加および構成します。
ワークフローの統合については、第10項「ワークフロー・エージェントの理解」および第7.2項「ワークフロー接続の作成」で詳しく説明します。
Imagingは、それぞれ異なるメカニズムを使用して、次の時点でワークフロー・プロセスに接続します。
構成
アプリケーション・フィールドをワークフロー・ペイロード要素にマップする際、Imagingをワークフロー・サーバーに接続します。接続するには、Web Services Inspection Language (WSIL)を使用して、プロバイダ、ポートおよび資格証明の情報を渡します。WSILは、HTTPプロトコルおよび特定のXML形式を使用して、サーバーでWebサービス・エンドポイントを検出できるようにします。Imagingは、特定の条件を満たすWSILのリンクをたどって、デプロイ済コンポジットを検出します。
コンポジットおよびサービスが選択されると、WSDLでサービス・バインディングによって定義されている使用可能な操作のリストを取得するために、WSDLドキュメントがサーバーから読み取られ、解析されます。WSDLを読み取るためのプロトコルはHTTPで、使用されるアドレスおよびポートはWSDL URIの一部に含まれています。ワークフロー・サーバーがOracle HTTP Server (OHS)などのHTTPフロントエンド・ロード・バランサで構成されている場合、使用されるアドレスおよびポートが接続のホスト名およびポートと異なることがあります。
WSDLが読み取られると、アプリケーション・フィールドをマップできるように、そのWSDLを使用して操作ペイロードのスキーマが取得されます。
接続、コンポジット名、サービス名、操作名、およびアプリケーション・フィールドとペイロードのマッピングの詳細は、実行時に使用されるApplication.BpelConfigセクションに保存されます。
実行時
Imagingでドキュメントが作成され、そのドキュメントについてワークフロー・プロセス・インスタンスを作成する必要があるという通知をワークフロー・エージェントが受け取ると、実行時の通信が開始されます。この通信では、まず、BpelConfigに保存されている接続、コンポジットおよびサービス名を使用して、サービスのWSDL URIが取得されます。
操作ペイロードのスキーマを取得するために、WSDL URIが読み取られます。そのペイロード・スキーマを使用してペイロードのXMLが作成され、マッピングの定義に従って、アプリケーション・フィールド値がXMLに挿入されます。
ペイロードが完全に定義され、マップされたフィールド値が挿入されると、WSDLドキュメントで指定されているアドレスを使用して、ペイロードがWebサービス・コールとしてワークフロー・サービスの操作に送信されます。Webサービス・コールは、HTTPプロトコルを使用して送信されます。
Imagingのワークフロー統合を構成するには、まず、Imaging内でワークフロー・システムの接続定義を作成します。ワークフロー接続を作成する手順については、第7.2項「ワークフロー接続の作成」で詳しく説明します。
構成に必要なパラメータは次のとおりです。
| パラメータ | 詳細 |
|---|---|
| HTTPフロント・エンド・アドレス | ワークフロー・サーバーのURLアドレス。リスニング・ポートがURLに定義されたプロトコルのデフォルト・ポートでない場合は、そのリスニング・ポートも含まれます。 |
| 資格証明別名 | 資格証明ストア・フレームワーク(CSF)に保存されるユーザー名およびパスワードの別名を指定します。リモートJNDI接続を確立するには、これらの資格証明が必要です。このパラメータは、実際のユーザー名やパスワードではありません。ユーザー名およびパスワードをCSFで検索するために使用される別名、つまりキーで、適切なセキュリティを確保するために暗号化されます。
この資格証明は、ワークフロー接続の構成を完了する前にCSFで作成する必要があります。CSFで資格証明を作成するには、Enterprise Manager (EM)またはWebLogic Scripting Tool (WLST)を使用します。 |
| プロバイダ | 接続に使用する1つ以上のホスト名を指定します。ワークフロー・サーバーが単一インスタンスである場合は、ワークフロー・マシンの名前またはIPになります。ワークフロー・サーバーがクラスタ内で動作している場合、このパラメータ値には、クラスタ内のサーバーのマシン名またはIPアドレスをカンマで区切ったリストを指定できます。クラスタのクラスタ名を指定することもできます。
クラスタ名を使用する場合、そのクラスタ名は、ドメイン・ネーム・サーバーで定義され、クラスタ内の複数のマシンに解決される名前である必要があります。この動作は、ImagingでもBPELでも定義されません。かわりに、クラスタ内のJNDIに対するWebLogicサポートによって定義されます。クラスタ化されたJDNIのサポートの詳細は、Oracle Fusion Middleware Oracle WebLogic Server JNDIのプログラミング・ガイドのクラスタ環境でのWebLogic JNDIの使用に関する項を参照してください。 |
SSLを使用してワークフロー・サーバー・インスタンスとの通信を保護するようにImagingの統合を構成できます。ワークフロー・サーバーへのSSL接続を有効化および構成する手順については、第7.2.1項「ワークフロー・サーバーのSSLの構成」で詳しく説明します。
デフォルトのデモ用資格証明ストア・フレームワークおよび証明書の操作
ワークフロー・サーバー・インスタンスでSSLを有効にすると、サーバーへの通信が正しく動作し、ワークフロー・サーバーとImagingサーバーの両方がデフォルトのDemoTrust証明書を使用するように構成されているかどうかをテストできます。これは、WebLogicのインストール時に特定のデモ用の自己署名証明書および信頼の構成が構成されるためです。これらのファイルは$WL_HOME/server/libに格納され、DemoIdentity.jksおよびDemoTrust.jksという名前です。デフォルトでは、WebLogicはこれらのファイルを使用するように構成されます。
|
注意: これらのファイルは、テストおよびデモにのみ使用してください。本番環境では、適切かつ有効な証明書を取得し、それらの証明書をインポートおよび構成するための適切な手順に従って、アイデンティティと信頼を確立する必要があります。適切に署名された証明書を使用し、証明書を正しく構成すれば、特別な構成を行わなくても、SSLは正しく動作します。 |
デモ用の証明書を使用して、ワークフローのSSL接続をテストおよび確認できます。SSLを構成すると、Imagingはコンポジットおよびサービスを列挙することはできますが、WSDLを読み取る段階で失敗します。これは、次の2つのSSLスタックがサーバー内で使用されているためです。
WLS SSLスタック。デモ用のアイデンティティおよび信頼の構成と統合されており、通信に使用されます。
ネイティブJava SSLスタック。WebLogicのデモ用のアイデンティティおよび信頼の構成とは統合されておらず、ネイティブJava APIを使用するWSDLリーダーによって使用されます。
WSDLリーダーを正しく動作させるには、ワークフロー・サーバー上の自己署名証明書を信頼するようImagingサーバー・インスタンス上のJava SSLスタックに指示する必要があります。
そのためには、Imaging管理対象サーバーのJVMで、SSLトラスト・ストアを指すようにjavax.net.ssl.trustStoreシステム・プロパティを正しく設定する必要があります。DemoTrust.jksを指すように構成するには、setDomainEnvスクリプトのJAVA_OPTIONSに次の行を追加します。
-Djavax.net.ssl.trustStore=$WL_HOME/server/lib/DemoTrust.jks.
DemoTrust.jksを指すように構成したら、Imaging管理対象サーバーを再起動します。
このようにすると、すべてのOracle WebLogic Server共有で同じDemoTrust.jksファイルが使用されるため、正しく動作します。
さらに実行時には、WebLogicがインストールされており、アイデンティティ・キーストア(DemoIdentity.jks)が自動的に生成される場合、アイデンティティがマシン名になることがあります。場合によっては、ドメインを含まないホスト名のみになることもあります(つまり、testhost.example.comではなく、testhostになります)。Imagingがワークフロー・プロセス・メッセージを送信する段階になると、WebLogicは、SSLハンドシェイクの一環としてホスト名検証を実行し、HTTPSリクエストのホスト名がサーバーに対するアイデンティティと一致していることを確認しようとします。しかし、ワークフロー・システムが提供するURLは、ホスト名のみではなく、完全なDNS名です。そのため、ハンドシェイクが検証に失敗し、通信は失敗します。
デモの場合の最も簡単な解決策は、Imagingシステムでホスト名検証を無効にすることです。この方法が最も簡単な解決策だと思われますが、実際の本番環境における解決策ではありません。その場合の手順は、次を参照してください。
新しいCSF資格証明の構成
デフォルトのデモ用資格証明を使用するかわりに、自己署名CSF資格証明を作成することもできます。ワークフロー接続のCSF資格証明を構成する方法の詳細は、第7.2.2項「ワークフロー接続のCSF資格証明の構成」を参照してください。
WebLogic WebサービスはWeb Services for Java EE 1.2仕様に従って実装されます。この仕様は、JavaでWebサービスを実装するための標準のJava EEランタイム・アーキテクチャを定義したものです。また、Java EE Web Serviceの標準のパッケージング形式、デプロイ・モデル、ランタイム・サービスも定義されており、これらすべてがWebLogic Webサービスによって実装されます。
表2-3 Webサービスに関するドキュメント
| 目的 | 参照ガイド |
|---|---|
|
JAX-WSクライアントで使用されるWebサービス |
Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド |
|
OWSMセキュリティをWebサービスに適用する |
Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server: 付録A: Oracle Webサービス・セキュリティ・ポリシーの使用 |
|
WebサービスでMTOMを使用する |
Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server: セクション2.2: MTOM Webサービスにセキュリティを追加する例 |
|
BPELから保護されたWebサービスを起動する |
『Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド』の第7章「BPELプロセスからの同期Webサービスの起動」 『Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド』の第8章「BPELプロセスからの非同期Webサービスの起動」 |
|
Oracle Server Busを使用してWebサービスを起動する |
Oracle® Fusion Middleware Oracle Service Bus開発者ガイドのWSトランスポートに関する項 |
|
Oracle Enterprise Server Busを使用してWebサービスを起動する |
『Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド』の第19章「Mediatorルーティング・ルールの作成」 |
Webサービスを介したImagingへのアクセスは、Oracle Web Services Manager (OWSM)ポリシーによって制御されます。ポリシーを構成するには、WebLogic Serverコンソールを使用します。一部のポリシーについては、キーストアを定義する必要があります。たとえば、ワークフロー・サーバーと通信する場合やSSLを使用する場合、Imagingでは、資格証明ストア・フレームワーク(CSF)に保存されているアクセス資格証明を使用する必要があります。キーストアを定義するには、Java Development KitのKeytoolを使用します。定義したキーストアに資格証明を追加するには、WebLogic Scripting Tool (WLST)を使用します。
Oracle Web Services Managerは、あらかじめ定義されたセキュリティ・ポリシーを使用するのではなく、使用するセキュリティ・ポリシーをエンド・ユーザーが柔軟に定義できるように設計されています。
ポリシーが適用されていない場合、デフォルトで、HTTP Basic認可またはWS-Security UsernameTokenベースの認可が使用されます。HTTP Basic認可は、HTTPヘッダーのAuthorizationフィールドにユーザー資格証明を格納して渡します。このフィールドの値には、ユーザー名とパスワードのbase64エンコードが格納されます。BasicUserTokenクライアント・クラスは、この形式の認証を使用することを目的としています。
WS-Security UsernameTokenプロファイルは、ユーザー名とパスワードの両方を渡しますが、SOAPヘッダー構造を使用します。詳しくは、WS-Security UsernameToken Profile 1.0に関するドキュメントを参照してください。OWSMポリシーを使用してUsernameTokenポリシーを適用することもできます。その場合、デフォルトの実装よりもOWSMポリシーの実装が優先されます。このオプションは、OWSMポリシーを使用していない場合にのみ該当します。
Basic認証およびUsernameTokenセキュリティを使用している場合、パスワードが暗号化されずに送信されるため、Imagingには、RequireBasicAuthSSLという構成MBeanが用意されています。このMBeanを使用すると、この形式の認証ではSSLを使用するように要求できます。
OWSMポリシー・マネージャがドメインにインストールされている場合、セキュリティを強化するために、OWSMポリシーをサービスに適用できます。OWSMポリシーは、メッセージ・レベルの暗号化、トランスポート・レベルの暗号化、HTTPヘッダーではなくSOAPヘッダーを使用した資格証明の提供など、WS-Securityトークンの様々な用途に適用できます。適用されるポリシーの一部としてSSLを指定できるため、セキュリティ・ポリシーを使用している場合、RequireBasicAuthSSL MBeanの設定は適用されません。
ドメインの作成時に、Imagingアプリケーションには、アプリケーション・ディレクトリで定義されているデフォルトのデプロイメント・プランが付属していますが、そのプランはまだデプロイメントに割り当てられていません。デフォルトのプランではwss_username_token_service_policyが使用されます。このポリシーは、WS-Security SOAPヘッダーの簡単なユーザー名とパスワードを使用し、暗号化を必要としません。このデフォルトのプランによって、すべてのImagingサービスにwss_username_token_service_policyが割り当てられます。
デフォルトのプランを割り当てる手順は次のとおりです。
WebLogic Serverコンソールにログインします。
「デプロイメント」をクリックし、「デプロイメント」表で「imaging」を有効にして、「更新」をクリックします。「アプリケーション更新アシスタント」が表示されます。
デプロイメント・プランのパスの横にある「パスの変更」をクリックします。ソース・パスを変更しても、新しいプランで再デプロイされるわけではありません。
「現在の場所」フィールドのリンクを使用して、$MW_HOME/user_projects/applications/<domain_name>/server/ipmを参照し、「Plan.xml」ファイルを有効にします。
ウィザードの手順に従ってデプロイメントを完了します。
このプロセスを完了すると、すべてのサービスにwss_username_token_service_policyが適用されます。
実行時にポリシーを変更する場合は、次の手順を実行します。
WebLogic Serverコンソールにログインします。
「デプロイメント」をクリックし、「デプロイメント」表で「imaging」を開きます。ImagingのWebサービスのリストが表示されます。Webサービスを表示するには、スクロールする必要がある場合があります。
構成する各サービスのサービス名をクリックし、次の手順を実行します。
|
注意: DocumentContentServiceサービスにはポリシーを適用しないでください。 |
「構成」タブを選択します。
「WS-Policy」タブを選択します。現在適用されているポリシーが表示されます。
サービス・エンド・ポイントをクリックします。たとえば、「ApplicationServicePort」をクリックします。「選択可能なメッセージ・ポリシー」と「選択されたメッセージ・ポリシー」のリストが表示されます。
右側の「選択されたメッセージ・ポリシー」リストで、現在適用されているポリシーを選択し、矢印をクリックして移動し、「選択されたメッセージ・ポリシー」リストから削除します。
左側の「選択可能なメッセージ・ポリシー」リストで目的のポリシーを選択し、矢印をクリックして右側の「選択されたメッセージ・ポリシー」リストに移動します。
|
注意: DocumentContentServiceを除き、すべてのImagingサービスに同じポリシーを適用する必要があります。DocumentContentServiceサービスにはポリシーを適用しないでください。 |
すべてのサービスを変更したら、新しく編集したプランでデプロイメントを更新します。
デプロイメントのメイン・ページの「デプロイメント」表で「imaging」を有効にし、「更新」をクリックします。「アプリケーション更新アシスタント」が表示されます。
一番上のオプションを選択して、デプロイメント・プランのみを更新します。
「終了」をクリックします。
デプロイメントを容易にするために、代替デプロイメント・プラン・ディスクリプタが作成されています。$MW_HOME/user_projects/applications/<domain_name>/server/ipm/plan/imaging-ws.war/WEB-INFディレクトリにあります。いずれかのpolicy-<X>ファイルを同じディレクトリ内のweblogic-webservices-policy.xmlにコピーし、そのプランでデプロイメントを更新できます。デフォルトのプランの場合、weblogic-webservices-policy.xmlはpolicy-username_token.xmlです。
すべてのサービスに同じポリシーを割り当てることが重要です。クライアントAPIでは、ポリシーの必須の構成パラメータとともに、提供されたUserTokenから適切なクライアント・ポリシーを取得するようにServicesFactoryがコード化され、すべてのサービス・インタフェースでそのクライアント・ポリシーの構成が使用されます。正しく動作するには、有効なサービス・ポリシーをクライアント・コードが認識している必要があります。次の例では、UserTokenクラス内であらかじめ定義されているそれぞれのポリシー・タイプについてクライアントをコード化する方法を示します。
UserTokenクラスによって多数の新しいプロパティが公開されるため、クライアント側のポリシーを容易に構成できます。公開されるパラメータは、使用可能なすべてのOracle Web Service Managerパラメータの一部ですが、よく使用されるものです。これらのプロパティは名前と値のペアのマップのラッパーで、securityParametersプロパティを使用して直接公開されます。このマップ内のすべてのプロパティがWebサービス・リクエストのコンテキストに渡されるため、OWSMポリシーを使用することはできません。
次の例について詳しく説明します。
例2-1 ポリシーなし: HTTP Basic認証
最も簡単なデフォルトの構成です。これはデフォルトであるため、BasicUserTokenによってクライアントの実装が提供されます。
UserToken userToken = new BasicUserToken("weblogic", "weblogic");
ServicesFactory.login(userToken, wsurl);
BasicUserTokenの機能は次のコードと同じです。
UserToken userToken = new UserToken();
userToken.setUserName("weblogic");
userToken.setPassword("weblogic");
OWSMポリシーがサービスに適用されている場合は、WsmUserTokenを使用してクライアント側のポリシーの構成が提供されます。その場合は、個々のポリシーについて次のように構成します。
例2-2 ポリシー: wss_username_token_client_policy
これは最も簡単なポリシーです。
WsmUserToken userToken = new WsmUserToken ("weblogic", "weblogic");
userToken.setClientPolicy(WsmUserToken.USERNAME_TOKEN_POLICY);
ServicesFactory.login(userToken, wsurl);
例2-3 ポリシー: wss11_username_token_with_message_protection_client_policy
message_protectionポリシーは、メッセージ・レベルの暗号化を提供します。ただし、正しく動作させるには、クライアントとサーバーのキーストアを構成する必要があります。キーストアを作成および構成する方法の詳細は、第2.3.4.5項「キーストアの操作」を参照してください。キーストアがJSEクライアントによってクライアント側で使用される場合、クライアント・コードでキーストアの場所、タイプおよびパスワードを構成する必要があります。クライアント側のキーストアには、サーバーに送信されるメッセージの暗号化に使用されるキーであるRecipientAliasを格納する必要があります。サーバー側にも、復号化とレスポンスの暗号化を行うために同じキーが必要です。
WsmUserToken userToken = new WsmUserToken ("weblogic", "weblogic");
userToken.setClientPolicy(WsmUserToken.USERNAME_TOKEN_MP_POLICY);
userToken.setKeystore(".\\config\\default-keystore.jks", "JKS", "welcome");
userToken.setRecipientAlias("orakey");
このポリシーがWebアプリケーションやサーブレットなどからサーバー側で使用されている場合、キーストアはJPSセキュリティで構成されるため、クライアント側でキーストアの構成パラメータを指定する必要はありません。jps-configファイルを指すようにoracle.security.jps.config環境プロパティを設定することによって、JSEにもこの動作をレプリケートできます。
System.setProperty("oracle.security.jps.config", ".\\config\\jps-config.xml");
WsmUserToken userToken = new new WsmUserToken ("weblogic", "weblogic");
userToken.setClientPolicy(WsmUserToken.USERNAME_TOKEN_MP_POLICY);
クライアントのJPSを構成したら、資格証明ストア・フレームワーク(CSF)を利用して、ユーザー名およびパスワード資格証明を定義することもできます。第2.3.4.6項「WLSTを使用したCSFの操作」を参照してください。使用するには、サーバーで資格証明を作成し、クライアントにコピーします。資格証明ストアでは任意の別名を使用できますが、標準のデフォルト別名はbasic-credentialsです。
System.setProperty("oracle.security.jps.config", ".\\config\\jps-config.xml");
WsmUserToken userToken = new WsmUserToken ();
userToken.setClientPolicy(WsmUserToken.USERNAME_TOKEN_MP_POLICY);
userToken.setCsfKey("basic.credentials");
すべてのmessage_protectionポリシーについて、クライアントとサーバーのキーストアを構成する必要があります。本番環境では、適切かつ有効な証明書を取得し、それらの証明書をインポートおよび構成するための適切な手順に従って、アイデンティティと信頼を確立する必要があります。この例は、開発およびテストに有効な解決策を提供するためのものです。KeyToolというJDKツールのビルドを使用して、キーストアを作成できます。キーストアを生成するには、次のコマンドを使用します。
>keytool -genkey -alias orakey -keyalg RSA -keystore default-keystore.jks
Enter keystore password: ß welcome
Re-enter new password: ß welcome
What is your first and last name?
[Unknown]: Joe Smith
What is the name of your organizational unit?
[Unknown]: Human Resources
What is the name of your organization?
[Unknown]: Our Company
What is the name of your City or Locality?
[Unknown]:
What is the name of your State or Province?
[Unknown]:
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Joe Smith, OU=Human Resources, O=Our Company, L=Unknown, ST=Unknown, C=US correct?
[no]: yes
Enter key password for <orakey>
(RETURN if same as keystore password): ß RETURN...so welcome
>
キーストア内のキーをリストするには、次のコマンドを使用します。
> keytool -list -keystore default-keystore.jks
この例では、前述のすべての例で使用される1つの共通キーを作成します。サーバーとクライアントの両方で同じdefault-keystore.jksが使用されています。
WLSTで次のコマンドを使用することで、資格証明をキーストアに追加できます。ただし、これらのコマンドを使用するには、WLSホームのcommon/binからではなく、$ORACLE_HOME/common/binディレクトリからWLSTを実行する必要があります。JDeveloperの場合、これは、Oracle/Middleware/wlserver_10.3/common/binではなく、Oracle/Middleware/jdeveloper/common/binにあります。$ORACLE_HOME/common/binから、wlst.sh (Linux)またはwlst.cmd (Windows)を実行し、connect()を実行します。
資格証明ストア・コマンドの完全なセットは『Oracle Fusion Middleware WebLogic Scripting Tool コマンド・リファレンス』に記載されていますが、これらの例で使用されている2つの主なコマンドは次のとおりです。
createCred(map="oracle.wsm.security", alias="<alias>", user="<user>", password="<pwd>")
および
listCred(map="<map>", key="<key>)
資格証明ストアには、別名でアクセスする任意のユーザーIDとパスワードのペアを格納できます。WSMポリシーについては、キーストアの別名およびパスワードを取得するために、acsf別名が使用されます。これらのCSF別名は、jps-config.xmlファイルの次の要素で構成されます。
<!-- KeyStore Service Instance -->
<serviceInstance name="keystore" provider="keystore.provider" location="./default-keystore.jks">
<description>Default JPS Keystore Service</description>
<property name="keystore.type" value="JKS"/>
<property name="keystore.csf.map" value="oracle.wsm.security"/>
<property name="keystore.pass.csf.key" value="keystore-csf-key"/>
<property name="keystore.sig.csf.key" value="enc-csf-key"/>
<property name="keystore.enc.csf.key" value="enc-csf-key"/>
</serviceInstance>
キーストアには、キーストアのパスワードを含むkeystore-csf-keyという名前の別名が1つ必要です。前述の例では、keytoolに最初に入力されるパスワードです。ここでは、ユーザー名は無視されます。続いて、キーストアにはenc-csf-keyという名前の別名がもう1つ必要です。ユーザー名はキーストアの別名で、パスワードはそのキーストアの別名のプライベート・パスワードです。前述の例では、keytoolの2番目のパスワードです。
この項では、Oracle Access Manager (OAM) 11gと連携するようにImagingを構成する方法について説明します。企業内にImagingとOAMをデプロイする方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』を参照してください。
OAM 11gをImagingと統合する手順は次のとおりです。
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Identity Management 11gソフトウェアのインストールに関する項の説明に従って、Oracle Access Manager (OAM)、Oracle HTTP Server (OHS)およびWebGateをインストールして構成します。
次の例を使用して、Imagingのエントリをmod_wl_ohs.confに追加します。hostnameは、Imagingインスタンスをホストするマシンの名前に、portnumberは、ImagingをホストするOracle WebLogic Serverドメインのポートに置き換えてください。
Forwarding URLs:
<Location /imaging>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
Oracle OAMリモート登録ツール(oamreg)を使用し、保護、公開および除外するImagingのURIを指定して、Oracle OAMエージェントを登録します。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』および『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
| ImagingのパブリックURI | ImagingのプライベートURI | イメージング除外URI |
|---|---|---|
| /imaging | /imaging/faces | /imaging/ws
/imaging/lib |
次のタスクを確実に実行して、Imagingドメインを構成します。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
OAMアイデンティティ・アサータを構成します。OAMアイデンティティ・アサータの制御フラグをREQUIREDに設定し、アクティブなタイプとしてOAM_REMOTE_USERを選択する必要があります。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
認証プロバイダを構成します。これは、Oracle Internet Directory (OID)や別の外部LDAPサーバーなど、ユーザー・ストアを指定する場合に必要です。たとえば、OAMでOIDを使用する場合、OID認証プロバイダをImagingドメインに追加する必要があります。
|
注意: DefaultAuthenticatorプロバイダ以外の認証プロバイダを使用するようにImagingのOracle WebLogic Serverドメインを構成する場合、新しい認証プロバイダは、セキュリティ・レルム構成の最初の認証プロバイダである必要があります。そうでない場合、Imagingはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。また、DefaultAuthenticator制御フラグがSUFFICIENTに設定されていることを確認してください。詳細は、 『Oracle Fusion Middleware Oracle WebCenter Contentの管理』の第一認証プロバイダの構成に関する項を参照してください。 |
OAM 10gとOAM 11gで認証プロバイダをデプロイするときの違いの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
OPSS (OAM)シングル・サインオン・プロバイダを構成します。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
OAM 11gをインストールおよび構成した後、構成済のすべてのImagingアプリケーションにアクセスできることと、ログインにより、再度サインインを要求されることなく、構成済のすべてのImagingアプリケーションにアクセスできることを確認します。また、可能な場合、グローバル・ログアウトをテストし、その他のすべての関連アプリケーションからログアウトしていることを確認します。
|
注意: Oracle Access Manager (OAM) 11g WebGate 11gシングル・サインオン(SSO)を使用する場合、WebGate 11gエージェントのユーザー定義パラメータfilterOAMAuthnCookie=falseを設定する必要があります。このようにしない場合、ビューアを詳細モードで使用するときにエラーが発生します。OAMコンソールを使用したエージェントのユーザー定義パラメータの設定やパートナのリモート登録の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。 |
詳細は、Oracle Fusion Middleware Oracle Adaptive Access Managerの管理者ガイドおよびOracle Fusion Middlewareのアプリケーション・セキュリティ・ガイドを参照してください。
この項では、Oracle Access Manager (OAM) 10gと連携するようにImagingを構成する方法について説明します。OAMを構成する前に、Oracle WebLogic Server、WebCenter ContentおよびImagingがデプロイされていることを確認してください。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』を参照してください。
|
注意: Oracle Access Managerバージョン10gを使用する環境にImagingバージョン11gR1をデプロイするには、ログアウト・リクエストを正しく処理するための追加の構成が必要です。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。 |
Oracle Access Manager (OAM)を構成する前に、Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOracle Identity Management 10gソフトウェアのインストールに関する項に記載されている手順に従ってソフトウェアをインストールします。
Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドに記載されている説明に従って、Oracle Access Manager (OAM)、Oracle HTTP Server (OHS)およびWebゲートをインストールして構成します。
次の例を使用して、Imagingのエントリをmod_wl_ohs.confに追加します。hostnameは、Imagingインスタンスをホストするマシンの名前に、portnumberは、ImagingをホストするOracle WebLogic Serverドメインのポートに置き換えてください。
<Location /imaging>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
Oracle OAM構成ツール(cfgtool)を使用して、保護するImagingのURIを指定します。Imagingの場合、/imaging/facesを保護します。
Oracle Access Manager構成ツールはコマンドライン・ユーティリティで、情報を要求する一連のスクリプトを起動し、Oracle Access Managerで必要なプロファイルとポリシーを設定するのに使用します。詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOAMCtgToolの使用に関する項を参照してください。
次のタスクを確実に実行して、Imagingドメインを構成します。詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドを参照してください。
OAMアイデンティティ・アサータを構成します。OAMアイデンティティ・アサータの制御フラグをREQUIREDに設定し、アクティブなタイプとしてObSSOCookieを選択する必要があります。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
認証プロバイダを構成します。これは、Oracle Internet Directoryや外部LDAPサーバーなど、ユーザー・ストアを指定する場合に必要です。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
OAM 10gとOAM 11gで認証プロバイダをデプロイするときの違いの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の表15-2を参照してください。
OPSS (OAM)シングル・サインオン・プロバイダを構成します。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
詳細は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドを参照してください。
MicrosoftクライアントでImagingおよびシングル・サインオン(SSO)を設定するには、Microsoft Active Directory、クライアントおよびOracle WebLogic Serverドメインを構成する必要があります。MicrosoftクライアントでのSSOへのシステム要件を含む詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のMicrosoftクライアントでのシングル・サインオンの構成に関する項に記載されています。
MicrosoftクライアントでのSSOの構成の一部として、外部Microsoft Active DirectoryにアクセスするようにLDAP認証プロバイダを指定する必要があります。Oracle WebLogic ServerではMicrosoft Active Directory用に構成済のLDAPプロバイダであるActive Directory Authentication providerが提供されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のLDAP認証プロバイダの構成に関する項を参照してください。
|
注意: DefaultAuthenticatorプロバイダとは異なる認証プロバイダを使用するようにImagingのOracle WebLogic Serverドメインを構成する場合、新しい認証プロバイダは、セキュリティ・レルム構成の最初の認証プロバイダである必要があります。そうでない場合、Imagingはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。また、DefaultAuthenticator制御フラグがSUFFICIENTに設定されていることを確認してください。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』の第一認証プロバイダの構成に関する項を参照してください。 |
MicrosoftクライアントでのSSOの構成の一部として、Oracle WebLogic Serverセキュリティ・レルムにネゴシエートIDアサーション・プロバイダを構成する必要があります。IDアサーション・プロバイダは、Simple and Protected Negotiate (SPNEGO)トークンをデコードしてKerberosトークンを取得し、このKerberosトークンを検証してWebLogicユーザーにマップします。Oracle WebLogic Server管理コンソールを使用して、ドメイン構造内の適切なセキュリティ・レルムに新しいプロバイダを追加し、名前を付けて、そのタイプとしてNegotiateIdentityAsserterを選択します。変更をアクティブ化して、Oracle WebLogic Serverを再起動します。サーバーはKerberosチケットを使用できるようになり、それはブラウザから受信します。
Imagingのデプロイメント・プランを使用してImagingを再デプロイする必要があります。デプロイ・プランはXMLドキュメントです。オラクル社からImagingのプランが提供されています。Oracle WebLogic Scripting Toolを使用してデプロイメント・プランを作成することもできます。提供されているプランを使用してデプロイする手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ナビゲーション・ツリーで、「デプロイメント」をクリックします。
「制御」タブで、Imagingデプロイメントが表示されるまで「次へ」をクリックします。
デプロイメントの左にあるチェック・ボックスを選択します。
「更新」をクリックします。
デプロイ・プラン・パスの下で「パスの変更」を選択します。
ipm-deployment-plan.xmlプラン・ファイルに移動して選択します。
「このアプリケーションを次のデプロイメント・ファイルを使用して再デプロイします。」が選択されていることを確認します。
「次へ」をクリックします。
「終了」をクリックします。
MicrosoftクライアントでのSSOが適切に構成されていることを確認するには、ブラウザを使用して、使用するMicrosoft WebアプリケーションまたはWebサービスにアクセスします。Windowsドメインにログインし、ドメインのActive Directoryサーバーから取得したKerberos資格証明がある場合、ユーザー名またはパスワードを指定せずにWebアプリケーションまたはWebサービスにアクセスできるはずです。
ipm-deployment-plan.xml
提供されたipm-deployment-plan.xmlファイルを使用するか、または.xmlファイルを作成してそれにipm-deployment-plan.xmlという名前を付けます。
<?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"
global-variables="false">
<application-name>app</application-name>
<variable-definition>
<variable>
<name>http-only</name>
<value>false</value>
</variable>
</variable-definition>
<module-override>
<module-name>imaging-ui.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<name>http-only</name>
<xpath>/weblogic-web-app/session-descriptor/cookie-http-only</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
</deployment-plan>
