| Oracle® Fusion Middleware Forms Servicesデプロイメント・ガイド 11g リリース1(11.1.1) B61388-02 |
|
 前 |
 次 |
この章には、次の項が含まれています。
Oracle Forms Servicesアプリケーションは、Oracle Application Server Single Sign-On Server(OracleAS Single Sign-On)とOracle Internet Directoryを使用して、ユーザー名とパスワード情報が格納されるシングル・サインオン環境で実行できます。OracleAS Single Sign-Onは、複数のWebベースのアプリケーションにブラウザからアクセスできるWeb環境で機能するように設計されています。OracleAS Single Sign-Onがない場合、各ユーザーはアクセスするアプリケーションごとにIDやパスワードを保持する必要があります。複数のアカウントやパスワードを保持するのは安全とは言えず、しかも効率的ではありません。
OracleAS Single Sign-On Server 10gは、共有される認証トークンまたは認証局を使用してユーザーを認証するアプリケーション機能です。あるアプリケーションで認証されたユーザーは、同一の認証ドメイン内にある他のすべてのアプリケーションでも自動的に認証されます。
Formsアプリケーションでは、OracleAS Single Sign-On Server 10gはデータベース接続認証を取得するためにのみ使用されます。この接続が確立すれば、OracleAS Single Sign-On Server 10gとの相互作用は発生しません。Formsアプリケーションを終了しても、OracleAS Single Sign-On Server 10gのログアウトは実行されません。また、OracleAS Single Sign-On Serverセッションをログアウトしても、アクティブなFormsセッションは終了しません。データベース・セッションは、サーバーのFormsランタイム(frmweb.exeなど)が(通常は明示的にフォームを終了することによって)終了するまで存続します。
OracleAS Single Sign-On Server 10gを使用すると、オラクル社の製品ではないアプリケーション(カスタムJ2EEアプリケーションなど)も認証できます。
Oracle Formsアプリケーションは、OracleAS Single Sign-On ServerとOracle Internet Directoryに基づいて、企業のOracleAS Single Sign-On Serverアーキテクチャに統合されます。Oracle Forms Servicesでは、サーバー・インスタンスで実行されるすべてのFormsアプリケーションに対するシングル・サインオンが、最初からサポートされています。Formsアプリケーションでさらにコーディングを行う必要はありません。
|
注意: Oracle Forms Servicesアプリケーションは、次のOIDとSSOの組合せを使用して、シングル・サインオン環境で実行されます。
OracleAS Single Sign-Onの詳細は、OTNにある『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。Oracle Internet Directoryの詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。 |
図9-1に、ユーザーが最初にOracleAS Single Sign-On Server 10gで保護されたアプリケーションURLをリクエストした場合におけるOracle FormsのOracleAS Single Sign-On Server 10gサポートの認証フローを示します。
図の左上で、ユーザーは、http(s)://<hostname>:<port>/forms/frmservlet?config= <application>&...のようなForms URLをリクエストします。
|
注意: シングル・サインオンを使用するFormsアプリケーションでは、HTTPまたはWeb Cacheのポート番号をForms URLで指定します。Forms URLはhttp://<host name>:<http port>/forms/frmservlet?config=ssoappのように記述します。ssoappは、Forms構成ファイルの中で(ssoModeを指定して)シングル・サインオンを有効にしたセクションの名前です。 |
Formsサーブレットが、図の左下に示されているOracleAS Single Sign-On Serverログイン・ページにユーザーをリダイレクトします。
ユーザーが、ログイン・フォームでユーザー名とパスワードを指定します。
図の中央に示されているOracle Internet Directory(LDAP Server)で、パスワードが検証されます。
図の右上に示されているように、ユーザーのリクエストがsso_userid情報とともにURLにリダイレクトされます。
FormsサーブレットがOracle Internet Directoryからデータベース接続情報を取得します。
Formsサーブレットがランフォーム・セッションにユーザーIDパラメータを設定し、アプレットのFormsリスナー・サーブレットへの接続を許可します。
FormsサーブレットがFormsサーバーを起動します。
図9-2に、別のパートナ・アプリケーションで認証されたユーザーが、OracleAS Single Sign-On Serverで保護されたアプリケーションをリクエストした場合におけるOracle Forms Servicesのシングル・サインオン・サポートの認証フローを示します。
図の左上に示されているように、ユーザーがForms URLをリクエストします。
Formsサーブレットが、図の左下に示されているOracleAS Single Sign-On Serverサーバーとそのログイン・ページにユーザーをリダイレクトします。
ユーザーのリクエストが、sso_userid情報とともにURLにリダイレクトされます。
Formsサーブレットが、図の中央に示されているOracle Internet Directoryからデータベース接続情報を取得します。
Formsサーブレットがランフォーム・セッションにユーザーIDパラメータを設定し、アプレットがFormsリスナー・サーブレットに接続されます。
Formsサーブレットが、図の右下に示されているFormsサーバーを起動します。
このリリースのOracle Forms Servicesでは、次の機能および拡張機能が利用可能です。
シングル・サインオン・モードでは、ユーザーがFormsを使用してデータベースに接続しようとすると、そのユーザーは、OracleAS Single Sign-On ServerとOracle Internet Directoryの連係動作でmod_ossoによって認証されます。認証されたユーザーは、Formsサーブレットに送られます。Formsサーブレットは、シングル・サインオンのユーザー名が含まれたユーザーのリクエスト情報を取得します。このユーザー名とアプリケーション名によって、Oracle Internet Directoryでこのアプリケーションに対するユーザーのリソース情報を識別する一意のペアが作成されます。
認証されたFormsユーザーが、リクエストしている特定のアプリケーションのリソース、またはOracle Internet Directoryのデフォルトのリソースのいずれも持たない場合、Oracle Internet Directory/DASのセルフサービス・コンソール・ページにリダイレクトされリソースが動的に作成されます。このリソースの作成後、ユーザーは元のFormsのリクエストURLに再びリダイレクトされます。
不足したリソース情報をForms Servicesで処理する方法は、アプリケーションまたはForms Services管理者によってカスタマイズできます。次のオプションが利用可能です。
リソースの動的な作成の許可(デフォルト)
ssoErrorUrlパラメータに指定されている事前定義されたURLへのユーザーのリダイレクト
Formsのエラー・メッセージの表示
システム管理者は、Forms構成ファイルにリダイレクションURL(絶対URLまたは相対URL)を指定します。
Formsでのシングル・サインオンの適用はformsweb.cfgファイルで行われます。シングル・サインオン・パラメータssoModeをTRUEに設定すると、アプリケーションはOracleAS Single Sign-On Serverによる認証を要求します。
このパラメータを使用すると、データベースのパスワードで保護されているアプリケーションとOracleAS Single Sign-On Serverで保護されているアプリケーションの両方を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でのOracleAS Single Sign-On Serverによるそのユーザーの認証が引き続き機能します。ただし、Oracle FormsではなくSQL*PLUSでパスワードが変更された場合、データベース接続文字列はOracle Internet Directoryで更新されません。
シングル・サインオン・モードでFormsアプリケーションを実行すると、Oracle Fusion Middlewareの次のソフトウェア・コンポーネントが使用されます。
OracleAS Single Sign-On Server - Oracle Fusion Middlewareの認証サービス。Oracle Internet Directoryを使用してユーザー名とパスワードを格納します。
mod_osso - HTTPモジュールmod_ossoは、OracleAS Single Sign-On Serverに対する唯一のパートナ・アプリケーションとして認証プロセスを簡素化し、アプリケーションで認証を透過的に行います。Oracle Forms ServicesおよびOracle Reports Servicesは、mod_ossoを使用してOracleAS Single Sign-On Serverにパートナ・アプリケーションとして登録します。
Oracle Internet Directory - LDAP V3準拠のディレクトリ・サーバー。ユーザーのログイン情報を格納します。LDAPサーバーは、読取りアクセス用に最適化された特別なデータベースです。
Formsサーブレット - Oracle Forms Servicesコンポーネント。最初のユーザー・リクエストを受け取り、Formsアプリケーションを起動します。Formsサーブレットは、アプリケーションでOracleAS Single Sign-On Serverが必要かどうかを検出し、リクエストをOracleAS Single Sign-On Serverにダイレクトし、Oracle Internet Directoryにアクセスしてデータベースの接続情報を取得します。
formsweb.cfg - Forms構成ファイル。Formsアプリケーションでシングル・サインオンを有効にするためのパラメータが含まれます。formsweb.cfgファイルは、$DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/configディレクトリにあります。
Oracle Formsアプリケーションは、中央の構成ファイル($DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/configディレクトリにあるformsweb.cfgファイル)を使用して構成されます。formsweb.cfgファイルの管理には、Fusion Middleware Controlを使用することをお勧めします。
シングル・サインオンおよびエラー処理は、formsweb.cfgファイル内の次のパラメータで定義されます。
ssoMode [true|false]
ssoProxyConnect [yes|no]
ssoDynamicResourceCreate [true|false]
ssoErrorUrl [文字列URL]
ssoCancelUrl [文字列URL]
formsweb.cfgファイル内のこれらのOracle Formsパラメータは、User Parameterセクションで設定します。これらのパラメータは、サーバーで実行されるすべてのFormsアプリケーションの動作を定義します。これらのパラメータは、Named Configurationで設定することもできます。これらは特定のアプリケーションのみに対して定義されます。Named Configurationセクションで設定したシングル・サインオン・パラメータは、User Parameterセクションで設定した同一のパラメータよりも優先して適用されます。
アプリケーションのシングル・サインオンを有効にするには:
Fusion Middleware Controlを起動します。
「Forms」メニューから「Web構成」を選択します。
アプリケーションの構成セクションをリストする行を選択します。
「セクション」リージョンの「表示」ドロップ・ダウン・リストからssoを選択します。
「セクション」リージョンで、ssoModeを含む行を選択します。
「値」フィールドに、trueと入力します。
「適用」をクリックしてformsweb.cfgファイルを更新します。
選択したアプリケーションでシングル・サインオンが有効になります。
アプリケーションのシングル・サインオンを無効にするには:
「Forms」メニューから「Web構成」を選択します。
アプリケーションの構成セクションをリストする行を選択します。
「セクション」リージョンの「表示」ドロップ・ダウン・リストからssoを選択します。
「セクション」リージョンで、ssoModeを含む行を選択します。
「値」列に、falseと入力します。
「適用」をクリックします。
選択したアプリケーションでシングル・サインオンが無効になります。
ssoModeパラメータを使用して、Forms ServicesアプリケーションをOracleAS Single Sign-On Serverに接続できます。デフォルトでは、Oracle Formsアプリケーションは、シングル・サインオン・モードで実行するようには構成されません。ssoModeパラメータは、formsweb.cfgファイル内の2つの場所で設定できます。
ssoProxyConnectパラメータを使用することにより、ユーザーは、Oracle Formsでデータベースへのプロキシ接続を使用するかどうかを制御できます。ssoProxyConnectパラメータは、次の2つの方法で設定できます。
ssoDynamicResourceCreateパラメータはデフォルトでtrueに設定されます。これにより、ユーザーはOracle Internet Directoryでリソース・アクセス記述子(RAD)エントリを作成し、アプリケーションを実行できます(このリソース・エントリが存在しない場合)。使用されるWebページは、Oracle Delegated Administration Servicesで用意された標準フォームです。このWebページはOracle Forms固有のものであるため、カスタマイズできません。
リソースが動的に作成されることによって、管理者がユーザーの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アプリケーションでOracleAS Single Sign-On Serverの認証情報を扱う場合は、必要に応じて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).
|
注意: configは非シングル・サインオン・モードでも取得できます。 |
Formsを非SSOモードでインストールおよび構成した後に、SSOを有効にする必要がある場合は、次の手順に従います。次の手順を実行して、WebTier OHSのモジュールmod_ossoを、パートナ・アプリケーションとしてOracleAS Single Sign-On Serverに登録します。
「OIDホストをFormsアプリケーションに再度関連付けるには」のステップ3とステップ4に従い、osso.confファイルを作成してコピーします。
$ORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/moduleconfディレクトリにmod_osso.confファイルを作成します。このファイルの内容は次のようになります。
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
mod_osso.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項「Oracle Internet Directoryの構成」のトピック「OIDホストをFormsアプリケーションに関連付けるには」に従って、Enterprise ManagerでOIDホストを関連付けます。
変更を有効にするために、Oracle WebLogic管理対象サーバー(WLS_FORMS)とフロントエンドOHSを再起動します。
Oracle Reportsは、OracleAS Single Sign-On Serverを有効にしてインストールします。
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項「アプリケーションでのOracleAS Single Sign-Onの有効化」を参照してください。
Reportsでのシングル・サインオンの構成の詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』を参照してください。
Oracle FormsとOracle Reportsの統合の詳細は、http://www.oracle.com/technology/products/forms/でホワイト・ペーパーOracle Forms 11gとOracle Reports 11gの統合を参照してください。
11gリリース1(11.1.1)よりも前のOracle ReportsではジョブIDを順番に生成していたので、ジョブIDを容易に予測できました。その結果、認可されていないユーザーや悪意のあるユーザーがrwservlet経由でGETJOBIDを使用してジョブの出力を見ることができ、別のユーザーのジョブ出力を取得する可能性がありました。11gのOracle Reportsでは、ジョブIDの生成を順番どおりではなくランダム化しているので、特定のジョブのジョブIDを予測することは不可能です。レポートの出力を見ることができるのは、Oracle Forms Servicesでそのレポートを実行しているユーザーのみです。ジョブIDはランダムであり、順序どおりの番号になっていないので、他のユーザーがレポート出力を見ることはできません。
保護されていない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ファイルでreports_servermap要素を設定する必要があります。例:
<reports_servermap>
cluster:repserver
</reports_servermap>
詳細は、『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』を参照してください。
この項は、次の小項目に分かれています。
Oracle E-Business Suiteなどの大規模なアプリケーションの多くでは、すべての接続で単一のユーザー名が使用されます。これにより、多くの場合、大企業に適した方法でユーザーを管理できますが、監査に関する問題が発生します。レコードの挿入、更新および削除のすべてでは、シングル・ユーザーにより実行されるようにデータベースでは見えます。監査をリストアするには、アプリケーション開発者は、カスタマイズされた監査コードをデータベースにおいて記述して実装する必要があります。コードでは、ユーザー名をアプリケーションからデータベースに渡す必要があります。この手順は、開発時間が必要になるだけでなく、Oracle Databaseで実装済の機能と重複することにもなります。2番目の問題はセキュリティです。シングル・ユーザーのアクセスは脆弱であり、脆弱なユーザーがアプリケーション・スキーマ全体にアクセスできてしまいます。これらの問題に対処するために、Oracle Databaseではプロキシ・ユーザー認証がサポートされています。これによって、クライアント・ユーザーはデータベースにアプリケーション・サーバー経由でプロキシ・ユーザーとして接続できます。
図9-3は、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にそれぞれ設定します。
プロキシ接続で使用されるユーザー名とパスワードは、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公開ガイド』を参照してください。
Formsアプリケーションを介してプロキシ・ユーザーとして接続するユーザーは、OracleAS Single Sign-On ServerとOracle Internet Directoryでも定義しておく必要があります。Oracle Formsでは、OracleAS Single Sign-On Serverを介してこのユーザーを認証します(プロキシ・ユーザーを使用する際、FormsではOracleAS Single Sign-On Serverを使用する必要があります)。次に、Oracle Formsはデータベースにプロキシ・ユーザーとして接続しますが、その接続で使用するプロキシ・ユーザーの名前とパスワードは、アプリケーション・ユーザー用のOracle Internet DirectoryエントリのRADに格納されています。
Oracle FormsとOracle Identity Managementの統合の詳細は、第11.1.4項「Oracle Identity Management Infrastructureの使用」を参照してください。
|
注意: Enterprise Managerを使用してOracle Web Cacheポートを変更する場合は、osso.confを再生成し、生成したosso.confファイルを$ORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/moduleconfディレクトリにコピーします。変更を有効にするために、Oracle HTTP ServerとOracle Web Cacheを再起動します。 |
「OIDの関連付け/関連付けの解除」ページにアクセスするには:
Oracle Enterprise Managerを起動します。
Formsのホーム・ページにナビゲートします。
「Forms」メニューから「OIDの関連付け/関連付けの解除」を選択します。
「OIDの関連付け/関連付けの解除」ページが表示されます。
OIDホストをFormsアプリケーションに関連付けるには:
Oracle Internet DirectoryホストをFormsアプリケーションに初めて関連付けるには、「OIDの関連付け/関連付けの解除」ページでそのFormsアプリケーションを選択します。「関連付け」をクリックします。
「関連付け」ダイアログが表示されます。
表9-1「Oracle Internet Directoryホストの詳細」に従ってOracle Internet Directoryホストの詳細を入力します。
「関連付け」をクリックします。
「OIDの関連付け/関連付けの解除」ページが再び表示されます。
表9-1 Oracle Internet Directoryホストの詳細
| パラメータ | 説明 |
|---|---|
|
OIDホスト |
リストからOracle Internet Directoryホストを選択するか、「新規OIDホスト」を選択して新しいホストの詳細を追加します。 |
|
新規OIDホスト |
LDAPディレクトリ・サーバーのホスト名このフィールドは、新規のOracle Internet Directoryホストを追加する場合に有効になります。 |
|
新規OIDポート |
LDAPがリスニングしているポート番号このフィールドは、新規のOracle Internet Directoryホストを追加する場合に有効になります。 |
|
ユーザー名 |
Oracle管理者のユーザー名 |
|
パスワード |
Oracle管理者のパスワード |
|
SSLポートの使用 |
Oracle Internet Directoryホストへの接続でSSLを使用する場合はこのボックスを選択します(この場合、指定するポート番号は、SSLポートとなります)。 |
OracleAS Single Sign-On Serverで、$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でssoreg.batファイルを実行します。
生成されたosso.confファイルを$ORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/にコピーします。詳細は、OTNでOracle Application Server Single Sign-On管理者ガイドを参照してください。
変更を有効にするために、Oracle WebLogic管理対象サーバーとフロントエンドOHSを再起動します。
アクティブなFormsセッションからユーザーが誤って接続解除されないように、Oracle WebLogic管理対象サーバーとフロントエンドOHSの再起動は、ユーザーがFormsセッションを実行していない都合の良い時間に実行するようにします。
OIDホストとFormsアプリケーションの関連付けを解除するには:
「OIDの関連付け/関連付けの解除」ページから、Formsアプリケーションを選択します。「関連付けの解除」をクリックします。
「確認」ボックスが表示されます。
「はい」をクリックします。
Oracle Internet DirectoryホストとFormsアプリケーションの関連付けが解除されます。
変更を有効にするために、Oracle WebLogic管理対象サーバーとフロントエンドOHSを再起動します。
アクティブなFormsセッションからユーザーが誤って接続解除されないように、Oracle WebLogic管理対象サーバーとフロントエンドOHSの再起動は、ユーザーがFormsセッションを実行していない都合の良い時間に実行するようにします。
OIDホストをFormsアプリケーションに再度関連付けるには:
「OIDの関連付け/関連付けの解除」ページから、Formsアプリケーションを選択します。「関連付けの解除」をクリックします。
「OIDの関連付け/関連付けの解除」ページから、Formsアプリケーションを選択します。「関連付け」をクリックします。
表9-1「Oracle Internet Directoryホストの詳細」に従ってOracle Internet Directoryホストの詳細を入力します。
OracleAS Single Sign-On Serverで、$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でssoreg.batファイルを実行します。
生成されたosso.confファイルを$ORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/にコピーします。詳細は、OTNでOracle Application Server Single Sign-On管理者ガイドを参照してください。
変更を有効にするために、Oracle WebLogic管理対象サーバーとフロントエンドOHSを再起動します。
アクティブなFormsセッションからユーザーが誤って接続解除されないように、Oracle WebLogic管理対象サーバーとフロントエンドOHSの再起動は、ユーザーがFormsセッションを実行していない都合の良い時間に実行するようにします。
