| Oracle® Fusion Middleware Forms Servicesデプロイメント・ガイド 11gリリース2 (11.1.2) B66165-03 |
|
 前 |
 次 |
この章には、次の項が含まれています。
Oracle Forms Servicesアプリケーションは、Oracle Single Sign-On Server 10g(OSSO)との連動に加えて、Oracle Access Manager 11g(OAM)およびOracle Internet Directory(OID)を使用してシングル・サインオン環境で実行できるようになり、同じユーザー・セッション中に多くのアプリケーションにアクセスするための追加または別のログインの必要がなくなりました。
Oracle FMW 11gリリース2にあるOracle Forms Servicesアプリケーションは、次の認証サーバーの1つを使用して保護できます。
Oracle Access Manager(OAM)11g
Oracle Single Sign-On Server(OSSO)10g
Forms and Reports 11gリリース2のインストール中に、ユーザーは、これらの認証サーバーの1つを使用してFormsアプリケーションを認証することを選択できます。これらの認証サーバーは、バックエンド・アイデンティティ・ストアとしてOracle Internet Directoryを使用するように構成する必要があります。認証サーバーは、複数のWebベースのアプリケーションにブラウザからアクセスできるWeb環境で機能するように設計されています。認証サーバーがない場合、各ユーザーはアクセスするアプリケーションごとにIDやパスワードを保持する必要があります。複数のアカウントやパスワードを保持するのは安全とは言えず、しかも効率的ではありません。
Oracle Access Manager 11gはJavaプラットフォームのEnterprise Edition(Java EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、機密情報へのアクセスを制限したり、認証や認可のサービスを一元化します。Oracle Access Manager 11gは、Oracle Fusion Middleware 11gのコンポーネントの1つで、認証と認可のためのシングル・サインオン・ソリューションです。
認証サーバーを使用すると、アプリケーションで共有認証トークンまたは認証局を使用してユーザーを認証できるようになります。あるアプリケーションで認証されたユーザーは、同一の認証ドメイン内にある他のすべてのアプリケーションでも自動的に認証されます。
Formsアプリケーションでは、Oracle Internet Directoryからデータベース接続情報を取得するためにのみ、シングル・サインオン・ソリューションが使用されます。データベース情報を取得した後は、認証サーバーとの連携は発生しません。Formsアプリケーションを終了しても、シングル・サインオンのログアウトは実行されません。また、シングル・サインオン・セッションからログアウトしても、アクティブなFormsセッションは終了しません。データベース・セッションは、サーバーのFormsランタイム(frmweb.exeなど)が(通常は明示的にフォームを終了することによって)終了するまで存続します。
認証サーバーを使用すると、Oracle製品ではないアプリケーション(カスタムJava EEアプリケーションなど)も認証できます。
Oracle Forms Servicesでは、サーバー・インスタンスで実行されるすべてのFormsアプリケーションに対するシングル・サインオンが、最初からサポートされています。Formsアプリケーションでさらにコーディングを行う必要はありません。
|
注意: Oracle Forms Servicesアプリケーションは、次のOIDと認証サーバーの組合せを使用して、シングル・サインオン環境で実行されます。
シングル・サインオンの詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。 Oracle Access Managerの詳細は、『Oracle Fusion Middleware Oracle Access Manager管理者ガイド』を参照してください Oracle Internet Directoryの詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。 |
認証サーバーを使用したシングル・サインオン・モードでFormsアプリケーションを実行するときに関連する、Oracle Fusion Middlewareの様々なシングル・サインオン・コンポーネントがあります。図9-1に、Forms Servicesのシングル・サインオン・デプロイメント設定に関連する、様々なコンポーネントの上位レベルの概要を示します。
図9-1 Forms Servicesのシングル・サインオン・デプロイメント設定に関連するコンポーネント
前述の図で示されたコンポーネントの説明を次に示します。
認証サーバー
Oracle Access Manager(OAMサーバー) - これは、Webシングル・サインオン、認証、認可などを含む全セキュリティ機能を提供するOracle FMW 11g認証サーバーです。Forms Servicesを実行するときに、アイデンティティ・ストアとしてOracle Internet Directoryを使用します。Oracle Access Managerは、Oracle HTTP Serverに対して構成されるアクセス・クライアントとしてmod_ossoまたはwebgateを使用できます。
Oracle Single Sign-On Server(OSSOサーバー) - これはOracleAS 10g認証サーバーです。アイデンティティ・ストアとしてOracle Internet Directoryを使用します。Oracle Single Sign-On Serverは、Oracle HTTP Serverに対して構成されるアクセス・クライアントとしてmod_ossoを使用します。
アクセス・クライアント
webgate - WebGateはシングル・サインオン・サポートを提供します。これは受信HTTPリクエストをインターセプトし、認証のためにそれらをアクセス・サーバーに転送します。Oracle Forms ServicesおよびOracle Reports Servicesは、OAMサーバーに対するアクセス・クライアントとしてwebgateを使用できます。
mod_osso - HTTPモジュールmod_ossoは、OAMサーバーに対するパートナ・アプリケーションとして機能し、アプリケーションに対して認証を透過的に行うことによって、認証プロセスを簡素化します。Oracle Forms ServicesおよびOracle Reports Servicesは、mod_ossoを使用して、OAMサーバーにパートナ・アプリケーションを登録できます。mod_ossoも、Oracle Single Sign-On server(OSSO)に対するアクセス・クライアントとして使用されます。
アイデンティティ・ストア
Oracle Internet Directory(OID)は、認証サーバーおよびFormsアプリケーションによってアイデンティティ・ストアとして使用されるLDAPサーバーです。LDAPサーバーは、読取りアクセス用に最適化された特別なデータベースです。
Forms Servlet - Formsアプリケーションを起動する最初のユーザー・リクエストを受け取るOracle Forms Servicesコンポーネントです。Formsサーブレットは、アプリケーションに認証が必要かどうかを検出してリクエストを認証サーバーに転送し、Oracle Internet Directoryにアクセスしてデータベース接続情報を取得します。
図9-2に、認証サーバーで保護されたアプリケーションURLをユーザーが最初にリクエストしたときの、Oracle Formsでの認証サーバー・サポートの認証フローを示します。
ユーザーは、http(s)://<hostname>:<port>/forms/frmservlet?config= <application>&...のようなForms URLをリクエストします。
|
注意: シングル・サインオンを使用するFormsアプリケーションでは、HTTPまたはWeb Cacheのポート番号をForms URLで指定します。Forms URLは |
Formsサーブレットは、認証サーバー・ログイン・ページにユーザーをリダイレクトします。
ユーザーが、ログイン・フォームでユーザー名とパスワードを指定します。
Oracle Internet Directory(LDAPサーバー)で、パスワードが検証されます。
ユーザーは、sso_userid情報とともにそのURLにリダイレクトされます。
FormsサーブレットがOracle Internet Directoryからデータベース接続情報を取得します。
Formsサーブレットは、ランフォーム・セッションにsso_useridパラメータを設定し、アプレットのFormsリスナー・サーブレットへの接続を許可します。
FormsサーブレットがFormsサーバーを起動します。
図9-3に、別のパートナ・アプリケーションで認証されたユーザーが、認証サーバーで保護されたアプリケーションをリクエストした場合におけるOracle Forms Servicesのシングル・サインオン・サポートの認証フローを示します。
ユーザーは、Forms URLをリクエストします。
Formsサーブレットは、認証サーバーおよびそのログイン・ページにユーザーをリダイレクトします。
ユーザーのリクエストが、sso_userid情報とともにURLにリダイレクトされます。
FormsサーブレットがOracle Internet Directoryからデータベース接続情報を取得します。
Formsサーブレットは、ランフォーム・セッションにsso_useridパラメータを設定し、アプレットがFormsリスナー・サーブレットに接続します。
FormsサーブレットがFormsサーバーを起動します。
ユーザーは、インストール時またはインストール後に、Formsアプリケーションにシングル・サインオンを有効化できます。この項では、次のシナリオについて説明します。
ユーザーが、Oracle Forms and Reports 11g R2のインストール時にアプリケーション・アイデンティティ・ストアおよび認証サーバーを選択すると、FormsアプリケーションはOracle AS認証サーバーで認証されるように構成されます。図9-4のフローチャートに、FormsアプリケーションのSSO認証を有効化する手順を示します。
このフローチャートに示した手順の詳細を表9-1に示します。
表9-1 インストール時にFormsアプリケーションのシングル・サインオンを有効化するためのタスク
| タスク | オプション | 説明 | コメント |
|---|---|---|---|
|
タスク1: アプリケーション・アイデンティティ・ストア(OID)の選択 |
いいえ |
ユーザーは、シングル・サインオン認証でFormsを構成しないことを選択します。 |
|
|
はい |
ユーザーは、シングル・サインオン認証でFormsを構成することを選択します。ユーザーは、インストール画面でOIDアクセス詳細を入力する必要があります。ユーザーは、続くインストール画面で、SSOサーバーの選択を求められます。 |
アプリケーション・アイデンティティ・ストアを選択する手順の詳細は、『Oracle Fusion Middleware Oracle Forms and Reportsインストレーション・ガイド』のOracle Forms and Reportsインストレーションおよび構成画面のフローチャートに関する説明を参照してください。 |
|
|
タスク2: 認証(SSO)サーバーの選択 |
Oracle Single Sign-On Server (OSSO) |
ユーザーは、認証/SSOサーバーとしてOracle AS 10g Oracle Single Sign On Server(OSSO)を選択します。ここでは追加の資格証明は不要です。 |
認証サーバーを選択する手順の詳細は、『Oracle Fusion Middleware Oracle Forms and Reportsインストレーション・ガイド』のOracle Forms and Reportsインストレーションおよび構成画面のフローチャートに関する説明を参照してください。 |
|
OAMサーバー |
ユーザーは、認証/SSOサーバーとしてOracle Access Manager(OAMサーバー)を選択します。ユーザーは、OAMサーバーの管理者資格証明を入力する必要があります。 |
認証サーバーを選択する手順の詳細は、『Oracle Fusion Middleware Oracle Forms and Reportsインストレーション・ガイド』のOracle Forms and Reportsインストレーションおよび構成画面のフローチャートに関する説明を参照してください。 |
|
|
タスク3: Webgateアクセス・クライアントの設定 |
いいえ |
ユーザーは、初期状態の設定で、FormsアプリケーションをOAM認証サーバーに対して構成することを選択します。 |
|
|
はい |
ユーザーは、webgateをアクセス・クライアントとして使用し、FormsアプリケーションをOAM認証サーバーに対して構成することを選択します。ユーザーは、Webgateを手動でインストールして構成する必要があります。 |
Webgateアクセス・クライアントの設定手順の詳細は、第9.7.4項「OAMに対するWebgateのインストールと構成」を参照してください。 |
|
|
タスク4: formsweb.cfgでのFormsアプリケーションに対するSSOの有効化 |
このタスクは必須です。 |
認証サーバーにアクセス・クライアントを登録した後で、ユーザーは、Formsアプリケーションに対してSSOを有効化する必要があります。 |
formsweb.cfgでFormsアプリケーションに対してSSOを有効化する手順の詳細は、第9.4項「シングル・サインオンでのFormsアプリケーションの保護」を参照してください。 |
|
注意: インストール時のFormsアプリケーションのシングル・サインオンの有効化の詳細は、『Oracle Fusion Middleware Oracle Forms and Reportsインストレーション・ガイド』を参照してください。 |
ユーザーがOracle Forms and Reports 11g R2のインストール中にアプリケーション・アイデンティティ・ストアを選択しない場合、Formsアプリケーションは認証サーバーで認証されません。ただし、ユーザーはインストール後に、Formsアプリケーションに対するシングル・サインオンの有効化を選択できます。図9-5のフローチャートに、インストール後にFormsアプリケーションに対してSSOを有効化する手順を示します。
このフローチャートに示した手順の詳細を表9-2に示します。
表9-2 インストール後にFormsアプリケーションのシングル・サインオンを有効化するためのタスク
| タスク | オプション | 説明 | コメント |
|---|---|---|---|
|
タスク1: Fusion Middleware Control(EM)を使用したFormsアプリケーションとOIDの関連付け |
ユーザーは、FormsアプリケーションをOracle Internet Directoryと関連付けることを選択します。 |
アプリケーション・アイデンティティ・ストアを選択する手順の詳細は、第9.7.1項「Oracle Internet Directoryに対するForms J2EEの構成」を参照してください。 |
|
|
タスク2: 認証(SSO)サーバーの選択 |
Oracle Single Sign-On Server (OSSO) |
ユーザーは、認証サーバーとしてOracle AS 10g Oracle Single Sign On Server(OSSO)を選択しました。 |
すでにOracle Single Sign-On (OSSO) 10gサーバーがインストールされている場合は、それを使用できます。そうでない場合は、Oracle Access Manager 11gをインストールできます。OAM 11gのインストール手順の詳細は、『Oracle Fusion Middleware Oracle Forms and Reportsインストレーション・ガイド』を参照してください。 |
|
OAMサーバー |
ユーザーは、認証サーバーとしてOracle Access Manager(OAMサーバー)を選択しました。 |
OAM 11gのインストール手順の詳細は、『Oracle Fusion Middleware Oracle Forms and Reportsインストレーション・ガイド』を参照してください。 |
|
|
タスク3: osso.confファイルの生成および適用 |
Oracle Single Sign-On Server (OSSO) |
ユーザーは、認証サーバーとしてOracle AS 10g Oracle Single Sign-On Server(OSSO)を選択しました。ユーザーは、OSSOサーバー・ホームから |
認証サーバーでの |
|
OAMサーバー |
ユーザーは、認証サーバーとしてOracle Access Manager(OAMサーバー)を選択しました。ユーザーは、OAMコンソールを使用してOAMサーバーで |
||
|
タスク4: Webgateアクセス・クライアントの設定 |
いいえ |
この場合、追加の手順は必要ありません。mod_ossoがアクセス・クライアントとして設定されます。 |
|
|
はい |
ユーザーは、webgateをアクセス・クライアントとして使用し、FormsアプリケーションをOAM認証サーバーに対して構成することを選択します。ユーザーは、Webgateを手動でインストールして構成する必要があります。 |
Webgateアクセス・クライアントの設定手順の詳細は、第9.7.4項「OAMに対するWebgateのインストールと構成」を参照してください。 |
|
|
タスク5: formsweb.cfgでのFormsアプリケーションに対するSSOの有効化 |
このタスクは必須です。 |
認証サーバーにアクセス・クライアントを登録した後で、ユーザーは、Formsアプリケーションに対してSSOを有効化する必要があります。 |
formsweb.cfgでFormsアプリケーションに対してSSOを有効化する手順の詳細は、第9.4項「シングル・サインオンでのFormsアプリケーションの保護」を参照してください。 |
このリリースのOracle Forms Servicesでは、次の機能および拡張機能が利用可能です。
シングル・サインオン・モードでは、ユーザーがFormsアプリケーションに接続しようとしたときに、認証サーバーおよびOracle Internet Directoryと組み合せてmod_ossoまたはwebgateでユーザーが認証されます。認証されたユーザーは、Formsサーブレットに送られます。Formsサーブレットは、シングル・サインオンのユーザー名が含まれたユーザーのリクエスト情報を取得します。このユーザー名とアプリケーション名によって、Oracle Internet Directoryでこのアプリケーションに対するユーザーのリソース情報を識別する一意のペアが作成されます。
認可されたFormsユーザーが、リクエストしている特定のアプリケーションのリソース、またはOracle Internet Directoryのデフォルトのリソースのいずれも持たない場合、ユーザーはリソース・アクセス記述子の作成のために、DASまたはForms RAD Servletにリダイレクトされます。このリソースの作成後、ユーザーは元のFormsのリクエストURLにリダイレクトされます。
不足したリソース情報をForms Servicesで処理する方法は、アプリケーションまたはForms Services管理者によってカスタマイズできます。次のオプションが利用可能です。
リソースの動的な作成の許可(デフォルト)
ssoErrorUrlパラメータに指定されている事前定義されたURLへのユーザーのリダイレクト
Formsのエラー・メッセージの表示
システム管理者は、Forms構成ファイルにリダイレクションURL(絶対URLまたは相対URL)を指定します。
Formsでのシングル・サインオンの適用はformsweb.cfgファイルで行われます。シングル・サインオン・パラメータssoModeにFALSE以外の有効な値が設定されている場合は、アプリケーションが認証サーバーによる認証を必要としていることを示します。
このパラメータによって、Forms Servicesインスタンスで、データベース・パスワードを取得するためにシングル・サインオンに依存するアプリケーション・タイプと依存しないアプリケーション・タイプの両方を処理できます。シングル・サインオンはformsweb.cfgファイルで構成するので、Enterprise Manager Fusion Middleware Controlを使用して、認証のこの側面を管理できます。
Oracle Formsの以前のリリースでは、データベース・パスワードは問題なく変更できましたが、これらの変更(期限切れも含む)はOracle Internet Directoryに伝播されませんでした。
Oracle Forms Services 11gでは、データベース・パスワードが期限切れになり、かつシングル・サインオン・モードで実行されるForms Servicesアプリケーションを使用してパスワードが更新された場合、ユーザーが入力した新しいパスワードによって、Oracle Internet Directoryでこのアプリケーションのリソース・アクセス記述子(RAD)が更新されます。この機能により、Formsユーザーのデータベース・パスワードが変更されても、Formsでの認証サーバーによるそのユーザーの認証が引き続き機能します。ただし、Oracle FormsではなくSQL*Plusでパスワードが変更された場合、データベース接続文字列はOracle Internet Directoryで更新されません。
Oracle Formsアプリケーションは、集中構成ファイル($DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/configにあるformsweb.cfgファイル)を使用して構成されます。formsweb.cfgファイルの管理には、Fusion Middleware Controlを使用することをお薦めします。
ユーザーが個別のFormsアプリケーションまたは複数のFormsアプリケーションのシングル・サインオンを有効化するには、Oracle Forms Services構成ファイルformsweb.cfgに定義されている次のパラメータを使用する必要があります。このファイルは、Fusion Middleware Controlを使用して管理することをお薦めします。
表9-3 シングル・サインオンの有効化に使用するパラメータ
| パラメータ名 | 有効値 | デフォルト値 |
|---|---|---|
|
ssoMode |
mod_osso true webgate false |
false |
|
ssoProxyConnect |
yes no |
yes |
|
ssoDynamicResourceCreate |
true false |
true |
|
ssoErrorUrl |
URLの文字列 |
|
|
ssoCancelUrl |
URLの文字列 |
|
注意: これらのパラメータの詳細および可能な値を次に説明します。 |
formsweb.cfgファイル内のこれらのOracle Formsパラメータは、User Parameterセクションで設定します。これらのパラメータは、サーバーで実行されるすべてのFormsアプリケーションの動作を定義します。これらのパラメータは、Named Configurationで設定することもできます。これらは特定のアプリケーションのみに対して定義されます。Named Configurationセクションで設定したシングル・サインオン・パラメータは、User Parameterセクションで設定した同一のパラメータよりも優先して適用されます。
アプリケーションのシングル・サインオンを有効にするには:
Fusion Middleware Controlを起動します。
「Forms」メニューから「Web構成」を選択します。
アプリケーションの構成セクションをリストする行を選択します。
「セクション」リージョンの「表示」ドロップ・ダウン・リストからssoを選択します。
「セクション」リージョンで、ssoModeを含む行を選択します。
「値」フィールドに、mod_ossoまたはwebgateまたはTRUEと入力します。
「適用」をクリックしてformsweb.cfgファイルを更新します。
選択したアプリケーションでシングル・サインオンが有効になります。
アプリケーションのシングル・サインオンを無効にするには:
「Forms」メニューから「Web構成」を選択します。
アプリケーションの構成セクションをリストする行を選択します。
「セクション」リージョンの「表示」ドロップ・ダウン・リストからssoを選択します。
「セクション」リージョンで、ssoModeを含む行を選択します。
「値」列に、FALSEと入力します。
「適用」をクリックします。
選択したアプリケーションでシングル・サインオンが無効になります。
ssoModeパラメータを使用して、Forms Servicesアプリケーションを認証サーバーに接続できます。シングル・サインオン・パラメータssoModeに設定できる値を次に示します。
ssoModeをTRUEまたはmod_ossoに設定すると、アプリケーションがOAMサーバーまたはOracleAS Single Sign-On Serverによる認証を要求することを示します。
ssoModeをwebgateに設定すると、アプリケーションがwebgateをアクセス・クライアントとして使用してOAMサーバーによる認証を要求することを示します。Webgateは、手動でインストールして構成する必要があります。
ssoModeをFALSEに設定すると、アプリケーションが認証サーバーによる認証を要求しないことを示します。
デフォルトでは、Oracle Formsアプリケーションは、シングル・サインオン・モードで実行するようには構成されません。ssoModeパラメータは、formsweb.cfgファイル内の次の2つの場所で設定できます。
ssoProxyConnectパラメータを使用することにより、ユーザーは、Oracle Formsでデータベースへのプロキシ接続を使用するかどうかを制御できます。ssoProxyConnectパラメータは、次の2つの方法で設定できます。
ssoDynamicResourceCreateパラメータはデフォルトでtrueに設定されます。これにより、ユーザーはOracle Internet Directoryでリソース・アクセス記述子(RAD)エントリを作成し、アプリケーションを実行できます(このリソース・エントリが存在しない場合)。
リソースが動的に作成されることによって、管理者がユーザーのRAD情報を事前に作成する必要がなくなるため、Oracle Internet Directoryの管理が簡素化されます。ssoDynamicResourceCreateパラメータは、システム・パラメータとしてformsweb.cfgファイルに設定するか、名前を付けた構成のパラメータとして設定できます。デフォルトでtrueに設定されているため、このパラメータを特定のアプリケーションの名前を付けた構成で使用し、デフォルトとは異なる方法で不足したRADエントリを処理できます。
ssoDynamicResourceCreateパラメータをfalseに設定してアプリケーションでシングル・サインオンを有効にし、ssoErrorURLに値を指定しないでおくと、認証されたユーザーとこのアプリケーションにRADリソースがない場合にOracle Formsにエラー・メッセージが表示されます。
管理者にとって、ユーザーが自分自身のリソースを作成することは望ましくないこともあるため(Oracle Internet Directoryで問題を起こす可能性もあるため)、管理者はこれらのパラメータを使用して、Oracle Internet Directoryのリソース作成を制御できます。デフォルトの動作では、リソースを作成できるHTMLフォームにユーザーをダイレクトしますが、管理者はその設定を変更し、ユーザーをカスタムURLにリダイレクトできます。
Formsアプリケーションの構成セクションで、次のパラメータを設定する必要があります。
[myApp]form=myFmxssoMode=truessoDynamicResourceCreate=false
Enterprise Manager Fusion Middleware Controlを使用してこれらのパラメータを設定する方法の詳細は、第4.2.4項「パラメータの管理」を参照してください。
管理者はssoErrorURLパラメータを使用して、特定のアプリケーションにユーザーのRADエントリがない場合の処理を行うリダイレクションURLを指定できます。このパラメータは、ssoDynamicResourceCreateパラメータがfalseに設定され、動的リソース作成の動作が無効になっている場合にのみ有効になります。ssoErrorURLパラメータは、デフォルト・セクションで定義できるほか、名前を付けた構成セクションのパラメータとして定義することもできます。URLには、任意のアプリケーション、静的HTMLファイル、RADを作成するカスタム・サーブレット(JSP)アプリケーション(次の例を参照)などを指定できます。
[myApp] form=myFmx ssoMode=true ssoDynamicResourceCreate=false ssoErrorURL=http://example.com:7779/servlet/handleCustomRADcreation.jsp …
ssoCancelURLパラメータは動的RAD作成機能(ssoDynamicResourceCreate= true)とともに使用します。このパラメータでは、ユーザーがHTMLフォーム(要求されたアプリケーションのRADエントリを動的に作成するためのフォーム)で取消しボタンを押した場合にリダイレクトされるURLが定義されます。
Formsアプリケーションで情報を認証するための認証サーバーを扱う場合は、必要に応じてGET_APPLICATION_PROPERTY()ビルトインを使用すると、ログイン情報(シングル・サインオンのユーザーID、ユーザー識別名(dn)およびサブスクライバ識別名(サブスクライバdn))を取得できます。
authenticated_username := get_application_property(SSO_USERID); userDistinguishedName := get_application_property(SSO_USRDN); subscriberName := get_application_property(SSO_SUBDN); config := get_application_property(CONFIG).
Formsアプリケーション開発者は、アクセス・クライアントとしてmod_ossoまたはwebgateを使用している場合、OracleAS Single Sign-On serverまたはOracle Access Managerを使用してSSOモードでシングル・サインオンのユーザーID、サブスクライバ識別名(サブスクライバdn)、ユーザー識別名(dn)などのSSO情報を取得できます。
|
注意:
|
Oracle Reportsは、認証サーバーが有効化された状態でインストールされます。
Oracle Formsアプリケーションで統合Oracle Reportsをコールする最適な方法は、Oracle FormsビルトインのRUN_REPORT_OBJECTを使用することです。
SSOを有効にしたFormsアプリケーションからレポートを要求する場合、RUN_REPORT_OBJECTビルトインへの各コールを使用して、認証されたユーザーのSSOアイデンティティが暗黙的にReports Serverに渡されます。必要に応じてさらに認可チェックを行う場合は、このSSOアイデンティティを使用してReports Serverへのユーザーを認証します。
非SSOモードで実行されているFormsアプリケーションは、SSOで保護されたReports Serverのレポートを実行できますが、Reports Serverで認可が要求されるとレポートは実行できなくなります。また、Web上でReports出力を取得する場合、ユーザーは自身のSSO資格情報を指定する必要があります。
Formsでのシングル・サインオンの有効化の詳細は、第9.4項「シングル・サインオンでのFormsアプリケーションの保護」を参照してください。
Reportsでのシングル・サインオンの構成の詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』を参照してください。
Oracle FormsとOracle Reportsの統合の詳細は、http://www.oracle.com/technetwork/developer-tools/forms/overview/index.htmlでホワイト・ペーパーOracle Forms 11gとOracle Reports 11gの統合を参照してください。
11gリリース1(11.1.1)よりも以前のOracle Reportsでは、連番のジョブIDが生成されていました。その結果、認可されていないユーザーや悪意のあるユーザーがrwservlet経由でGETJOBIDを使用してジョブの出力を見ることができ、別のユーザーのジョブ出力を取得する可能性がありました。11gのOracle Reportsでは、ランダムかつ不連続なジョブIDを生成して、特定のジョブのジョブIDを予測不能にできます。この機能は、インストール後に有効化する必要があります。レポートの出力を見ることができるのは、Oracle Forms Servicesでそのレポートを実行しているユーザーのみです。ジョブIDはランダムであり、順序どおりの番号になっていないので、他のユーザーがレポート出力を見ることはできません。
ランダムかつ不連続なジョブIDの生成の詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』を参照してください。
保護されていないReports Serverでは、Reports Serverの構成ファイルにある識別子要素に、管理者のユーザーIDとパスワードを設定できます。
ユーザーに対するアクセス・レベルの構成の詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』を参照してください。
以前のリリースのOracle Forms アプリケーションで複数のReports Serverクラスタ名を使用する場合は、各クラスタ名を別のReports Serverにマップできます。Oracle Reports 11g リリース1(11.1.1)では、Reports Serverのクラスタ化はお薦めされていません。以前のリリースで作成したOracle FormsアプリケーションでReports Serverクラスタ名を使用している場合は、参照先のReports Serverクラスタにバインドできません。
この問題を解決するには、reports_servermap要素でクラスタ名をReports Server名にマップします。これにより、すべてのOracle Formsアプリケーションでクラスタ名を変更する必要がなくなります。
Oracle Formsアプリケーションでは、次の方法でOracle Reportsをコールできます。
RUN_REPORT_OBJECTの使用: コールで指定する名前がReports Server名ではなく、Reports Serverクラスタ名である場合は、Oracle Forms Servicesのdefault.envファイルでreports_servermap環境変数を設定する必要があります。Oracle Formsアプリケーションで複数のReports Serverクラスタ名を使用している場合は、rwservlet.propertiesで次のようにreports_servermapを使用して、各クラスタ名を別のReports Serverにマップできます。
<reports_servermap>
cluster1:repserver1;cluster2:repserver2;cluster3:repserver3
</reports_servermap>
たとえば、10.1.2のOracle Formsアプリケーションにdev_cluster、prd_clusterおよびqa_clusterという名前の3つのクラスタが含まれる場合、10.1.2よりも後のリリースでは、これらのクラスタ名を次のようにそれぞれ別のサーバー名にマップできます。
<reports_servermap>
dev_cluster:dev_server;prd_cluster:prd_server;qa_cluster:qa_server
</reports_servermap>
WEB.SHOW_DOCUMENTの使用: この場合はリクエストがrwservletに送信されます。Reports Server名ではなくReports Serverクラスタ名がコールで指定されていると、rwservlet.propertiesファイルでrwservlet.properties要素を設定する必要があります。例:
<reports_servermap>
cluster:repserver
</reports_servermap>
詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』を参照してください。
この項は、次の小項目に分かれています。
Oracle E-Business Suiteなどの大規模なアプリケーションの多くでは、すべての接続で単一のユーザー名が使用されます。これにより、多くの場合、大企業に適した方法でユーザーを管理できますが、監査に関する問題が発生します。レコードの挿入、更新および削除のすべてでは、シングル・ユーザーにより実行されるようにデータベースでは見えます。監査をリストアするには、アプリケーション開発者は、カスタマイズされた監査コードをデータベースにおいて記述して実装する必要があります。コードでは、ユーザー名をアプリケーションからデータベースに渡す必要があります。この手順は、開発時間が必要になるだけでなく、Oracle Databaseで実装済の機能と重複することにもなります。2番目の問題はセキュリティです。シングル・ユーザーのアクセスは脆弱であり、脆弱なユーザーがアプリケーション・スキーマ全体にアクセスできてしまいます。これらの問題に対処するために、Oracle Databaseではプロキシ・ユーザー認証がサポートされています。これによって、クライアント・ユーザーはデータベースにアプリケーション・サーバー経由でプロキシ・ユーザーとして接続できます。
図9-6は、Formsプロキシ・ユーザーの認証を示します。
図の中央に示されているOracle Internet Directory(LDAP)を使用して、Oracle Formsでユーザーが認証されます。
Formsではプロキシ・ユーザーとして接続(パスワードを使用する場合と使用しない場合のどちらか)し、実際のユーザー名をOracle Internet Directoryリポジトリから渡します。
通常、プロキシ・ユーザーは最低限の権限で構成されています。次の手順では、プロキシ・ユーザーには接続権限とセッション作成権限が割り当てられています。
データベースでは、プロキシ・ユーザー用にcreateセッション・アクションを受け付け、実際のユーザー名を監査とアクセス制御で使用します。
Oracle Internet Directoryのユーザーは、プロキシ・ユーザー・アカウントの構成がないとデータベースに単独では接続できません。
プロキシ・ユーザー・アカウントは、SQL *Plusにクライアントが直接接続できないようにします。
Formsでプロキシ・サポートを使用できるようにするには、まずプロキシ・ユーザーを作成する必要があります。この例では、プロキシ・ユーザー名はmidtierです。
データベースにプロキシ・ユーザーを作成します。
SQL> CREATE USER midtier IDENTIFIED BY midtierPW;
midtierへの接続を割り当て、midtierへのセッション権限を作成します。
SQL> GRANT CONNECT,CREATE SESSION TO midtier;
この時点で、このプロキシ・ユーザーは接続権限とセッション作成権限を持っていますが、どのユーザー・スキーマに対しても権限はありません。
SSOユーザー名に対して1対1でマップしたデータベース・ユーザーを作成します(たとえば、SSOユーザー名がappuserであれば、appuserというデータベース・ユーザーを作成します)。
SQL> CREATE USER appuser IDENTIFIED BY appuserPW;
appuserにセッション作成権限を割り当てます。
SQL> GRANT CREATE SESSION TO appuser;
midtierユーザーを介して接続できるようにするには、次のようにデータベース・ユーザーを変更する必要があります。
SQL> ALTER USER appuser GRANT CONNECT THROUGH midtier;
これで、ユーザーappuserがmidtierアカウントを介して接続できるようになります。
また、次のようにプロキシ・ユーザーからデータベースへの接続が可能なロールを定義することもできます。
SQL> ALTER USER appuser GRANT CONNECT THROUGH midtier WITH ROLE <role_name>;
プロキシ・ユーザー・アカウントを使用する必要があるすべてのデータベース・ユーザーについて、ステップ3とステップ4を繰り返します。
また、エンタープライズ・ユーザー・セキュリティと呼ばれるデータベース機能を使用することで、データベース・ユーザーをOracle Internet Directoryで設定することもできます。この方法を選択すると、プロキシ・ユーザーは、データベースにおいて定義された唯一のユーザーになり、管理が容易になるという利点があります。エンタープライズ・ユーザー・セキュリティの使用の詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11gリリース1(11.1.1)を参照してください。
アプリケーション・ユーザーのパスワードは、データベースに渡されません。アプリケーション・ユーザーの名前、プロキシ・ユーザーの名前とパスワードのみ渡されます。Formsでは、OCIコールを使用して、次のコマンドと同等のコマンドを発行します。
SQL> connect midtier[appuser]/midtierPW@databaseTnsName
たとえば、必ずmidtierを使用してデータベースに接続するアプリケーションがあるとします。このmidtierからは、実際のユーザーがappuserであることがデータベースに通知されます。プロキシ・ユーザーを使用しない場合、SQLコマンドselect USER from DUALはmidtierを返しますが、プロキシ・ユーザーを使用すると、この問合せはappuserを返します。これは、ユーザーが他の方法で認証済であることを信頼し、パスワードなしでのユーザー接続を許可して接続のロールを付与するようにデータベースに指示していることになります。
|
注意:
|
formweb.cfgにシングル・サインオン用の構成セクション(たとえばssoapp)を作成し、SSOProxyConnectをyes、ssoModeをtrueまたはmod_ossoまたはwebgateに設定します。
プロキシ接続で使用されるユーザー名とパスワードは、Oracle Internet Directoryにおいてログオン・ユーザー用のRADエントリに定義されています。ssoProxyConnect=yesに設定されている場合、Formsによって発行された接続文字列は有効になります。
SQL> connect RADUsername[appuserName]/RADPassword@databaseTnsName
プロキシ・ユーザーの接続とシングル・サインオンを有効にした後、次の手順を実行してFormsアプリケーションにアクセスします。
http://<host name>:<http port>/forms/frmservlet?config=ssoappというURLを使用して、Formsアプリケーションを実行します。ssoappはシングル・サインオン(ssoMode)を有効にした構成セクションの名前です。
シングル・サインオンのユーザー名とパスワードを使用してログインします(第9.6.2項「プロキシ・ユーザー接続の有効化」で取り上げたこの例では、シングル・サインオンのユーザー名はappuser、パスワードはappuserPWです)。
ビルトインのget_application_propertyには、IS_PROXY_CONNECTION(ブール型)の新しいパラメータがあります。このパラメータが渡されたときに、Formsがプロキシ・ユーザー・モードで実行していると、コールによりtrueが返されます。それ以外の場合は、falseが返されます。
プロキシ・ユーザーがFormsで使用されていると、Reportsとの統合が維持されます。Oracle Reports管理者は、プロキシ・ユーザーを設定する必要があります。Reportsの構成ファイルで次の構成が完了していることを確認してください。
rwserver.confに、Forms構成セクション名(frm_config_name)とプロキシ・ユーザー・サポート用に構成されているデータベースSID名(dbname)を入力します。
<dbProxyConnKeys>
<dbProxyKey name="frm_config_name" database="dbname"/>
</dbProxyConnKeys>
rwservlet.propertiesで、プロキシ・モードが有効になっていることを確認します。
<enabledbproxy>yes</enabledbproxy>
Reportsの構成ファイルの詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』を参照してください。
この項では、インストール後のいくつかの手順について説明します。これらの手順はオプションであり、第9.2項「設定プロセス」での選択に応じて、これらの手順の実行が必要になることがあります。この項のトピックは、次のとおりです。
Formsアプリケーションを介してプロキシ・ユーザーとして接続するユーザーは、認証サーバーとOracle Internet Directoryにも定義する必要があります。Oracle Formsでは、認証サーバーを介してこのユーザーを認証します(プロキシ・ユーザーを使用する際、Formsでは認証サーバーを使用する必要があります)。次に、Oracle Formsはデータベースにプロキシ・ユーザーとして接続しますが、その接続で使用するプロキシ・ユーザーの名前とパスワードは、アプリケーション・ユーザー用のOracle Internet DirectoryエントリのRADに格納されています。
Oracle FormsとOracle Identity Managementの統合の詳細は、第11.1.4項「Oracle Identity Management Infrastructureの使用」を参照してください。
|
注意: Enterprise Managerを使用してOracle Web Cacheポートを変更する場合は、 |
「OIDの関連付け/関連付けの解除」ページにアクセスするには:
Oracle Enterprise Managerを起動します。
Formsのホーム・ページにナビゲートします。
「Forms」メニューから「OIDの関連付け/関連付けの解除」を選択します。
「OIDの関連付け/関連付けの解除」ページが表示されます。
OIDホストをFormsアプリケーションに関連付けるには:
Oracle Internet DirectoryホストをFormsアプリケーションに初めて関連付けるには、「OIDの関連付け/関連付けの解除」ページでそのFormsアプリケーションを選択します。「関連付け」をクリックします。
「関連付け」ダイアログが表示されます。
表9-4「Oracle Internet Directoryホストの詳細」の記載に従って、Oracle Internet Directoryホストの詳細を入力します。
「関連付け」をクリックします。
「OIDの関連付け/関連付けの解除」ページが再び表示されます。
表9-4 Oracle Internet Directoryホストの詳細
| パラメータ | 説明 |
|---|---|
|
OIDホスト |
リストからOracle Internet Directoryホストを選択するか、「新規OIDホスト」を選択して新しいホストの詳細を追加します。 |
|
新規OIDホスト |
Oracle Internet Directoryサーバーのホスト名。このフィールドは、新規のOracle Internet Directory(OID)ホストを選択して追加した場合に有効になります。 |
|
新規OIDポート |
Oracle Internet Directoryでリスニングが行われているポート番号。このフィールドは、新規のOracle Internet Directoryホストを追加する場合に有効になります。 |
|
ユーザー名 |
Oracle Internet Directory管理者のユーザー名 |
|
パスワード |
Oracle Internet Directory管理者パスワード |
|
SSLポートの使用 |
Oracle Internet Directoryホストへの接続でSSLを使用する場合はこのボックスを選択します(この場合、指定するポート番号は、SSLポートとなります)。 |
第9.7.2項「アクセス・クライアント・ファイルの生成」の記載に従って、アクセス・クライアント・ファイルを生成して適用します。
OIDホストとFormsアプリケーションの関連付けを解除するには:
「OIDの関連付け/関連付けの解除」ページから、Formsアプリケーションを選択します。「関連付けの解除」をクリックします。
「確認」ボックスが表示されます。
「はい」をクリックします。
Oracle Internet DirectoryホストとFormsアプリケーションの関連付けが解除されます。
変更を有効にするために、Oracle WebLogic管理対象サーバーとフロントエンドOHSを再起動します。
アクティブなFormsセッションからユーザーが誤って接続解除されないように、Oracle WebLogic管理対象サーバーとフロントエンドOHSの再起動は、ユーザーがFormsセッションを実行していない都合の良い時間に実行するようにします。
OIDホストをFormsアプリケーションに再度関連付けるには:
「OIDの関連付け/関連付けの解除」ページから、Formsアプリケーションを選択します。「関連付けの解除」をクリックします。
「OIDの関連付け/関連付けの解除」ページから、Formsアプリケーションを選択します。「関連付け」をクリックします。
表9-4「Oracle Internet Directoryホストの詳細」の記載に従って、Oracle Internet Directoryホストの詳細を入力します。
第9.7.2項「アクセス・クライアント・ファイルの生成」の記載に従って、アクセス・クライアント・ファイルを生成して適用します。
認証サーバー用に、アクセス・クライアント・ファイルを生成する必要があります。アクセス・クライアント・ファイルの生成手順は、OracleAS Single Sign-On 10gまたはOracle Access Manager 11gのいずれを使用しているかによって異なります。
OracleAS Single Sign-On Server 10g用のosso.confファイルの生成
次の手順を実行して、OSSO Server用のosso.confファイルを生成します。
認証サーバーのORACLE_HOME/sso/binにあるssoreg.shスクリプトを実行します。
ORACLE_HOME/sso/bin/ssoreg.sh
-oracle_home_path <ORACLE_HOME>
-site_name www.example.com
-config_mod_osso TRUE
-mod_osso_url http://www.oidtierexample.com:7777
-config_file osso.conf
-remote_midtier
|
注意: Windowsで |
生成されたosso.confファイルをORACLE_INSTANCE/config/OHS/<OHS_INSTANCEにコピーします。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。
変更を有効にするために、Oracle WebLogic管理対象サーバー(WLS_FORMS)とフロントエンドOHSを再起動します。
アクティブなFormsセッションからユーザーが誤って接続解除されないように、Oracle WebLogic管理対象サーバーとフロントエンドOHSの再起動は、ユーザーがFormsセッションを実行していない都合の良い時間に実行するようにします。
Oracle Access Manager用のosso.confファイルの生成
次の手順を実行して、OAM Server用のosso.confファイルを生成します。
OAMコンソールにログインします。
「システム構成」タブにナビゲートします。「エージェント」を選択し、「OSSOエージェント」ノードにナビゲートします。「作成」をクリックします。
ベースURLなどの詳細すべてを指定します。「ポリシーの自動作成」チェック・ボックスが選択されていることを確認します。
「適用」をクリックします。
OAMサーバー用にosso.confファイルが生成されます。このファイルの場所は、OAMコンソールに示されます。
生成されたosso.confファイルをORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>にコピーします。
OHSを再起動して、変更を有効にします。
アクティブなFormsセッションからユーザーが誤って接続解除されないように、Oracle WebLogic管理対象サーバーとフロントエンドOHSの再起動は、ユーザーがFormsセッションを実行していない都合の良い時間に実行するようにします。
OAMコンソールを使用したosso.confファイルの生成の詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの管理者コンソールを使用したOSSOエージェントの登録と管理に関する説明を参照してください。
Formsを非SSOモードでインストールして構成することを選択した後で、SSOを有効にする必要がある場合は、次のタスクを実行する必要があります。後でSSOを有効化するには、mod_ossoをOHS内のパートナ・アプリケーションとして認証サーバーに登録する必要があります。これを実行する手順を次に示します。
第9.7.2項「アクセス・クライアント・ファイルの生成」に記載されている手順に従って、osso.confファイルを生成してコピーします。
mod_osso.confファイルをORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/moduleconfディレクトリに作成します。ファイルは次の例のようになります。
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIpCheck off
OssoSecureCookies off
OssoIdleTimeout off
OssoConfigFile osso.conf
#
# Insert Protected Resources: (see Notes below for
# how to protect resources)
#
#______-
#
# Notes
#
#______-
#
# 1. Here's what you need to add to protect a resource,
# e.g. <ApacheServerRoot>/htdocs/private:
#
<Location /private>
require valid-user
AuthType Osso
</Location>
</IfModule> # # If you would like to have short hostnames redirected to # fully qualified hostnames to allow clients that need # authentication via mod_osso to be able to enter short # hostnames into their browsers uncomment out the following # lines # #PerlModule Apache::ShortHostnameRedirect #PerlHeaderParserHandler Apache::ShortHostnameRedirect
次の行をforms.confファイルの先頭に追加します。
<IfModule !mod_osso.c>
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
</IfModule>
<IfModule mod_osso.c>
OssoHTTPOnly off
</IfModule>
第9.7.1項「Oracle Internet Directoryに対するForms J2EEの構成」の「OIDホストをFormsアプリケーションに関連付けるには」の記載に従って、Enterprise Managerを使用してOIDホストを関連付けます。
変更を有効にするために、Oracle WebLogic管理対象サーバー(WLS_FORMS)とフロントエンドOHSを再起動します。
webgateをOracle Access Manager 11gと連携させるには、webgateを手動でインストールして構成する必要があります。webgateをアクセス・クライアントとしてインストールして構成する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managmentインストレーション・ガイド』のOAM用のOracle HTTP Server 11g Webgateのインストールと構成に関する説明を参照してください。
インストール後に、webgateをOAM 11gに対して登録し、webgateがOracle Access Manager 11gサービスと直接通信できるようにします。webgateをOAM 11gに登録するには、次の手順を実行します。
RREGツールまたはOAMコンソールを使用してwebgate 11gエージェントを作成します。
webgateエージェントを作成する際、次のURLを保護されているリソース・リストに追加する必要があります。
/forms/frmservlet?*oamMode=true*
"/"および"/.../"をパブリック・リソース・リストに追加します。
次の例に示すように、ObAccessClient.xmlおよびcwallet.ssoを該当するOHSのwebgateインスタンス・ディレクトリにコピーします。
cp <OAM_DOMAIN_HOME>/output/<Agent_Name>/*.xml <WEBGATE_INSTANCE>/webgate/config
OAMコンソールまたはRREGツールを使用してwebgateをエージェントとして登録する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managmentインストレーション・ガイド』の新しいWebgateエージェントの登録に関する説明を参照してください。
|
注意: webgateアクセス・クライアントがOracle Access Manager 11gと連携するようにインストールして構成した後に、ユーザーがアクセス・クライアントとしてwebgateを使用して初めてFormsアプリケーションにアクセスする際、java例外エラーが表示されます。この問題を回避するには、HTTPOnlyパラメータを無効にする必要があります。これを実行する手順を次に示します。
|
