| Oracle® Fusion Middleware Oracle Portal管理者ガイド 11gリリース1 (11.1.1) B61385-05 |
|
 前 |
 次 |
ポータル・ソリューションの最も重要な側面の1つにセキュリティがあります。Webコンテンツへのユーザー・アクセスを制御したり、システムへの侵入者からサイトを保護したりできることがきわめて重要です。この章では、Oracle Portalのセキュリティのアーキテクチャについて説明します。
|
関連項目:
|
次の項では、Oracle Portalのセキュリティの概要と、Oracle Fusion Middleware Security Frameworkでの動作について説明します。
Web上でコンテンツを利用可能にするときは、少なくともそのコンテンツの一部へのアクセスを制限する必要があることが普通です。たとえば、サイトにあるすべてのドキュメントの表示をすべてのユーザーに可能にすることはまず考えられません。また、サイトにあるすべてのドキュメントの変更をすべてのユーザーに許可することはさらに考えられません。Oracle Portalでは、Webサイトの表示や変更ができるユーザーを完全に制御できる包括的なセキュリティ・モデルを提供しています。
ユーザーは、Oracle Portalにログインしないと、コンテンツ作成者がパブリックとして作成したコンテンツしか閲覧できません。パブリック・コンテンツは、ポータル・オブジェクト(ページなど)のURLを知っていて、それが格納されているコンピュータに接続できるユーザーであれば誰でも閲覧できます。ユーザーは、パブリックとして作成されたオブジェクト(パブリック・ポートレットなど)のみを表示できます。オブジェクトにパブリック・コンテンツが含まれていない場合、ユーザーはそのオブジェクトへのアクセスを拒否されます。
ポータルにログインしたユーザーは、そのユーザーのアクセス権限によって、コンテンツの表示および変更ができる場合もあれば、できない場合もあります。一般に、認証されたユーザーは、パブリック・ユーザーに比べてポータルで表示や、より多くの操作を実行できます。たとえば、認証されたユーザーは、パブリック・ユーザーが閲覧できないページ上のアイテムやポートレットを表示できます。また、認証されているユーザーは、パブリック・ユーザーだったら通常拒否される可能性のある、コンテンツの追加や編集、プロパティ、権限の変更などを行うことができます。ポータルでは、ユーザーやグループごとにオブジェクト(ページ、アイテムまたはポートレット)へのアクセスを制御することができます。つまり、ページに対するアクセス権限を特定のユーザー名、ユーザー・グループ名またはその両方の組合せで付与できます。
Oracle Portalでは、このように柔軟な方法でWebコンテンツへのアクセスを管理するために、Oracle Fusion Middlewareの他のコンポーネントとOracle Database 11gを活用して、ポータルの強固な保護を実現します。Oracle Portalでは、そのセキュリティ・モデルを実装するために、次のすべてのコンポーネントと対話します。
Oracle Application Server Single Sign-Onは、ポータルのパブリック以外の領域にアクセスしようとするユーザーを認証します。
mod_ossoは、Oracle HTTP Serverモジュールの1つで、OracleAS Single Sign-Onに認証リクエストをリダイレクトします。パートナ・アプリケーションのユーザー・アクティビティの追跡にも使用されます。
Oracle Web Cacheは、Oracle Portalによって作成されたページの処理に使用されるキャッシュです(リクエストを処理できない場合は、Oracle HTTP Serverが代行します)。Oracle Portalでは、無効化キャッシュに基づいて、基となるページまたはメタデータが変更されると、キャッシュを無効にします。
Oracle Internet Directoryは、Oracle固有のLDAPバージョン3のサービスで、ユーザー証明書とグループ・メンバーシップのリポジトリとして機能します。
Oracle Internet DirectoryのOracle Delegated Administration Servicesは、ディレクトリの内部に格納される情報(ユーザーおよびグループ)を追加または更新します。
Oracle Directory Integration Platformは、Oracle Portalがサブスクライブするなんらかのディレクトリ・イベント(ユーザーの削除など)が発生したときにOracle Portalに通知します。基本的に、Directory Integration Serverは、Oracle Portalにおいて変更が必要なディレクトリで変更が行われたときに、Oracle Portalに通知します。
Oracle Portalのアーキテクチャ
図7-1は、Oracle Portalのセキュリティ・アーキテクチャのコンポーネントおよびそれらの関係を示しています。
Oracle Portalのアーキテクチャは、3つの基本層(クライアント・ブラウザ、中間層サーバー、およびインフラストラクチャ・サーバーとリポジトリ)で構成されています。Oracle Internet DirectoryとOracleAS Single Sign-Onは、インフラストラクチャをインストールする過程でデフォルトで同じホストにインストールされます。この層は、引き続きOracle Portalのインストールに使用されます。
デフォルトのインストールでは、3つのサーバーとリポジトリがすべて同じホストにインストールされますが、これらの機能を別々のサーバーにインストールすることをお薦めします。
Oracle Portalでは、中間層とインフラストラクチャ層のコンポーネントに多数の共通コンポーネントがあります。その中には、データベース・アクセス記述子(DAD)とOracle Fusion Middlewareで構成するリポジトリ・アクセス・コンポーネントがあります。後者は、インフラストラクチャ層で使用され、Oracle Delegated Administration Servicesを実行し、中間層でポータル・ランタイム・エンジンを実行します。
Oracle Portalのスループットとパフォーマンスを最適化するために、生成されたページはOracle Web Cacheにキャッシュされます。Oracle Web Cacheからポータル・ページに対するリクエストを提出できる場合、リクエストはOracle Portal中間層にアクセスせずに返されます。それ以外の場合、リクエストは、HTTPのオリジナル・サーバーとParallel Page Engineに転送されます。
現在のユーザーがSingle Sign-On環境で認証されておらず、リクエストされたページがパブリック・ページではない場合、ユーザーはユーザー名とパスワードを入力するよう要求されます。この機能は、認証のためにOracleAS Single Sign-Onへリダイレクトすることによって実行され、そこでLDAPリクエストを介して、Oracle Internet Directoryを基準として証明書が検証されます。証明書はディレクトリ内で見つかったものと照合されます。
認証に成功すると、シングル・サインオンのセッションCookieがOracleAS Single Sign-Onで作成されます。ユーザーが認証され、適切なOracle Portalセッションが作成されたら、ユーザーがアクセスに必要な権限を持つページやオブジェクトを特定する必要があります。パフォーマンス上の理由から、すべてのポータル・オブジェクトのアクセス制御リスト(ACL)は、保護対象のオブジェクトの定義とともにOracle Metadata RepositoryのOracle Portalスキーマに格納されます。
ユーザーとグループのプロビジョニングは、Oracle Internet Directoryの機能です。つまり、すべてのユーザーおよびグループ・メンバーシップの情報がOracle Internet Directoryに格納されます。ユーザーが初めてOracle Portalにログインすると、ユーザーの現在のグループ・メンバーシップがディレクトリから読み取られ、ACLと同じリポジトリにキャッシュされます。このプロセスによって、オブジェクトの権限をすばやく検索することができます。ユーザーのオブジェクトやページの権限がわかると、適切なページ・メタデータを生成して、Parallel Page Engineによって保護されたページを収集できるようになります。
Oracle Internet Directory内のユーザーとグループのプロビジョニングを単純化してポータルで使用するために、Oracle PortalはOracle Delegated Administration Servicesを使用して、Oracle Internet Directoryへのダイレクト・アクセスを可能にするユーザー・インタフェースを生成します。Oracle Delegated Administration Servicesへのコールは、mod_ossoプラグインによって保護されます。これは、Oracle Internet Directoryへのアクセスを提供する前に、ユーザーが正しく認証されていることを確認します。
セキュリティ・アーキテクチャの重要な機能の1つは、ローカルでキャッシュされたグループ・メンバーシップ・リストをOracle Internet Directoryと同期化する機能です。Oracle Directory Integration Platformでは、ローカルでキャッシュされた情報をOracle Internet Directoryでの変更に合せて自動的に最新の状態にしています。
外部リポジトリと照合して認証を行う必要がある場合は、Oracle Internet Directoryによって、委任された認証と外部認証の両方がサポートされます。Oracle Directory Integration Platformは、ローカル・キャッシュとOracle Internet Directoryを常に同期化するだけでなく、同様にOracle Internet Directoryと外部のすべてのリポジトリを常に同期化しています。
Oracle Portalには、デフォルトでユーザー・アカウントとユーザー・グループが多数用意されています。
表7-1で、Oracle Portalのインストール時にデフォルトで作成されるユーザー・アカウントについて説明します。
表7-2は、Oracle Portalのインストール時にデフォルトで作成されるグループを示しています。
表7-2 デフォルトのOracle Portalグループ
| グループ脚注 1 | 説明 |
|---|---|
|
認証された、つまりログインしているユーザーを含むグループ。このグループの目的は、ポータルにログインしているすべてのユーザーに与えるデフォルトの権限を割り当てる手段を提供することです。 デフォルトでは、このグループにはグループの作成権限とすべてのスタイルの作成権限が付与されます。 このグループは、OracleDASCreateGroupのメンバーです。 |
|
|
Oracle Fusion Middlewareの管理者向けに設定された、高度な権限を持つグループ。Oracle Fusion Middlewareの一部であるコンポーネントによって、すべてのコンポーネント固有の権限がこのグループのメンバーに付与されます。 DBAグループは、 このグループは、次のOracle Fusion Middlewareの権限グループのメンバーにもなっています。
DBAのメンバーには、OracleAS Single Sign-Onの管理に必要な権限は付与されません。このグループのメンバーにOracleAS Single Sign-Onを管理させる場合は、Oracle Application Server Single Sign-On管理者ガイドの説明に従って、それらの権限をこのグループのメンバーに付与する必要があります。 |
|
|
Oracle Portal向けに設定された高度な権限のあるグループ。 デフォルトでは、このグループには次のOracle Portalのグローバル権限が付与されます。
このグループは、次のOracle Fusion Middlewareの権限グループのメンバーでもあります。
|
|
|
ポータルの他のユーザーにポートレットを公開する必要があるユーザー向けに設定された権限のあるグループ。 このグループには、デフォルトでOracle Portalの「すべてのポートレットの公開」グローバル権限が付与されます。 |
|
|
ポートレットを構築しているユーザー向けに設定された権限のあるグループ。 デフォルトでは、このグループには次のOracle Portalのグローバル権限が付与されます。
Portalの開発者には、データベース・プロバイダおよびポートレットを作成するための特別な権限が必要です。その権限を、すべてのスキーマでのデータ変更などのタスクを実行する開発者に割り当てることができます。詳細は、表7-6を参照してください。また、管理者権限 |
|
|
Oracle Reports Servicesのレポート、プリンタ、カレンダおよびサーバーを管理するユーザーのグループ。 「管理」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。 |
|
|
Oracle Reports Servicesのレポートを開発するユーザーのグループ。 「実行」や「管理」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。 |
|
|
Oracle Reports Servicesのレポートを変更できるユーザーのグループ。 「実行」や「管理」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。 |
|
|
Oracle Reports Servicesのレポートを使用するユーザーのグループ。 「実行」など、必要なオブジェクト権限をこのグループに割り当てる必要があります。 |
|
|
Oracle Instant Portalの作成とユーザー管理の両方を実行できるユーザーのグループ。FMWADMINユーザーはこのグループのメンバーです。 |
|
|
Oracle Instant Portalにアクセスできるユーザーのグループ。このリストは、Oracle Instant Portalのユーザー・インタフェースの「ユーザー権限の管理」ダイアログ・ボックスに表示されます。 注意: Oracle PortalユーザーをOracle Instant Portalユーザーとして指定するには、「グループ」ポートレットを使用して、インストール時にデフォルトで作成される |
脚注1 この表に示すグループはすべて、cn=<portal_group_container>,cn=Groups,dc=MyCompany,dc=comにあります。ID管理レルムの名前は、システムがインストールされているサーバーのドメイン名によって決定されることに注意してください。たとえば、サーバーのドメイン名がoracle.comであった場合、デフォルトのID管理レルム名はdc=oracle,dc=comとなります。サーバーのドメイン名がわからない場合、Oracle Internet Directoryではデフォルトでインストール時に管理者が指定したドメインになります。OracleDASxxxxxグループは、Oracle Internet Directoryの権限グループで、cn=groups,cn=OracleContext,dc=MyCompany,dc=com下にあります。これらのグループは、Oracle Internet Directoryでの操作(ユーザーやグループ、およびそれらの権限の作成または編集)を実行する権限を付与します。
|
注意:
|
Oracle Portalをインストールすると、インストール・プロセスによって、知っておく必要のあるデフォルトのスキーマがいくつかインストールされます。
表7-3で、Oracle Portalのインストール時にデフォルトで作成されるスキーマについて説明します。
表7-3 Oracle Portalのデフォルト・スキーマ
| スキーマ | 説明 |
|---|---|
|
Oracle Portalのデータベース・オブジェクトとコードを含んでいます。 Webでリクエストされたプロシージャを実行する際に、PortalサービスはN層認証を使用して、軽量ユーザー・アカウントが割り当てられているスキーマ(デフォルトではPREFIX_PORTAL_PUBLIC)に接続します。図7-2に示すように、ポータル・ユーザーのデータベースへのアクセスは、単一のスキーマ・ユーザーを介してプロキシ処理されます。 |
|
|
すべての軽量ユーザーがデフォルトでマップされるスキーマです。プロシージャの権限は、このPREFIX_PORTAL_PUBLICスキーマ独自に付与されます。PUBLICにはプロシージャの実行権限が付与されなくなりました。 |
|
|
デモ・コードを保持するために作成されます。このスキーマのインストールはオプションです。 |
|
|
外部JSPアプリケーションの認証に使用されます。 |
図7-2に、ユーザー・プロキシによるN層認証を示します。
Oracle Portal内では、アクセスを制御するときの精度レベルを決定します。権限はユーザーごと、またはグループごとに、どのオブジェクトに対しても割り当てることができます。たとえば、ポータル内の各アイテムに対してユーザーごとにアクセス権限を割り当てることができますが、この方法ではコンテンツ作成者にかなりの負担がかかります。
作成者の負担を減らす場合は、ページ・レベルでグループごとに権限を割り当て、所定のページに配置したすべてのアイテムが同様のセキュリティ要件を持つようにすることができます。この方法を使用すると、通常はアイテムが含まれるページを介してアイテムが受けるセキュリティで十分であるため、コンテンツ作成者はページよりも高いセキュリティを必要とするアイテムに対してのみ権限を割り当てる必要があります。
ユーザーまたはグループに特定のタイプのすべてのオブジェクトに対する一定レベルの権限を付与する場合は、グローバル権限を使用します。
|
注意: グローバル権限を付与されたユーザーには、多大な権限が与えられます。そのため、グローバル権限は本当にそれを必要としているユーザーまたはグループに対してのみ、十分に注意して付与する必要があります。グローバル権限は少数のユーザーに限定するようにしてください。 |
権限グループには、3つのタイプがあります。
| オブジェクト・タイプ | 権限 |
|---|---|
|
「なし」: グローバル・ページ・グループ権限は一切付与されません。 「すべて管理」: ページ・グループであらゆる作業を実行できます。この権限は、他のグローバル・ページ・グループ権限に含まれる他のすべての権限に優先します。たとえば、この権限ですべてのページを管理できます。 「クラスの管理」: ページ・グループのカテゴリ、パースペクティブ、カスタム属性、カスタム・ページ・タイプまたはカスタム・アイテム・タイプを作成、編集および削除できます。 「テンプレートの管理」: ページ・グループのPortalテンプレートまたはHTMLテンプレートを作成、編集および削除できます。すべてのテンプレートへのアクセス権限を付与します。 「スタイルの管理」: ページ・グループのスタイルを作成、編集および削除できます。 「表示」: ページ・グループのすべてのページを表示できます。 「作成」: ページ・グループを作成し、そのページ・グループにページ・グループ・オブジェクトを作成できます。この権限を保持するユーザーまたはグループは、作成したページ・グループおよびページ・グループ・オブジェクトを編集および削除することもできます。注意: この権限を保持するユーザーは、既存のページ・グループにはオブジェクトを作成できません。 |
|
|
「なし」: グローバル・ページ権限は一切付与されません。 「管理」: ページ・グループのページを作成、編集、パーソナライズまたは削除できます。ページ・グループのすべてのページへのアクセス権限を付与します。 「コンテンツの管理」: ページ・グループのページのアイテム、ポートレットまたはタブの追加、編集、非表示、共有または削除を行うことができます。 「承認付きアイテムの管理」: ページ・グループのページに新しいアイテムを作成できます。新しいアイテムは、指定された承認プロセスによって承認されるまで公開されません。この権限を持つユーザーおよびグループは、作成したアイテムを編集することもできます。また、ページをパーソナライズすることもできます。ページ・グループに対する承認が有効になっていない場合、アイテムに対するこの権限は、オブジェクト・タイプ「すべてのページ」のグローバル権限「コンテンツの管理」と同様になります。 「スタイルの管理」: ページ・グループのページに、選択可能なスタイルまたは新しいスタイルを適用できます。新しいスタイルを作成、編集および削除できます。注意: ユーザー自身が作成したスタイルの編集のみを許可します(他のユーザーのスタイルは変更または削除できません)。 「ポートレットのパーソナライズ(フル)」: ページ・グループのページをパーソナライズして、ポートレットを追加、表示、非表示、削除、移動または再配置できます。ページをパーソナライズして、タブを表示、非表示、削除または再配置できます。または既存のタブ・リージョンにタブを追加できます。ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。 「ポートレットのパーソナライズ(追加のみ)」: ページ・グループのページをパーソナライズして、ポートレットの追加または既存のタブ・リージョンにタブを追加できます。これらの権限を保持するユーザーまたはグループは、追加したポートレットを削除することもできます。ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。 「ポートレットのパーソナライズ(非表示-表示)」: ページ・グループのページをパーソナライズして、ポートレットまたはタブを表示または非表示にできます。ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。ページ・グループのページにポートレットを配置できます。 「パーソナライズ(スタイル)」: ページ・グループのページをパーソナライズして、別のスタイルを使用することもできます。 「表示」: ページ・グループのすべてのページを表示できます。 「作成」: ページ・グループにサブページを作成できます。この権限を保持するユーザーまたはグループは、作成したサブページの編集および削除もできます。注意: ページを作成するには、ページを作成するページ・グループのルート・ページの「管理」権限を保持している必要があります。 |
|
|
「なし」: グローバル・スタイル権限は一切付与されません。 「管理」: ページ・グループのスタイルを作成、編集および削除できます。 「表示」: ページ・グループのスタイルを表示できます。 「公開」: ページ・グループのスタイルを他のユーザーが使用できるように公開できます。 「作成」: ページ・グループにスタイルを作成できます。この権限を保持するユーザーまたはグループは、作成したスタイルを編集および削除することもできます。 |
|
|
「なし」: グローバル・プロバイダ権限は一切付与されません。 「管理」: プロバイダを登録、編集および登録解除し、ポートレット・リポジトリを表示および更新することができます。プロバイダの編集権限を付与することもできます。 「編集」: 登録されたプロバイダを編集できます。 「公開」: プロバイダを登録および登録解除できます。 「実行」: プロバイダのコンテンツを表示できます。 「作成」: ポートレット・プロバイダを登録できます。ユーザー(またはグループ)が作成したプロバイダでは、そのユーザーに「管理」権限が付与されます。したがって、ユーザーは、自分が作成したプロバイダに対して(編集と登録解除を含め)すべての操作を実行できます。 |
|
|
「なし」: グローバル・ポートレット権限は一切付与されません。 「管理」: プロバイダのポートレットを作成、編集または削除できます。 「編集」: プロバイダのポートレットを編集できます。 「実行」: プロバイダのポートレットを実行できます。この権限を保持するユーザーまたはグループは、ポートレットにセキュリティが適用されている場合でも、すべてのポートレットを表示できます。ナビゲータには、すべてのポートレットに対する「表示」リンクが表示されます。 「アクセス」: プロバイダのポートレットを表示できます。 「公開」: ページ、ナビゲーション・ページまたはPortal DBプロバイダ・ポートレットをポータルに公開して、ページに追加できるようにします。 |
表7-5 Portal DBプロバイダ権限
| オブジェクト・タイプ | 権限 |
|---|---|
|
「なし」: グローバル・アプリケーション権限は一切付与されません。 「管理」: Portal DBプロバイダを編集または削除できます。Portal DBプロバイダのポートレットを作成、編集または削除できます。Portal DBプロバイダおよびPortal DBプロバイダのポートレットへのアクセス権限を付与します。 「コンテンツの編集」: Portal DBプロバイダのポートレットを編集できます。 「ソースの表示」: パッケージの仕様部と本体を表示し、Portal DBプロバイダのポートレットを実行できます。ポートレットのソースを確認できるユーザーまたはグループを主な対象にしているため、その呼出し方法についての説明は省略します。 「パーソナライズ」: Portal DBプロバイダのポートレットを実行およびパーソナライズできます。 「実行」: Portal DBプロバイダのポートレットを実行できます。 「作成」: Portal DBプロバイダを作成できます。この権限を保持するユーザーまたはグループは、作成したプロバイダを編集および削除できます。また、作成したプロバイダのポートレットを作成、編集および削除できます。 |
|
|
「なし」: グローバル共有コンポーネント権限は一切付与されません。 「管理」: Portal DBプロバイダの共有コンポーネントを作成、表示、コピー、編集、削除およびエクスポートできます。システム共有コンポーネントを表示およびコピーできます。非システム共有コンポーネントへのアクセス権限を付与します。 「作成」: Portal DBプロバイダ内に共有コンポーネントを作成できます。システム共有コンポーネントを表示およびコピーできます。共有コンポーネントを表示できます。この権限を保持するユーザーまたはグループは、作成した共有コンポーネントを表示、コピー、編集、削除およびエクスポートできます。 |
| オブジェクト・タイプ | 権限 |
|---|---|
|
「なし」: グローバル・ユーザー・プロファイル権限は一切付与されません。 「管理」: ユーザー・プロファイルを編集できます。他のユーザーおよびグループにこの権限を付与できます。 「編集」: ユーザー・プロファイルを編集できます。 |
|
|
「なし」: グローバル・グループ・プロファイル権限は一切付与されません。 「管理」: グループ・プロファイルを編集できます。この権限を他のグループに付与できます。グループ・プロファイルの「権限」タブを使用すると、ユーザーはグループにこの権限を付与できます。「管理」権限によって「編集」権限が付与され、この権限を他のユーザーに付与できます。 「編集」: ポータル・グループ・プロファイルを編集(デフォルトのホーム・ページとデフォルトのモバイル・ホーム・ページを設定)できます。注意: グループの説明、メンバーシップおよび所有者を変更する権限は、Oracle Internet Directoryのアクセス制御ポリシーで制御されます。このポリシーは、OracleDASEditGroupグループのメンバーシップにより管理されます。 |
|
|
「なし」: グローバル・スキーマ権限は一切付与されません。 「管理」: スキーマを作成、編集および削除できます。スキーマへのアクセス権限を付与します。スキーマのデータベース・オブジェクトの作成、編集、削除および名前の変更ができます。表のデータまたはスキーマのビューの問合せ、更新、削除および挿入を行うことができます。スキーマのファンクション、プロシージャ、パッケージまたはビューをコンパイルできます。スキーマのファンクション、プロシージャまたはパッケージを実行できます。すべてのスキーマのデータベース・オブジェクトへのアクセス権限を付与します。 「データの変更」: スキーマを作成できます。表のデータまたはスキーマのビューの問合せ、更新、削除および挿入を行うことができます。スキーマのファンクション、プロシージャ、パッケージまたはビューをコンパイルできます。スキーマのファンクション、プロシージャまたはパッケージを実行できます。この権限を保持するユーザーまたはグループは、作成したスキーマの編集、削除およびアクセス権限の付与を行うことができます。 「データの挿入」: スキーマを作成できます。表のデータまたはスキーマのビューの問合せおよび挿入を行うことができます。この権限を保持するユーザーまたはグループは、作成したスキーマの編集、削除およびアクセス権限の付与を行うことができます。 「データの表示」: スキーマを作成できます。表のデータまたはスキーマのビューに対する問合せを行うことができます。この権限を保持するユーザーまたはグループは、作成したスキーマの編集、削除およびアクセス権限の付与を行うことができます。 「作成」: スキーマを作成します。この権限を保持するユーザーは各自が作成したスキーマの編集、削除およびアクセス許可も実行できます。注意: 「ビルダー」ページの「データベースの管理」タブで、「スキーマ」ポートレットへのアクセスをユーザーまたはグループに許可する場合は、そのユーザーまたはグループをDBAグループのメンバーにするか、「データベースの管理」タブで明示的にそのユーザーまたはグループに表示権限を付与します。これらの権限が付与されていないユーザーやグループは、「ナビゲータ」からスキーマにアクセスすることができません。 |
|
|
「なし」: グローバル・ログ権限は一切付与されません。 「管理」: ログを編集またはパージ(消去)できます。この権限を他のユーザーに付与できます。 「編集」: ログを編集またはパージ(消去)できます。 「表示」: ログを表示できます。 |
|
|
「なし」: グローバル・トランスポート・セット権限は一切付与されません。 「実行」: 共有されていないオブジェクトをエクスポートおよびインポートできます。また、この権限を保持するユーザーは、共有されていないエクスポート・オブジェクトとインポート・オブジェクトを編集またはパージ(消去)できます。 「管理」: インポート・セットまたはエクスポート・セットを編集またはパージ(消去)できます。この権限を他のユーザーに付与できます。 |
オブジェクトの「ページの編集」の「アクセス」タブを使用すると、Oracle Portal内の次のすべてのオブジェクトに対するアクセス権限をユーザーまたはグループに割り当てることができます。
表7-7 Oracle Portalオブジェクトと権限の制御
| オブジェクトのタイプ | 利用できる権限 | 権限の継承元 |
|---|---|---|
|
カレンダ |
|
データベース・プロバイダ |
|
チャート (SQL問合せベース) |
|
データベース・プロバイダ |
|
チャート (ウィザード・ベース) |
|
データベース・プロバイダ |
|
データ・コンポーネント |
|
データベース・プロバイダ |
|
データ・コンポーネント・セル |
|
データ・コンポーネント |
|
データベース・プロバイダ |
|
該当なし |
|
ドキュメント |
|
ページまたはアイテム |
|
動的ページ・コンポーネント |
|
データベース・プロバイダ |
|
フォーム脚注 1 |
|
データベース・プロバイダ |
|
フレーム・ドライバ |
|
データベース・プロバイダ |
|
階層 |
|
データベース・プロバイダ |
|
イメージ・チャート |
|
データベース・プロバイダ |
|
リンク |
|
データベース・プロバイダ |
|
値リスト |
|
データベース・プロバイダ |
|
メニュー |
|
データベース・プロバイダ |
|
Oracle Reports Servicesプリンタ |
|
データベース・プロバイダ |
|
Oracle Reports Servicesレポート |
|
データベース・プロバイダ |
|
Oracle Reports Servicesサーバー |
|
データベース・プロバイダ |
|
ページ |
|
ページ・グループのルート・ページ |
|
ページ・グループ |
|
該当なし |
|
ページ・アイテム |
|
ページ |
|
ポートレット |
|
該当なし |
|
プロバイダ |
|
該当なし |
|
例による問合せフォーム |
|
データベース・プロバイダ |
|
レポート脚注 3 |
|
データベース・プロバイダ |
|
スキーマ |
|
該当なし |
|
URL |
|
データベース・プロバイダ |
|
XML |
|
データベース・プロバイダ |
脚注1 フォームには多様なタイプ(ストアド・プロシージャまたは表ベース、リリース2またはリリース3ベース、マスター/ディテール)がありますが、これらのタイプで利用できる権限や権限の継承元はすべて同じです。
脚注2 この権限は、承認がページ・グループ・レベルで有効になっている場合にのみ、「アクセス」タブで使用できます。ページ・グループに対する承認が有効になっていないか、承認は有効になっているがページ・レベルまたはページ・グループ・レベルに承認プロセスが定義されていない場合、この権限はページのグローバル権限「コンテンツの管理」と同様になります。
脚注3 レポートには2つの異なるタイプ(SQLおよび表ベース)がありますが、これらのタイプで利用できる権限や権限の継承元はすべて同じです。
新規プロバイダを作成または登録すると、「ポートレット・ステージング領域」の「ポートレット・リポジトリ」にページが作成され、そのプロバイダのポートレットが表示されます。このページはすべてのログイン・ユーザーに表示されるわけではありません。プロバイダを公開したユーザーおよびポータル管理者にのみ表示されます。公開者またはポータル管理者は、プロバイダのページ・プロパティを変更して、必要に応じて適切なユーザーまたはグループに権限を付与できます。
ファイルを直接操作するかわりに、ユーザー・インタフェースを使用してWebプロバイダとプロバイダ・グループを管理するには、管理ユーザーに適切な権限を付与する必要があります。アクセス制御リストの実装方法は、Oracle Portalスキーマに常駐するオブジェクトの場合とは異なります。Oracle Portalスキーマに常駐するオブジェクトの詳細は、第7.1.3.1項「グローバル権限」および第7.1.3.2項「オブジェクト権限」を参照してください。プロバイダ権限の付与は、XMLファイルで管理します。
Webプロバイダまたはプロバイダ・グループを編集および削除するための権限を付与するには、次のファイルを手動で変更する必要があります。
DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INF\deployment_providerui\provideruiacls.xml
次に、このファイルの例を示します。
|
注意: この例のユーザー名 |
<providerui xmlns="http://www.example.com/portal/providerui/1.0">
<objectType name="ALL_OBJECTS">
<object name="ANY_PROVIDER" owner="providerui">
<user name="any_provider_manager_user" privilege="500"/>
<user name="any_provider_edit_user" privilege="400"/>
<user name="any_provider_execute_user" privilege="300"/>
</object>
<object name="ANY_PORTLET" owner="providerui">
<user name="any_portlet_manage_user" privilege="500"/>
<user name="any_portlet_edit_user" privilege="400"/>
<user name="any_portlet_execute_user" privilege="300"/>
</object>
</objectType>
<objectType name="PROVIDER">
<object name="TEST_PROVIDER" owner="providerui">
<user name="provider_manage_user" privilege="500"/>
<user name="provider_edit_user" privilege="400"/>
<user name="provider_execute_user" privilege="300"/>
</object>
</objectType>
<objectType name="PORTLET">
<object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
<user name="portlet_manage_user" privilege="500"/>
<user name="portlet_edit_user" privilege="400"/>
<user name="portlet_execute_user" privilege="300"/>
</object>
</objectType>
</providerui>
このファイルでは、次の項に説明されている権限タイプを付与できます。
表7-8で、provideruiacls.xmlファイルでユーザーに付与できるグローバル・オブジェクト・タイプおよび対応する権限コードについて説明します。ユーザーに権限を付与するときには、数値の権限コードを指定する必要があります。
表7-8 provideruiacls.xmlのグローバル権限コード
| オブジェクトのタイプ | 利用できる権限 |
|---|---|
|
ANY_PROVIDER |
500(管理): プロバイダまたはプロバイダ・グループおよびそれらのポートレットを編集または削除したり、開くことができます。 400(編集): プロバイダまたはプロバイダ・グループを編集したり、それらのポートレットを実行することができます。 300(実行): プロバイダまたはプロバイダ・グループを開いたり、それらのポートレットを実行することができます。 |
|
ANY_PORTLET |
500(管理): プロバイダのポートレットを編集、削除または実行できます。 400(編集): プロバイダのポートレットを編集または実行できます。 300(実行): プロバイダのポートレットを実行できます。 |
特定のユーザーの権限を追加するには、たとえば次のように、適切なオブジェクト・タイプ・コンテナにエントリを追加します。
<objectType name="ALL_OBJECTS">
<object name="ANY_PROVIDER" owner="providerui">
<user name="jdoe" privilege="400"/>
…
</object>
</objectType>
これらのグローバル権限では、objectTypeの名前はALL_OBJECTSに、オブジェクト所有者はprovideruiに設定します。また、オブジェクト名は、設定している権限付与のタイプに応じてANY_PROVIDERまたはANY_PORTLETになります。
次に、ユーザー名および権限を、権限受領者のOracleAS Single Sign-Onのユーザー名と、割り当てる権限コードに対応する値に設定します。このモデルでは、グループへの権限付与はサポートされません。ユーザーへの直接付与のみがサポートされます。
表7-9では、ユーザーに付与できるオブジェクト・レベルの権限について説明します。オブジェクト・レベルの権限を付与されたユーザーは、provideruiacl.xml XMLファイル内で特定のオブジェクト・インスタンスを参照できます。
表7-9 provideruiacl.xmlのオブジェクト権限コード
| オブジェクトのタイプ | 利用できる権限 |
|---|---|
|
PROVIDER |
500(管理): 指定されたプロバイダまたはプロバイダ・グループおよびそれらのポートレットを編集または削除したり、開くことができます。 400(編集): 指定されたプロバイダまたはプロバイダ・グループを編集したり、それらのポートレットを実行することができます。 300(実行): 指定されたプロバイダまたはプロバイダ・グループを開いたり、それらのポートレットを実行することができます。 |
|
PORTLET |
500(管理): 指定されたプロバイダの指定されたポートレットを編集、削除または実行できます。 400(編集): 指定されたプロバイダの指定されたポートレットを編集または実行できます。 300(実行): 指定されたプロバイダの指定されたポートレットを実行できます。 |
特定のユーザーの権限を追加するには、たとえば次のように、適切なオブジェクト・タイプ・コンテナにエントリを追加します。
<objectType name="PORTLET">
<object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
<user name="jdoe" privilege="400"/>
…
</object>
</objectType>
オブジェクト・レベルの権限では、objectTypeの名前は、アクセスを許可するオブジェクト・インスタンスに応じてPROVIDERまたはPORTLETに設定します。オブジェクト名は、同じくインスタンスに応じてプロバイダ名またはポートレット名に設定します。オブジェクト所有者は、プロバイダとポートレットのそれぞれについて、provideruiまたは関連プロバイダ名に設定します。
表7-10に、これらの規則をまとめます。
WSRPプロデューサを作成および編集する権限の付与の詳細は、次の場所に記載されているJSR 168仕様のセキュリティに関する項を参照してください。
http://jcp.org/aboutJava/communityprocess/first/jsr168/index.html.
ポートレット・リポジトリ内のURLおよびXMLポートレットを編集するには、ユーザーに権限を付与する必要があります。URLおよびXMLポートレットは、ポートレット・リポジトリの「ポートレット・ビルダー」ページから利用できます。アクセス権限を付与したり、JPDK Webアプリケーションでサンプル・プロバイダを編集するには、次のフォルダのprovideruiacls.xmlを手動で変更する必要があります。
DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INF\deployment_providerui\
付与できる権限の詳細は、第7.1.3.4項「Webプロバイダとプロバイダ・グループを編集する権限」を参照してください。
ユーザーがOracle Portalへのログインを試みると、まずOracleAS Single Sign-Onによって証明書がディレクトリと照合される必要があります。IDの照合が終わると、Oracle Portalによってディレクトリに格納されているユーザーのアクセス権限がチェックされて、ポータルで表示および使用できるオブジェクトが特定されます。
Oracle Portalから、ユーザーが「ログイン」リンクをクリックして、ログインするようリクエストします。
ログイン・リクエストがmod_ossoに転送されます。mod_ossoは、動的ディレクティブを使用して、認証のためにOracleAS Single Sign-Onサーバーと連携します。
OracleAS Single Sign-Onによってユーザー証明書がディレクトリに格納されている情報と照合されます。
認証に成功すると、OracleAS Single Sign-OnによってユーザーのSSO Cookieが作成されます。認証に成功しなかった場合、ユーザーはアクセスを拒否され、ユーザー名とパスワードの再入力のためにログイン・ページに戻されます。
ユーザーIDが確認されると、制御がOracle Portalに戻され、ポータル・セッションCookieが作成されます。次に、Oracle Portalはディレクトリに接続して、ユーザーのグループ・メンバーシップと権限を確認します。
そのセッションの間に、Oracle Portalによってユーザーのメンバーシップと権限の情報がローカルにキャッシュされます。
ユーザーがページへのアクセスを試みると、Oracle Portalによって次の確認が行われます。
ページがパブリックであるかどうかを確認します。パブリックであれば、ユーザーはそのページを表示できます。
そのページがパブリックでない場合は、Oracle Portalによってローカルの権限表が照合されて、現行のユーザーにそのページを表示する権限があるかどうかが確認されます。ユーザーに表示する権限があれば、ユーザーはページを表示できます。
現行のユーザーにページを直接表示する権限がない場合は、Oracle Portalによって、キャッシュされているメンバーシップ情報と権限表が照合されて、ユーザーが属しているいずれかのグループにそのページを表示する権限があるかどうかが確認されます。ユーザーが属しているいずれかのグループにページを表示する権限があれば、ユーザーはページを表示できます。
|
注意: ユーザーの権限に影響を及ぼす変更がOracle Internet Directoryに対して行われた場合は、通知が送信され、そのユーザーに関するキャッシュされた情報が無効になります。このため、Oracle Portalでは、通知を受信するとすぐに、ユーザーの更新された権限を適用し始めます。 |
Oracle Portal 11gでは、ユーザーが特定のページを表示または編集できるかどうかが、ページとユーザー(またはユーザーが属するロール)を参照するACLポリシー定義に従って決まります。ユーザーの権限は、特定のビジネス・ルール(リクエストの発信元など)ではなく、名前付きの個別IDで定義します。このセキュリティ・モデルの拡張を実現するために、Oracle Portal 11gでは、認可ルーチンを拡張するAuthorization Modifierパッケージが導入されています。このパッケージは、標準のACLチェックの前に実行され、ACLそのものを照合する前に別のルールによる評価を可能にします。この機能は、新規のページまたはページ・グループにのみ適用され、既存のページまたはページ・グループには適用されません。Authorization Modifierでアクセスが許可されると(trueが返される)、認証チェックはデフォルトのACLベースのメカニズムに戻り、ユーザーに適切なアクセス権限があるかどうかが判断されます。逆に、Authorization Modifierでアクセスが拒否されると(falseが返される)、ACLの照会も実行されず、たとえACLで許可されている場合でも、該当の操作に対する適切な権限がユーザーにない場合と同様に扱われます。インストールした状態のままのAuthorization Modificationパッケージは、デフォルトで必ずtrueを返すため、この機能は事実上無効になっています。したがって、アクセス権限の決定は、セキュリティACLの評価のみが基準となります。Authorization Modifierの機能を有効にするには、デフォルトのパッケージ本体を、目的のビジネス・ルールを実装したパッケージに置き換える必要があります。
Portalには、次のAuthorization Modifierが付属しています。
Oracle Portalには、事前に定義された3つのModifierパッケージが付属します(表7-11を参照)。これを使用して、セキュアなネットワーク認識のPortal環境を構築することで、ACLに基づくだけでなく、Portalページのリクエスト元にも基づくセキュリティ・ポリシーを実装できます。
表7-11 Authorization Modifierパッケージ
| スクリプト・ファイル | 説明 |
|---|---|
|
|
デフォルトのConFiGuration Authorization Modifierでは、セキュアなネットワークの外部からのリクエストに対して、すべてのページの編集機能やカスタマイズ機能が無効になっています。 |
|
|
ConFiGuration Authorization Modifier for Page Edit and Viewでは、セキュアなネットワークの外部に対して個々のページを保護できます。つまり、セキュアなネットワーク環境の外部からのリクエストに対しては、特定のページの表示および編集を許可しない機能です。 |
|
|
Authorization Modifierを無効にしてデフォルトの状態に戻します。 |
Modifierパッケージは、ORACLE_HOME\upgrade\portal\admin\plsql\wwcディレクトリにあります。
このパッケージを使用するには、次の手順を実行します。
SQL*Plusを使用して、所有者としてOracle Portalスキーマに接続します。
必要なパッケージ本体のスクリプト・ファイルを実行して、現在インストールされているAuthorization Modifierを上書きします。
このAuthorization Modifierパッケージの実装では、前述のORA_EXT_REQ CGI環境変数が存在するかどうかによって、リクエストを受信したサーバーが誰にでもアクセス可能なサーバーであるかどうかを認識します。そのようなサーバーで受信したリクエストは、セキュアなネットワーク環境の外部にあるものと見なします。Authorizationパッケージでコンパイルしたネットワーク外部からのリクエストは、編集リクエストを含め、すべて自動的に無効となります。つまり、カスタマイズおよび編集のリンクはすべてページから削除され、直接編集のURL参照はどれも許可されません。
この実装では次の内容を扱います。
より厳密なAuthorization Modifier (cfgampev)でも、CGI変数を使用して外部リクエストを判別します。ただし、この場合は、定義済のページ・メタデータと組み合せて、カスタムのページ属性としてそれを使用することで、目的とする内部と外部のセキュリティをポータル内のページの一部にのみ配置します。このように、特定のページに対する外部からの表示および編集を可能にする権限は、表示や編集に対する名前付き属性が当該のページに定義されているかどうかによって決まります。
ページを外部から表示できるかどうかは、カスタム属性isViewRestrictedで決まります。カスタム・ページ・テンプレートを使用してページ記述の一部として定義したこの属性の設定によって、ページの表示が可能かどうかが動的に決まります。この属性をOnに設定すると外部からはページを表示できなくなり、Off(デフォルト値)に設定すると外部からでも表示できるようになります。このルールが有効になっている場合は、エンド・ユーザーから見ると、ページを参照するリンクはすべて削除され、ページに対する直接のURLアクセス(ブラウザのブックマークなど)は不可能になります。
同様に、もう1つの名前付き属性であるisEditRestrictedによって、特定のページがセキュアなネットワークの外部から編集できるかどうかが決まります。これは、すべてのeditWhenを実行する機能をグローバルでオフにするDefault Modifierとは異なります。この属性値をOnに設定すると、ページの編集機能とカスタマイズ機能は無効となり、Offに設定すると外部からでも編集できるようになります。この属性を設定すると、ページ・レベルで編集リンクが削除されるだけでなく、Portalにあるどのページでも、page.ファンクションに埋め込んだポートレットの編集機能やカスタマイズ機能が無効になります。
現在、前述の属性は標準ページ・メタデータに含まれていませんが、拡張可能なページ・モデルを使用すると、これらの属性を「カスタム属性」としてページ定義に追加できます。内部と外部の保護可能ページの基礎として使用するカスタム・ページ・タイプを作成することで、ページ設計者は、ページを内部で保護するか、セキュアなネットワークの内外からアクセス可能にするかを宣言によって定義できます。次の項では、前述のAuthorization Modifier機能でページを保護するために使用する適切なページ・タイプの作成手順について説明します。
Oracle Portalにログインします。
「Portalビルダー」ページで「ナビゲータ」を選択します。
「Portalナビゲータ」ページの「ページ・グループ」タブで「共有オブジェクト」を選択して、「カスタム属性」および「ページ・タイプ」を定義します。これらのプロパティは、有効範囲を特定のページ・グループに限定したオブジェクトとしてではなく、複数のページ・グループで再利用できるように共有オブジェクトとして定義することをお薦めします。
「共有オブジェクト」ページで「属性」を選択します。
「属性」ページで、「新規作成」→「属性」を選択して、次のように入力します。
表示名: 必要な機能に応じて、「isViewRestricted」または「isEditRestricted」と入力します。Authorization Modifierのルールでは大文字と小文字が区別されるので、属性名を入力する際は特に注意してください。
「データ型」を「BOOLEAN」に設定します。
「作成」をクリックします。
「isViewRestricted」リンクをクリックして、属性を編集します。
「属性の編集」ページで「翻訳を使用可能にする」を選択します。
「適用」をクリックします。
「OK」をクリックします。
必要なカスタム属性を定義した後、それをページのメタデータに記述する必要があります。そのためには、次の手順を実行します。
「共有オブジェクト」で「ページ・タイプ」を選択します。
「ページ・タイプ」ページで、「新規作成」→「ページ・タイプ」を選択し、次のように入力します。
表示名: 名前に「NetworkSecurablePage」と入力します。
基となるページ・タイプ: 「標準」を選択します。
「作成」をクリックします。
新しいページ・タイプを編集し、「属性」タブを選択して、そのページ・タイプに関連する属性を定義します。
「NetworkSecurablePage」リンクをクリックして、ページ・タイプを編集します。
「属性」タブをクリックします。
「属性」ページで、「使用可能な属性」リストから属性を選択して「選択した属性」リストに移動します。
「適用」をクリックします。
セキュリティ要件に応じて、属性のデフォルト値を設定します。
「必須」チェック・ボックスを選択して、この属性が「ページ・タイプ」とページ・デザイナに表示されるようにします。
「適用」をクリックします。
作成した新しいページ・タイプが公開されるようにページ・グループを構成する必要があります。そのためには、次の手順を実行します。
「ページ・グループ」を選択して「プロパティ」をクリックします。
「ページ・グループの編集」ページで「構成」タブをクリックします。
「タイプおよび分類」で「編集」をクリックします。
このシナリオで作成したページを選択し、「NetworkSecurablePage」を「非表示のページ・タイプ」から「表示されるページ・タイプ」に移動して、この新しいページ・タイプが「ページ・グループ」で公開されるようにします。
Oracle Portalでは、次の方法でOracle Fusion Middlewareのセキュリティ・サービスを利用します。
|
関連項目: 詳細は、次を参照してください。
|
SSL暗号化
HTTPSとSecure Socket Layer (SSL)を使用すると、クライアントとサーバーとの間に安全な接続を確立できます。通信の両端で発行されるデジタル証明書によって、サーバーと通信の暗号化の妥当性が検証され、それらが脅かされていないことが確認されます。Oracle Fusion Middlewareのセキュリティ・サービスを使用してOracle PortalのSSL暗号化を実装できます。
コンテナがJAZN LDAP用に構成されており、ポータルが拡張認証を使用してメッセージの整合性を保証するように構成されている場合、JPDK WebプロバイダではWLS J2EEセキュリティ・ロールを利用して認証ロジックを実装できます。
より包括的なセキュリティ・ソリューションを実現するために、Oracle PortalではOracle Identity Managementインフラストラクチャに含まれている各種コンポーネントを利用します。
Oracle Portalでは、ユーザーやグループを作成するときにも、Oracle Identity Managementを利用します。ポータルのユーザーやグループの作成、およびグローバル権限や設定項目の設定に最もよく使用される方法では、次のポートレットが使用されます。
|
関連項目: Oracle Fusion Middleware Oracle Identity Managementスタート・ガイド |
Oracle Portalでは、ユーザー認証にOracleAS Single Sign-Onを使用します。
OracleAS Single Sign-Onでは外部アプリケーションの概念をサポートしています。外部アプリケーションは独自の認証メカニズムを保持していますが、OracleAS Single Sign-OnではOracle Portalユーザーのログインを自動化できます。これは、シングル・サインオン・サーバーに登録されている外部アプリケーションのリストを公開する外部アプリケーション・ポートレットを提供することで実現できます。
|
注意: Basic認証方式(ユーザー名とパスワード)を使用したシングル・サインオンは、ユーザーがFirefoxを使用してアクセスする外部アプリケーションで利用できます。ただし、シングル・サインオンは現在、Basic認証方式を使用する外部アプリケーションにInternet Explorer 6.xまたは7.xでアクセスしたときには利用できません。 |
OracleAS Single Sign-On Serverではグローバルな非アクティブのタイムアウトを構成できます。この機能を使用するには、インフラストラクチャ層でOracleAS Single Sign-Onサーバーを構成し、Oracle Fusion Middlewareの中間層でmod_ossoを構成する必要があります。
OracleAS Single Sign-On server 10.1.2.xを使用するOracle Portal 11gでのグローバルな非アクティブのタイムアウトの構成の詳細は、Oracle Application Server Single Sign-On管理者ガイドを参照してください。
OracleAS Single Sign-On server 10.1.4.3を使用するOracle Portal 11gでグローバルな非アクティブのタイムアウトを構成するには、次のようにします。
|
注意: ここで説明する例はすべてUNIXのコードおよびディレクトリ・パスを使用しています。Windowsの場合は、円記号(\)を使用し、 |
ssogito.sqlスクリプトを実行します。これは、ORACLE_HOME/sso/admin/plsql/ssoにあります。
フィールドのリストが表示されます。
timeout_cookie_domainの値を入力フィールドに、Oracle PortalおよびSingle Sign-Onがインストールされたドメインの名前を入力します(例: timeout_cookie_domainの値を入力: acme.org)。
非アクティブなタイムアウト値を入力フィールドに、必要な非アクティブ期間の長さを分単位で入力します(例: 非アクティブなタイムアウト値を入力: 15)
new_git_versionの値を入力フィールドに、値v3.0を設定します。
次のコマンドを実行して、OracleAS Single Sign-OnサーバーにMOD_OSSOを登録します。
/app/oracle/product/sso10143/sso/bin/ssoreg.sh -oracle_home_path /app/oracle/product/sso10143 -site_name ssoacme.org:7777 -config_mod_osso TRUE -mod_osso_url http://sso.acme.org -config_file /app/oracle/product/sso10143/Apache/Apache/conf/osso/osso.conf
mod_osso.confファイルを編集してOssoIdleTimeoutパラメータをオンにします。このファイルは次の例のようにORACLE_HOME/Apache/Apache/confにあります。
<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout on
OssoConfigFile /app/oracle/product/sso10143/Apache/Apache/conf/osso/osso.conf
OC4J_SECURITYとOracle HTTP_Serverの両方を再起動します。
/app/oracle/product/sso10143/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY /app/oracle/product/sso10143/opmn/bin/opmnctl restartproc process-type=HTTP_Server
OracleAS SIngle Sign-Onサーバーで、グローバルな非アクティブのタイムアウトをテストします。
http://sso.acme.org:7777/oiddasに移動します。
orcladminとしてログインして、20分待ちます。
サーバーから再度認証を求められるかどうかを確認します。
PortalサーバーのMOD_OSSOを登録します。
ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path $ORACLE_HOME -site_name www.acme.org:8090 -config_mod_osso TRUE -mod_osso_url http://www.acme.org:8090 -remote_midtier -config_file /app/oracle/product/Middleware_Portal/asinst_1/config/OHS/ohs1/osso.conf
mod_osso.confファイルを編集してOssoIdleTimeoutパラメータをオンにします。このファイルは次の例に示されるようにORACLE_INSTANCE/config/OHS/ohs1/moduleconfにあります。
<IfModule mod_osso.c>
OssoIpCheck off
OssoSecureCookies off
OssoIdleTimeout on
OssoConfigFile osso.conf
Portalの中間層からHTTP Serverを再起動します。
/app/oracle/product/Middleware_Portal/asinst_1/bin/opmnctl restartproc process-type=OHS
Portalの中間層でグローバルな非アクティブのタイムアウトをテストします。
http://www.acme.org:8090/portal/pls/portalに移動します。
orcladminとしてログインして、20分待ちます。
サーバーから再度認証を求められるかどうかを確認します。
Oracle Access Managerは、Oracle Fusion Middlewareのコンポーネントの1つです。OracleAS Single Sign-On 10gのかわりに使用して、集中認証、ポリシーベースの認可、委任管理などを実装できます。
OracleAS Single Sign-On 10gからOracle Access Manager 11gへのアップグレード
OracleAS Single Sign-On 10gからOracle Access Manager 11gへのアップグレードにはOracle Fusion Middleware Upgrade Assistantを使用できます。
|
注意: Oracle Access Manager 11gにアップグレードすると、SSOサーバー管理ポートレットからは外部アプリケーションの作成、管理およびアクセスを実行できなくなります。ポートレットでリンクのいずれかをクリックすると、エラーが発生します。 アップグレード・プロセス時に外部アプリケーションが検出された場合、Upgrade Assistantには、アップグレードを中止するオプションが表示されます。処理の続行を選択すると、OAMへのアップグレード後に外部アプリケーションが機能しなくなり、外部アプリケーションの作成や管理はできなくなります。 |
Oracle Access Manager 11gへのアップグレードの詳細は、 Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイドの「Oracle Single Sign-On環境のアップグレード」の章を参照してください。このドキュメントでは、Oracle Access Manager 11gへのアップグレード後にOracle Delegated Administration Servicesを引続き使用するかどうかに応じて実行する必要のあるアップグレード・パスを説明しています。
Oracle Internet Directory (OID)は、スケーラブルなOracle固有のLDAPバージョン3のサービスで、Oracleの一般的なユーザーIDをホストします。Oracle Portalは、OIDに対して問合せを行い、ユーザーの権限、およびユーザーがOracle Portalで何を表示し、実行できるのかを確認します。特に、Oracle Portalは、OIDからユーザーのグループ・メンバーシップを取得して、ユーザーが何にアクセスし、変更できるのかを確認します。
このモデルでは、Oracle Portalに次のようなOracle Internet Directoryとの対話が必要となります。
ディレクトリに格納されているOracle Portal固有のエントリ
ディレクトリに格納されているグループ属性
ディレクトリに格納されているユーザー属性
ディレクトリからのユーザーおよびグループ情報のキャッシュ
Oracle Delegated Administration Servicesによるディレクトリからのユーザーとグループの値リストの生成
Oracle Portalは、Oracle Internet Directoryの機能を使用してユーザーとグループを効率的に管理します。Oracle Internet Directoryが提供する機能の一覧は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryの新機能」を参照してください。ただし、Oracle Internet Directoryの一部の機能は、Oracle Portalでは使用できません。
表7-12は、Oracle PortalでサポートされていないOracle Internet Directoryの機能とその説明です。
表7-12 Oracle PortalでサポートされていないOracle Internet Directoryの機能
| 機能 | 説明 |
|---|---|
|
動的グループ |
動的グループのメンバーシップは、指定した属性値およびアサーションに基づいて、動的に計算されます。動的グループに対してはWebキャッシュの無効化を行うタイミングを特定できないため、動的グループで保護されているページは、有効期限ベースのキャッシュを使用するか、またはキャッシュを使用しないようにする必要があります。 |
|
Single Authentication Security Layer (SASL) |
SASLは、接続ベースのプロトコルに認証サポートを追加するための手段です。Oracle Internet DirectoryサーバーはSASLベースの認証メカニズムをサポートしています。しかし現在のところ、Oracle Portalが使用するDBMS_LDAPパッケージはこれらのメカニズムをサポートしていません。 |
|
クライアント側の参照キャッシュ |
パフォーマンスを向上させるため、APIを使用してクライアント側にキャッシュされた参照エントリをキャッシュできます。現在のところ、Oracle Portalが使用するDBMS_LDAPパッケージは、クライアント側の参照キャッシュをサポートしていません。 |
セキュリティを正しく機能させるには、Oracle Portalのディレクトリのディレクトリ情報ツリー(DIT)構造内に次のエントリが必要です。
デフォルト・ユーザー・アカウント (cn=PUBLIC, cn=orcladmin)。ID管理レルムのユーザー・ベース(cn=Users,dc=MyCompany,dc=com脚注 1 )に作成されます。orcladminユーザーは、ポータルのインストールおよび構成時に、デフォルトでDBAグループに追加されます。PUBLICユーザーは、認証されていないユーザー用に作成されます。通常、PUBLICユーザー・エントリは、どのユーザーでもアクセスできる(制限されていない)ポータル・コンテンツを表示する権限を付与するためのものです。
グループ・コンテナ 。ID管理レルムのグループ・ベース(cn=Groups,dc=MyCompany,dc=com1)内に作成されます。Oracle Portalでは、ディレクトリ内のどのグループも利用できますが、グループがOracle Portalグループ・コンテナ内にあると、より簡単にアクセスして値リストに表示できます。
グループ・コンテナの名前は、Oracle Portalの情報に基づいています。
Oracle Portalスキーマ名
Oracle Portalがインフラストラクチャ・サービスの使用を開始した日時
名前の書式は次のとおりです。
schema_name.yymmdd.hh24miss.ff
|
注意: Oracle Portal 10g リリース1より前のリリースでは、グループ・コンテナの名前の書式が異なる場合があります。 |
グループ。ディレクトリのOracle Portalグループ・コンテナ内に作成されます。
cn=AUTHENTICATED_USERS
cn=DBA
cn=PORTAL_ADMINISTRATORS
cn=PORTAL_DEVELOPERS
cn=PORTLET_PUBLISHERS
cn=RW_ADMINISTRATOR
cn=RW_DEVELOPER
cn=RW_POWER_USER
cn=RW_BASIC_USER
アプリケーション・エンティティ(orclApplicationCommonName=application_name)。ルートのOracleコンテキスト(cn=Portal,cn=Products,cn=OracleContext)に作成されます。アプリケーションのパスワードはランダムに生成されます。Oracle Portalでは、ディレクトリへの問合せやディレクトリに対する操作(ユーザーの追加など)をユーザーにかわって行う必要があるときに、このエンティティを使用してディレクトリにバインドします。Oracle Portalがユーザーにかわってディレクトリにバインドするときは、プロキシ接続を使用してユーザーとして接続します。この方法により、ユーザーの認可制限がディレクトリによって正しく適用されていることが確認されます。Oracle Portalのアプリケーション・エンティティは、ユーザーのプロキシ権限グループ(cn=UserProxyPrivilege,cn=Groups,cn=OracleContext)内のメンバーシップによって、プロキシ接続を開始するための権限を取得します。アプリケーション・エンティティの名前は、スキーマと、Oracle Portalがインフラストラクチャ・サービスの使用を開始した日時に基づいています。たとえば、アプリケーション・エンティティの名前がportal.040820.123756.096286000であるとすると、portalはスキーマ名であり、040820.123756.096286000はyymmdd.hh24miss.ffという書式のタイムスタンプです。
ディレクトリ同期サブスクリプション。プロビジョニング・プロファイルのエントリは、ディレクトリ(cn=Provisioning Profile,cn=changelog subscriber,cn=oracle internet directory)のプロビジョニング・プロファイル・ノードに作成されます。このエントリは、ユーザーまたはグループの権限情報が変更されたときにディレクトリからOracle Portalに通知する必要があることを示します。このエントリによって、Oracle Portalではユーザーの認可とディレクトリに格納されている情報を同期化できます。
|
注意: Oracle Internet Directoryからプロビジョニング・プロファイルを削除すると、「グローバル設定」ページの「SSO/OID」タブにある「ディレクトリ同期」セクションから、「ディレクトリ同期の有効化」とイベント通知の送信頻度n秒が表示されなくなります。「グローバル設定」ページに移動するには、「Portalビルダー」で、「管理」タブの「ポータル」サブタブに移動し、「サービス」ポートレットの「グローバル設定」リンクをクリックします。 |
図7-7は、Oracle Portalの情報がディレクトリのDIT構造のどこにあるかを示しています。
cn=Groups,cn=OracleContext,<subscriber_dn>の下に、次のグループを含むcn=Groupsコンテナがあります。
これらの権限グループのエントリは、そのメンバーシップにポータル・グループとポータル・アプリケーション・エントリを追加するよう、ポータルのインストール時に変更されます。これにより、目的のポータル機能が実現します。同様に、ポータル情報もこれらのグループに含まれます。
Oracle Portalは、Oracle Fusion Middlewareの他のすべてのコンポーネントと同様に、ディレクトリを使用して、ユーザー情報を格納しています。ディレクトリ内のユーザーはすべて、次のオブジェクト・クラスを使用して定義されます。
inetOrgPersonオブジェクト・クラスには、Internet Engineering Task Force (IETF)のRequest for Comments (RFC) 2798番によって定義されているユーザー属性がすべて含まれています。
orclUserおよびorclUserV2オブジェクト・クラスには、Oracle製品のその他の標準属性のセットが含まれています。
次の表は、Oracle Internet Directoryに格納されている様々なユーザー属性を示しています。
| inetOrgPerson (IETF)の属性 | コメント |
|---|---|
|
cn |
ユーザーの共通名。 この属性は必須です。 |
|
employeeNumber |
従業員の識別に使用される番号。 |
|
sn |
姓。この属性は必須です。この属性を明示的に指定しない場合は、ユーザーのニックネームが使用されます。 |
|
givenName |
名。 |
|
middleName |
|
|
displayName |
優先名。 |
|
|
電子メール・アドレス。 |
|
telephoneNumber |
|
|
homePhone |
|
|
mobile |
|
|
pager |
|
|
facsimileTelephoneNumber |
|
|
street |
|
|
l |
オフィスの所在地(市)。 |
|
st |
オフィスの所在地(州)。 |
|
postalCode |
オフィスの郵便番号。 |
|
c |
オフィスの所在地(国)。 |
|
homePostalAddress |
自宅の住所。 |
|
jpegPhoto |
本人の画像。 |
|
o |
組織 |
|
title |
|
|
manager |
従業員の監督者。 |
|
uid |
ユーザーID。 |
|
userPassword |
|
|
preferredLanguage |
| orclUserv2の属性 | コメント |
|---|---|
|
orclIsVisible |
ユーザーを管理者以外の全員に対して非表示にするかどうかを示すフラグ。 |
|
orclDisplayPersonalInfo |
ユーザーの個人情報を管理者以外の全員に対して非表示にするかどうかを示すフラグ。 |
|
orclMaidenName |
|
|
orclDateOfBirth |
|
|
orclHireDate |
|
|
orclDefaultProfileGroup |
本人のデフォルト・ユーザー・グループ。 |
|
orclActiveStartDate |
アカウントが有効になった日付。 |
|
orclActiveEndDate |
アカウントが終了した(または終了する)日付。 |
|
orclTimeZone |
|
|
orclIsEnabled |
ユーザー・アカウントがアクティブかどうかを示すフラグ。アクティブでない場合、ユーザーはログインできません。 |
Oracle Portalは、Oracle Fusion Middlewareの他のすべてのコンポーネントと同様に、ディレクトリを使用して、グループ情報を格納しています。ディレクトリ内のグループはすべて、次のオブジェクト・クラスを使用して定義されます。
groupOfUniqueNamesオブジェクト・クラスには、IETF (RFC 2256)によって定義されているグループ属性がすべて含まれています。
orclGroupオブジェクト・クラスには、Oracle Portalのその他の標準属性のセットが含まれています。
|
注意: Oracle Portalリリース9.0.2以上では、グループの適用範囲を特定のページ・グループにすることはできません。このオプションは、Oracle Portalリリース3.0.9.x以下でのみ有効でした。 |
図7-8は、Oracle Portalのグループ情報がディレクトリのDIT構造のどこにあるかを示しています。
次の表は、Oracle Internet Directoryに格納されている様々なグループ属性を示しています。
表7-15 groupOfUniqueNames/groupOfNamesの属性
| groupOfUniqueNames/groupOfNames (IETF)の属性 | コメント |
|---|---|
|
cn |
グループの共通名。「グループ」ポートレットの「グループの編集」フィールドのような場所に入力してグループを見つけることができます。 |
|
description |
グループの説明。そのグループが表示されている値リストに表示されます。 |
|
uniqueMember/member |
グループのすべてのメンバーの識別名(DN)のリスト。メンバーのDNは、ユーザーまたは別のグループを表します。 |
|
owner |
このグループを管理する権限を持っているすべてのユーザーおよびグループのDNのリスト。 |
パフォーマンスを向上させるために、Oracle Portalでは一部のディレクトリ情報をローカルにキャッシュします。特に、Oracle Portalでは次の情報をキャッシュします。
Oracle Portalのディレクトリ接続情報
Oracle Delegated Administration ServicesのURL
ディレクトリのポートレット(「ユーザー」および「グループ」ポートレットなど)に対する認可チェックのための特定の権限グループのorclGUID
一部のOracleコンテキスト情報
ローカルで選択したグループの検索および作成ベース
各ユーザーのグループ・メンバーシップおよびデフォルト・グループ
Oracle Portalによってキャッシュされる情報のほとんどは、ディレクトリ接続情報などの静的な情報です。Oracle Portalでは、グループ・メンバーシップやデフォルト・グループなどのより動的なアイテムの更新は、Oracle Directory Integration and Provisioningエージェントに依存しています。Oracle Portalでは、ディレクトリ同期サブスクリプションがディレクトリ内で管理されていて、Oracle Portalのセキュリティに影響する変更イベント(グループにユーザーを追加する、グループからユーザーを削除するなど)が発生した場合には、エージェントにフラグを設定して通知します。
「ユーザー」、「グループ」、「Portalユーザー・プロファイル」、「Portalグループ・プロファイル」の各ポートレットには、ユーザーまたはグループの値リストが含まれています。これらの値リストには、ディレクトリに格納されている情報を設定する必要があります。デフォルトでは、値リストにはOracle PortalのDIT構造のOracle Portalグループ・コンテナに含まれるグループが表示されます。正しいアクセス権限があれば、ツリー内のどのグループでも参照することができます。
グループの値リストに表示されるグループは、それらを表示するユーザーの権限によって異なります。たとえば、ユーザーが「グループ」ポートレットから値リストを表示すると、そのユーザーが編集または削除できるグループのみがリストに表示されます。Oracle Portal 10g リリース2 (10.1.2)以降では、LOVを実装すると、コールバック・メソッドをサポートできます。このコールバック・メカニズムは、Oracle Delegated Administration Services環境での対応するサポートを必要とします。
Oracle Portal 10g リリース2 (10.1.2)より前のバージョンからアップグレードし、インフラストラクチャ層とFusion Middleware中間層を別々のホストやプロトコルに切り離している場合、追加のユーザーとグループの値リスト(LOV)構成を実行して、JavaScriptオリジン・サーバーのセキュリティ・ポリシーを取り込んでいる可能性があります。
次の2つの構成オプションがあります。
secjsdom.sqlスクリプトの実行による共通ドメインの設定
Oracle Delegated Administration Servicesの中間層への配置
ご使用の環境に適したOracle Delegated Administration Servicesのバージョンをインストールし、前述の構成オプションをまだ使用していない場合、Oracle Portalでは、別のホストのLOVをサポートするために後続の構成手順は不要です。ただし、前述の構成オプションを使用した場合は、これらの手順を削除する必要があります。これは、次のように行うことができます。
Oracle Portalを構成して、ローカルに配置されたOracle Delegated Administration Servicesサーブレットを使用するようにした場合は、次のとおりsecdaslc.sqlスクリプトを実行して、インフラストラクチャ層を指すように再構成します。
オペレーティング・システムのプロンプトから、次のディレクトリに移動します。
ORACLE_HOME\portal\admin\plsql\wwc
SQL*Plusを使用して、所有者としてOracle Portalスキーマに接続し、次のコマンドを実行します。
@secdaslc N commit;
Oracle Portalをコールバック・メソッドをサポートしない前のリリースのOracle Delegated Administration Servicesとともに使用し、ディレクトリとOracle Portalサーバーが別のドメインに常駐している場合、Oracle Delegated Administration Services環境に必要なパッチをインストールして、ドメイン全体でLOVを使用できるようにする必要があります。
図7-9に示すように、Oracle Directory Integration Platformには、コンポーネントにユーザーやグループの変更イベントを通知して、ディレクトリを同期化するための重要なサービスがいくつかあります。
この図では、Oracle Internet Directoryに対するフローに2つのパスがあります。最初のパスは、Oracle Directory Synchronization Serviceと呼ばれており、同期化の概念を示しています。この場合、Oracle Internet Directoryは一部の外部ディレクトリまたはリポジトリへのゲートウェイとして機能します。同期化サービスでは、変更内容がOracle Internet Directoryとそれに接続されているディレクトリとの間で確実に調整されるようにします。いずれかのディレクトリで変更が行われるたびに、Oracle Internet Directoryで通知が発行され、影響を受けるすべてのディレクトリに変更が適切に反映されるようにする必要があります。
2番目のパスは、Oracle Directory Provisioning Integration Serviceと呼ばれており、プロビジョニングの概念を示しています。プロビジョニングでは、Oracle Portalなどのアプリケーションは特定のユーザーまたはグループ情報に対する変更をサブスクライブします。たとえば、管理者がOracle Delegated Administration Servicesを使用してグループからユーザーを削除したとします。この変更の結果、そのユーザーはOracle Portalの特定のページにアクセスできなくなります。Oracle Directory Integration Platformでは、Oracle Portalに、ローカル・キャッシュを更新するように通知して、ユーザーがアクセスできなくなったページにアクセスするのを速やかに防ぐ必要があります。
プロビジョニング・サービスの場合、Oracle Portalなどのコンポーネントは、ユーザーやグループ情報のローカル・キャッシュをOracle Internet Directoryの中央のユーザーやグループのリポジトリと同期化するために、プロビジョニング・イベント(グループの削除など)をサブスクライブします。変更イベントが発生すると、その変更イベントをサブスクライブするコンポーネントはすべて、Oracle Directory Integration Platformのディレクトリ同期プロビジョニング・エージェントによって通知されます。Oracle Portalでは、ディレクトリ内にポータル・ディレクトリ同期サブスクリプションのフラグを設定して、サブスクライブされた変更イベントが実行されるたびに通知されるようにします。表7-17は、Oracle Portalがサブスクライブするイベントとそれらのイベントが発生したときに実行される処理を示しています。
表7-17 Oracle Portalによって処理されるディレクトリ同期イベント
|
注意: Oracle Portalでは、ユーザーやグループの作成イベントをサブスクライブする必要はありません。新しいユーザーが初めてログインするか、新しいユーザーになんらかの権限を初めて割り当てることによって、そのユーザーがOracle Portalのアクセス制御リスト(ACL)で参照されると、ローカルのユーザー・プロファイルが自動的に作成されます。同様に、新しいグループが初めてACLで参照されると、ローカルのグループ・プロファイルが自動的に作成されます。 |
正しく機能させるには、次の要件に従ってOracle PortalとOracle Directory Integration Platformを統合する必要があります。
Oracle Directory Integration Platformが動作していること。Oracle Portalリリース11.0.0以上では、opmctl start allを使用してインフラストラクチャ層を起動した場合、Oracle Directory Integration and Provisioningのエージェントもデフォルトで開始されます。Oracle Directory Integration Platformを起動するには、oidctlコマンドを実行します。例:
oidctl instance=1 server=odisrv flags="host=iasqa-ultra1.abc.com port=4032" start
サブスクリプション・プロファイルがOracle Internet Directory内に作成されていること。デフォルトのサブスクリプション・プロファイルは、Oracle Portalのインストール中に自動的に作成されます。
|
関連項目: Oracle Fusion Middleware Oracle Internet Directory管理者ガイド |
デフォルトでは、Oracle Delegated Administration ServicesによってOracle Internet Directory内に作成されたグループは、IETFオブジェクト・クラスgroupOfUniqueNamesを基にしています。ただし、現在はオブジェクト・クラスgroupOfNamesで作成されたグループの処理もサポートしています。ポータルで、既存のOracle Directory Integration Platformのサブスクリプション・プロファイルがOracle Internet Directory (9.0.2以降)に存在する場合は、groupOfUniqueNamesを使用するグループに基づいてグループの変更や削除がサブスクライブされています。Oracle Internet Directoryに格納されている既存のグループがgroupOfNamesオブジェクト・クラスを基にしている場合は、groupOfUniqueNamesの他にgroupOfNamesを基にしたグループのイベントもサブスクライブするようOracle Directory Integration Platformのサブスクリプション・プロファイルを更新する必要があります。
サブスクリプション・プロファイルを作成または更新するには、次の例に示すように次のようにoidprovtoolを実行します。
oidprovtool operation=create ldap_host=myhost.mycompany.com \ ldap_port=389 \ ldap_user_dn="cn=orcladmin" \ application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext"\ organization_dn="dc=us,dc=mycompany,dc=com" \ interface_name=PORTAL.WWSEC_OID_SYNC \ interface_type=PLSQL \ interface_connect_info=myhost:1521:iasdb:PORTAL:password\schedule=360 \ event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \ event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE"\ event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY (orclDefaultProfileGroup,userpassword)"\ eventsubscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \ profile_mode=OUTBOUND
これにより、プロビジョニング・プロファイルが作成または更新され、uniqueMemberおよびmember属性の変更がサブスクライブされます。デフォルトでは、このプロビジョニング・プロファイルが有効化されます。
Oracle Portalでは、ディレクトリに対してユーザーおよびグループ情報を問い合せるだけでなく、ユーザーおよびグループ情報を追加および変更する方法をユーザーに提供する必要があります。ディレクトリ内の情報を変更するには、Oracle Delegated Administration Servicesを使用します。Oracle Portalは、ユーザーやグループを追加および変更する権限を持つユーザーに対して委任管理サーバーへのリンクを提供します。
Oracle Delegated Administration Servicesには、ディレクトリを更新するための包括的なインタフェースが用意されています。適切な権限を持っている認証されたユーザーは、Oracle Portalの「管理」タブの「ユーザー」および「グループ」ポートレットを使用して委任管理サーバーにアクセスできます。これらのポートレットにアクセスするには、それぞれOracleDASCreateUserおよびOracleDASCreateGroupグループのメンバーである必要があります。AUTHENTICATED_USERSは、デフォルトでグループを作成できます。
mod_ossoは、HTTPサーバーを事実上パートナ・アプリケーションにすることによって、OracleAS Single Sign-On環境の内側にあるURLを保護します。Oracle Delegated Administration Servicesの機能は、mod_ossoを使用してOracleAS Single Sign-OnセッションからユーザーのIDを取得することによってシングル・サインオン対応になります。
図7-10 Oracle Delegated Administration Services、mod_ossoおよびOracleAS Single Sign-Onの関係
mod_ossoは、Oracle HTTP Serverのモジュールであり、パートナ・アプリケーションとして作成されています。mod_ossoを使用すると、WLSアプリケーション上のアプリケーションでシングル・サインオンを使用できるようになります。このためには、Oracle HTTP Serverのディレクティブでmod_ossoを構成して、Oracle Fusion MiddlewareアプリケーションのURLへのアクセスを制限します。
Oracle Delegated Administration Servicesでは、アクセスを試みるユーザーの認証にmod_ossoを利用します。ユーザーがOracle Delegated Administration Servicesのダイアログ(ユーザーまたはグループのリスト、「ユーザーの作成」フォームなど)にアクセスしようとすると、mod_ossoによってユーザーが認証されているかどうかが確認されます。mod_ossoでは、認証を確認する以外の認可チェックは行いません。ユーザーが認証されていない場合は、mod_osso (OracleAS Single Sign-Onのパートナ・アプリケーション)によってユーザーのリクエストがOracleAS Single Sign-Onにリダイレクトされます。OracleAS Single Sign-Onでは、次のいずれかを実行します。
ユーザーが正しく認証されたことを示すCookieを見つけ、認証済のトークンをmod_ossoに返信します。
Cookieがまだ1つも作成されていない場合は、ユーザーを認証するためのログイン・ページを表示します。
正しく認証されたユーザーは、mod_ossoによって、リクエストされたOracle Delegated Administration ServicesのURLにリダイレクトされます。これで、そのユーザーはOracle Delegated Administration Servicesにアクセスできるようになり、通常はOracle Internet Directory内のアクセス制御項目に応じてユーザーの権限が適用されます。
Oracle Delegated Administration ServicesのURL
Oracle Portalのユーザー・セッションからOracle Delegated Administration Servicesに送信された最初のリクエストはOracleAS Single Sign-Onにリダイレクトされ、mod_ossoがパートナ・アプリケーションとしてOracle Delegated Administration ServicesのかわりにユーザーのIDを確立します。OracleAS Single Sign-Onは、リクエストされたOracle Delegated Administration ServicesのURLを含むURLCトークンを作成します。URLCトークンの長さは、Internet Explorerによって約2Kに制限されます。同様に、Oracle Delegated Administration ServicesのURLの長さも制限されます。Oracle Portalは、Oracle Delegated Administration Servicesとシームレスに統合できるように、現在のポータル・ページとポータル・ホーム・ページのURLをこのOracle Delegated Administration ServicesのURL内に含めます。Oracle Delegated Administration Servicesの標準的なURLを次に示します。
http://myportal.us.abc.com:8090/oiddas/ui/oracle/ldap/das/group/AppCreateGroupInfo Admin?doneURL=https%3A%2F%2Fwebsvr.us.abc.com%3A5001%2Fportal%2Fpage%3F_ pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2_ 6_7&homeURL=https%3A%2F%2Fwebserver.us.abc.com%3A5001%2Fportal%2Fpage%3F_ pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2 _6_7&parentDN=cn%3Dportal_9_0_2_6_ 7.s901dev0.portalserver.us.abc.com%2Ccn%3Dgroups%2Cdc%3Dus%2Cdc%3Doracle%2Cdc%3Dco m&enablePA=true
このURLが、URLCトークンに含まれ、セキュリティ上の理由から暗号化された場合、最終的なトークンの長さは容易に2Kのしきい値に到達します。この制限を超えた場合、ブラウザにエラーが表示される可能性があります。
URLに固定サイズはありません。ただし、Oracle Delegated Administration Services操作の実行時にブラウザでエラーが発生した場合は、URLが2Kの制限を超えないようポータルURLを構成する様々な部分のサイズを短縮する必要があります。たとえば、ホスト名を8文字以下に制限したり、DAD名を6文字以下に制限します。
この問題が発生した場合の回避策は、最初に「サービス」ポートレットの「ディレクトリ管理」リンクなど、比較的短い長さのURLを通じてOracle Delegated Administration Servicesにログインすることです。これ以降のOracle Delegated Administration Servicesへのアクセスでは、SSOリダイレクトを必要としないため、正常に接続できます。
「管理」にある「ポータル」タブの「ユーザー」ポートレットを使用すると、Oracle Delegated Administration Servicesを使用してユーザーを作成および更新できます。新しいユーザーを作成するには、「ユーザー」ポートレットの「新規ユーザーの作成」リンクをクリックします。既存のユーザーの情報を更新するには、「名前」フィールドにそのユーザー名を入力するか、値リストからそれを選択して、「編集」をクリックします。ユーザーを削除するには、「名前」フィールドにそのユーザー名を入力するか、値リストからそれを選択して、「削除」をクリックします。
|
注意: OracleDASCreateUser、OracleDASEditUserまたはOracleDASDeleteUser権限グループのメンバーであるユーザーのみが「ユーザー」ポートレットを表示することができます。新しいユーザーを作成するためのリンクは、OracleDASCreateUserグループのメンバーであるユーザーにのみ表示されます。 |
|
関連項目: Oracle Fusion Middleware Oracle Internet Directory管理者ガイド |
|
注意: 「Portalユーザー・プロファイル」ポートレットは、すべてのユーザー・プロファイルに対する「管理」または「編集」権限を持つユーザーのみが表示することができます。 |
特にポータルに関係するグローバル・ユーザー権限や設定項目を設定する場合は、「Portalユーザー・プロファイル」ポートレットを使用します。ポータルに関するユーザーの設定項目や権限を更新するには、「名前」フィールドにそのユーザー名を入力するか、値リストからそれを選択します。ユーザーのプロファイルに対して、次のすべての設定を行うことができます。
プリファレンス
ユーザーがポータルにアクセスできるかどうか
ユーザーのデータベース・スキーマ名
ユーザーが個人用ページを持っているかどうか
ユーザーのデフォルト・ユーザー・グループ
ユーザーのデフォルトのホーム・ページ
ユーザーのデフォルト・スタイル
ユーザーのOracle Web Cacheを消去するかどうか
グローバル権限
ページ・グループ権限
Portal DBプロバイダ権限
管理権限
|
注意: どのユーザーも「グループ」ポートレットを表示できますが、新しいグループを作成するためのリンクは、OracleDASCreateGroup権限グループのメンバーであるユーザーにのみ表示されます。ユーザーがグループを編集または削除できるのは、そのグループの所有者であるか、そのグループを編集または削除するための適切なアクセス制御情報(ACI)を持つグループのメンバーである場合のみです。次の権限グループは、Oracle Internet Directoryに組み込まれています。
これらの権限グループは、グローバル権限に相当するため、慎重に割り当てる必要があります。 |
「管理」にある「ポータル」タブの「グループ」ポートレットを使用すると、Oracle Delegated Administration Servicesを使用してユーザー・グループを作成および更新できます。新しいグループを作成するには、「グループ」ポートレットの「新規グループの作成」リンクをクリックします。既存のグループの情報を更新するには、「名前」フィールドにその名前を入力するか、値リストからそれを選択して、「編集」をクリックします。グループを削除するには、「名前」フィールドにそのグループ名を入力するか、値リストからそれを選択して、「削除」をクリックします。
|
関連項目: Oracle Fusion Middleware Oracle Internet Directory管理者ガイド |
|
注意: 「Portalグループ・プロファイル」ポートレットはすべてのユーザーに表示されますが、すべてのグループ・プロファイルに対する「管理」または「編集」権限を持つユーザー、またはグループの所有者のみがそのプロファイルを編集することができます。 |
特にポータルに関係するグローバルなグループの設定項目や権限を設定する場合は、「Portalグループ・プロファイル」ポートレットを使用する必要があります。ポータルに関するグループの設定項目や権限を更新するには、「名前」フィールドにそのグループ名を入力するか、値リストからそれを選択します。グループのプロファイルに対して、次のすべての設定を行うことができます。
プリファレンス
グループのデフォルトのホーム・ページ
グループのデフォルト・スタイル
グローバル権限
ページ・グループ権限
Portal DBの権限
管理権限
多くの場合、Oracle Delegated Administration Servicesに用意されているユーザー・ロールを使用したほうが、より効率的に個々のユーザーに権限を割り当てることができます。ユーザー作成時、「ユーザーの作成」ページに「ロール割当て」セクションがあります。
|
注意: 9.0.4より前のリリースでは、ロールはパブリック・グループと呼ばれていました。 |
ロールには、非常に便利なメカニズムが備えられており、それによって同時に複数のユーザーを作成し、権限のセットを付与することができます。ロールのチェック・ボックスを特定のユーザーに対して選択しておくと、そのユーザーには作成時に特定のロールが指定されます。管理者は、独自のロールを作成して、Oracle Internet DirectoryとOracle Portalの権限を組み合せてそのロールに事前に割り当てることができます。
ユーザー管理者として適切な権限を持つロールを作成するとします。このようなロールは、次の手順に従って作成できます。
まず、次のようにグループを作成します。
「管理」タブをまだ表示していない場合、「Portalビルダー」(設計時のページ)で、「管理」タブをクリックします。
「グループ」ポートレットの「新規グループの作成」をクリックします。図7-15に示すような「グループの作成」ページが表示されます。
必須フィールド(アスタリスクで表示)を入力します。
「グループの作成」ページで、「権限の割当て」をクリックしてそのセクションに移動し、図7-16に示すように、次の権限を選択します。
ユーザーの作成を許可
ユーザーの編集を許可
ユーザーの削除を許可
「発行」をクリックします。
ステップ2: すべてのユーザー・プロファイルに対する「管理」権限を割り当てる
ユーザー管理者グループを作成したら、そのグループにすべてのユーザー・プロファイルに対する「管理」権限を割り当てる必要があります。この権限は、ユーザー管理のためにこのグループに割り当てる必要がある唯一のグローバル権限です。
「管理」タブをまだ表示していない場合、「Portalビルダー」(設計時のページ)で、「管理」タブをクリックします。
「Portalグループ・プロファイル」ポートレットで、新しく作成したグループの名前を入力して、「編集」をクリックします。
「権限」タブをクリックします。
図7-17に示すように、「管理権限」セクションが表示されるまで下方にスクロールします。「すべてのユーザー・プロファイル」の横のリストから、「管理」を選択します。
「OK」をクリックします。
ユーザー管理者ロールを表すグループの作成が終わったので、そのグループをロールとして有効にし、「ユーザーの作成」ページのロールのリストに表示されるようにする必要があります。
「管理」タブをまだ表示していない場合、「Portalビルダー」(設計時のページ)で、「管理」タブをクリックします。
「サービス」ポートレットで、「ディレクトリ管理」をクリックします。
「構成」タブをクリックします。
「ユーザー・エントリ」をクリックします。
図7-18に示すように、ウィザードのステップ5「ロールの構成」が表示されるまで「次へ」をクリックします。
「ロールの追加」をクリックして、新しいグループを選択し、それをロールのリストに追加します。
「終了」をクリックします。これで、「ユーザーの作成」ページのパブリック・グループ・リストに、作成したグループが表示されます。
ステップ4: 詳細な「権限の割当て」セクションを非表示にする
権限の直接割当てではなく、ロールの使用を推進するには、「ユーザーの作成」ページの権限の割当ての詳細セクションを無効にします。この変更を実装するには、Oracle Portalスキーマ内の構成エントリを更新する必要があります。この設定によって、Oracle Delegated Administration Servicesでは、Oracle Portal管理ページからコールされたユーザーの作成/編集ページの「権限の割当て」セクションが非表示になります。
SQL*Plusを介してPORTALスキーマにログインします。
次のコマンドを実行して、das_enable_pa変数をOracle PortalのOracle Internet Directory構成のプリファレンス・ストア内に設定します。
$ sqlplus
...
Enter user-name: portal
Enter password:
...
SQL> set serverout on
SQL> exec wwsec_oid.set_preference_value('das_enable_pa', 'N');
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> exit
...
「ユーザー」ポートレットはOracle Web CacheだけでなくOracle Portalの中間層のファイル・システム・キャッシュにもキャッシュされるため、キャッシュされているポートレットを事前に無効にしておく必要があります。構成パラメータを更新すると、このポートレットの動作は変更されますが、パラメータを更新してもキャッシュは無効になりません。「ユーザー」ポートレットのキャッシュ・バージョンを無効にするには、次の手順を実行します。
管理者権限を持つユーザーとしてOracle Portalにログインします。
「ビルダー」に移動します。
「管理」タブをクリックします。
「ポータル」タブから、「グローバル設定」を開き、「SSO/OID」タブに移動します。
ページの一番下までスクロールします。
「OIDパラメータ用キャッシュのリフレッシュ」を選択します。
「適用」をクリックします。
|
関連項目: Oracle Fusion Middleware Oracle Web Cache管理者ガイド |
ステップ5: 変更内容を検証する
ステップ1から4を実行した後、「ユーザーの作成」ページを表示して、作成したユーザー管理者のグループがそこに表示されることを確認します。Oracle Portalの他の管理ロールまたはグループがどのようにしてこのページの「ロール割当て」リストに事前に生成されているのか注意してください。
動的グループのサポートは、動的に移入された静的グループの機能に依存します。11.1.1では、動的グループは静的グループと同様に公開されます(実際には、動的グループは、静的メンバー・リストと動的に決定されたメンバーシップから作成されます)。
グループの動的メンバーシップは、グループのlabeledURI属性に適切なLDAP問合せフィルタを設定することで定義します。問合せフィルタでは、グループのメンバーシップを定義するユーザー・セットを定義します。
|
注意: labeledURI属性はDASコンソールには公開されないため、動的グループはDASで定義できません。labeledURI属性は、Oracle Directory Manager内で、またはコマンドラインからldapmodifyなどの適切なLDAPコマンドを使用して定義する必要があります。 |
動的グループは次の2つの方法で作成できます。
LDIFファイルでldapaddコマンドを使用して作成する
Oracle Directory Services Manager (ODSM)を使用して作成する
オプション1: LDIFファイルを使用した動的グループの作成
LDIFファイルを使用して動的グループを作成するには、次の手順を実行します。
テキスト・エディタでLDIFファイルを作成します。次の例は、デフォルトのユーザー検索ベースで役職が「Manager」のユーザーをすべて表示するように動的グループを定義する方法を示しています。
例7-1 動的グループの定義
dn: cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=orac le,dc=com labeleduri: ldap://myserver.mycompany.com.com:12061/cn=users,dc=us,dc=mybiz,dc=com ??sub?(title=Manager) description: Dynamic Group of Managers cn: Managers orclisvisible: true objectclass: orclDynamicGroup objectclass: orclGroup objectclass: top objectclass: groupOfUniqueNames displayname: Managers owner: cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com
|
注意: LDAPのURLのlabeledURI属性の構文は、RFC 2255 (http://www.faqs.org/rfcs/rfc2255.html)で定義します。上の例は、DN cn=users,dc=us,dc=mybiz,dc=comでtitle=Manager属性の全エントリの検索を表しています。myserver.mycompany.comサーバーのLDAPポート12061でサブツリー(sub)の検索を使用して行います。 動的グループは、LDAPのURLとして表してlabeledURI属性で定義することができるすべての属性または条件で定義できます。また動的グループは、orclDynamicGroupオブジェクト・クラスに含まれるConnectByアサーションを使用して定義することもできます。この方法の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。 |
ファイルを保存し、ldapaddコマンドを発行してOIDサーバーを更新します。例:
ldapadd -h myserver -p 12061 -D cn=fmwadmin -w mybiz1 –f managers.ldif –v
add labeleduri: ldap://myserver.mycompany.com:12061/cn=users,dc=us,dc=mybiz,dc=com??sub?(title=Manager)
add description:
Dynamic Group of Managers
add cn:
Managers
add orclisvisible:
true
add objectclass:
orclDynamicGroup
orclGroup
top
groupOfUniqueNames
add displayname:
Managers
add owner:
cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com
adding new entry cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=mybiz,dc=com
modify complete
オプション2: ODSMを使用した動的グループの作成
Oracle Directory Services Manager (ODSM)を起動し、Oracle Internet Directoryサーバーに接続します。
Oracle Directory Services Managerの起動と使用の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のOracle Directory Services Managerの使用に関する項を参照してください。
「移動先」リストから、「データ・ブラウザ」を選択します。
データ・ブラウザで、「新規エントリ」アイコンをクリックします。
DNを入力し、オブジェクト・クラスorclDynamicGroupおよびgroupOfUniqueNamesを追加します。
「必須プロパティ」タブで、CN属性を入力します。
「オプション・プロパティ」タブで、labeleduriの属性を入力します。
「OK」をクリックし、動的グループの定義を完了します。
ツリー・ビューをリフレッシュすると、作成した新規グループが表示されます。グループ・メンバーがODSMには表示されないことに注意してください。
ポートレットは、アプリケーションのウィンドウの役目を果たし、サマリー情報を表示したり、アプリケーションのすべての機能にアクセスする方法を提供したりします。ポートレットでは、アプリケーションの機能をポータルに直接公開したり、タスクを実行するためにアプリケーション自体にアクセスできる深いリンクを提供したりします。ポートレットでは情報をWebページに表示できるように書式設定するため、基になるアプリケーションはOracle Portalと統合されるためにWeb対応である必要はありません。
Oracle Portalでは、ポートレットはプロバイダによって管理されます。プロバイダとは、Oracle Portalに登録されているアプリケーションのことです。Oracle Portalでは、次の3種類のプロバイダをサポートしています。
ポートレットのセキュリティは、次の3つの主な機能領域で構成されています。
認証: ユーザーがセキュアなURLに初めてアクセスすると、そのユーザーのIDを確認する情報(ユーザー名、パスワード、デジタル証明書など)を入力するよう要求されます。
認可: 認可とは、特定のユーザーがアプリケーションの一部にアクセスできるようにするプロセスのことです。アプリケーションには、誰でも自由にアクセスできる部分もあれば、限られた何人かの認証済ユーザーのみがアクセスできる部分もあります。
通信セキュリティ: 通信セキュリティとは、Oracle Portalがプロバイダとやり取りする通信(メッセージなど)の真正性を確立するために使用する方法のことです。高度にネットワーク化された環境では、通信が認証されたものであるかどうかを確認することがきわめて重要です。
Webプロバイダを確実に安全なものにするためには、これらの各領域でプロバイダが保護されていることを確認する必要があります。3つの領域のうちの1つか2つのセキュリティ機能を実装しただけでは、プロバイダがセキュアであるとみなすことはできません。Webプロバイダの保護に力を注いだだけ、プロバイダが公開するデータの機密性も高くなります。
WSRPポートレットのセキュリティを確保するために、Oracle PortalおよびWSRPプロデューサは、VPNネットワークや、ファイアウォールの内側にあるネットワークなど、本質的にセキュアなネットワークを介して通信します。
ユーザーが初めてOracle Portalにログインするときは、アクセスを許可される前に、ユーザーのIDを確認するためのパスワードを入力する必要があります。このログイン・プロセスは、OracleAS Single Sign-Onによって管理されています。詳細は、第7.1.9.7項「シングル・サインオン」を参照してください。
認可により、特定のユーザーがポートレットの表示または対話を行えるかどうかが判断されます。認可チェックには、次の2種類があります。
Portalのアクセス制御リスト: Oracle Portalにログインすると、ユーザーはOracleAS Single Sign-Onによって認証されます。認証されると、Oracle Portalではアクセス制御リスト(ACL)を使用して、ページやポートレットなどのポータル・オブジェクトに対する権限をユーザーに付与します。操作の範囲は、単にオブジェクトを表示することから管理機能の実行にまで及びます。ある特定の権限が付与されているグループに属さないユーザーは、Oracle Portalで、その権限に関連付けられている操作が実行できません。
プログラムによるポートレットのセキュリティ: Portal Developer's Kit-Javaには、特定のユーザーにポートレットの表示が認可されているかどうかを確認するためにコールされるAPIが含まれています。これらのAPIを使用して、Portal ACLのセキュリティを強化する認可ロジックを実装できます。
J2EEセキュリティ・ロール: プロバイダ・コードではプログラムによるJ2EEセキュリティを使用できます。この機能を利用するには、アサートされたIDの整合性を保護するため、拡張認証を使用するようにプロバイダを構成する必要があります。ポートレット・コード内からは、request.isUserInRole("securityrole")を使用できます。ここで、requestはHttpServletRequestリクエストで、securityroleは宣言されたJ2EEセキュリティ・ロールです。拡張認証の構成方法の詳細は、第7.3.1.3.2項「拡張認証」を参照してください。
認証と認可は、Webプロバイダを保護する重要なコンポーネントです。ただし、認証と承認ではプロバイダが受信したメッセージの認証性までは確認されないため、それだけでプロバイダへのアクセスを保護するのには適していません。通信が保護されていないと、誰かがOracle Portalを装い、Webプロバイダをだまして機密情報を返信させる危険があります。
通信セキュリティは、Oracle PortalとJPDK Webプロバイダとの通信を保護することに的を絞っています。これらの方法は、ポータル・データベースの内部で実行するデータベース・プロバイダには適用されません。通信セキュリティには、次の3つのタイプがあります。
Portalサーバー認証では、受信メッセージが信頼できるホストから送信されたことを確認します。
メッセージ認証では、受信メッセージが改ざんされていないことを確認します。
メッセージの暗号化では、メッセージの内容を暗号化することによって保護します。
Portalサーバー認証では、プロバイダへのアクセスを少数の認証されているコンピュータに制限します。この方法では、受信したHTTPメッセージのIPアドレスまたはホスト名を信頼できるホストのリストと比較します。IPアドレスまたはホスト名がリストにあれば、メッセージはプロバイダに渡されます。リストになければ、そのメッセージはプロバイダに達する前に拒否されます。
メッセージ認証は、共有キーをベースとしたチェックサムをプロバイダのメッセージに追加することによって機能します。メッセージがプロバイダによって受信されると、予想されるチェックサムの値が計算され、その値が実際に受信された値と比較されることによって、メッセージの認証性が確認されます。それらの値が同じであれば、メッセージは受け入れられます。それらの値が異なっていれば、メッセージは拒否されてその後の処理も行われません。チェックサムには、送信中にメッセージが不法に記録され、後で再送信される可能性を低くするためのタイムスタンプが含まれています。
Oracle Portalにログインすると、ユーザーはOracleAS Single Sign-Onによって認証されます。次に、Oracle Portalで、アクセス制御リスト(ACL)を使用して、ユーザーに各コンテンツ(プロバイダやポートレットなど)の表示が認可されているかどうかが確認されます。ある特定の権限が付与されているグループに属さないユーザーは、Oracle Portalで、その権限に関連付けられている操作が実行できません。
ACLは、次のように管理されます。
権限は、それらが付与されているオブジェクトに対して実行できる操作を定義します。「管理」、「実行」、「アクセス」、「公開」などのいくつかの権限を付与できます。これらの権限のいずれかを設定すると、ユーザーはポートレットにアクセスできます。
ユーザーとその権限は、ビルダーの「管理」タブにある「ポータル」タブで管理されます。
グループ内のグループ・メンバーシップとそのグループに付与されている権限は、ビルダーの「管理」タブにある「ポータル」タブで管理されます。ユーザー・グループに付与されている権限は、そのグループのすべてのメンバーによって継承されます。
プロバイダに権限を付与できます。デフォルトでは、それらの権限はプロバイダとそのプロバイダ内のすべてのポートレットに適用されます。プロバイダのACLは、ナビゲータの「プロバイダ」タブで管理されます。
ポートレットの権限によって、ポートレットのプロバイダに設定された権限をオーバーライドできます。ポートレットのACLは、ナビゲータの「プロバイダ」タブで管理されます。「プロバイダ」の「開く」をクリックすると、プロバイダのポートレットを管理するためのページが表示されます。
ACLは、ポータル・オブジェクトを保護するための、簡単で、しかも非常に強力なメカニズムを備えています。
ユーザーやグループは集中管理されているため、グループのメンバーシップの変更に伴ってACLを変更する必要はありません。
プロバイダへの認可されていないアクセスを回避する方法の1つは、サーバー・レベルでプロバイダへのアクセスを既知のクライアント・コンピュータに制限することです。この方法は、サービス拒否攻撃に対する防御にある程度役に立ちます。
Oracle HTTP Serverでは、ホスト名またはIPアドレスを基にしたhttpd.confファイル内のディレクティブを許可または拒否できます。識別子としてホスト名を使用すると、サーバーはドメイン・ネーム・サーバーでそれらを見つける必要があり、各リクエストの処理に対してオーバーヘッドが発生します。IPアドレスを使用すると、このような余分のオーバーヘッドが発生しなくて済みますが、IPアドレスは警告なしに変更される可能性があります。
Oracle Web CacheにはIPアドレスのチェック機能がありません。プロバイダの手前にOracle Web Cacheがある場合は、どのホストのクライアントもOracle Web Cacheに表示リクエストを送信できます。
この方法を回避するには、偽のIPアドレスとホスト名が含まれるメッセージをプロバイダに送信します。この方法は慎重に実行する必要があります。リターン・メッセージでは、コピーされたIPアドレスをコンピュータに送信しますが、そのIPアドレスによって引き続き問題が発生する可能性があるからです。
次の各項は、Webプロバイダにのみ適用され、WSRPプロデューサには適用されません。
特に設定を行っていない場合、Portalツール(OmniPortletとWebクリッピング)のプロバイダ構成ページは一定の権限によって保護されています。この権限の詳細は、第7.1.3.4項「Webプロバイダとプロバイダ・グループを編集する権限」を参照してください。これらのページが保護されていない場合は、DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INFディレクトリのweb.xmlファイルで、次のパラメータと値がfalseではなくtrueに設定されていることを確認してください。
<init-param> <param-name>oracle.webdb.providerui.securedAccessParam</param-name> <param-value>true</param-value> </init-param>
ポートレットは、アプリケーションのウィンドウの役目を果たし、コンテンツのサマリーや、アプリケーションのすべての機能にアクセスする方法を表示します。ポートレットでは、アプリケーションの機能をポータルに直接公開したり、タスクを実行するためにアプリケーション自体にアクセスできる深いリンクを提供したりできます。
アプリケーションで認可が行われない場合は、ユーザーがそのアプリケーションを表示したり、そのアプリケーションやそれに関連付けられているポートレットを使用するのに認証は必要ありません。より制限のあるアプリケーションについては、それにアクセスしているユーザーを認証する必要があります。
パートナ・アプリケーションでは、Oracle Portalのユーザーと同じ認証ユーザーを共有しています。この場合、アプリケーションのユーザーとOracle Portalのユーザーは同じです。
外部アプリケーションでは、ユーザーの証明書にOracle Portalとは異なる認証メカニズムを使用し、通常は異なるリポジトリを使用します。アプリケーションのユーザー名がOracle Portalと同じである場合がありますが、外部アプリケーションでは独自のメカニズムによってユーザーを確認します。
パートナ・アプリケーションでは、認証のためにOracle Portalと同じOracleAS Single Sign-Onを共有しています。OracleAS Single Sign-Onのインスタンスを共有すると、ユーザーがOracle Portalにすでにログインしているときは、再度ログインしなくてもそのIDがパートナ・アプリケーションにアサートされることになります。
パートナ・アプリケーションは、OracleAS Single Sign-Onと密接に統合されています。ユーザーがパートナ・アプリケーションへのアクセスを試みると、パートナ・アプリケーションはそのユーザーの認証をOracleAS Single Sign-Onに委任します。有効なユーザー名とパスワードによって一度認証されると、ユーザーは同じOracleAS Single Sign-Onインスタンスを共有している他のパートナ・アプリケーションにアクセスするときにユーザー名またはパスワードを入力する必要がありません。OracleAS Single Sign-Onでは、ユーザーが正常に認証されたことを確認し、認証が成功したことを他のパートナ・アプリケーションに示します。
パートナ・アプリケーションのプロバイダは、プロバイダにかわってOracle Portalにユーザーを認証してもらいます。この関係が可能なのは、Oracle Portal自体がパートナ・アプリケーションであるからです。パートナ・アプリケーションのプロバイダは、それ自体で認証を行うことができないため、この方法でOracle Portalにユーザーを認証してもらう必要があります。ユーザーを直接認証するには、プロバイダがブラウザをOracleAS Single Sign-Onにリダイレクトし、成功URLと失敗URLを提供する必要があります。この方法は、プロバイダのアーキテクチャが原因で実行できません。その主な理由は、認証がOracle PortalからプロバイダへのAPIコールを受けて行われるからです。認証に際し、OracleAS Single Sign-OnではinitSession()/dologin()メソッドを同様にコールして、通常の処理を行うことができません。
パートナ・アプリケーションでのユーザーの認証は、従来型のアプリケーションとは異なります。パートナ・アプリケーションは、ユーザー認証をOracleAS Single Sign-Onに委任します。ユーザーが認証されていない場合、OracleAS Single Sign-Onでは、ユーザーにユーザー名とパスワードを入力するよう要求するログイン・ページが表示されます。ログイン・ページでは、ユーザー名とパスワードがOracleAS Single Sign-Onに送り返されます。
認証に成功すると、OracleAS Single Sign-Onではユーザーに関する情報を格納した専用のCookieが作成されます。セキュリティを確保するために、OracleAS Single Sign-OnではCookieの内容が暗号化されています。Cookieは、ユーザーのブラウザに送り返されますが、OracleAS Single Sign-Onのみがそれにアクセスできるように適用範囲が設定されます。それは他のリスナーには渡されません。Cookieの作成後、OracleAS Single Sign-OnはWebブラウザをパートナ・アプリケーションによって指定された成功URLにリダイレクトします。この時点で、パートナ・アプリケーションでは、アプリケーションのセッションCookieが作成されます。このCookieにはその後のセッションの再確立に必要な情報が格納されます。以降はこのパートナ・アプリケーションに対するリクエストを発行すると、パートナ・アプリケーションのセッションCookieの存在が検出され、それによりユーザーがすでに認証済であることが確認されます。
ユーザーが後で別のパートナ・アプリケーションにアクセスすると、そのアプリケーションはアプリケーション固有のセッションCookieを検索します。Cookieが見つからない場合は、前に説明したように、アプリケーションはリクエストをOracleAS Single Sign-Onにリダイレクトします。今度は、OracleAS Single Sign-OnがユーザーのOracleAS Single Sign-On Cookieの存在を検出します。このCookieはユーザーがすでに認証されていることを示しているため、OracleAS Single Sign-Onでは、ユーザーに証明書の再入力を要求せずに、ブラウザを2番目のパートナ・アプリケーションの成功URLにリダイレクトします。この時点で、パートナ・アプリケーションでは、そのアプリケーション固有のセッションCookieが作成されます。
Oracle Portalによって行われるIDアサーションのプロバイダに対する整合性を保護するには、HMACを使用したメッセージ認証を構成する必要があります。この設定方法の詳細は、第7.3.1.3項「プロバイダのメッセージ認証の構成」を参照してください。
利点
Oracle PortalとOracleAS Single Sign-Onを最も密接に統合できます。
ユーザーはOracleAS Single Sign-Onを最も有効に利用できます。
ポータルとプロバイダの間でユーザー名やパスワードを送信しないため、最もセキュアな形式で統合を行うことができます。
アプリケーションとポータルは同じユーザー・リポジトリを共有しているため、ユーザーの管理が軽減されます。
不利な点
アプリケーションのユーザー・コミュニティがポータルのユーザー・コミュニティのサブセットである可能性があっても、アプリケーションはOracle Portalと同じユーザー・リポジトリを共有する必要があります。この小さな問題には、そのアプリケーションをアプリケーションのユーザー・コミュニティに公開するポータル・ページへのアクセスを制限することによって対処できます。
アプリケーションを1つ以上のOracleAS Single Sign-Onと密接に統合できるのは、それらが同じユーザー・リポジトリを共有している場合のみです。
実装テクニック
アプリケーションは、mod_ossoを使用してURLを保護することで、パートナ・アプリケーションにすることができます。一度構成すると、mod_ossoはURLへのアクセスを制限し、OracleAS Single Sign-OnへのリダイレクトやCookieの作成などの処理を行います。
mod_ossoは、汎用的なOracle HTTP Serverモジュールで、OracleAS Single Sign-Onのパートナ・アプリケーションです。それは、OracleAS Single Sign-Onを使用して認証を行います。モジュールは、Oracle HTTP ServerとOracleAS Single Sign-Onの間のCookieの通信や処理をすべて行います。WebアプリケーションのURLを保護するようにmod_ossoを構成すると、そのアプリケーションは実質的にパートナ・アプリケーションとなります。
Oracle Portalもパートナ・アプリケーションであり、OracleAS Single Sign-Onを使用してユーザーを認証します。Oracle Portalとmod_ossoが同じOracleAS Single Sign-Onインスタンスを使用するという前提で、ユーザーはいずれか一方にログインすることによって、WebアプリケーションにもOracle Portalにもアクセスできます。つまり、一度のログインのみで、WebアプリケーションとOracle Portalの両方にアクセスできるようになります。
利点
mod_ossoは、設定が簡単です。
アプリケーションにコードを追加する必要がありません。
OracleAS Single Sign-On環境の新機能は、単純な動的ディレクティブを通じて公開されます。
mod_ossoは、パートナ・アプリケーションのCookieを作成し、Cookieの処理をすべて行います。
mod_ossoは、パートナ・アプリケーション、およびパートナ・アプリケーションのプロバイダからの深いリンクを保護します。
不利な点
必ずしも不利な点ではありませんが、mod_ossoは、Webアプリケーションでしか使用できません。
外部アプリケーションとは、Oracle Portalとは異なる認証メカニズムを使用するアプリケーションのことです。このアプリケーションでは、Oracle Portalによって使用されるのとは異なるOracleAS Single Sign-Onインスタンスを使用することも、他の認証方法を使用することもできます。どちらの場合も、OracleAS Single Sign-Onでは、ユーザー名のマッピングやパスワードなど、ユーザーの認証に必要な資格証明を各外部アプリケーションに格納します。Oracle Portalにすでにログインしているユーザーは、ユーザー名やパスワードを入力しなくても外部アプリケーションにログインできます。
独自のユーザー認証を管理しているアプリケーションは、外部アプリケーションとして登録することにより、OracleAS Single Sign-Onと柔軟に統合できます。Oracle Fusion Middleware Portal Developer Kitを使用して外部アプリケーションをプロバイダとして公開すれば、ページのポートレットからその外部アプリケーションにアクセスできます。外部アプリケーションのプロバイダは、JPDK Webプロバイダでのみ利用できます。
|
関連項目: 「外部アプリケーション」ポートレットの詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』を参照してください。 |
以前に認証されたユーザーが初めて外部アプリケーションにアクセスするとき、OracleAS Single Sign-Onではその外部アプリケーションを使用してユーザーの認証を試みます。この認証は、そのアプリケーションの登録情報、ユーザーのユーザー名とパスワードを結合するHTTPリクエストを送信することによって行われます。ユーザーがまだその外部アプリケーションのユーザー名とパスワードを登録していない場合、OracleAS Single Sign-Onでは認証リクエストを作成する前に、ユーザーに必要な情報を入力するよう要求します。ユーザーが外部アプリケーションのユーザー名とパスワードを入力すると、OracleAS Single Sign-Onでは新しいユーザー名とパスワードが、そのユーザーのOracle Portalのユーザー名にマップされ、格納されます。次回ユーザーが外部アプリケーションにアクセスする必要があるときは、格納されている証明書が使用されます。
|
注意: 外部アプリケーションのURLを変更した場合は、OracleAS Single Sign-On Serverでその外部アプリケーションを更新する必要があります。外部アプリケーションの更新については、『Oracle Application Server Single Sign-On管理者ガイド』の外部アプリケーションの編集に関する項を参照してください。 |
利点
多数のポータルとの統合が可能です。優先ポータルがある場合は、アプリケーションをそのポータルのパートナ・アプリケーションとして統合し、他のポータルの外部アプリケーションとして統合できます。
ユーザーはシングル・サインオンを利用することができます。ただし、ユーザーは異なるユーザー名やパスワードを管理する必要があります。さらに、外部アプリケーションのユーザー名のマッピングも管理する必要があります。
複数のポータルとの統合を、それらのユーザー・リポジトリやシングル・サインオンのメカニズムに関係なく行うことができます。
不利な点
外部アプリケーションは、ポータルと同じユーザー・リポジトリを共有しません。このため、ユーザー情報の管理がさらに必要となります。
ユーザー名とパスワードが平文でプロバイダに送信されます。この方法は、パートナ・アプリケーションほどセキュアではありません。SSLを使用するようにプロバイダのURLを構成すると、この問題に対処できます。
JavaまたはPL/SQLと簡単に統合できるテクノロジを使用してアプリケーションを作成する必要があります。
プロバイダ内部にポートレットのセキュリティ・メソッドを実装して、特定のユーザーがポートレット・インスタンスにアクセスできるかどうかを確認できます。これらのセキュリティ・メソッドは、ポートレット・レベルで機能します。つまり、各ポートレットに独自のユーザー・アクセス制御を適用することができます。プロバイダでアクセス制御メソッドを実装することにより、ユーザーの証明書が認可ロジックに通った場合にのみコンテンツがポートレットから取得されます。プロバイダでポートレットのセキュリティ・メソッドを実装しない場合は、偽名や認証されていない名前であっても、すべてのユーザー名が通ります。
プロバイダでは、次の2つのポートレットのセキュリティ・メソッドを実装できます。
ポートレットのリストを取得します。
ポートレットのアクセスを確認します。
これらのメソッドでは、認可レベルに関する次の情報にアクセスできます。
強い認証は、ユーザーが現行のOracle PortalセッションでOracleAS Single Sign-Onによって認証されたこと、つまり有効なユーザー名とパスワードを使用してOracle Portalにログインし、そのセッションでポートレットをコールしたことを示します。
パブリックは、ユーザーが現行のOracle Portalセッションのコンテキスト内でログインしておらず、そのような状態が以前に存在したことを示す永続的なCookieもないことを示します。
ポートレットは、次に示すOracle Portalのユーザー権限やグループ・メンバーシップにもアクセスできます。
ユーザーのデフォルト・グループ
ユーザーまたはグループの権限
すべてのグループで利用できる最高のユーザー権限
ユーザーがアクセスできるオブジェクト
Oracle Fusion Middleware Portal Developer Kitでは、メッセージ認証をサポートして、指定されたプロバイダ・インスタンスまたはプロバイダ・インスタンスのグループへのアクセスを制限します。プロバイダは、ポータルとプロバイダの管理者のみが知っている秘密共有キーに登録されます。
Oracle Portalインスタンスでは、Hashed Message Authentication Code (HMAC)アルゴリズムを使用して計算されたデジタル署名が各メッセージとともにプロバイダに送信されます。プロバイダは、共有キーの独自のコピーで署名を確認することによって、メッセージを認証することができます。このテクニックは、プロバイダとのSSL通信でクライアント証明書のかわりに使用することができます。
Oracle Portalインスタンスでは、ユーザー情報、共有キーおよびタイムスタンプを基にして署名が計算されます。署名とタイムスタンプは、SOAPメッセージの一部として送信されます。タイムスタンプは、UTC(協定世界時、グリニッジ標準時の学術名)を基にしているため、異なるタイム・ゾーンのコンピュータ間のメッセージに使用することができます。
プロバイダがこのメッセージを受信すると、その署名の独自のコピーを作成します。署名が合致すると、メッセージのタイムスタンプを現在の時刻と比較します。2つの時刻の差が許容値の範囲内にある場合は、メッセージは本物とみなされ、その結果、処理されます。
1つのプロバイダ・インスタンスで複数の共有キーをサポートすることはできません。複数のキーを使用すると、プロバイダを共有している複数のクライアントが同じキーを使用した場合にセキュリティや管理上の問題が発生する可能性があります。たとえば、共有キーのコピーの1つがなんらかの方法で侵害された場合、プロバイダの管理者は新しいキーを作成して、それをすべてのクライアントに配布し、クライアントはそのプロバイダ定義を更新する必要があります。この問題を回避するには、異なるプロバイダ・サービスを配置して、サービスごとに一意の共有キーを指定します。各プロバイダ・サービスには独自のデプロイ・プロパティ・ファイルがあるため、各サービスは他のサービスとは無関係に構成されます。同じプロバイダ・アダプタ内に複数のプロバイダ・サービスを配置することによるオーバーヘッドは比較的小さいものです。
プロバイダの手前にOracle Web Cacheがない場合、プロバイダ・セッションの存続期間中に同じ署名Cookieが使用されるということは、パフォーマンスと、リクエストを認証することによって得られるセキュリティの間で妥協する必要があることを意味します。署名Cookieの値は、最初のSOAPリクエストによってプロバイダとのセッションが確立された後に1回のみ計算されます。プロバイダ・セッションのタイムアウトが短いほど、署名が計算される頻度が多くなり、不正な表示リクエストに対するセキュリティが高まります。ただし、セッションの確立に必要なSOAPリクエストにより時間がかかります。
Oracle Web Cacheを使用して表示リクエストのレスポンスをキャッシュするプロバイダでも、同様の妥協が必要です。キャッシュされたコンテンツは、受信リクエストに、キャッシュされたコンテンツを取得するための署名Cookieが含まれているという点でセキュアですが、長期間にわたってコンテンツをキャッシュすると、プロバイダは不正な表示リクエストに対して無防備になります。
署名要素では、メッセージの傍受や再送信に対する保護は行われますが、メッセージ・コンテンツの傍受や読取りを防ぐための処理は何も行われません。しかも、メッセージは平文で送信されます。メッセージの内容が認可されていない者に読み取られるのが心配な場合は、メッセージ認証をSSLと組み合せて使用する必要があります。
Oracle Portalとプロバイダとの通常の通信には、TCPをトランスポート・レイヤーとして使用し、データを平文で送信するHTTPというネットワーク・プロトコルが使用されます。認可されていないエージェントが、傍受したメッセージを読む可能性があります。HTTPSは、TCPの上位にある特別なセキュリティ・レイヤー(SSL)を使用して、クライアントとサーバーとの通信を保護します。
SSLを使用して通信を受け入れる各エンティティ(Oracle Web Cacheインスタンスなど)は、自由に利用できる公開鍵と、エンティティのみが知っている秘密鍵を持っています。エンティティに送信されるメッセージはすべて、そのエンティティの公開鍵で暗号化されます。公開鍵で暗号化されたメッセージは、秘密鍵によってのみ復号化できるため、メッセージが傍受された場合でも復号化はできません。
証明書は通信の署名に使用され、それによって公開鍵が実際に正しいエントリに属していることが保証されます。このような証明書は、認証局(CA)として知られる信頼できるサード・パーティ(OracleAS Certificate AuthorityやVerisign社など)によって発行されます。この証明書には、エンティティの名前、公開鍵およびその他のセキュリティ資格証明が含まれています。これは、サーバーのIDを確認するためにSSL通信のサーバー側にインストールされます。クライアントのIDを確認するためにクライアントの証明書をクライアントにインストールすることもできますが、この機能ではまだOracle Portalがサポートされていません。かわりにメッセージ認証を使用できます。
Oracle Wallet Managerは、公開鍵のセキュリティ資格証明の管理に使用されるアプリケーションです。これは、公開鍵/秘密鍵のペアの生成、CAへの証明書リクエストの作成およびサーバーでの証明書のインストールに使用されます。
プロバイダをOracle Portalインスタンスから登録するときは、URLを1つのみ入力します。HTTPまたはHTTPSを使用できますが、両方を組み合せての使用はできません。
コンピュータにインストールされたサーバー側の証明書は、そのコンピュータ(ドメイン)の識別に使用されますが、そのコンピュータの複数のポート定義で使用される場合があります。証明書の信頼リストを使用することで、特に識別されたサーバーのみに通信が限定されます。信頼できるOracle Portalインスタンスとプロバイダとの通信を完全に保護するには、メッセージ認証もあわせて使用する必要があります。
|
関連項目:
|
SSLは、プロバイダからParallel Page Engineへのデータの転送中に、ポートレットのコンテンツを暗号化します。ポートレット・コンテンツのセキュリティを強化するには、周囲のページをSSLベースのリクエストで起動する必要があります。
暗号化は、Oracle Portalのパフォーマンスに影響を与えます。
暗号化を使用する場合は、一部のコンテンツがパブリックであっても、プロバイダのすべてのポートレットでHTTPSを使用する必要があります。
Webプロバイダのセキュリティに関する詳細は、次の文書を参照してください。
「Overview of Provider Security」
「Overview of Password Authenticated Applications」
Oracle Technology Network (OTN)のサイト(http://www.oracle.com/technology/)で入手できます。
ここでは、Oracle PortalからWSRPポートレットへのアクセスをセキュリティで保護する方法について説明します。
WSRPプロデューサの概要の詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』を参照してください。
WSRPプロデューサおよびPortalアプリケーションのセキュリティ資格証明は、Java Keystore (JKS)またはOracle Walletを使用して取得および管理できます。キーストアとは、使用可能な公開鍵および秘密鍵に関する情報を提供するファイルです。キーは、認証やデータ整合性などの様々な目的で使用します。ピアの証明書の検証に必要なユーザー証明書およびトラスト・ポイントも、ウォレットまたはキーストアに保存されます。キーストアの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
次の手順にあるコンシューマは、WSRPを介してリモート・ポートレット・プロデューサで生成したポートレットを利用するOracle Portalです。このプロデューサでは、コンシューマの公開鍵を使用して、そのコンシューマから受け取ったセキュリティ・トークンの真正性を検証します。このトークンは、getMarkupインタフェースを介して受け取ったリクエストのWS-Security・ヘッダーにあります。そのために、プロデューサではコンシューマの証明書とその署名に使用するルート証明書を収めたJavaキーストアが必要になります。これらの証明書は、信頼できる証明書としてJavaキーストアに追加されます。
この項では、Java Keystore (JKS)を使用してキーストアおよびキーを作成する方法について説明します。JKSは、Sun社で規定した固有のキーストア・フォーマットです。JKSでキーおよび証明書を作成および管理するには、Java JDK 6で配布されているkeytoolユーティリティを使用します。
コンシューマおよびプロデューサで使用するJavaキーストアの作成
コンシューマのJavaキーストアを作成するには、次の手順を実行します。
MW_HOME\jdk160_xx_\binに移動して、コマンド・プロンプトを開きます。
次のようにkeytoolを使用して、キーのペアを生成します。
keytool -genkeypair -keyalg RSA -dname "<consumer_dname>" -alias <consumer_alias> -keypass <key_password> -keystore <keystore> -storepass <keystore_password> -validity <days_valid>
説明:
<consumer_dname>はコンシューマの名前です(cn=consumer,dc=example,dc=comなど)。
<consumer_alias>はコンシューマの別名です(consumerなど)。
<key_password>は新しい公開鍵のパスワードです(welcome1など)。
<keystore>はキーストアの名前です(consumer.jksなど)。
<keystore_password>はキーストアのパスワードです(welcome1など)。
<days_valid>はキーのパスワードの有効日数です(360など)。
|
注意: キーを生成するためにkeytoolで使用するデフォルトのアルゴリズム(DSA)は機能しないので、前述のように |
コンシューマの公開鍵をエクスポートします。
keytool -exportcert -v -alias <consumer_alias> -keystore <keystore> -storepass <keystore_password> -rfc -file <certificate_file>
説明:
<consumer_alias>はコンシューマの別名です(consumerなど)。
<keystore>はキーストアの名前です(consumer.jksなど)。
<key_password>は、公開鍵のパスワードです(welcome1など)。
<keystore_password>はキーストアのパスワードです(welcome1など)。
<certificate_file>は、キーのエクスポート先の証明書のファイル名です(consumer.cerなど)。
次のように、プロデューサのキーストアに信頼できる証明書をインポートします。
keytool -importcert -alias <consumer_alias> -file <certificate_file> -keystore <keystore> -storepass <keystore_password>
説明:
<consumer_alias>は、コンシューマの別名です。
<certificate_file>は、コンシューマの証明書のファイル名です。
<keystore>は、プロデューサのキーストアの名前です。
<keystore_password>は、プロデューサのキーストアのパスワードです。
プロデューサを構成するには、次の手順を実行します。
グローバル・キーストアの構成
キーストアを構成するには、次の手順を実行します。
Oracle Portalにログインします。
「管理」タブをクリックします。
「サービス」ポートレットで「グローバル設定」をクリックします。
デフォルトでは、「サービス」ポートレットは、「Portalビルダー」ページの「管理」タブの「ポータル」サブタブにあります。
「キーストア」タブをクリックします。
「デフォルト・キーストア」ページが表示されます。
「デフォルト・キーストア」ページで、必要な情報を入力します。
「適用」をクリックします。
「OK」をクリックします。
WSRPプロデューサの登録
プロデューサを登録するには、次の手順を実行します。
「ポートレット」サブタブをクリックします。
「リモート・プロバイダ」ポートレットで、「プロバイダの登録」をクリックして「プロバイダの登録」ページを表示し、次の情報を入力します。
「名前」フィールドにプロバイダの名前を入力します。名前は200文字以内で入力します。空白や特殊文字は使用できません。
「表示名」フィールドに、そのプロバイダを参照したときに表示される名前を入力します(Portlet Repositoryなど)。表示名は200文字以内で入力します。
「タイムアウト」フィールドに、タイムアウト・メッセージを表示するまでにOracle Portalがプロバイダへの接続を試行し続ける時間を秒数で入力します。
「タイムアウト・メッセージ」フィールドには、「タイムアウト」フィールドで指定した秒数内にOracle Portalがプロバイダとの接続を確立できなかったときに表示されるメッセージを入力します。このメッセージはポートレットの本文内に表示されます。
「実装スタイル」リストから、使用しているWSRPプロバイダの「WSRP」を選択します。
「次へ」をクリックして「接続の定義」ページを表示します。
「WSDL URL」フィールドで、プロバイダのWSDL URLを入力して「次へ」をクリックします。
ポータル登録プロパティ値ページが表示されます。
プロバイダに必要な登録プロパティを入力します。登録プロパティがない場合は、次の手順に進みます。
「WS-Security構成」ページが表示されます。
「キーストア構成」セクションで、表7-18の説明にあるパラメータを入力します。
表7-18 WSRPプロデューサのキーストア接続パラメータ
| フィールド | 説明 |
|---|---|
|
ストア・パス |
SOAPメッセージの一部(セキュリティ・トークンおよびSOAPメッセージ本体)での署名に使用する証明書および秘密鍵を収めたキーストアのフルパスを入力します。 選択するファイルとして、JDK keytoolまたはOracle Walletで作成したキーストアを指定できます。 |
|
ストア・パスワード |
キーストアを作成したときに設定したキーストアのパスワードを入力します。ストアの正しいパスワードを入力してください。正しくないパスワードを入力すると、実行時のプロデューサ・ポートレットにエラーが表示されます。 |
|
ストア・タイプ |
このプロデューサのキーストア・タイプ(JKSまたはORACLEWALLET)を選択します。 |
|
署名鍵の別名 |
リストから署名キーの別名を選択します。 |
|
署名鍵のパスワード |
「署名鍵の別名」で指定した別名で特定するキーにアクセスするためのパスワードを指定します。 |
「終了」をクリックします。「登録確認」ページが表示されます。
|
注意: PeopleSoft 8.48および8.49 WSRPプロデューサは、ユーザー名トークンのプロファイルのみをサポートします。Oracle WSRPプロデューサは、SAMLトークンのプロファイルをサポートします。その他のWSRPコンテナでサポートされているトークンのフォーマットについては、それぞれのベンダーに確認してください。 |
「OmniPortlet」と「シンプル・パラメータ・フォーム」は、ポートレット・リポジトリの「ポートレット・ビルダー」にあります。デフォルトでは、ページを作成する権限を持つユーザーであれば、これらのポートレットをページに追加したり、それらを定義したりすることができます。さらに、ページに対して最低でも「コンテンツの管理」権限を持っていれば、「OmniPortletの定義」または「シンプル・パラメータ・フォームの定義」をクリックしてこれらのポートレットを定義できます。
この種のアクセスを制御する場合は、権限チェックをアクティブにします。次の手順を実行すると、「アクセス」タブからユーザーまたはユーザー・グループに付与された権限に応じてこれらのポートレットの表示が変わります。ポートレットに対してなんらかの操作を実行するには、ユーザーまたはユーザー・グループに少なくとも「実行」権限が必要です。
Oracle Portalにログインします。
「ナビゲータ」リンクをクリックします。
「ポートレット・リポジトリ」ページ・グループをクリックします。
「ページ」をクリックします。
「ポートレット・ビルダー」ページの横の「編集」をクリックします。
ページの左上にあるページの「アクセス」をクリックします。
「アイテム・レベルのセキュリティを有効にする」を選択します。
「OK」をクリックします。
「OmniPortlet」の横の「アイテムの編集」アイコンをクリックします。
「アクセス」タブをクリックします。
「ポートレットのアクセス権限を設定」を選択します。
「適用」をクリックし、このページの「アクセス権限の付与」セクションと「アクセス権限の変更」セクションの表示内容を書き留めます。
「アクセス権限の付与」セクションを使用して、ユーザーとグループに必要な権限を割り当てます。
「OK」をクリックします。
付録E「Portalツールのプロバイダの構成」では、Webクリッピング・プロバイダを使用する前に実行する必要がある管理タスクについて説明します。次の項では、Webクリッピング・プロバイダによって信頼できるサイトにアクセスし、それ自体とデータベース間のチャネルを暗号化できるようにするために必要ないくつかのセキュリティ構成オプションについて説明します。
ユーザーがセキュアなサイトへ移動すると、そのWebサイトは、セキュリティに関する情報をユーザーから要求されたときに自身の身元を示す証明書をユーザーに返すことが普通です。ユーザーが証明書を受け取ると、その証明書はブラウザの信頼できる証明書のリスト内に置かれるので、ブラウザとそのサーバーとの間でセキュアなチャネルを開くことができます。Webブラウザと同様に、Webクリッピング・プロバイダは外部Webサイトに対してHTTPクライアントとして機能します。Webクリッピング・プロバイダが信頼できるサイトを追跡できるように、このようなサイトの証明書を格納するファイル(ORACLE_HOME\portal\confディレクトリのca-bundle.crtファイル)が使用されます。
出荷されるca-bundle.crtは、Oracle Wallet Managerからの信頼できるサーバー証明書ファイルをエクスポートしたものです。Oracle Wallet Manager内のデフォルトの信頼できるサーバー証明書は、Web上に存在するすべてのサーバー証明書を網羅するものではありません。このため、ユーザーがHTTPSを使用してセキュアなサーバーに移動しているときに、Webクリッピング・スタジオ内で、SSLのハンド・シェイク・フォームに失敗したという例外が発生することがあります。この問題を解決するには、参照された新しい信頼できるサイトを使用してca-bundle.crtファイルを拡張する必要があります。ポータル管理者として、次の手順に従って、出荷されたca-bundle.crtファイルを拡張する必要があります。
ブラウザ(Internet Explorerを推奨)を使用して、参照できても信頼できる証明書ファイルにない外部の各HTTPS Webサイトから、BASE64形式でルート・サーバーの証明書をダウンロードします。
Oracle Wallet Managerを使用して、各証明書をインポートします。
信頼できるサーバー証明書をファイルにエクスポートして、ca-bundle.crtファイルをそのファイルで置き換えます。
Oracle Wallet Managerの詳細は、OTNのサイト(http://www.oracle.com/technology/)のOracle Databaseのドキュメントの『Oracle Database Advanced Security管理者ガイド』を参照してください。
Webクリッピング・プロバイダでは、中間層のプロバイダ自身とWebクリッピング・リポジトリのホストであるデータベース間のチャネルを保護し暗号化する、Oracle Advanced Security Option (ASO)を使用することができます。ASOは、Oracle Fusion Middleware Enterprise Editionでの利用またはStandard Editionへの追加オプションとしての利用のみが可能な機能なので、デフォルトでは、この機能は無効になっています。この機能を有効にするには、次の手順を実行します。
次の場所にあるWebクリッピングの「プロバイダ・テスト・ページ」に移動します。
http://<host>:<port>/portalTools/webClipping/providers/webClipping
「プロバイダ構成」セクションの「設定」列の下に、「Webクリッピング・リポジトリ」フィールドがあります。「操作」列内の対応する「編集」リンクをクリックします。
「プロバイダの編集: Webクリッピング」ページの「リポジトリ設定」セクションで、「詳細セキュリティ・オプション」フィールドの「有効化(保護されたデータベース接続)」オプションを選択します。
「OK」を選択して設定を保存し、Webクリッピングの「プロバイダ・テスト・ページ」に戻ります。
さらに、sqlnet.oraファイル内に次のASO構成パラメータを設定して、Webクリッピング・プロバイダと、Webクリッピング・リポジトリのホストとして動作するデータベース間で確立されるデータベース接続でASOが使用されるようにします。使用する値リストについては、『Oracle Database Advanced Security管理者ガイド』を参照してください。考えられるすべてのパラメータの組合せについて詳しく説明しています。
SQLNET.AUTHENTICATION_SERVICES -- このパラメータは、ASOとのデータベース接続を行う際にサポートされている認証方法を選択するのに使用します。このパラメータの設定の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
SQLNET.CRYPTO_SEED -- このパラメータは、暗号化シード値(FIPS 140-1設定)を指し、ASOとのデータベース接続を行う際に使用します。
このパラメータの設定の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
|
注意: 最初の構成、つまりデータベース・パラメータがすでに設定されている状態の後にこれらのパラメータを設定する場合は、データベース接続がすでに開いているとみなされます。ASOを有効にすると、データベースへのすべての接続が影響を受けるため、ASOを使用する場合は、Webクリッピング・プロバイダが含まれているWLSインスタンスを再起動して、現在のすべての接続をリセットすることをお薦めします。ASOを無効にするときも、この作業が必要です。 |
連携型Portalアダプタは、Oracle Portalのコンポーネントで、ポータル・インスタンスがWebポートレット・インタフェースを介してポートレットを共有できるようにするために使用します。たとえば、あるポータル・インスタンスで、ソースが別のポータル・インスタンスに存在するポートレットを含むページをユーザーが表示するとします。リモート・ポータルの連携型Portalアダプタがポートレットのリクエストを受信すると、リモート・ポータルでそのユーザーのセッションが開始されます。これで、ポートレットがユーザーによってリモート・ポータル・インスタンスから実行できるようになります。このシナリオには、セキュリティ上、次の2つの意味があります。
連携型Portalアダプタは、リモート・ポータルでそのユーザーのセッションを作成する必要があるため、2つのポータル・インスタンスが同じSingle Sign-On Serverを共有するのが最善の方法です。そうしない場合、連携型Portalアダプタがユーザーをリモート・ポータル・インスタンスにログインさせようとしたときに名前の重複が起こる可能性があります。
連携型Portalアダプタは、受信したSOAPメッセージを基にしてプライベート・ポータル・セッションを作成するため、セキュリティ上のリスクとなる可能性があります。メッセージ認証コードを使用して、連携型Portalアダプタによって受信されたメッセージが信頼できるソースから送信されたものであることを確認する必要があります。
詳細は、OTNのサイト(http://www.oracle.com/technology/)にある「How to Add Remote Portlets Using the Federated Portal Adapter」を参照してください。
WebDAV (World Wide Web Distributed Authoring and Versioning)は、Web上でのコラボレーションによるオーサリングのためのIETFの標準です。それは、インターネット上で、互いに離れた位置にいるユーザーが共同で編集やファイル管理を行うためのHTTPの拡張のセットを定義します。
OraDAV (WebDAVをOracleに実装したもの)は、Oracle HTTP ServerがWebDAVのクライアントと通信するのに使用するメカニズムです。OraDAVを使用すると、ユーザーはそのWebDAVクライアントを使用してOracle Portalに接続できます。セキュリティについては、WebDAVを介してOracle Portalにアクセスする場合は、次の2つのセキュリティ問題を考慮する必要があります。
OraDAVのOracle PortalセッションCookieの有効期限
SSLとOraDAV
OraDAVの構成パラメータ、ORACookieMaxAgeは、DAVクライアントがCookieを保持する時間を秒単位で指定します。デフォルト値は、28800 (8時間)です。多くのWebDAVクライアント(Oracle Drive、WebFolders、Cadaverなど)では、ユーザーが初めて接続したときに入力した値を保持しており、それを使用して新しいCookieを作成するので、この時間が経過してもユーザーにユーザー名とパスワードの入力を要求することはありません。
ORACookieMaxAgeは、Oracle Enterprise Managerで変更できるほか、ORACLE_INSTANCE\config\OHS\ohs1\moduleconfにあるmod_oradav.confファイルで直接編集することもできます。このファイルを手動で変更する場合は、その変更を動的構成管理と同期化する必要があります。構成ファイルを変更したら、Oracle HTTP Serverを再起動して、変更を実行時システムに反映させる必要があります。
ORACLE_INSTANCE\bin\opmnctlから次のコマンドを実行して、Oracle HTTP Serverを再起動します。
opmnctl restartproc type=ohs
|
注意: すべてのWebDAVクライアントがCookieを使用するわけではありません。HTTP Basic認証を使用して各リクエストに対する認証を行うクライアントもあります。クライアントでは、WebDAVクライアント・セッションの接続期間中、ユーザー名とパスワードを記録するように選択できるため、ユーザーに対して証明書の入力を1度要求するだけで済みます。ただし、どちらの場合も、この動作によってOracle Portalからのレスポンス時間が長くなります。これは、そのようなクライアントからのリクエストはすべて認証する必要があるため、Oracle Internet Directoryとの通信が余分に必要となるからです。 |
|
関連項目: Oracle Fusion Middleware Oracle HTTP Server管理者ガイド |
ここでは、mod_oradav.confファイルのパスワードを暗号化する方法を説明します。
次のタスクを実行します。
DAVパスワードの編集
mod_oradav.confファイルのパスワードを編集するには、次のようにします。
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf (UNIX)にあるmod_oradav.confファイルを開きます。
パスワードを変更するDAVエントリの場所を確認します。デフォルトのポータル・インスタンスの場合、DAV構成エントリは次のディレクティブにあります。
<Location /dav_portal/portal>
DAVエントリで、ディレクティブORACRYPTPASSWORD (例: DAVParam ORACRYPTPASSWORD BS50NfrosVZOjfgc9hUQ9wcbFFxLSYT/BA==)を削除し、次の構文を使用してクリア・テキストのパスワードに置換します。
DAVParam ORAPASSWORD <your_password_here>
例:
passwd123というパスワードを設定する場合は、DAVParam ORAPASSWORD passwd123という行を追加します。
ファイルを保存します。
パスワードの曖昧化
DAVパスワードの編集後は、UNIXのORACLE_HOME/bin、またはWindowsのORACLE_HOME\binにあるoradavTool.plスクリプトを実行して、DAVパスワードを曖昧化することをお薦めします。これを行うには、次の手順を実行します:
必要に応じて、次のコマンドを使用して、ユーザーをOracleソフトウェアの所有者ユーザー(通常はoracle)に変更します。
su - oracle
現在のリリースのOracleホーム・ディレクトリへのパスを指定するようにORACLE_HOME環境変数を設定し、Perl実行可能ファイルを格納したディレクトリおよびoradavTool.plスクリプトの場所(UNIXの場合はORACLE_HOME/ohs/bin、Windowsの場合はORACLE_HOME\ohs\bin)を指定するようにPATH環境変数を設定します。
Bourne、Bash、またはKornシェルの場合:
$ ORACLE_HOME=new_ORACLE_HOME_path;export ORACLE_HOME PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH;export PATH
Cまたはtcshシェル:
% setenv ORACLE_HOME new_ORACLE_HOME_PATH % setenv PATH ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:PATH
Microsoft Windowsでは、PATHおよびPERL5LIB環境変数を設定します。
set PATH=ORACLE_HOME\bin;%ORACLE_HOME%\perl\bin;%PATH% set PERL5LIB=ORACLE_HOME\perl\lib
UNIXプラットフォームでは、共有ライブラリ・パス環境変数を設定します。
ORACLE_HOME/libまたはlib32ディレクトリを共有ライブラリ・パスで指定します。表7-19に、各プラットフォームに適したディレクトリおよび環境変数を示します。
表7-19 共有ライブラリ・パスの環境変数
| プラットフォーム | 環境変数 | 指定するディレクトリ |
|---|---|---|
|
AIXベース・システム |
|
|
|
HP-UX PA-RISC |
|
|
|
Solarisオペレーティング・システム |
|
|
|
その他のUNIXプラットフォーム(Linux、HP Tru64 UNIXなど) |
|
|
たとえば、HP-UX PA-RISCシステムの場合は、ORACLE_HOME/libディレクトリを指定するようにSHLIB_PATH環境変数を設定します。
$SHLIB_PATH=$ORACLE_HOME/lib:$SHLIB_PATH;export SHLIB_PATH
ディレクトリを、oradavTool.plスクリプトの場所であるORACLE_HOME/bin (UNIX)ディレクトリに変更します。
次のPerlスクリプトを起動して、mod_oradav.confパスワードを暗号化します。
perl oradavTool.pl -f mod_oradav.conffilename
ここで、mod_oradav.conffilenameは、mod_oradav.confファイルへのフルパスを記述したmod_oradav.confのファイル名です。
UNIXの例:
perl oradavTool.pl -f /u01/app/oracle/as11gr1/ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_oradav.conf
ディレクティブORAPASSWORDが新しいディレクティブORACRYPTPASSWORDによって更新され、パスワードが曖昧化されます。
Oracle HTTP Serverを再起動します。
この項では、次の考慮事項について説明します。
Oracle Fusion Middleware Security Frameworkを構成する際にOracle Portalで考慮が必要な主な事項は、SSLをどのように正しく構成するかという点です。Oracle PortalのSSLの構成の詳細は、第7.3.2.1項「Oracle PortalのSSLの構成」を参照してください。
Oracle Portalのセキュリティを構成するときは、Oracle Identity Managementに関連する次のトピックについて考慮する必要があります。
Oracle Identity Managementインフラストラクチャのディレクトリ情報ツリー構造とOracleコンテキスト・パラメータの設定を決めるときは、命名属性とニックネーム属性を異なる値にするように考慮する必要があります。命名属性は、エントリの識別名の最初の属性として使用されます。対照的に、ニックネーム属性はOracleAS Single Sign-Onのユーザー名を保持します。
Oracle Portalで、Oracle Internet Directory内のニックネーム属性の値を変更することによってユーザーの名前を正しく変更されるようにするには、ニックネーム属性が命名属性と異なっている必要があります。この2つを分けておくことにより、Oracle Internet Directory内のユーザーのエントリの識別名は、ニックネーム属性の値が変わっても変更されません。
|
関連項目: Oracle Fusion Middleware Oracle Identity Managementスタート・ガイド |
Oracle Portal Configuration Assistant (OPCA)を実行するには、このツールで各種操作を実行するための権限が必要です。ユーザーがptlasstを実行したときに、証明書に-ldap_d 'cn=orcladmin' -w orcladmin_pwdを指定すると、それはOracle Internet DirectoryのスーパーユーザーのIDとみなされ、すべての操作を実行できるようになります。一方、cn=orcladmin以外のユーザーがptlasstを実行する必要がある場合、操作を正常に実行するためには、そのユーザーに明示的に権限を付与する必要があります。
Oracle Fusion Middlewareのエンタープライズ・デプロイメントでは、中央のOracle Identity Managementインフラストラクチャ(Oracle Internet DirectoryやOracle Application Server Single Sign-Onなど)の保守と管理を中央のデータ・センターで担当していることがあります。企業内の部署でOracle Portalをインストールし、それを中央のインフラストラクチャに関連付ける必要がある場合、その部署の管理者にOracle Identity Managementインフラストラクチャの管理者がcn=orcladminパスワードを渡し、Oracle Portalをインストールできるようにすることは望ましい方法ではありません。このような場合は、Oracle Identity Management管理者が特定の権限をOracle Portal管理者に付与し、Oracle Portalを構成できるようにすることが可能です。構成後に、その権限を取り消すことができます。
Oracle Portalインストーラのロールを定義し、それを特定のユーザーに割り当てるには、次の手順を実行します。
このような目的のために、LDIF置換ファイル(.sbs)が用意されています。このファイルを使用すると、グループを作成したうえで、Oracle Portalの構成に必要な権限を継承できるように、そのグループを適切な権限グループに追加できます。
このファイルは次の場所にあります。
ORACLE_HOME/portal/admin/plsql/wwc/secadmin.sbs
ldifmigratorを使用してこのファイルを実行し、キーワードを置き換えてファイルを適切なLDIFファイルに変換する必要があります。
ldifmigrator 'input_file=secadmin.sbs' 'output_file=secadmin.ldif' -lookup 'host=oidhost' 'port=oidport' 'DN=cn=orcladmin' 'password=orcladmin_pwd'
このコマンドにより、secadmin.ldifというファイルが作成されます。これをOracle Internet Directoryサーバーにロードして、Oracle Portalインストーラで必要なロールをインストールできます。
ldapmodify -h <oidhost> -p <oidport> -D cn=orcladmin -w orcladmin_pwd -v -c -f secadmin.ldif
secadmin.ldifファイルをOracle Internet Directoryにロードすると、Oracle Delegated Administration Servicesの「ユーザーの作成」ページや「ユーザーの編集」ページで、新しく作成されたロールを使用できるようになります。ユーザーにこのロールを付与するには、orcladminとしてログインする必要があります。orcladminユーザーのみが、このロールを他のユーザーに付与できます。
Oracle Delegated Administration Servicesにログオンして、Oracle Portalをインストールする機能の付与先とするユーザーのエントリを見つけます。そのユーザーのエントリを編集して、Oracle Portalインストーラのロールを有効にします。これで、このユーザーはOracle Portalを構成できるようになります。
|
注意: ディレクトリに大量のグループが存在する場合は、Oracle Portalインストーラ用のこのロールを定義するだけでなく、ディレクトリ・サーバーの問合せエントリの返送制限を適切に設定し、Oracle Portalの構成で問い合せたときにすべての該当グループの情報が返るようにしておく必要があります。この制限は、ディレクトリのルート・エントリの ldapmodifyコマンドライン・ユーティリティで使用できるサンプルLDIFファイルは、次のとおりです。
また、Oracle Directory Managerから問合せエントリの返送制限を設定することもできます。この属性はサーバー・エントリに対して表示されます。 |
Oracle Portalの構成が終了した後、構成を実施したユーザーのエントリを再編集して権限を削除できます。初期構成が完了すればこの権限は不要になります。
この項では、Oracle Portalの構成上の考慮事項について説明します。
この項には次の項目が含まれています。
Oracle Portalをインストールし、第7.3.2.3項「インストール後のセキュリティのチェックリスト」にある適切なタスクを実行すると、Oracle Portalの「グローバル設定」ページでセキュリティに関連する次のすべての設定を変更できます。
第7.1.7項「Oracle Identity Managementインフラストラクチャの利用」で説明したように、Oracle Portalではディレクトリからの情報のキャッシュを管理しています。「グローバル設定」ページで、このキャッシュをディレクトリからの更新済の情報で更新することができます。「OIDパラメータ用キャッシュのリフレッシュ」では、ディレクトリからの最新のパラメータ値でキャッシュがただちに更新されます。キャッシュされた情報は比較的静的な情報であるため、キャッシュを頻繁に更新する必要はありません。
Oracle Portalではグループ・メンバーシップの情報をキャッシュするため、ディレクトリでその情報が変更されたらキャッシュが更新されるメカニズムを必要とします。Directory Integration Serverでは、Oracle Portalに反映する必要がある変更がディレクトリで行われるたびにOracle Portalに通知します。「グローバル設定」では、次の設定を行うことができます。
「ディレクトリ同期の有効化」: 関連する変更がディレクトリで行われたときにDirectory Integration ServerがOracle Portalに通知するかどうかを定義します。この設定を選択しないと、Directory Integration ServerによってサブスクライブされたイベントがOracle Portalに通知されません。Oracle Portalの構成が適切であり、かつサポートされている場合には、このオプションを有効にする必要があります。
「イベント通知の送信頻度n秒」: 関連する変更をOracle Portalに通知するためにDirectory Integration Serverによってイベント通知が送信される時間間隔を定義します。この設定は、「ディレクトリ同期の有効化」が選択されている場合にのみ利用できます。
次の設定により、ログイン・パフォーマンスに対応して、グループのプロビジョニング変更の影響がユーザーの認可に反映されるまでの時間を指定できます。
ロール・メンバーの遅延同期を有効にする
ユーザーのグループ・メンバーシップがポータルで更新されるのは、Oracle Internet Directoryでのグループ・メンバーシップの変更後のログインとその次のログインのみです。認可の変更は、次のログインで反映されます。ログイン・イベント間にユーザーのグループの更新が行われなかった場合、その後のログインでは、いずれかのユーザーのグループに対して変更が行われるまで、ユーザーのグループに対して再び問合せが行われることはありません。
ロール・メンバーの即時同期を有効にする
ユーザーのグループ・メンバーシップはログインごとに更新されます。また、グループの更新通知をOracle Internet DirectoryからPortalが受信したときにも更新されます。このモードは、Oracle Internet Directoryの更新後すぐに認可の更新を適用する必要がある場合(考えられるのは、現在のセッション内でユーザーの認可を変更する場合)にのみ設定することをお薦めします。
ログインのたびにロール・メンバーの同期を有効にする
ユーザーのグループ・メンバーシップは、ログインごとにポータルで更新され、グループがOracle Internet Directoryで更新された次のログインで有効になります。
ユーザーのグループ・メンバーシップは、ログインごとにポータルで、そのセッションの間、有効なグループ・メンバーシップの更新セットを反映して更新されます。Oracle Internet Directoryに対して、必要か不要かに関係なく、ログインごとにグループ・メンバーシップの現在のセットを問い合せます。なんらかの理由により、ユーザーのグループ・メンバーシップがPortalに正しく反映されない場合は、ログインごとに正しいセットを使用して再確立が行われます。
表7-18では、ログイン・パフォーマンスと、各設定でユーザーの認可が更新される速度のトレードオフを比較しています。
表7-20 同期設定の比較
| 設定 | 説明 |
|---|---|
|
遅延同期 |
ベスト・パフォーマンス - このユーザーに影響を与えるグループ・メンバーシップ変更が行われた後にのみログインが遅くなります。 |
|
即時同期 |
この設定は、パフォーマンスに対する影響が最大になります。グループ同期化の更新がユーザーのセッション内で行われることがあり、また更新はログインごとに行われ、最も迅速な効果が得られるために、DIPの同期化間隔とWebキャッシュの弱い無効化間隔をかなり低く設定する必要があるので、これらのイベントの頻度が増加するからです。 |
|
ログインごとの同期化 |
ベースライン・パフォーマンス - 以前のリリースと整合性があります。 |
Oracle Directory Integration and Provisioningサーバーが稼働していて、Oracle Portalを使用できるように構成されているときは、Oracle Internet Directoryでグループ・メンバーシップが変更されると、Oracle Portalで弱いキャッシュの無効化が行われます。
次に、グループ・メンバーシップのキャッシュの無効化の例を示します。
ユーザーをグループに追加すると、Oracle Directory Integration and Provisioningサーバーではその変更をOracle Portalに通知します。そうするとOracle Portalでは、弱い無効化ジョブによって処理される弱い無効化メッセージを1つ発行します。これは、このユーザーが持っている新しい権限が、表示できるデータに影響を与える可能性があるからです。
グループ_Aをグループ_Bに追加すると、Oracle Directory Integration and Provisioningサーバーではその変更をOracle Portalに通知します。そうするとOracle Portalでは、グループ_Aの各ユーザーに弱い無効化メッセージを発行します。これは、グループ_Aのユーザーが持っている新しい権限が、表示できるデータに影響を与える可能性があるからです。
Oracle Portalでは、ディレクトリ内のユーザー・グループの情報を管理しています。「グループ」ポートレットを使用してグループを作成すると、それらはLDAPのディレクトリ情報ツリー(DIT)のノードの下に作成されます。ノードは、その識別名(DN)によって識別されます。このため、Oracle Portalでは、どのノードにグループを作成するかを指定する必要があります。
「グループ作成ベースDN」は、Oracle Portalで管理するユーザー・グループが含まれているノードのDNです。例:
cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com
この設定は、Oracle Portalを既存のDITと対話するように構成する場合に特に役立ちます。
どのノードにグループを作成するのかを定義する必要があるのと同様に、Oracle Portalでどのノードで既存のグループを検索するのかも定義する必要があります。たとえば、「グループ」ポートレットにグループの値リストが表示されているときにOracle Portalでどこを検索するのかを指定する必要があります。
「ローカル・グループ検索ベースDN」は、Oracle Portalで管理するユーザー・グループが含まれているノードのDNです。例:
cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com
この設定は、Oracle Portalを既存のDITと対話するように構成する場合に特に役立ちます。
Oracle Portal 10g リリース2 (10.1.2)以降では、ロール・ベースのアクセス制御の適用を有効化または無効化できます。このオプションは、デフォルト構成では無効です。ロール・ベースのアクセス制御では、オブジェクト・レベルの権限やグローバル権限を、Oracle Portalのユーザー・インタフェースからユーザーに直接割り当てることを禁止し、グループにのみ権限を付与するように強制できます。ただし、このオプションは、ユーザーに直接付与される次のような権限には影響しません。
ロール・ベースのアクセス制御が有効になる前の権限
オブジェクトの作成時に自動で付与される権限
Oracle Portal APIの使用を通じて付与される権限
ロール・ベースのアクセス制御の有効と無効を切り替えるには、ORACLE_HOME/portal/admin/plsql/wwcディレクトリのsecrlacl.sqlスクリプトを実行する必要があります。secrlacl.sqlの構文は、次のとおりです。
@secrlacl.sql Y|N
たとえば、ロール・ベースのアクセス制御を有効にする場合、次のようにスクリプトを実行します。
@secrlacl.sql Y
ロール・ベースのアクセス制御が有効になると、Oracle Portalが次のように変化します。
オブジェクトの「アクセス」タブ。ここには、グループのLOVのみが表示され、ユーザーのLOVは表示されません。
「権限」タブは、ユーザー・プロファイルの編集ページに表示されません。
HMAC対応の通信を行うプロバイダ・サービスには、追加の構成が必要です。Basic認証または拡張認証を設定できます。
JPDKプロバイダ・コードがoracle.portal.provider.v2.render.PortletRenderRequestオブジェクトのoracle.portal.provider.v2.ProviderUserを経由してポータル・ユーザーのIDを受け入れ、このIDを使用して機密情報を取り扱う操作を実行する場合は、Basicメッセージ認証を使用するようにポータルとこのプロバイダを構成する必要があります。Basicメッセージ認証ではHashed Message Authentication Code(HMAC)を利用します。HMACは、暗号化ハッシュ関数を使用してメッセージ認証を行い、メッセージの整合性を保証するメカニズムです。
HMACを使用したBasic認証を構成するには、JPDK WebプロバイダとOracle Portalの両方を次のように構成する必要があります。
JPDK Webプロバイダ
JPDK Webプロバイダでは、WebプロバイダのJNDI環境変数として、共有キーをweb.xmlファイルに追加します。web.xmlの中でこの環境エントリを追加する場所は、ファイル末尾近くにある、表7-21に太字で示されている場所です。この表は、web.xmlの中で各要素が占める相対的な順序を示しています。
表7-21 web.xml内の要素の相対順
| 要素名 |
|---|
|
icon? |
|
display-name? |
|
description? |
|
distributable? |
|
context-param* |
|
filter* |
|
filter-mapping* |
|
listener* |
|
servlet* |
|
servlet-mapping* |
|
session-config? |
|
mime-mapping* |
|
welcome-file-list? |
|
error-page* |
|
taglib* |
|
resource-env-ref* |
|
resource-ref* |
|
security-constraint* |
|
login-config? |
|
security-role* |
|
env-entry* |
|
ejb-ref* |
|
ejb-local-ref* |
JNDI環境変数の定義をweb.xmlファイルに追加するには、次のenv-entry要素を適切な場所に追加します。
<env-entry> <env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name> <env-entry-value>shared_key_value</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry>
例7-2に示すように、サービス名と共有キーの値を入力します。
例7-2 web.xmlへのJNDI環境変数の定義の追加
<env-entry> <env-entry-name>oracle/portal/provider/sample/sharedKey</env-entry-name> <env-entry-value>1234567890abcdeFGHIJ</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry>
この例では、sampleはプロバイダのサービス名、1234567890abcdeFGHIJは共有キーの値です。HMACの計算に使用する共有秘密鍵の値には、10から20文字の英数字を指定する必要があります。
例7-3に示すように、保護するプロバイダ・インスタンスごとに、この環境変数を定義する必要があります。
例7-3 web.xmlでの複数プロバイダ・インスタンスに対するJNDI環境変数の定義
<env-entry> <env-entry-name>oracle/portal/provider/provider0/sharedKey</env-entry-name> <env-entry-value>1234567890abcdeFGHIJ</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry> <env-entry> <env-entry-name>oracle/portal/provider/provider1/sharedKey</env-entry-name> <env-entry-value>0987654321abcdeFGHIJ</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry> <env-entry> <env-entry-name>oracle/portal/provider/provider2/sharedKey</env-entry-name> <env-entry-value>123123123123</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry>
または、プロバイダのプロパティsharedKeyを.propertiesファイルに追加することもできます。これを行うには、次の手順を実行します:
ファイル<app_root>/WEB-INF/deployment/service_name.propertiesを開きます。(service_nameはプロバイダのサービス・インスタンス名に置き換えてください。)
次の例に示すように、プロバイダのプロパティsharedKeyと共有キーの値を追加します。
sharedKey=1234567890abcdeFGHIJ
このプロパティは、各service_name.propertiesファイルで、保護するプロバイダ・インスタンスごとに設定する必要があります。
|
注意: この代替手法の短所として、JNDI環境エントリではプロバイダの環境変数を管理できるにもかかわらず、Oracle Fusion Middleware Controlを使用するとこれらの環境変数を管理できないという点があります。 |
Oracle Portal
次の手順を実行して、Oracle Portalでプロバイダを登録し、共有キーとログイン周期を設定します。
JPDK Webプロバイダ・コードがJAZN-LDAP用に構成されているWLSコンテナで実行されており、プロバイダ・コードがJ2EEセキュリティを使用しているか、HttpServletRequestオブジェクトのgetRemoteUser()メソッドまたはgetUserPrincipal()メソッドを経由してユーザーのIDを取得する場合は、拡張メッセージ認証を使用するようにポータルとこのプロバイダを構成する必要があります。また、『Oracle Fusion Middleware Oracle Portal開発者ガイド』に説明されているように、プロバイダでLDAP (Oracle Internet Directory)セキュリティ機能を使用している場合にも拡張メッセージ認証を構成する必要があります。拡張メッセージ認証では、認証されたユーザーIDをプロバイダに伝播するための追加のヘッダーの整合性が保護されます。
HMACを使用した拡張認証を構成するには、JPDK WebプロバイダとOracle Portalの両方を構成する必要があります。
JPDK Webプロバイダ
JPDK Webプロバイダを構成するには、次の手順を実行します。
JPDK Webプロバイダでは、WebプロバイダのJNDI環境変数として、共有キーをweb.xmlファイルに追加します。web.xmlの中でこの環境エントリを追加する場所は、表7-21に示す、ファイルの末尾近くです。この表は、web.xml内で各要素が占める相対的な順序を示しています。
JNDI環境変数の定義をweb.xmlファイルに追加するには、次のenv-entry要素を適切な場所に追加します。
<env-entry> <env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name> <env-entry-value>shared_key_value</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry>
例7-2に示すように、サービス名と共有キーの値を入力します。
例7-2では、sampleがプロバイダのサービス名、1234567890abcdeFGHIJが共有キーの値です。HMACの計算に使用する共有秘密鍵の値には、10から20文字の英数字を指定する必要があります。
例7-3に示すように、保護するプロバイダ・インスタンスごとに、この環境変数を定義する必要があります。
または、プロバイダのプロパティsharedKeyを.propertiesファイルに追加することもできます。これを行うには、次の手順を実行します:
ファイル<app_root>/WEB-INF/deployment/service_name.propertiesを開きます。(service_nameはプロバイダのサービス・インスタンス名に置き換えてください。)
次の例に示すように、プロバイダのプロパティsharedKeyと共有キーの値を追加します。
sharedKey=1234567890abcdeFGHIJ
このプロパティは、各service_name.propertiesファイルで、保護するプロバイダ・インスタンスごとに設定する必要があります。
|
注意: この代替手法の短所として、JNDI環境エントリではプロバイダの環境変数を管理できるにもかかわらず、Oracle Fusion Middleware Controlを使用するとこれらの環境変数を管理できないという点があります。 |
プロバイダのプロパティenhancedAuthenticationを.propertiesファイルに追加します。これを行うには、次の手順を実行します:
ファイル<app_root>/WEB-INF/deployment/service_name.propertiesを開きます。(service_nameはプロバイダのサービス・インスタンス名に置き換えてください。)
次の例に示すように、プロバイダのプロパティenhancedAuthenticationを追加してtrueに設定します。
enhancedAuthentication=true
このプロパティは、各service_name.propertiesファイルで、保護するプロバイダ・インスタンスごとに設定する必要があります。
Oracle Portal
次の手順を実行して、Oracle Portalでプロバイダを登録し、共有キーとログイン周期を設定します。
Oracle Portalを構成するときは、Oracle Fusion Middleware Security Frameworkを利用する次のオプションを考慮する必要があります。
次の項では、Oracle Portalの最も一般的なSSL構成の概要と、それらを実装するために必要な手順について説明します。
Oracle Portalでは、多くの様々なコンポーネント(Parallel Page Engine、Oracle HTTP Server、Oracle Web Cacheなど)を使用しますが、それらの各コンポーネントはHTTP通信でクライアントまたはサーバーの役目を果たすことがあります。このため、Oracle Fusion Middlewareの中間層にある各コンポーネントを、HTTPではなくHTTPSプロトコルで個別に構成する場合があります。
Oracle Portalとの対話処理では、様々なネットワーク・ホップを実行します。これらのホップは次のとおりです。
クライアント・ブラウザと、ポータル環境のエントリ・ポイントの間。次のいずれかです。
Oracle Web Cache
リバース・プロキシやSSLアクセラレータなどのネットワーク端のハードウェア・デバイス
Oracle Fusion Middleware中間層のOracle Web CacheとOracle HTTP Serverの間
クライアント・ブラウザと、OracleAS Single Sign-OnまたはOracle Internet Directory(またはインフラストラクチャ)層のOracle HTTP Serverの間
中間層のParallel Page Engine (PPE)とOracle Web Cacheまたはフロントエンドのリバース・プロキシの間のループバック
Parallel Page Engine (PPE)と、ポートレット・コンテンツを生成するリモートWebプロバイダの間
Oracle PortalインフラストラクチャとOracle Internet Directoryの間
SSL使用上の制限
部分的なSSL構成モードの場合、Parallel Page Engineの下では外部JavaServer Pagesが機能しません。それらは、Oracle Portal全体でSSLを使用している場合にのみ機能します。ロード・バランシング・ルーターを使用している環境でSSLを外部実装した場合は、内部JavaServer Pagesのみが機能します。
このことから、第7.3.2.1.2項「OracleAS Single Sign-OnとのSSL接続」、第7.3.2.1.5項「Oracle PortalのエンドツーエンドSSL」、および第7.3.2.1.6項「Oracle Fusion Middleware内では非SSLの外部SSL」で取り上げているSSL構成でのみ、外部JSPを使用するようにします。
ssl.confファイルのデフォルト設定を使用すると、HP-IA上で実行されるOracle Portalサーバーには、Microsoft Internet Explorerからアクセスできません。この問題を回避するには、次のようにしてssl.confファイルから行downgrade-1.0 force-response-1.0を削除します。
修正前
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
修正後
BrowserMatch ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown
SSLを構成する前の確認事項
推奨される方法に従ってSSLを構成する前に、デフォルトの非SSL構成で、Oracle Portalが正常に動作することを確認する必要があります。そのためには、次のポータル・タスクを正常に実行できるかどうかを確認します。
Oracle Portalのホーム・ページにアクセスできる
ユーザーはOracle Portalにログインできる
コンテンツの編集が即座に表示される
接続をSSLで保護する必要があるとすれば、それはブラウザとOracleAS Single Sign-Onの間の接続です。ブラウザとOracleAS Single Sign-Onの間での送信中は、SSLによってパスワードが保護される必要があります。最低レベルのセキュリティでも、このオプションを使用してインストールを構成する必要があります。この後のすべてのSSLの構成では、SSLがOracleAS Single Sign-Onに対応するように構成されているものとします。
図7-19は、SSLを使用できるように構成されたOracleAS Single Sign-Onを示しています。
「SSLを構成する前の確認事項」で示した事項を確認したら、次のいずれかの手順を使用してOracleAS Single Sign-OnとのSSL接続を構成できます。
SSLConfigToolを使用したOracleAS Single Sign-OnのSSL構成
|
注意: このOracleAS Single Sign-On中間層パートナ・アプリケーションはまだ非SSLなので、非SSLとして再登録する必要があります。つまり、mod_ossoを再登録するときには、 詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のmod_ossoの登録に関する項を参照してください。 |
SSLConfigToolを使用してOracleAS Single Sign-OnにSSLを構成するには、次の手順を実行します。
Oracle Fusion Middleware InfrastructureでSSLConfigToolスクリプトを実行します。
Identity ManagementがインストールされているOracleAS InfrastructureでSSLを有効にします。次のWindowsの例に示すように、インフラストラクチャのOracleホームでSSLConfigToolを実行します。
SSLConfigTool.bat -config_w_default -opwd <fmwadmin_pwd>
説明:
config_w_defaultは、portlist.iniファイルに指定された値を使用して、ツールをサイレント・モードで実行します。
opwdはOracle管理者パスワードです。パスワードを指定しないと指定を求められます。
|
関連項目: Oracle Fusion Middleware管理者ガイド 『Oracle Application Server Single Sign-On管理者ガイド』のSSLの有効化に関する説明。リバース・プロキシ・サーバーの内側でOracleAS Single Sign-Onを構成する場合は、『Oracle Application Server Single Sign-On管理者ガイド』のプロキシ・サーバーと組み合せたOracleAS Single Sign-Onの配置に関する説明を参照してください。 |
Identity ManagementがインストールされているOracleAS InfrastructureでSSLを有効にした場合、OracleAS Single Sign-On URLを保護する必要があります。これを行うには、『Oracle Application Server Single Sign-On管理者ガイド』のシングル・サインオンURLの保護に関する項を参照してください。
ウォレットを作成します。詳細は、「空のウォレットの作成(HTTPS)」を参照してください。
OracleAS Single Sign-Onの証明書の発行者が、「信頼できる証明書」リストに存在することを確認します。このリストにない場合は、「ウォレットへの信頼できるルート証明書の追加(HTTPS)」に示すように、信頼できるルート証明書をウォレットに追加する必要があります。
「Portalリポジトリのプリファレンス・ストアでのウォレットのパスとパスワードの更新」の説明に従ってウォレットのパスとパスワードを更新します。
「Oracle HTTP Serverパートナ・アプリケーションの再登録」の説明に従ってOracle HTTP Serverを再登録します。
Oracle Internet Directoryで、cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContextエントリのorcldasurlbase属性の更新が必要になる場合があります。HTTPSポートを使用するように設定されていない場合は、Oracle Internet Directoryパラメータのキャッシュをリフレッシュする必要があります。更新するには、次の手順を実行します。
Oracle Directory Manager(統合管理ツール: Windowsの場合はOracle Directory Manager、UNIXの場合はINFRA_ORACLE_HOME/bin/oidadmin)を使用し、Oracle Directory Managerを実行して、cn=fmwadminとしてログインします。
「エントリ管理」で、cn=OracleContext→cn=Products→cn=DAS→cn=OperationURLsに移動します。
orcldasurlbaseエントリに、インフラストラクチャ層で使用されているHTTPSポート(https://<infrahost>:<port>/)が反映されているかどうかを確認します。
orcldasurlbaseエントリにHTTPSポートが反映されていない場合は、それをOracle Internet Directoryで変更し、関連するOracle Internet Directory情報を格納したポータル・キャッシュをリフレッシュする必要があります。このポータル・キャッシュをリフレッシュするには、次の手順を実行します。
管理者権限を持つユーザーとしてOracle Portalにログオンします。
「Portalビルダー」ページで「管理」タブをクリックします。
「ポータル」タブから、「グローバル設定」を開き、「SSO/OID」タブに移動します。
ページの一番下までスクロールします。
「OIDパラメータのキャッシュ」で「OIDパラメータ用キャッシュのリフレッシュ」を選択します。
「適用」をクリックします。
「DASホスト名」フィールドの適切な値でページが更新されます。
これで、OracleAS Single Sign-OnとのSSL通信の構成が完了しました。
|
注意: ページに正しいSSO URLを表示するため、Portal modplsqlキャッシュをクリアする必要があります。 次の例は、UNIX上でPortal modsqlをクリアする方法を示しています。 cd $INSTANCE_HOME/portal/cache rm –rf ./session/* rm -rf ./plsql/* rm -rf ./pmd/* |
WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化
次の手順を実行して、WebLogicプラグインを有効化します。
WebLogic管理コンソールにログインします。
「チェンジ・センター」ペインの「ロックして編集」を選択していない場合は選択します。
「ドメイン構造」ペインで、「環境」ノードを開き、「クラスタ」を選択します。
ドメインに構成されているクラスタのリストが表示されます。
cluster_portalをクリックします。
ページ下部近くの「詳細」リンクを開きます。
「WebLogicプラグインの有効化」オプションを選択します。
「保存」をクリックします。
次の例に示すように、ORACLE_INSTANCE/config/OHS/OHS Name/moduleconf/portal.confのWLS routing configurationセクションで、WLProxySSLPassThroughおよびWebLogic ProxySSLのパラメータをONに設定します。
# WLS routing configuration <Location /portal> SetHandler weblogic-handler WebLogicCluster <HostName>:<Weblogic portal ClusterPort> WLProxySSL On WLProxySSLPassThrough ON </Location>
Oracle WebLogic管理コンソールを使用して、WLS_PORTALを再起動します。
次のコマンドを使用して、Oracle HTTPを再起動します。
ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall
手動でのOracleAS Single Sign-OnのSSL構成
このオプションを手動で構成する場合は、『Oracle Application Server Single Sign-On管理者ガイド』のSSLの有効化に関する項を参照してください。リバース・プロキシ・サーバーの内側でOracleAS Single Sign-Onを構成する場合は、『Oracle Application Server Single Sign-On管理者ガイド』のプロキシ・サーバーと組み合せたOracleAS Single Sign-Onの配置に関する説明を参照してください。
|
注意: このOracleAS Single Sign-On中間層パートナ・アプリケーションはまだ非SSLなので、非SSLとして再登録する必要があります。つまり、mod_ossoを再登録するときには、 詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のmod_ossoの登録に関する項を参照してください。 |
Oracle Portalのこのリリースでは、OracleAS Single Sign-OnのURLへのアクセスでHTTPまたはHTTPSのどちらを使用するかを、ポータルを構成するときに選択できます。次の手順では、各構成に必要な手順を示します。
Oracle Internet DirectoryでのOracle Delegated Administration ServicesのURLベース・エントリの条件付き更新(HTTPおよびHTTPS)
空のウォレットの作成(HTTPS)
この項の手順は、OracleAS Single Sign-OnでHTTPSポートを使用する場合にのみ実行してください。この手順は、SSLを使用するようOracleAS Single Sign-Onを構成した後に実行します。
空のウォレットを作成して、OracleAS Single Sign-OnへのSSLアクセスのトラスト・ポイントを確立します。これを行うには、次の手順を実行します:
Oracle Wallet Manager(ORACLE_HOME\bin\owm)を開きます。生成したウォレットにOracle Metadata Repositoryのポータル・スキーマからアクセスできるかぎり、Oracle Wallet Managerはどこからでも実行できます。ウォレット(ウォレット・ファイルを格納したディレクトリ)を任意の場所に保存して、Oracle Metadata Repositoryのポータル・スキーマからアクセス可能な別の場所に移動することもできます。
「ウォレット」→「新規」を選択します。
UNIXの場合、ウォレットはデフォルトで次の場所に格納されます。
/etc/ORACLE/WALLETS/<Account Name creating the Wallet>
Windowsの場合、ウォレットはデフォルトで次の場所に格納されます。
\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS
ウォレットのパスワードを作成します。
同じパスワードを「パスワードの確認」フィールドに入力します。
「ウォレット・タイプ」に「標準」を選択します。
「OK」をクリックします。
証明書リクエストの作成を求められたら、「いいえ」をクリックします。
OracleAS Single Sign-Onの証明書の発行者が、「信頼できる証明書」リストに存在することを確認します。このリストにない場合は、「ウォレットへの信頼できるルート証明書の追加(HTTPS)」に示すように、信頼できるルート証明書をウォレットに追加する必要があります。
このウォレットを次のように、適切なディレクトリに保存します。
INFRA_ORACLE_HOME\wallets
「ウォレット」、「保存」の順に選択します。
「ウォレット」を選択し、「自動ログイン」を選択していない場合は選択します。
ウォレットへの信頼できるルート証明書の追加(HTTPS)
この項の手順は、認証局の発行したOracleAS Single Sign-Onサーバーの信頼できるルート証明書が「信頼できる証明書」リストに含まれていない場合にのみ実行してください。この場合は、次の手順に示すように信頼できるルート証明書をウォレットに追加する必要があります。この手順は、Internet Explorerブラウザに基づいています。
ブラウザを使用して、https://infra.domain.com/pls/orassoにあるOracleAS Single Sign-Onのホーム・ページにアクセスします。これがHTTPS URLにあることを確認します。
サーバーの証明書がブラウザによって自動的に信頼されない場合は、「セキュリティの警告」ダイアログ・ボックスが表示されます。
「証明書の表示」をクリックします。
「証明のパス」タブをクリックします。
リストの最初の証明書である証明機関のルートを選択します。
「証明書の表示」をクリックします。
「証明書のインストール」をクリックします。
これによって、「証明書のインポート ウィザード」が表示されます。ウィザードによって、ブラウザの信頼できる認証機関リストに証明書がインポートされます。
「次へ」をクリックします。
「証明書の種類に基づいて、自動的に証明書ストアを選択する」を選択します。
「次へ」をクリックします。
「終了」をクリックします。
信頼できるルート証明書がブラウザにインストールされます。
ステータス・バーのロック・アイコンをクリックすると、「証明書」ダイアログ・ボックスが表示されます。
「証明のパス」タブをクリックします。
リストの最初の証明書である証明機関のルートを選択します。
「証明書の表示」をクリックします。
「詳細」タブをクリックします。
「ファイルにコピー」をクリックします。
これによって、「証明書のエクスポート ウィザード」が表示されます。
「次へ」をクリックします。
「使用する形式を選択してください」で「Base 64 encoded X.509 (.CER)」を選択します。
「次へ」をクリックして、証明書のファイル名を指定します。証明書には、.cer拡張子を持つ任意のファイル名を指定できます。
「次へ」をクリックして、「完了」をクリックします。
この時点で、.cer証明書ファイルが作成されます。このファイルには、信頼できる証明機関のルート証明書が含まれています。この証明書を、ウォレットの信頼できる証明書リストに追加する必要があります。追加するには、Wallet Managerがすでに実行され、空のウォレットが開いている状態で次の手順を実行します。
「信頼できる証明書」ノードを右クリックします。
「信頼できる証明書のインポート」を選択します。
「証明書の貼付け」を選択し、「OK」をクリックします。
以前作成した証明書ファイルの内容をBASE64形式の証明書のテキスト領域にコピーし、「OK」をクリックします。
信頼できる証明書のリストに証明機関のルートが追加されていることを確認します。
ウォレットを保存します。
Portalリポジトリのプリファレンス・ストアでのウォレットのパスとパスワードの更新
この項の手順は、OracleAS Single Sign-OnでHTTPSポートを使用する場合にのみ実行してください。この手順は、SSLを使用するようOracleAS Single Sign-Onを構成した後に実行します。
Oracle Portal中間層ホームから次のスクリプトを使用して、Portalリポジトリのプリファレンス・ストアにあるウォレットのパスとパスワードを更新します。
cd $ORACLE_HOME/portal/admin/plsql/wwc sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location> <wallet_pwd>
Oracle HTTP Serverパートナ・アプリケーションの再登録 (HTTPおよびHTTPS)
ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binにあります。
次の例は、UNIX上でのssoregの使用方法を示しています。
ORACLE_HOME/sso/bin/ssoreg.sh -site_name www.abc.com -config_mod_osso TRUE -mod_osso_url http://www.abc.com:8090 -remote_midtier -config_fileORACLE_INSTANCE/conf/OHS/ohs1/osso.conf-admin_info cn=orcladmin
Windowsでは、このかわりにssoreg.batバッチ・ファイルを実行する必要があります。詳細は、Oracle Application Server Single Sign-On管理者ガイドを参照してください。
WebLogicプラグインの有効化(HTTPS)
「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。
ウォレットのパスとOracleAS Single Sign-Onの問合せパスURLの確認(HTTPおよびHTTPS)
Oracle Portalでは、データベースからコールを介して特定の情報にアクセスするためのOracleAS Single Sign-OnのURL接頭辞を、UTL_HTTPパッケージを使用して管理しています。このインタフェースを介して行われるコールは、次の理由で欠かすことができません。
外部アプリケーションのリストを取得して、「外部アプリケーション」ポートレットのカスタマイズができるようにします。
OracleAS Single Sign-Onのユーザー名を外部アプリケーションのユーザー名にマップします。
ウォレットのパスおよびOracleAS Single Sign-Onの問合せパスのURLを確認するには、次の手順を実行します。
ポータル管理者としてOracle Portalにログインします。
「管理」タブをクリックします。
「ポータル」タブをクリックします。
「サービス」ポートレットの「グローバル設定」をクリックします。
「SSO/OID」タブをクリックします。
「SSO Server設定」セクションに、適切な値が表示されます。
Oracle Internet DirectoryでのOracle Delegated Administration ServicesのURLベース・エントリの条件付き更新(HTTPおよびHTTPS)
OracleAS Single Sign-On上でSSLを有効にしたら、これ以降に認証をリクエストしたときに各パートナ・アプリケーションが更新済のSSLログインURLを取得できるように、すべてのOracleAS Single Sign-Onパートナ・アプリケーションを再登録する必要があります。
インフラストラクチャ層のOracle HTTP ServerのSSLを有効にしたら、インフラストラクチャ層のmod_ossoを含むすべてのパートナ・アプリケーションを再登録する必要があります。Oracle Delegated Administration Servicesにアクセスするときに、非SSLモードまたはSSLモードを選択できます。Oracle Delegated Administration ServicesのベースURLは、Oracle Internet Directoryに格納されます。このベースURLを基にして、他のアプリケーションからOracle Delegated Administration Services機能に接続するときに表示されるURLが決まります。
SSLモードでOracle Delegated Administration Servicesにアクセスする場合は、mod_ossoを再登録するときに、ssoregのmod_osso_urlパラメータとしてSSL URLを指定する必要があります。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のmod_ossoの登録に関する項を参照してください。
SSLモードでOracle Delegated Administration Servicesにアクセスする場合は、その設定を行うために、Oracle Internet Directory内のcn=OperationURLs, cn=DAS, cn=Products, cn=OracleContextエントリのorcldasurlbase属性を更新する必要があります。この属性値は、Oracle Portalによって、後続のOracle Delegated Administration ServicesのURLの生成に使用されます。この手順は、インフラストラクチャ層のOracle HTTP ServerもHTTPSポートでリスニングしていることを前提とします。
この手順では、Oracle Directory Manager(統合管理ツール: Windowsの場合はOracle Directory Manager、UNIXの場合はINFRA_ORACLE_HOME/bin/oidadmin)を使用する必要があります。Oracle Directory Managerを実行し、cn=orcladminとしてログインします。
「エントリ管理」で、cn=OracleContext→cn=Products→cn=DAS→cn=OperationURLsに移動します。
orcldasurlbaseエントリを更新して、HTTPSポート(https://<infrahost> :<port> /)がインフラストラクチャ層で使用されるように反映させます。
Oracle Internet Directoryでエントリを更新したら、ポータル・キャッシュを更新する必要があります。ここには、関連するOracle Internet Directory情報が格納されています。
管理者権限を持つユーザーとしてOracle Portalにログオンします。
「ビルダー」に移動します。
「管理」タブをクリックします。
「ポータル」タブから、「グローバル設定」を開き、「SSO/OID」タブに移動します。
ページの一番下までスクロールします。
「OIDパラメータ用キャッシュのリフレッシュ」を選択します。
「適用」をクリックします。
「DASホスト名」フィールドの適切な値でページが更新されます。
|
注意: SSOのSSLが有効で、Portal URLを介してアクセスするようにSSOを登録している場合、Oracle PortalからOIDを容易に操作できるように、「ポータル・グループ」設定ページでOIDの |
これで、OracleAS Single Sign-OnとのSSL通信の構成が完了しました。
|
注意: ページに正しいSSO URLを表示するため、Portal modplsqlキャッシュをクリアする必要があります。 次の例は、UNIX上でPortal modsqlをクリアする方法を示しています。 cd $INSTANCE_HOME/portal/cache rm –rf ./session/* rm -rf ./plsql/* rm -rf ./pmd/* |
Oracle Access Manager (OAM)を認証サーバーとして使用する場合は、Oracle Access Manager (OAM)とのSSL通信を有効にする必要があります。Oracle Access Manager (OAM)との通信を保護する方法の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』の安全な通信と証明書の管理に関する項を参照してください。
Oracle Single Sign-Onの通信を保護したら、次にOracle Portalの玄関口に相当するOracle Web Cacheとの通信を保護します。この構成では、Oracle Web Cacheは、パフォーマンスを向上させるために、HTTPを使用してリクエストをOracle HTTP Server (Oracle Portalの中間層の役目を果たす)に転送できます。同様に、Oracle Web Cacheにループバックされるポートレット・コンテンツに対するParallel Page Engineのリクエストでも、HTTPを使用してコンテンツをリクエストできます。
図7-20は、SSLを使用できるように構成されたOracle Web Cacheを示しています。
「SSLを構成する前の確認事項」で示した事項を確認したら、次のようにしてOracle Web Cacheに対するSSLを構成します。
|
注意: 前述のSSL構成では、Oracle Portal中間層パートナ・アプリケーションを再登録する必要があります。このOracleAS Single Sign-On中間層パートナ・アプリケーションはまだ非SSLなので、非SSLとして登録する必要があります。つまり、mod_ossoを再登録するときには、
|
OracleAS Single Sign-OnでのSSLの有効化
「手動でのOracleAS Single Sign-OnのSSL構成」の説明にある手順を実行して、OracleAS Single Sign-OnのSSLを有効にします。
Oracle Portalの各種コンポーネントでは、Oracle Wallet Managerを使用してセキュアな通信のための証明書を格納しています。このプロセスの最初の手順は、認証局(OracleAS Certificate Authority、Verisign社、GTE CyberTrust社など)から証明書を取得することです。
|
注意: OracleAS Single Sign-OnのSSLを有効にしている場合は、空のウォレットを作成する必要があります。この手順では、新しいウォレットを作成することをお薦めします。 |
証明書の取得 適切な署名機関からデジタル証明書を取得するには、サーバーを一意に識別する証明書リクエスト(CR)を署名機関に送信します。
中間層のORACLE_HOME/binにあるOracle Wallet Managerを開きます。UNIXの場合は、コマンド・プロンプトから「owm」と入力します。Windowsの場合は、「スタート」メニューからOracle Wallet Managerを起動します。
「ウォレット」→「新規」を選択します。
UNIXの場合、ウォレットはデフォルトで次の場所に格納されます。
/etc/ORACLE/WALLETS/<Account Name creating the Wallet>
Windowsの場合、ウォレットはデフォルトで次の場所に格納されます。
\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS
ウォレットのパスワードを作成して、「ウォレット・タイプ」として、「標準」(デフォルト値)またはPKCS1のいずれかのオプションを選択します。
「はい」をクリックして、CRを作成するオプションを受け入れます。
「証明書リクエスト」ダイアログに、サーバーを一意に識別する詳細を入力します。表7-22に、「証明書リクエスト」ダイアログの各種フィールドのサンプル値をいくつか示します。
「OK」をクリックします。証明書リクエストが正常に作成されたことを示すダイアログが表示されます。ウォレット・ナビゲータの「証明書」ノードが「Requested」に変わります。
このウォレットを次のように、適切なディレクトリに保存します。
ORACLE_HOME\webcache\wallets\portalssl
選択した認証局(CA)にCRを送信します。
切取りと貼付け
CAによっては、証明書リクエストを切り取ってWebページに貼り付けたり、引き続きサイトにアップロードできるようにCRをファイルにエクスポートしたりすることが必要な場合もあります。
ウォレット・ナビゲータの「証明書」ノードを選択します。
「証明書リクエスト」フィールドの証明書のテキストを強調表示します。BEGIN/END NEW CERTIFICATE REQUEST行が含まれていることを確認してください。
CAのWebサイトにある「証明書リクエスト」フィールドにコピーして貼り付けます。
証明書リクエストをエクスポートするには、次の手順を実行します。
「操作」→「証明書リクエストのエクスポート」を選択します。
CRファイルの名前と場所を選択します。CRのエクスポートが正常に行われたことを示すステータス行メッセージが表示されます。
エクスポートしたCRは、CAのWebサイトにアップロードできます。
信頼できる証明書の管理 CAによるリクエストの処理が終わると、ユーザー証明書が電子メールの本文、または指定のWebページからダウンロードするシンプル・ファイルとしてユーザーに転送されます。
|
注意: 試用版のルート証明書を使用している場合、またはOracle Wallet Managerに現在インストールされていないCAを選択した場合は、まずCAの信頼できる証明書をインポートしてから、サーバー固有のユーザー証明書をインポートしてください。 |
信頼できる証明書をインポートするには、次の手順を実行します。
「操作」→「信頼できる証明書のインポート」を選択します。
CAに基づいて、「証明書の貼付け」または「証明書を含むファイルを選択」を選択します。
適切な証明書ファイルを選択するか、電子メールの本文を貼り付けます。Oracle Wallet Managerでは、BASE64でエンコードされたルート証明書を想定しています。BASE64でエンコードされたルート証明書がない場合は、「信頼できる証明書の書式の変更(必要な場合)」で説明する手順を実行する必要があります。
「OK」をクリックします。
証明書が正常にインポートされたことを示すステータス行メッセージが表示されます。サーバー固有のユーザー証明書をインポートすると、ツリー構造内の証明書ノードにも「待機中」と表示されます。
証明書のインポートに失敗した場合は、その証明書の書式がOracle Wallet Managerでサポートされていない可能性があります。この場合は、その証明書をサポートされている書式に変換してからインポートする必要があります。これを最も簡単に行うには、ブラウザ内にある証明書のインポート/エクスポート・ウィザードを使用します。次の手順は、Internet Explorerのブラウザを使用した場合です。
Internet Explorerで、「ツール」→「インターネット オプション」を選択します。
「コンテンツ」タブをクリックします。
「証明書」をクリックします。
「信頼されたルート証明機関」タブをクリックします。
「インポート...」を選択し、ウィザードに従って証明書をインポートします。
新しくインポートされた証明書をリストで強調表示します。
「エクスポート...」をクリックし、ウィザードに従って「エクスポート ファイルの形式」ページに進みます。
「Base 64 encoded X.509」を選択します。
「次へ」をクリックして、証明書のファイル名を入力します。
「次へ」をクリックします。
「終了」をクリックします。
Oracle Wallet Managerで、「操作」→「信頼できる証明書のインポート」を選択します。
信頼できるルート証明書がOracle Wallet Managerに正常にインポートされたら、サーバー固有のユーザー証明書をインポートすることができます。
サーバーのユーザー証明書をインポートするには、次の手順を実行します。
「操作」→「ユーザー証明書のインポート」を選択します。
CAに基づいて、「証明書の貼付け」または「証明書を含むファイルを選択」を選択します。
適切な証明書ファイルを選択するか、電子メールの本文を貼り付けます。
「OK」をクリックします。
ユーザー証明書が正常にインポートされたことを示すステータス行メッセージが表示されます。
証明書のインポートが終了したら、自動ログイン機能を有効にしてWalletを保存することが重要です。この手順が必要なのは、プロセスが開始されてOracle Web Cacheがウォレットにアクセスしても、ウォレットのパスワードはOracle Web Cacheによって保持されないためです。このプロパティが設定されていないと、Oracle Web CacheをSSLモードで実行した場合にすぐにシャットダウンします。このプロパティを設定するには、次の手順を実行します。
「ウォレット」→「保存」を選択します。
「ウォレット」→「自動ログイン」をまだ選択していない場合は選択します。
Oracle Web Cacheの保護
次の項では、Oracle Web CacheがSSL接続を許可するように構成する方法について説明します。
Oracle Web CacheのSSLポートを構成するには、次の手順を実行します。
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』で説明しているように、Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。
「Webキャッシュ」メニューから「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。
「作成」をクリックします。
「ポートの作成」ページで次の情報を入力します。
ポート・タイプ: NORM
IPアドレス: ANY
Port Number: Web CacheがリスニングするSSLポート
「OK」をクリックします。
SSLポートを追加するには、前述の手順で作成したポートを選択して「編集...」をクリックし、「SSL構成」セクションで次の情報を入力します。
SSLの有効化: チェック・ボックスを選択します。
サーバー・ウォレット名: SSLサーバー証明書を収めたウォレットを選択します。
「OK」をクリックします。
「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。
前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
デフォルトではSSLは構成されていないので、Oracle Web CacheがキャッシュするSSLベースのサイトの定義を追加する必要があります。サイト定義を追加するには、次の手順を実行します。
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、Oracle Enterprise Manager 11g Fusion Middleware ControlのWeb Cacheホーム・ページに移動します。
「Webキャッシュ」メニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。
「サイト」で「作成」をクリックします。
「サイトの作成」ページで次の詳細情報を入力します。
ブラウザに表示するホスト名を「ホスト」に入力します。
ロード・バランシング・ルーターまたはリバース・プロキシを使用する構成の場合は、ロード・バランシング・ルーターまたはリバース・プロキシ・サーバーの名前になります。Oracle Web Cacheがブラウザ・リクエストを受け取る構成の場合は、Oracle Web Cacheのホスト名になります。
ブラウザ・リクエストに指定されているHTTPSポートを「Port」に設定します。
「URL接頭辞」は空白のままにします。
「デフォルト・サイト」チェック・ボックスを選択します。
「圧縮」チェック・ボックスを選択解除します。
「OK」をクリックします。
「適用」をクリックします。
デフォルトのアウト・オブ・ボックスの非SSLサイトなど、変更後の構成では使用できなくなるすべてのサイトを削除します。
前述の手順の詳細は、次を参照してください。
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のキャッシュ用のHTTPSリクエストのサイト作成に関する項
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のサイト定義の作成に関する項
いくつかの異なるホスト名またはポート、あるいはその両方にコンテンツがキャッシュされているときに、それらが実際には同じ論理コンテンツを参照している場合には、サイトの別名が必要になります。たとえば、PPEがあるポートレットのリクエストを作成したときに、このポートレットが非SSLポート上でリクエストされているが、メイン・サイトがSSLモードでアクセスされる場合には、別名のエントリが必要になります。これにより、SSLを使用するサイトからアクセスされるコンテンツと非SSLモードでアクセスされるコンテンツが、等しいとみなされます。このようにした場合には、そのコンテンツを無効化するために無効化リクエストを送信すると、どちらのモードのURLでキャッシュされている場合でもコンテンツが無効化されます。
このOracle Web Cache SSLサイトについて、非SSL Oracle Web Cacheリスニング・ポート用の別名を作成する必要があります。サイトの別名を作成するには、次の手順を実行します。
新しく追加したサイトを「サイト」ページで選択して「編集」をクリックします。
「別名」セクションで、「作成」をクリックして新しい別名を作成してから、このサイトを入力したときに使用したホスト名を入力し、PPEがOracle Web Cacheからポートレットをリクエストするときに使用する非SSLポートを指定します。
「OK」をクリックします。
「適用」をクリックします。
必要な追加を行ってからサーバーを再起動します。
たとえば、URL、https://portal.mycompany.com:4443を使用して論理サイト名にアクセスするとき、Oracle Web Cacheの非SSLリスニング・ポートが8090の場合、SSLポート4443のサイトを選択してOracle Web Cacheの非SSLポート(8090)を使用して別名を追加します。
前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のサイト定義の作成に関する項を参照してください。
新しいサイトのサイト・サーバー間マッピングのオリジン・サーバーへの追加
新しいサイト定義を追加した後、そのサイトのサイト・サーバー間マッピングをオリジン・サーバーに追加する必要があります。これを行うには、次の手順を実行します。
「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。
「サイト・サーバー間マッピングの作成」セクションで、マッピングするサイトの情報を入力します。このサイトには、SSLポートを使用するOracle Web Cacheサイトを指定する必要があります。たとえば、論理サイト名がhttps://portal.mycompany.com:4443の場合は、ホスト・パターンがportal.mycompany.comで、ポート・パターンが4443のサイトを選択します。
「オリジン・サーバー」セクションで、コンテンツのリクエストのルーティング先とする非SSLのオリジン・サーバーを選択し、それを「すべてのオリジン・サーバー」から「選択したオリジン・サーバー」のリストに移動します。たとえば、ホストportal.mycompany.comのポート8888でオリジン・サーバーを実行している場合は、portal.mycompany.com:8888を選択します。
「OK」を選択してダイアログ・ボックスを閉じると、元のページに表7-23「サイト・サーバー間マッピング」のような新しいマッピングが表示されます。
「変更の適用」をクリックします。
「適用」をクリックします。
Oracle Web Cacheを再起動します。
前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。
セッション・バインドの有効化
Oracle Web Cacheのセッション・バインド機能は、ユーザー・セッションを特定のオリジン・サーバーにバインドして、状態を一定の期間保持するために使用されます。デフォルトのOracle Portal中間層で実行するほとんどのコンポーネントはステートレスですが、セッション・バインドが必要です。
Oracle Web Cacheでポータル・ユーザー・セッションをOracle Portal中間層にバインドするには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware Controlで、Web Cacheホーム・ページに移動します。
「Webキャッシュ」メニューから、「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。
前述の手順で作成したサイトを選択します。
「セッション・バインディング構成」セクションで「Set-Cookieを使用したCookieに基づくセッション・バインディング」を選択します。
「適用」をクリックします。
詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
オリジン・サーバー・ウォレットへのウォレットのパスの追加
「オリジン・サーバー・ウォレット」ページにウォレットのパスを入力するには、次の手順を実行します。
Oracle Web Cache管理ページ(http://www.abc.com:<webcache_admin_port>/webcacheadmin)の「オリジン・サーバー」、「サイト」および「ロード・バランシング」でオリジン・サーバー・ウォレットをクリックします。
|
注意:
|
「キャッシュ名」のオプションを選択して、ウォレットのパスを変更します。
「選択対象の編集」をクリックして、オリジン・サーバー・ウォレットの編集ダイアログ・ボックスを表示します。
有効なウォレット・ディレクトリを入力します。たとえば、「リスニング・ポート」ページで指定したウォレット・ディレクトリ・パスを使用します。
「Submit」をクリックしてダイアログ・ウィンドウを閉じます。「オリジン・サーバー・ウォレット」ページの表に、新しいウォレットのディレクトリ・パスが表示されます。
|
注意: Oracle Web Cacheをセキュリティで保護するすべての手順を実行したら、変更を有効にするため、Oracle Fusion Middleware Controlを使用してOracle Web Cacheサーバーを再起動する必要があります。 |
Parallel Page Engineの構成
この構成では、ポートレットをリクエストするときにHTTPリクエストを使用するように、PPEを構成する必要があります。次の項では、この目的のために部分的SSL PPE構成を実装する方法について説明します。 PPEを構成するには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。
Oracle Portalホーム・ページの「ポータル」メニューから、「設定」→「ページ・エンジン」を選択します。
「ページ・エンジン構成」ページが表示されます。
「拡張プロパティ」セクションで、次のパラメータを追加します。
ポートの使用: 8090
スキームの使用: http
HTTPSポート: 4443
(オプション) PPEが特定の証明書のみを信頼するようにする必要がある場合は、「拡張プロパティ」セクションの「509証明書ファイル」フィールドにx509certfileを追加します。x509certfileの値は、「信頼できる」サーバーのグループを定義する証明書のリストが記載されたテキスト・ファイルへの絶対パスです。
|
注意: x509certfileを実装しないと、PPEではすべてのSSL証明書を信頼します。 |
「適用」をクリックします。
管理対象サーバー(WLS_PORTAL)を再起動します。
HTTPサーバーの構成
仮想ホストの定義を追加します。PortalがWeb CacheのSSLポートを使用して動作する場合、この構成でホスト名とポートの自己参照URLを指定します。httpd.confファイルで、仮想ホストについて次の詳細情報を追加します。
Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。
「Web層」を開いて、Oracle PortalインスタンスのOracle HTTP Server (ohs1)リンクをクリックします。
Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。
「サーバーの詳細構成」ページの「ファイルの選択」オプションで「httpd.conf」を選択して、「実行」をクリックします。
httpd.confファイルで、仮想ホストについて次の詳細情報を追加します。
LoadModule certheaders_module ORACLE_HOME/ohs/modules/mod_certheaders.so
NameVirtualHost *:OHS http port
<VirtualHost *:OHS http port>
ServerName https://webcachehost:webcache=sslport
RewriteEngine On
RewriteOptions inherit
SimulateHttps On
UseCanonicalName On
</VirtualHost>
ORACLE_HOMEは、Oracle PortalインストールのOracleホームへのフルパスです。
「適用」をクリックします。
Oracle HTTP Serverのホーム・ページで「制御」→「再起動」を選択してOracle HTTP Serverを再起動します。
Oracle HTTP Serverパートナ・アプリケーションの再登録
ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binのインフラストラクチャ層(OID)にあります。
次の例は、UNIX上でのssoregの使用方法を示しています。
ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com:4443
-config_mod_osso TRUE
-mod_osso_url https://www.abc.com:4443
-update_mode MODIFY
-remote_midtier
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
Web Cache SSLポートの仮想ホストを構成したohsインスタンス (ORACLE_INSTANCE/config/OHS/ohs1/osso.conf)にosso.confをコピーします。
次のコマンドを使用してOracle HTTP Serverを再起動します。
ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall
Windowsでは、かわりにssoreg.batバッチ・ファイルを実行する必要があります。パートナ・アプリケーション登録の詳細は、Oracle Application Server Single Sign-On管理者ガイドを参照してください。
Oracle Web CacheとのSSL通信の構成が完了しました。
SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録
詳細は、「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」を参照してください。
SSLを介して公開されるWSRPプロデューサの構成と登録
詳細は、「SSLを介して公開されるWSRPプロデューサの構成と登録」を参照してください。
OmniPortletプロバイダのWebページ・データ・ソースを使用する場合は、Webクリッピング・プロバイダへのループバックを実行するので、OmniPortletのprovider.xmlファイルにある<trustedCertificateLocation>タグで指定した信頼できる証明書ファイルに、Webプロバイダのサーバー証明書を追加する必要があります。デフォルトの証明書ファイルは、ORACLE_HOME\portal\confディレクトリにあるca-bundle.crtファイルです。
これを行うには、Internet Explorerのブラウザに基づく次の手順を実行します。別のブラウザを使用して必要な証明書のキャプチャとエクスポートを行う場合、この手順は少し異なることがあります。
次の手順で必要な証明書をキャプチャします。ブラウザで、Webクリッピングの「プロバイダ・テスト・ページ」(http://<host>:<port>/portalTools/webClipping/providers/webClipping)を指定します。
「セキュリティの警告」ダイアログ・ボックスが表示され、「このセキュリティ証明書は、信頼する会社から発行されていません。証明書を表示して、この証明機関を信頼するかどうか決定してください。」などのメッセージが表示されます。「証明書の表示」をクリックし、次に示す手順を実行して証明書を一時ファイルにエクスポートします。
「詳細」タブを選択します。
ドロップダウン・リストから「表示: <すべて>」を選択し、「ファイルにコピー」をクリックします。エクスポート・ウィザードを実行して、Base-64 encoded X.509形式の証明書を一時ファイルORACLE_HOME/portal/conf/providertemp.cerにエクスポートします。
一時ファイル内の証明書を、OmniPortletプロバイダが使用する証明書ファイル(デフォルトはORACLE_HOME/portal/conf/ca-bundle.crt)に追加します。
Secure Enterprise Searchのアクセスの有効化
セキュアなWebサイトにSecure Enterprise Searchからアクセスするには、中間層インスタンスとインフラストラクチャ・インスタンスにあるクローラのトラストストアおよびOracle Containers for J2EE (WLS) JVMのトラストストアに証明書をインポートする必要があります。
デフォルトでは、WLS JVMは、既知の認証局の証明書を認識します。ただし、セキュアなポータル・インスタンスが、自己署名の証明書または不明な認証局によって署名された証明書を使用する場合は、そのポータルの証明書をWLS JVMのトラストストアにインポートする必要があります。WLS JVMのデフォルトのトラストストアは、ORACLE_HOME\jdk\jre\lib\security\cacertsにあります。
必要な証明書をトラストストアに追加するには、中間層インスタンスとインフラストラクチャ・インスタンスで次の手順を実行します。
ディレクトリを、中間層のORACLE_HOME\jdk\jre\lib\security\に変更します。
トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。
次のコマンドを実行して、必要な証明書をトラストストアに追加します。
$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/jdk/jre/lib/security/cacerts
|
注意:
|
トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。
|
注意: 前述の手順は、Secure Enterprise Searchクローラを含むOracleAS Infrastructure上でも実行する必要があります。 |
Portalリポジトリのワイヤ構成
Portalの中間層を次のように構成します。
Oracle Enterprise Manager 11gでPortalホーム・ページに移動します。
「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。
「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。
公開ホスト: ホスト名を入力します。
リスニング・ポート: ポート番号を入力します。
「SSLプロトコル」チェック・ボックスを選択します。
「適用」をクリックします。
管理対象サーバーを再起動します。
Web Cache SSLのPortalリポジトリの構成
SSO情報を取得するために、Portalでmod_ossoが必要になります。mod_ossoはSSLで構成されているので(WC SSLポートを使用するパートナ・アプリケーションとして登録されています)、ポータルはWC SSL証明書の保存に使用するウォレットのパスおよびパスワードが必要になります。
Portalリポジトリのプリファレンス・ストアにあるウォレットのパスとパスワードを更新するには、次の手順を実行します。
Web CacheのSSL証明書をPortalデータベース・ウォレットのトラストストアにインポートします。
データベース・ウォレットがない場合は、データベースがインストールされている環境でOWM (Oracle wallet manager)またはorapkiユーティリティを使用して作成できます。ウォレットができたら、Web CacheのSSL証明書をデータベース・ウォレットにインポートします。
ORACLE_HOME\portal\admin\plsql\wwcにあるsecwc.sqlスクリプトを使用して、このウォレットの場所をPortalプリファレンス・ストアに登録する必要があります。
例7-5 ウォレットの登録
cd $ORACLE_HOME/portal/admin/plsql/wwc sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location> <wallet_pwd> sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'
WebLogicプラグインの有効化
「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。
最大限のセキュリティを必要とするインストールに対しては、システム全体にわたってSSLを構成することができます。この構成では、PPEからOracle Web Cacheへのループバックでウォレットが使用され、PPEとWebプロバイダとのホップで証明書がウォレットを介さずに直接使用されます。
図7-21は、Oracle Portal全体にわたって構成したSSLを示しています。
|
注意: 第7.3.2.1.4項「Oracle Web CacheとのSSL接続」で説明した手順をすでに実行している場合は、Oracle Portal全体にSSLを構成する前に、適用したすべての変更を元に戻す必要があります。 |
「SSLを構成する前の確認事項」に記載された確認事項の実行を完了したら、次のようにしてOracleAS Single Sign-OnでSSLを構成します。
OracleAS Single Sign-OnでのSSLの有効化
「手動でのOracleAS Single Sign-OnのSSL構成」の説明にある手順を実行して、OracleAS Single Sign-OnのSSLを有効にします。
ウォレットの作成
Oracle Web CacheとOracle HTTP Serverが同じコンピュータ上にある場合は、リスナーとオリジン・サーバー(およびOracle Web Cacheで利用できる他のすべてポート)との間で1つのウォレットを共有できます。逆に、ポート別に専用のウォレットを作成することもできます。この場合は、この2つのサーバーおよびそのポートで前述と同じウォレットを共有します。
Oracle HTTP ServerとOracle Web Cacheが互いに別のコンピュータ上にある場合のように、Oracle HTTP Server用に別のウォレットの作成が必要になることがあります。この場合は、「ウォレットの作成」の手順を参照して、Oracle HTTP Server用のウォレットを作成します。
デフォルトでは、Oracle HTTP ServerとOracle Web Cacheは同じコンピュータ上にあり、これらの間でウォレットを共有できます。
|
注意: 作成したウォレットは、Fusion MiddleWare Controlまたは |
Oracle HTTP ServerおよびOracle WebLogic Serverの構成
WebLogic Server (WLS)とSSL通信を確立するようにOracle HTTP Serverを構成し、SSLモードをプロキシ処理するようにWeblogic管理対象サーバー(WLS_PORTAL)へのルーティング情報を設定する必要があります。HTTPおよびWLSを構成するには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware ControlからOracle HTTP Serverのホーム・ページに移動して、「管理」→「詳細構成」を選択します。
「詳細構成」ページが表示されます。
メニュー・オプションから「portal.conf」ファイルを選択して「実行」をクリックします。
次のように、WLProxySSLパラメータをONに設定します。
# WLS routing configuration
<Location /portal>
SetHandler weblogic-handler
WebLogicHost stbcr13-3.us.abc.com
WebLogicPort 9001
WLProxySSL On
</Location>
「適用」をクリックします。
Oracle HTTP Server用に別のウォレットを作成する必要があります。この場合は、「ウォレットの作成」の手順を参照してOracle HTTP Server用のウォレットを作成し、webcache.xmlファイルの<OSWALLET>タグにそのウォレットの場所が追加されていること確認します。
Oracle Enterprise Manager 11gを使用して、次のようにウォレットの場所を<OSWALLET>タグに追加できます。
「Web層」を開いて、Oracle PortalインスタンスのOracle Web Cache (webcache1)リンクをクリックします。
「Webキャッシュ」メニューから「セキュリティ」→「SSL構成」を選択します。
作成したウォレットを選択して「ウォレットの変更」をクリックします。
「OK」をクリックします。
Oracle HTTP Serverを再起動します。
新規に作成したウォレットからテキスト・ファイルに証明書をコピーします。次に、Oracle Portalがデプロイされた管理対象サーバーで使用されるキーストアにこのファイルをインポートします。
WebLogic Serverのキーストアの場所を確認するには、WebLogic Server管理コンソールに移動して、「環境」→「サーバー」と移動し、WLS_PORTALリンクをクリックします。「構成」タブで「キーストア」サブタブを選択し、「Java標準信頼キーストア」フィールドで指定されているパスを探します。
Oracle HTTP Serverウォレットから証明書をエクスポートする際は、Oracle Wallet Manager、または中間層で使用可能なorapkiユーティリティを使用できます。キーストアへの証明書のインポートには、keytoolを使用できます。
次は、keytoolの使用例です。
keytool -import -trustcacerts -alias aliasName -file certificate_file_name -keystore cacerts -storetype JKS
ファイル・サーバー証明書とウォレットからエクスポートした認証局のルート証明書がcertificate_file_nameで指定されている必要があります。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareにおけるSSL構成に関する項を参照してください。
Oracle Web Cacheの保護
次の項では、Oracle Web CacheがSSL接続を許可し、SSLリクエストをSSL対応のオリジン・サーバーに転送するように構成する方法について説明します。
Oracle Web CacheのSSLポートを構成するには、次の手順を実行します。
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。
「Webキャッシュ」メニューから「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。
「作成」をクリックします。
「ポートの作成」ページで次の情報を入力します。
ポート・タイプ: NORM
IPアドレス: ANY
Port Number: Web CacheがリスニングするSSLポート。
「OK」をクリックします。
SSLポートを追加するには、前述の手順で作成したポートを選択して「編集...」をクリックし、「SSL構成」セクションで次の情報を入力します。
SSLの有効化: チェック・ボックスを選択します。
サーバー・ウォレット名: SSLサーバー証明書を収めたウォレットを選択します。
「OK」をクリックします。
「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。
前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のキャッシュ用のHTTPS動作ポートの構成に関する項を参照してください。
SSLオリジン・サーバーを追加するには、次の手順を実行します。
「Webキャッシュ」メニューから「管理」→「オリジン・サーバー」を選択します。
「オリジン・サーバー」ページが表示されます。
「作成...」をクリックしてSSLオリジン・サーバーを追加します。
次の情報を入力します。
Host Name: Oracle HTTP Serverが実行されているコンピュータの物理ホスト名。
Port: Oracle HTTP ServerのSSLリスニング・ポート。このプロパティは、ORACLE_INSTANCE\config\OHS\ohs1にあるHTTPサーバーのssl.confファイル内のListenパラメータにマッピングされます。
Capacity: 100
Protocol: HTTPS
Routing: 有効
Failover Threshold: 5
Ping URL: /
Ping Interval: 10
「OK」をクリックします。
「適用」をクリックします。
「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。
前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバー、ロード・バランスおよびフェイルオーバー設定の構成に関する項を参照してください。
デフォルトではSSLは構成されていないので、Oracle Web CacheがキャッシュするSSLベースのサイトの定義を追加する必要があります。サイトを定義するには、次の手順を実行します。
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』の説明に従って、Oracle Enterprise Manager 11g Fusion Middleware ControlのWeb Cacheホーム・ページに移動します。
「Webキャッシュ」メニューから「管理」→「サイト」を選択します。
「サイト」ページが表示されます。
「サイト」で「作成」をクリックします。
「サイトの作成」ページで次の詳細情報を入力します。
ブラウザに表示するホスト名を「ホスト名」に入力します。
ブラウザ・リクエストに指定されているHTTPSポート(Oracle Web CacheのSSLリスニング・ポート)を「ポート」に設定します。
「デフォルト・サイト」で「Yes」を選択します。
サイト規模の圧縮で「No」を選択します。
その他のパラメータはデフォルト設定のままとして、空白のエントリがあってもそのままにしておきます。
「OK」をクリックします。
「適用」をクリックします。
変更後の構成では使用できなくなるすべてのサイトを削除します。
前述の手順の詳細は、次を参照してください。
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のキャッシュ用のHTTPSリクエストのサイト作成に関する項
『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のサイト定義の作成に関する項
新しいサイトのサイト・サーバー間マッピングのオリジン・サーバーへの追加
新しいサイト定義を追加した後、そのサイトのサイト・サーバー間マッピングをオリジン・サーバーに追加する必要があります。これを行うには、次の手順を実行します。
「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。
マッピングするサイトを選択し、「すべてのオリジン・サーバー」から「選択したオリジン・サーバー」リストにそのサイトを移動します。これはSSLポートが設定されたOracle Web Cacheサイトであることが必要です。
前の手順「SSLオリジン・サーバーを追加する」で追加した、コンテンツを取得するためにリクエストをルーティングするオリジン・サーバーを選択します。
「変更の適用」→「適用」をクリックすると、表7-23のような元のページの新しいマッピングが表示されます。
Oracle Web Cacheを再起動します。
前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。
セッション・バインドの有効化
Oracle Web Cacheのセッション・バインド機能は、ユーザー・セッションを特定のオリジン・サーバーにバインドして、状態を一定の期間保持するために使用されます。デフォルトのOracle Portal中間層で実行されるほとんどすべてのコンポーネントはステートレスですが、セッション・バインドは次の2つの理由で必要になります。
Oracle Web Cacheでポータル・ユーザー・セッションをOracle Portal中間層にバインドするには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware Controlで、Web Cacheホーム・ページに移動します。
「Webキャッシュ」メニューから「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。
前述の手順で作成したサイトを選択します。
「セッション・バインディング構成」セクションで「Set-Cookieを使用したCookieに基づくセッション・バインディング」を選択します。
「適用」をクリックします。
詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
オリジン・サーバー・ウォレットへのウォレットのパスの追加
「オリジン・サーバー・ウォレットへのウォレットのパスの追加」を参照してください。
Parallel Page Engineの保護
この構成では、リクエストがHTTPSを介してOracle Web Cacheに送信され、同様にPPEがHTTPSを介してループバックするときに、全体を通してSSLが使用されます。サーバーでは、その証明書とともに送信される連鎖を指定します。この連鎖が有効で、自己署名のルート証明書を得る場合、トラスト・ポイントがまだそれにロードされていないという前提では、その証明書が信頼できるかどうか確認しなくても有効となります。
この構成を実装するには、Oracle Portal中間層で次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。
Oracle Portalホーム・ページの「ポータル」メニューから「設定」→「ページ・エンジン」を選択して「ページ・エンジン構成」ページを表示します。
「拡張プロパティ」セクションで、「HTTPSポート」の値にOracle Web CacheのSSLポートを入力します。
(オプション)PPEで特定の証明書のみを信頼する場合はx509certfileを追加します。x509certfileの値は、信頼できるサーバー・グループを定義する証明書のリストを含むテキスト・ファイルへの絶対パスです。
|
注意: x509certfileを実装しないと、PPEではすべてのSSL証明書を信頼します。 |
「適用」をクリックします。
管理対象サーバー(WLS_PORTAL)を再起動します。
SSL用に変更されたポートでOracle Portalの公開アドレスを指定するには、次のようにOracle Enterprise Managerを使用する必要があります。
Oracle Enterprise Manager 11g Fusion Middleware Controlに移動します。
Oracle Portalの中間層で実行しているOracle Fusion Middlewareを含むスタンドアロン・インスタンスをクリックします。
Oracle Portalのシステム・コンポーネント(WLS_PORTAL)をクリックします。
「ポータル」メニューで「設定」→「ワイヤ構成」をクリックします。
「ポータル・ワイヤ構成」ページが表示されます。
「ポータル・ワイヤ構成」ページの「ポータル中間層」セクションに、次の情報を入力します。
リスニング・ポート: Oracle Web CacheのSSLポート番号を入力します。
「SSLプロトコル」チェック・ボックスを選択します。
「適用」をクリックします。
Oracle Portalのスキーマがこの設定で更新され、Oracle Enterprise Manager 11gのターゲット・インスタンスがそのURLテストにHTTPSを使用するように更新されます。
後でHTTPに切り替えることにする場合は、これと同じ手順を実行して、「リスニング・ポートSSL使用可能」を「いいえ」に戻します。
HTTPサーバーの構成
仮想ホストの定義を編集します。PortalがSSLで動作する場合、この構成でホスト名とポートの自己参照URLを指定します。Oracle Enterprise Manager 11g Fusion Middleware ControlのOracle HTTP Serverホーム・ページに移動して、「管理」→「拡張構成」を選択します。「ssl.conf」ファイルを選択して、次の太字で示す仮想ホストに関する詳細を追加します。
<VirtualHost *:8890> UseCanonicalName On ServerName https://dadvmn0041.us.abc.com:8094 <IfModule ossl_module> SSLEngine on SSLVerifyClient None SSLCipherSuite SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SH A,SSL_RSA_WITH_DES_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_C BC_SHA SSLCRLCheck Off SSLWallet "wallet_location"
次の例に示すように、wallet_locationを、カスタム・ウォレットのフルパスに置き換えます。
SSLWallet "$ORACLE_INSTANCE/config/OHS/ohs1/keystores/default"
Oracle HTTP Serverパートナ・アプリケーションの再登録
ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binのインフラストラクチャ層(OID)にあります。
次の例は、UNIX上でのssoregの使用方法を示しています。
ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com
-config_mod_osso TRUE
-mod_osso_url https://www.abc.com:8094
-update_mode MODIFY
-remote_midtier
-config_file ORACLE_INSTANCE/config/OHS/ohs1/osso.conf
-admin_info cn=orcladmin
osso.confをohsインスタンスにコピーします。これは、Web CacheのSSLポートで仮想ホストを構成した場所です(ORACLE_INSTANCE/config/OHS/ohs1/osso.conf)。
次のコマンドを使用してOracle HTTP Serverを再起動します。
ORACLE_HOME/bin/opmnctl stopall ORACLE_HOME/bin/opmnctl startall
Windowsでは、かわりにssoreg.batバッチ・ファイルを実行する必要があります。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のパートナ・アプリケーションの作成に関する項を参照してください。
Web Cache SSLのPortalリポジトリの構成
SSO情報を取得するために、Portalでmod_ossoが必要になります。mod_ossoはSSLで構成されているので(WC SSLポートを使用するパートナ・アプリケーションとして登録されています)、ポータルはWC SSL証明書の保存に使用するウォレットのパスおよびパスワードが必要になります。
Portalリポジトリのプリファレンス・ストアにあるウォレットのパスとパスワードを更新するには、次の手順を実行します。
Web CacheのSSL証明書をPortalデータベース・ウォレットのトラストストアにインポートします。
データベース・ウォレットがない場合は、データベースがインストールされている環境でOWM (Oracle wallet manager)またはorapkiユーティリティを使用して作成できます。ウォレットができたら、Web CacheのSSL証明書をデータベース・ウォレットにインポートします。
ORACLE_HOME\portal\admin\plsql\wwcにあるsecwc.sqlスクリプトを使用して、このウォレットの場所をPortalプリファレンス・ストアに登録する必要があります。
例7-6 ウォレットの登録
cd $ORACLE_HOME/portal/admin/plsql/wwc sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location> <wallet_pwd> sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'
WebLogicプラグインの有効化
「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。
SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録
「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」を参照してください。
SSLを介して公開されるWSRPプロデューサの構成と登録
「SSLを介して公開されるWSRPプロデューサの構成と登録」を参照してください。
「Portalツールの信頼できる証明書ファイルの拡張」を参照してください。
Secure Enterprise Searchのアクセスの有効化
「Secure Enterprise Searchのアクセスの有効化」を参照してください。
前の構成では、Oracle Fusion Middleware内の通信がSSLを介して保護されるようにOracle Portalを構成する方法について説明しました。特定の状況下では、サイトはSSL URLを介して外部にアクセスする一方で、内部的にはOracle Fusion Middlewareを非SSLモードで実行するようにOracle Portalを設定することもあります。後者のシナリオでは、ロード・バランシング・ルーター(LBR)またはSSLアクセラレータを使用してSSLから非SSLへの変換を行う必要があります。この項では、LBRまたはリバース・プロキシ・サーバーのアクセラレータでSSLの変換を行う場合に使用する手順について説明します。
このオプションでは、Oracle Fusion Middleware Security FrameworkのSSL機能は使用しませんが、そのかわり、SSLの接続ポイントを提供するために外部コンポーネントを使用します。これらの外部アクセラレータは、LBRやリバース・プロキシ・サーバーと組み合せることができます。Oracle Fusion Middlewareを使用すると、これらの外部装置でSSLを提供するように構成できるため、最良のパフォーマンスを得るためにOracle Fusion Middleware内部でHTTPを使用できるようになります。
図7-22は、Oracle PortalがSSLを介して外部にアクセスする構成を示しています。
|
注意: 通常の構成では、 |
この手順では、次のことを前提としています。
この例では、LBRなどのSSLアクセラレータでSSLを高速化し、LBRはHTTPプロトコルやHTTPSプロトコルとそのポート間のページ・リクエストのプロキシ処理も行うこと。SSLエンド・ポイントの場所は、ループバック・リクエストの送信先も決定します。たとえば、SSL対応のリバース・プロキシ・サーバーが単一プロトコルLBRのフロントエンドになっている場合、公開サイトがリバース・プロキシ・サーバーによって公開中に、ループバック・リクエストはLBRに送信されます。
使用するロード・バランシング・ルーターがlbr.abc.comで実行されており、サイトのアクセスに使用されるLBRのポートが443であること。
Oracle Web Cacheがコンピュータのw1.abc.comで実行されており、そのリスニング・ポートが8090、管理用ポートが4002であり、無効化ポートが4001であること。
Oracle HTTP Serverがコンピュータのm1.abc.comで実行されており、そのポートが8888であること。
使用されているポート番号は仮の値であること。
|
関連項目:
|
「SSLを構成する前の確認事項」に記載された確認事項の実行を完了したら、次のようにしてOracle Portalで外部SSLの構成を行います。
Oracle Fusion Middlewareの中間層の構成
基になるコンポーネントがロード・バランシング・ルーターのホスト名(lbr.abc.com)とポート(443)に基づくURLを作成できるように、Oracle Fusion Middlewareの中間層を構成する必要があります。これを行うには、次の手順を実行します。
httpd.confを次のように編集します。
Oracle Enterprise Manager 11g Fusion Middleware Controlにアクセスします。
Oracle Portalがインストールされている中間層のリンクをクリックします。
「Web層」を開いて、Oracle PortalインスタンスのHTTP Serverリンクをクリックします。
Oracle HTTP Serverのホーム・ページで「管理」→「拡張構成」をクリックします。
「サーバーの詳細構成」ページで、「ファイルの選択」オプションから「httpd.conf」を選択して「実行」をクリックします。
次の仮想ホストの定義を追加します。
NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName https://lbr.abc.com:443
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>
<VirtualHost *:8888> ServerName http://m1.abc.com:8090 RewriteEngine On RewriteOptions inherit </VirtualHost>
「適用」をクリックします。
Oracle HTTP Serverのホームから「制御」→「再起動」を選択してOracle HTTP Serverを再起動します。
Parallel Page Engineを構成します。これを行うには、次の手順を実行します:
Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。
Oracle Portalホーム・ページの「ポータル」メニューから「設定」→「ページ・エンジン」を選択して「ページ・エンジン構成」ページを表示します。
「拡張プロパティ」セクションで次のパラメータを追加して、サイトで使用したものとは異なるプロトコルとポートを使用してループバックを試みます。
スキームの使用: http
ポートの使用: 8090
HTTPSポート: 443
「適用」をクリックします。
「ポータル」メニューから「制御」→「停止」→「起動」を選択して、WLS_PORTALインスタンスを再起動します。
DNSでlbr.abc.comがLBRのIPアドレスに解決されることを確認します。
Oracle Enterprise Manager 11g Fusion Middleware Controlにログインして、次の手順を実行します。
Portalホーム・ページの「ポータル」メニューから「設定」→「ワイヤ構成」を選択して「ポータル・ワイヤ構成」ページを表示します。
「ポータル・ワイヤ構成」ページの「Oracle Web Cache」セクションで、次のWeb Cacheのパラメータを入力します。
ホスト: lbr.abc.com
無効化ポート: 4001
無効化ユーザー: invalidator
無効化パスワード: 指定したパスワード
「ポータル中間層」セクションで「SSLプロトコル」チェック・ボックスを選択します。
「適用」をクリックします。
Oracle Enterprise Manager 11g Fusion Middleware ControlのOracle Web Cacheホーム・ページで「管理」→「サイト」を選択します。
「サイト」ページが表示されます。
「サイト」で「作成」をクリックします。
「サイトの作成」ページで次の詳細情報を入力します。
ホスト: 公開されたホスト名と外部SSLアクセラレータ・デバイスまたはリバース・プロキシ・サーバーの完全修飾ドメイン名。
ポート: SSLポート番号(デフォルトのSSLポートの443など)。
URL接頭辞: 空白のまま
クライアント側証明書: 不要
Default Site: はい。
圧縮: いいえ。
前述の構成手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
「OK」をクリックします。
「適用」をクリックします。
Oracle Web Cacheの別名を設定します。Parallel Page EngineがOracle Web Cacheにループバックし、Oracle Web Cacheがロード・バランシング・ルーターとは異なるポートでリスニングしている構成では、ループバック・コンテンツがlbr.abc.com:8090というURLキーでキャッシュされます。一方、Oracle Portalでは書式がlbr.abc.com:443のURLを無効にする無効化リクエストを送信します。この矛盾に対処するには、Oracle Web Cache内に別名を設定して、その別名にlbr.abc.com:8090とlbr.abc.com:443が同じであることを認識させ、一方に対する無効化リクエストによって他方に対するリクエストも無効になり、キャッシュされたコンテンツもこの別名を基にして利用されるようにする必要があります。
Oracle Enterprise Manager 11g Fusion Middleware ControlのOracle Web Cacheホーム・ページで「管理」→「サイト」を選択します。
「サイト」ページで、新しく追加したサイトを選択し(ここではlbr.abc.com)、「編集」をクリックします。
「サイトの編集」ページが表示されます。
「別名」セクションで、「作成」をクリックして新しい別名を作成し、「ホスト」に「lbr.abc.com」、「ポート」に「8090」と入力します。この8090は、Parallel Page EngineのappConfig.xml構成ファイルで指定されているusePortの値です。
「OK」をクリックします。
「適用」をクリックします。
「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。
前の例のように、外部SSL構成で構成したサイトに対してデフォルトのHTTPSポート443を選択した場合、Oracle Web Cacheで、lbr.abc.com:443サイトの追加の別名(lbr.abc.com:80)を定義する必要があります。ステップ10で説明した別名の作成方法に従って、ポートの8090を80に置き換えます。
ブラウザが送信するホスト・ヘッダーは、ポート番号が付加されていないlbr.abc.comなので、ポート80には別名が必要となります。Oracle Web Cacheでは、HTTPポートをリスニングしているので、ポート番号が80であることが前提となっており、このポート番号を使用してサイト・サーバー間マッピングが決まります。キャッシュ・キーの作成にもこのポート番号が使用されます。
新しいサイト定義を追加した後、そのサイトのサイト・サーバー間マッピングをオリジン・サーバーに追加する必要があります。これを行うには、次の手順を実行します。
「サイト」ページの「サイト・サーバー間マッピング」セクションで、「作成」をクリックします。
サイト・サーバー間マッピング定義の作成ページが表示されます。
「サイト・サーバー間マッピングの作成」セクションで、マッピングするサイト(lbr.abc.com)の情報を入力して、前の手順で作成したサイトの定義を選択します。
「オリジン・サーバー」セクションで「m1.abc.com」を選択して、それを「すべてのオリジン・サーバー」から「選択したオリジン・サーバー」リストに移動します。
「OK」をクリックします。
「適用」をクリックします。
「Webキャッシュ」メニューから「制御」→「再起動」を選択してOracle Web Cacheを再起動します。
サイトが正しくマッピングされたことを確認するには、「サイト・サーバー間マッピング」ページに移動して、サイトlbr.abc.comにm1.abc.comがマッピングされていることを確認します。
前述の手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のオリジン・サーバーへのサイトのマッピングに関する項を参照してください。
次のようにロード・バランシング・ルーターlbr.abc.comを構成します。
HTTPSポート443のリクエストを受け入れ、それらをコンピュータw1.abc.comで動作しているOracle Web Cacheのポート(8090)に転送し、同時にHTTPSリクエストをHTTPに変換するようにします。
HTTPポート8090のリクエストを受け入れ、それらをコンピュータw1.abc.comで動作しているOracle Web Cacheのポート(8090)に転送するようにします。これでループバック・リクエストが有効になります。LBRのポート(8090)は、中間層からのみアクセス可能である必要があります。ファイアウォールは、正常に機能させるために別に構成する必要があります。これをテストするには、中間層サーバーで次のコマンドを実行します。
telnet lbr.abc.com 8090
telnetコマンドの実行時に、接続の失敗メッセージが表示されないようにします。
無効化リクエスト用のHTTPポート4001のリクエストを受け入れ、それらをOracle Web Cacheの無効化用ポート(4001)に転送するようにします。Oracle Metadata Repositoryから無効化リクエスト用のLBRのポートに接続できる必要があります。ファイアウォールは、正常に機能させるために別に構成する必要があります。これをテストするには、Oracle Metadata Repositoryサーバーで次のコマンドを実行します。
telnet lbr.abc.com 4001
telnetコマンドの実行時に、接続の失敗メッセージが表示されないようにします。
LBRを介して中間層からOracle Web Cacheへの通信を問題なく実行できるようにします。これには、NAT関連の構成が必要になることがあります。NATの構成の詳細は、第6.3項「ロード・バランシング・ルーターを使用する複数の中間層の構成」を参照してください。
LBRを介してOracle Metadata Repositoryから無効化リクエスト用のOracle Web Cacheへの通信を問題なく実行できるようにします。これには、NAT関連の構成が必要になることがあります。
Oracle HTTP Serverパートナ・アプリケーションの再登録
ssoregを実行して、仮想ホストを登録します。これはmod_ossoのシングル・サインオンに役立ちます。このサイト内でパートナ・アプリケーションとして定義する特定のアプリケーションURLは、osso.confファイルで定義します。ssoregは、ORACLE_HOME/sso/binのインフラストラクチャ層にあります。
次の例は、UNIX上でのssoregの使用方法を示しています。
$ ssoreg.sh
-site_name lbr.abc.com
-config_mod_osso TRUE
-mod_osso_url https://lbr.abc.com:8094
-Oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier
Windowsでは、かわりにssoreg.batバッチ・ファイルを実行する必要があります。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』のパートナ・アプリケーションの作成に関する項を参照してください。
Secure Enterprise Searchのアクセスの有効化
セキュアなWebサイトにSecure Enterprise Searchからアクセスするには、インフラストラクチャ・インスタンスにあるクローラのトラストストアおよびOracle Containers for J2EE (WLS) JVMのトラストストアに証明書をインポートする必要があります。
デフォルトでは、WLS JVMは、既知の認証局の証明書を認識します。ただし、セキュアなポータル・インスタンスが、自己署名の証明書または不明な認証局によって署名された証明書を使用する場合は、そのポータルの証明書をWLS JVMのトラストストアにインポートする必要があります。WLS JVMのデフォルトのトラストストアは、ORACLE_HOME\jdk\jre\lib\security\cacertsにあります。
必要な証明書をトラストストアに追加するには、インフラストラクチャ・インスタンスで次の手順を実行します。
ディレクトリを、インフラストラクチャのORACLE_INSTANCE\jdk\jre\lib\securityに変更します。
トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。
次のUNIXのコマンドを実行して、必要な証明書をトラストストアに追加します。
$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/jdk/jre/lib/security/cacerts
|
注意:
|
トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。
|
注意: 前述の手順は、Secure Enterprise Searchクローラを含むOracleAS Infrastructure上でも実行する必要があります。 |
WebLogicプラグインの有効化
「WebLogicプラグイン、WebLogic ProxySSL、およびWLProxySSLPassThroughパラメータの有効化」を参照してください。
この項では、WebLogic管理コンソールを使用して、WLSでSSLを有効にする方法について説明します。次の手順を実行します。
WebLogic管理コンソールにログインして、ポータルのインストール時に作成したドメインに対してコンソールが構成されていることを確認します。
まだログオンしていない場合には、Administration Consoleの「チェンジ・センター」で、「ロックして編集」をクリックします。
コンソールの左側のペインで、「環境」を開いて「サーバー」を選択します。
「サーバー」の表で、管理対象サーバーWLS_Portalのインスタンスをクリックします。
「SSLリスニング・ポート有効」を選択して「SSLリスニング・ポート」に番号を入力します。
「構成」タブ・グループ→「キーストア」タブ・ページを選択します。
「キーストア」フィールドで「デモIDとデモ信頼」オプションを選択します。
「一般」タブ・ページを選択します。
ページ末尾近くの「詳細」オプショングループを開き、「WebLogicプラグインの有効化」オプションを選択します。
「保存」をクリックします。
これで、WLS管理対象サーバー(WLS_Portal)がSSLで構成されました。
この項では、SSLを介して公開されるWebプロバイダ、プロバイダ・グループおよびWSRPプロデューサにアクセスするためのOracle Portalの構成方法について説明します。この項には次のトピックが含まれます:
SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録
SSLを介して公開されるWebプロバイダを登録するには、Webプロバイダが使用する認証局のルート証明書のコピーが必要です。Webプロバイダが不明または一般的でない認証局を使用している場合は、適切なルート証明書(Base-64 encoded X.509形式を使用)を信頼できる証明書のセットに追加する必要があります。この証明書セットは、Oracle Portalスキーマを含むOracle Metadata RepositoryをホストするOracle Databaseによって認識されます。SSLを介して公開されるWebプロバイダまたはプロバイダ・グループを構成するには、次の手順を実行します。
プロデューサのSSL証明書をデータベース・キーストアにインポートするには、次の手順を実行します。
ディレクトリを、Oracleホームの$ORACLE_HOME/javavm/lib/securityに変更します。ここには、Oracle Portalスキーマを収めたOracle Metadata RepositoryをホストするOracle Databaseが格納されています。
トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。
次のUNIXのコマンドを実行して、必要な証明書をトラストストアに追加します。
$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/javavm/lib/security/cacerts
|
注意:
|
トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。
|
注意: ポータル・スキーマがリポジトリ作成ユーティリティ(RCU)データベース内にあり、そのOracle Databaseリリースが10g (10.1.0.x)より古い場合、これらの手順は不要です。 |
例7-7 データベースへの証明書の登録
[ABC@stake03 security]$ $ORACLE_HOME/jdk/bin/keytool -import -alias cacert2 -file /home/name1/testcer.crt.cer -trustcacerts -v -keystore /u01/app/oracle/product/1021prod_ee/javavm/lib/security/cacerts
Enter keystore password: changeit
Owner: CN=xmlns.oracle.com, O=wc_1
Issuer: CN=xmlns.oracle.com, O=wc_1
Serial number: 0
Valid from: Thu Mar 06 19:48:48 PST 2008 until: Tue Mar 05 19:48:48 PST 2013
Certificate fingerprints:
MD5: 4D:43:B4:A7:E9:02:33:20:A9:82:C4:CE:8D:4A:46:59
SHA1: FB:3D:1D:6D:01:6F:7B:35:27:85:20:0F:C4:28:F2:6A 2:75:1D:29
Trust this certificate? [no]: yes
Certificate was added to keystore
[Saving /u01/app/oracle/product/1021prod_ee/javavm/lib/security/cacerts]
プロデューサのSSL証明書をポータル中間層のWLSキーストアにインポートするには、次の手順を実行します。
ディレクトリを、WLS_PORTAL管理対象サーバーを実行しているJDKのJavaホームJAVA_HOME/jre/lib/security/に変更します。
トラストストア・ファイルcacertsのバックアップ(cacerts.bakなど)を作成します。
次のコマンドを実行して、必要な証明書をトラストストアに追加します。
$JAVA_HOME/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $JAVA_HOME/jre/lib/security/cacerts
|
注意:
|
トラストストア・パスワードを入力し、確認を促すメッセージが表示されたら「Yes」と入力します。
例7-8 ポータル中間層のWLSへの証明書の登録
[ABC@stake03 security]$ $JAVA_HOME/jdk/bin/keytool -import -alias cacert2 -file /home/name1/testcer.crt.cer -trustcacerts -v -keystore /u01/app/oracle/product/portal/jdk/jre/lib/security/cacerts
Enter keystore password: changeit
Owner: CN=xmlns.oracle.com, O=wc_1
Issuer: CN=xmlns.oracle.com, O=wc_1
Serial number: 0
Valid from: Thu Mar 06 19:48:48 PST 2008 until: Tue Mar 05 19:48:48 PST 2013
Certificate fingerprints:
MD5: 4D:43:B4:A7:E9:02:33:20:A9:82:C4:CE:8D:4A:46:59
SHA1: FB:3D:1D:6D:01:6F:7B:35:27:85:20:0F:C4:28:F2:6A 2:75:1D:29
Trust this certificate? [no]: yes
Certificate was added to keystore
[Saving /u01/app/oracle/product/portal/jdk/jre/lib/security/cacerts]
SSLを介して公開されるWSRPプロデューサの構成と登録
SSLを介して公開されるWSRPプロデューサを構成するには、次の手順を実行します。
Webブラウザで、WSRPプロデューサのWSDL URLを入力し、このURLが機能していることを確認します。WSDL定義がブラウザに表示されない場合は、WARファイルの配置に失敗していることになります。詳細は、『Oracle Fusion Middleware Oracle Portal開発者ガイド』のJavaポートレットの問題の診断に関する項を参照してください。
WSDLファイルを変更して、HTTPを介して使用できるようにします。
|
注意: 次の手順は、HTTPプロトコルを使用してWSRPポートを生成する場合の設定用です。これは、WSDL URLのリクエストにHTTPが使用されていたためです。ただし、HTTPを使用してWSDLにアクセスしており、HTTPSを使用して内部URLを参照する場合は、ステップ2を省略してください。 |
Webブラウザに、HTTPS WSDL URLを入力します。例:
https://host:port/context-root/portlets?WSDL
WSDL定義内の各ポートがHTTPSの場所とともに表示されます。例:
<wsdl:port binding="bind:WSRP_v1_Markup_Binding_SOAP" name="WSRPBaseService"> <soap:address location="https://host:port/context-root/portlets/WSRPBaseService"/> </wsdl:port>
WSDL定義のコピーをアプリケーション・サーバー上のファイルに保存します。このファイルは、HTTPを介した外部アクセスが可能な場所に存在する必要があります。たとえば、Oracle PortalのインストールのORACLE_HOME/Apache/Apache/htdocs/ディレクトリを使用します。プロデューサをOracle Portalに登録する場合は、登録の「接続の定義」ページで、「WSDL URL」にこのWSDLの場所を使用します。WSDL URLの形式は次のとおりです。
http://<host>:<port>/<Savedxml.xml>WSDL
|
注意: WSDL URLの形式で、ファイル・タイプを |
ポートがHTTPSの場所とともに表示されていない場合は、ポートを手動で変更してから続行する必要があります。これを行うには、ブラウザでXMLをファイルに保存し、テキスト・エディタで開きます。
SSLを介して公開されるWSRPプロデューサを登録するには、WSRPプロデューサが使用する認証局のルート証明書のコピーが必要です。Oracle Portalスキーマを含むOracle Metadata RepositoryをホストしているOracle Databaseによって認識される、信頼できる証明書のセットにルート証明書が存在するかどうかを確認します。ルート証明書がすでに存在するかどうかを確認するには、第7.3.2.1.5項「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」の手順1と2を繰り返してください。SSL対応ポータルのホーム・ページにアクセスします。証明書のセキュリティの警告ダイアログ・ボックスが表示される場合は、ステップ4を省略します。
WSRPプロデューサが不明または一般的でない認証局を使用している場合は、適切なルート証明書(Base-64 encoded X.509形式を使用)を信頼できる証明書のセットに追加する必要があります。WSRPプロデューサで使用する認証局のルート証明書をトラストストアに追加するには、第7.3.2.1.5項「SSLを介して公開されるWebプロバイダまたはプロバイダ・グループの構成と登録」の手順1と2を繰り返してください。
(オプション)PPEで特定の証明書のみを信頼する場合は、x509certfileをappConfig.xmlファイル(場所: DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration)に追加します。x509certfileの値は、信頼できるサーバー・グループを定義する証明書のリストを含むテキスト・ファイルへの絶対パスです。例:
<x509certfile>c:\mySSLconfig\trustedCerts.txt</x509certfile>
一般的なtrustedCerts.txtファイルは、例7-9に示すような内容を含んでいます。
-----BEGIN CERTIFICATE----- MIICPDCCAaUCEDJQM89Q0VbzXIGtZVxPyCUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTIwMDEwNzIzNTk1OVow XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2 yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEtEZmBoZOSY G/OwcuaViXzde7OVwB0u2NgZ0C00PcZQmhCGjKo/O6gE/DdSlcPZydvN8oYGxLEb8IKIMEKOF1Ac ZHq4PplJdJf8rAJD+5YMVgQlDHx8h50kp9jwMim1pN9dokzFFjKoQvZFprY2ueC/ZTaTwtLXa9ze WdaiNfhF -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIICPTCCAaYCEQC6WslMBTuS1qe2307QU5INMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0wNDAxMDcyMzU5NTla MF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAtlqLow1qI4OAa885h/QhEzMGTCWi7VUSl8WngLn6g8EgoPovFQ18oWBrfnks +gYPOq72G2+x0v8vKFJfg31LxHq3+GYfgFT8t8KOWUoUV0bRmpO+QZEDuxWAk1zr58wIbD8+s0r8 /0tsI9VQgiZEGY4jw3HqGSRHBJ51v8imAB8CAwEAATANBgkqhkiG9w0BAQIFAAOBgQC2AB+TV6QH p0DOZUA/VV7t7/pUSaUw1iF8YYfug5MLv7Qz8pisnwa/TqjOFIFMywROWMPPX+5815pvy0GKt3+B uP+EYcYnQ2UdDOyxAArdG6S7x3ggKLKi3TaVLuFUT79guXdoEZkj6OpS6KoATmdOu5C1RZtG644W 78QzWzM91Q== -----END CERTIFICATE-----
|
注意: x509certfileを実装しないと、PPEではすべてのSSL証明書を信頼します。 |
Oracle Fusion Middlewareインスタンスを再起動します。
ORACLE_HOME/opmn/bin/opmnctl stopallORACLE_HOME/opmn/bin/opmnctl startall
WSDLを指定してWSRPプロデューサを登録します。ここで使用するURLは、HTTPSベースである必要があります。例:
http://><host>:<port>/wsrp-tools/portlets/wsrp2/WSDL
第7.3.2.1項「Oracle PortalのSSLの構成」では、主にHTTPベースのネットワーク・ホップについて説明しました。しかし、Oracle Internet Directory自体へのネットワーク接続(LDAPベースの通信)も保護することができます。この場合は、Oracle Internet DirectoryがLDAP over SSL (LDAPS)を使用するよう構成されている必要があります。Oracle Internet DirectoryをLDAPS用に構成する方法の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。
Oracle Internet DirectoryでSSLが使用されるように構成したら、Oracle Portalスキーマを更新して、LDAPサーバーで新しいポートが使用されるようにする必要があります。この手順を実行するには、ORACLE_HOME/portal/admin/plsql/wwcにあるSQLスクリプトsecupoid.sqlを実行します。このスクリプトを使用すると、次のOracle Internet Directory関連のパラメータを設定できます。
ディレクトリのホスト名
ディレクトリ・ポート
アプリケーション・ディレクトリのパスワード
SSL設定
このスクリプトを実行すると、現在の設定が表示され、それに応じてその設定を変更できます。この場合は、次の設定を行います。
use_ssl_to_connect_to_ldap=Y
スクリプトにより、Oracle PortalのOracle Internet Directoryキャッシュを自動更新するオプションが提供されます。詳細は、第B.2項「secupoid.sqlスクリプトの使用」を参照してください。
|
注意: 10g リリース2 (10.1.2)以降では、インストール後にLDAPSを実装する必要はなく、オプションで、LDAPSを使用してOracle Portalをインストールできます。 |
Oracle Portalをインストールした後は、次の手順を実行してセキュリティの構成を行うことを考慮する必要があります。
ポータルをSSLで構成したら、次の手順を実行してOracle TextのベースURLを更新します。
Oracle Portalにログインします。
「管理」タブをクリックします。
「サービス」ポートレットで、「グローバル設定」を選択します。
「グローバル設定」ページで「検索」タブを選択します。
「Oracle TextのベースURL」の「ベースURL」で、URLのプロパティを「http」から「https」に変更します。たとえば、http://abc0088.us.abc.com:8090/portal/pls/portal/からhttps://abc0088.us.abc.com:8090/portal/pls/portal/に変更します。
悪意のユーザーがデフォルト・ユーザーのパスワードを探ろうとすると、アカウントがロックされます。このロックはサーバーから解除することができますが、管理上、デフォルト・ユーザー・アカウントに依存しないことをお薦めします。これらのアカウントのパスワードを保護するには、次の手順を実行します。
デフォルト・ユーザーと同じアクセス権を使用して新しい軽量の管理者アカウントを作成し、OracleAS Single Sign-Onのデフォルト・ユーザーのアカウントの終了日付を設定します。または、デフォルト・ユーザーの「ユーザーの編集」ページの「ユーザーにログインを許可する」設定の選択を解除することもできます。
デフォルト・ユーザーのログインを無効にするか、パスワードを変更したら、デフォルトのパスワードを使ってデフォルト・ユーザーとしてポータルにログインし、変更が正しく行われたことを確認します。
廃止されたページや不要なページからポータルにユーザーが入るのを防ぐには、使用していないオブジェクトをOracle Portalおよびデータベース環境から削除する必要があります。例:
使用していないページ・グループを削除します。
使用していないOracle Portalプロバイダを削除します。
Oracle Portalがインストールされると、表7-2に示してある生成済のグループに、それらのロールで通常必要とされる権限のセットが用意されます。これらの最初の権限のセットを確認して、それらがセキュリティ・ポリシーと矛盾していないことを確認する必要があります。
ユーザーまたはグループは、次のいずれかのソースから権限を取得することができます。
Oracle Portalのアクセス制御エントリ
Oracle Internet Directoryの権限グループ
Oracle Portalのアクセス制御エントリから付与された権限を編集するには、「Portalユーザー・プロファイル」ポートレットまたは「Portalグループ・プロファイル」ポートレットの「管理」タブからユーザーまたはグループのプロファイルを編集します。「ユーザー・プロファイル」または「グループ・プロファイル」ダイアログの「権限」タブをクリックします。このリストから権限を取り消すことも、割り当てることもできます。
Oracle Internet Directoryの権限グループから付与された権限を編集するには、Oracle Internet Directoryで「ユーザー」ポートレットまたは「グループ」ポートレットを使用してユーザーまたはグループを編集します。Oracle Internet Directoryで「権限の割当て」リストの横のチェックマークを付けたり、外したりして、適切な権限を付与したり、取り消したりします。
AUTHENTICATED_USERSグループに付与された権限は、OracleAS Single Sign-Onを通じてOracle Portalにログインしたすべてのユーザーに、認証に成功した時点で与えられます。これは、ログインしたすべてのユーザーを対象にデフォルトの権限で作成するグループです。
たとえば、認証されているユーザーがグループを作成できないようにする場合は、「グループ」ポートレットからAUTHENTICATED_USERSグループを編集し、「権限の割当て」にある「グループの作成を許可」の横のチェックマークを外します。
場合によっては、Oracle Portalプロバイダのコンポーネントで、アプリケーション表のレコードを表示するか、変更するかをユーザーが選択できます。セキュリティを強化するには、不要な場合、このようなコンポーネントからのパブリック・アクセスを取り消す必要があります。また、メニュー・オプションに対して特定のアクセス権を持つメニュー・コンポーネントを使用して、アプリケーション・アクセスをより厳しく制御することもできます。
管理インタフェースにアクセスしてはならないユーザーが管理ページに入るのを防ぐには、次のページ・グループとそれらに含まれているページに対するアクセス権を制御する必要があります。
「ポータル・デザインタイム・ページ」: Oracle Portalホーム・ページ、ビルダー・ページ、ナビゲータ・ページが含まれているページ・グループです。
ポートレット・リポジトリ。
前述のページ・グループへのアクセスを制御するには、次の手順を実行します。
「ナビゲータ」で、「ページ・グループ」をクリックします。
アクセス設定を変更するページ・グループの横の「プロパティの編集」をクリックします。
「アクセス」タブをクリックします。
MANAGE ALLを特定のユーザーまたは特定のグループに付与します。たとえば、DBA、PORTAL_ADMINISTRATORS、PORTAL_DEVELOPERS、独自のグループなどです。
終了したら、「OK」をクリックします。
これらのページ・グループの個々の管理ページへのアクセスを制御するには、次の手順を実行します。
「ナビゲータ」で、「ページ・グループ」をクリックします。
アクセス設定を変更するページが含まれているページ・グループの横の「コンテンツ」をクリックします。
「ページ」をクリックします。
アクセス設定を変更するページの横の「プロパティ」をクリックします。
「アクセス」タブをクリックします。
MANAGE ALLを特定のユーザーまたは特定のグループに付与します。たとえば、DBA、PORTAL_ADMINISTRATORS、PORTAL_DEVELOPERS、独自のグループなどです。
終了したら、「OK」をクリックします。
|
注意: 「ビルダー」ページは、Portal設計時ページというページ・グループのルート・ページです。そのアクセス設定を変更するには、Portal設計時ページ・グループの横の「ルート・ページの編集」をクリックする必要があります。 |
デフォルトのインストールでは、PUBLICに付与されている標準のデータベース手順(dbms_*やutl_*など)を保護します。独自に記述したPL/SQLパッケージをPUBLICに割り当て、それらのパッケージへWebブラウザからアクセスできないようにするときは、『Oracle Fusion Middleware mod_plsqlユーザーズ・ガイド』の「mod_plsqlを使用したアプリケーション・データベース・アクセスの保護」を参照してください。
ポータルに機密情報が含まれている場合は、SSLを使用してポータルを構成することを考慮してください。使用可能なSSL構成オプションは、第7.3.2.1項「Oracle PortalのSSLの構成」を参照してください。
デフォルトでは、Oracle Portalは、ディレクトリに接続するときに、SSLを使用しないLDAPを使用します。ディレクトリ・サーバーがSSLポートに対応している場合は、LDAP over SSL (LDAPS)を使用するようにOracle Portalを構成できます。
|
関連項目: Oracle Fusion Middleware Oracle Internet Directory管理者ガイド |
ディレクトリへの接続にSSLを使用するようにOracle Portalを構成するには、ORACLE_HOME/portal/admin/plsql/wwcにあるsecupoid.sqlスクリプトを実行する必要があります。このスクリプトにより、ディレクトリに関連する次のOracle Portal構成パラメータを変更できます。
ディレクトリのホスト名
ディレクトリ・ポート
アプリケーション・ディレクトリのパスワード
SSL設定
Oracle Portalをインストールすると、ディレクトリ・サーバーを使用するように自動的に構成されます。ただし、SSLを使用するかどうかなど、インストール後に一部の設定を変更できます。ディレクトリのSSL接続を変更するには、PORTALスキーマのsecupoid.sqlスクリプトを実行して、LDAPポートのかわりにLDAPSポートを指定すると、SSLを使用するように指定されます。
この項では、SQL*Plusからsecupoid.sqlを実行した例を示します。
この例では、LDAPをポート389で実行するようにディレクトリを初期構成しています。次にLDAPSポートを636上で有効にします。サーバー名は変わらないため、以前の値を保持したままポートを更新し、SSLを使用することを指定するために「Use SSL?」に対して「Y」を設定します。このスクリプトを実行すると、現在の構成が表示され、変更可能な構成を置き換えることができます。スクリプトの実行後に、Oracle Portalのディレクトリ・キャッシュを更新することもできます。SSLを有効にしても、Oracle Portalによってキャッシュされたディレクトリ情報は変更されません。このため、通常はこうした状況でキャッシュを更新する必要はありません。
SQL> @secupoid Current Configuration -------------------- OID Host: oid.domain.com OID Port: 389 Application DN: orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext Application Password: 3E8C2D1B87CB61011757239C5AA9B390 Use SSL? N PL/SQL procedure successfully completed. Updating OID Configuration Entries Press [Enter] to retain the current value for each parameter For SSL Connection to LDAP, specify "Y"es or "N"o ------------------------------------------------ Enter value for oid_host: Enter value for oid_port: 636 Enter value for app_password: Enter value for use_ssl_to_connect_to_ldap: Y Enter value for refresh_with_new_settings: N PL/SQL procedure successfully completed. No errors.
このスクリプトの実行後に、Oracle Portalは、ディレクトリでLDAPSアクセスを使用するように構成されます。詳細は、第B.2項「secupoid.sqlスクリプトの使用」を参照してください。
Oracle Portalでは、ユーザーのパスワードをディレクトリに渡しません。OracleAS Single Sign-Onのみで、この処理が行われます。ただし、Oracle Portalは、そのアプリケーション・エンティティとパスワードを使用して、ディレクトリに対する認証を行います。
アプリケーション・エンティティのパスワードを変更する場合は、まずコマンドライン・ユーティリティまたはOracle Directory Managerを使用して、ディレクトリ内にあるそのエントリを変更する必要があります。ディレクトリでアプリケーション・エントリを見つけるには、secupoid.sqlスクリプトによって報告されるDNが必要です。デフォルトでは、Oracle Portalのアプリケーション・エントリは次のとおりです。
orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext
パスワードを変更するには、アプリケーション・エントリのuserPassword属性を新しいパスワードに設定します。
ディレクトリのパスワードの変更後に、PORTALスキーマでsecupoid.sqlスクリプトを実行し、同じように新しいパスワードを指定します。スクリプトを実行することで、Oracle Portalでパスワードを暗号化して保存し、ディレクトリへの接続時に検索できるようになります。
secupoid.sqlスクリプトの詳細は、第B.2項「secupoid.sqlスクリプトの使用」を参照してください。
|
関連項目: アプリケーション・エンティティの詳細は、第7.1.7.3.1項「Oracle PortalのOracle Internet Directoryにあるディレクトリ・エントリ」を参照してください。 |
ファイングレイン・アクセス・コントロールと保護アプリケーション・コンテキストがあれば、新しい局面でデータベース内のデータを保護することができます。
ファイングレイン・アクセス・コントロールは、仮想プライベート・データベースまたは行レベルのセキュリティと呼ばれることもあります。Oracle Database 11gのファイングレイン・アクセス・コントロールは、実行時に、データベース表やビューに対して発行されるあらゆる問合せに条件(WHERE句)を動的にアタッチする機能です。この機能を使用すると、実行時にプロシージャで問合せを変更できます。問合せを実行しているユーザー、問合せを実行している場所、問合せを実行している日時などを調べ、それらの状況をふまえて条件を作成することができます。アプリケーション・コンテキストを使用すると、安全に情報を環境(ユーザーが保持するアプリケーション・ロールなど)に追加したり、プロシージャや条件の中でもそれにアクセスしたりできます。
ファイングレイン・アクセス・コントロールの例として、異なるグループのユーザーが表示できる行を特定するセキュリティ・ポリシーを設けることができます。セキュリティ・ポリシーでは、ログインしているユーザーやそのユーザーが属しているグループに基づいて条件を作成します。
ファイングレイン・アクセスとアプリケーション・コンテキストの詳細は、Portal Center(http://portalcenter.oracle.com/)を参照してください。
脚注の凡例
脚注1: デフォルトのID管理レルムの名前は、システムがインストールされているサーバーのドメイン名によって決定されます。たとえば、ドメイン・ネーム・サーバーがoracleであった場合、デフォルトのID管理レルム名はdc=oracle,dc=comとなります。ドメイン・ネーム・サーバーがわからない場合、ディレクトリによって割り当てられているデフォルト名はdc=Default Company,dc=comです。