| Oracle® Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド 12c (12.2.1.2) E82763-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド 12c (12.2.1.2) E82763-01 |
|
前 |
次 |
この項では、Oracle Reportsに固有の認証の機能、タスクおよび概念について説明します。
ここでは、次の項目について説明します。
認証方法
Oracle Reports 12cリリース(12.2.1.1)では、次の認証方法をサポートしています。
シングル・サインオン。詳細は、「シングル・サインオン認証」を参照してください。
非SSO。これには次のものが含まれます。
Oracle Internet Directory (rwsec、または構成済のJPS-OID)
埋め込みIDストア(インプロセス・サーバー)
JAZN-XMLファイルベースのIDストア(スタンドアロン・サーバー)
次の表は、Oracle ReportsがサポートしているJPSベース・セキュリティの認証方法をまとめたものです。
表15-2 JPSベース・セキュリティの認証方法
| Reports Serverのタイプ | Oracle Internet Directory | WebLogic IDストア | シングル・サインオン | ファイルベース |
|---|---|---|---|---|
|
インプロセス・サーバー |
はい |
はい |
はい |
いいえ |
|
スタンドアロン・サーバー |
はい |
いいえ |
はい |
はい |
次の表は、Oracle ReportsがサポートしているPortalベース・セキュリティの認証方法をまとめたものです。
表15-3 Portalベース・セキュリティの認証方法
| Reports Serverのタイプ | Oracle Internet Directoryに基づく認証 | シングル・サインオン |
|---|---|---|
|
インプロセス・サーバー |
はい |
はい |
|
スタンドアロン・サーバー |
はい |
はい |
Oracle Reports Servicesアプリケーションは、Oracle Access Manager 11g (OAM)およびOracle Internet Directory (OID)を使用してSingle Sign-On環境で実行できるようになり、同じユーザー・セッション中に多くのアプリケーションにアクセスするための追加または別のログインの必要がなくなりました。Oracle FMW 12cリリース(12.2.1.1)のOracle Reports Servicesアプリケーションは、Single Sign-On環境内の次の認証サーバーにより保護されます。
Oracle Access Manager (OAM) 11g
認証サーバーのインストール中に、ユーザーは、これらの認証サーバーの1つを使用してReportsアプリケーションを認証することを選択できます。これらの認証サーバーは、バックエンド・アイデンティティ・ストアとしてOracle Internet Directoryを使用するように構成する必要があります。認証サーバーは、複数のWebベースのアプリケーションにブラウザからアクセスできるWeb環境で機能するように設計されています。認証サーバーがない場合、各ユーザーはアクセスするアプリケーションごとにIDやパスワードを保持する必要があります。複数のアカウントやパスワードを保持するのは安全とは言えず、しかも効率的ではありません。
Oracle Access Manager 11gはJavaプラットフォームのEnterprise Edition (Java EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、機密情報へのアクセスを制限したり、認証や認可のサービスを一元化します。Oracle Access Manager 11gは、Oracle Fusion Middleware 11gのコンポーネントの1つで、認証と認可のためのシングル・サインオン・ソリューションです。
図15-1に、認証サーバーとしてOracle Access Managerを使用する認証プロセスを示します。
ユーザーがURLを使用してレポート・リクエストを送信します。
Oracle HTTP Serverは、リクエストをOAMサーバーにルーティングします。
OAMサーバーは、ユーザー名とパスワードをリクエストするページを送信します。
ユーザーによって入力された資格証明がOAMサーバーに送信されます。
Oracle Access Manager (OAM)が資格証明をOracle Internet Directoryに確認します。
ユーザーが認証されると、OAMサーバーが「ユーザーが認証されました」というメッセージをrwservletに渡します。
URLでSSOCONNを使用した場合、rwservletが、Oracle Internet DirectoryでSingle Sign-Onキーを照合して、Single Sign-Onキーがデータ・ソース接続文字列(たとえば、scott/tiger@my_or_db)にすでにマッピングされているかどうかを確認します。
SSOCONNを使用しており、そのキーに関連付けられている接続文字列がOracle Internet Directoryにすでに存在する場合、rwservletではその接続文字列をレポートのデータ・ソース接続に使用します。
|
注意: ReportsアプリケーションがOAM 11gサーバーを使用して認証される場合、Single Sign-OnパラメータがNoに設定されていても、Reports認証ページではなく、OAM認証ページが表示されます。 |
SSOCONNを使用していても、そのキーに対する接続文字列がOracle Internet Directoryに存在しない場合、Oracle Reportsにより「キーが存在しません」というエラー・メッセージが表示されます。
Oracle Internet Directory、JPSベース・セキュリティの場合のファイルベース、および埋め込みIDストアに基づいて、いずれかの非SSO認証方法が使用される場合、Reports Serverのセキュアなインスタンスにユーザーがアクセスする際、独自の認証メカニズムを使用してrwservletまたはReportsクライアントにより識別情報を渡す必要があります。
表15-4 非SSO認証方法
| IDストア | 認証 |
|---|---|
|
Oracle Internet Directory ( |
Oracle Internet Directoryに対する認証 |
|
埋め込みIDストア(インプロセス・サーバー) |
WebLogic Serverの埋め込みIDストアに対する認証 |
|
JAZN-XMLファイルベースのIDストア(スタンドアロン・サーバー) |
ファイルベースのIDストアに対する認証 |
HTTP 1.0プロトコルはステートレスであるため(つまり、サーバーへの各コールは事実上独立しているので)、Cookieが保持されていないかぎり、レポート・リクエストのたびにユーザーの認証が必要になる場合があります。セッションごとに1度の認証で済むように、rwservletには独自のクライアント側のCookieであるauthid Cookieが保存されます。ここには、現行セッションに必要な認証情報が格納されます。一度ユーザーが認証されると、暗号化されたCookieがブラウザで作成され、ユーザーはリクエストごとに認証を受けることなく、複数のレポート・ジョブを実行できます。
|
注意: 特定のレポートに対してユーザーに認証を要求する場合は、SHOWAUTHコマンドライン・キーワードを使用できます。または、キー・マップ・ファイル内の対応するレポート・エントリに%Sを使用することもできます。このファイルは通常cgicmd.datと呼ばれ、$DOMAIN_HOME/config/fmwconfig/servers/<WLS_SERVER_NAME>/applications/reports_<version>/configuration/cgicmd.datにあります。%Sを使用すると、ユーザーはレポートをコールするたびに、ユーザー名とパスワードの入力が要求されます。詳細は、第18.14項「キー・マップ・ファイルの使用」を参照してください。 |
ユーザーがブラウザ・セッションを終了するとAUTHID Cookieも終了しますが、この方法だけでCookieを終了するのは十分とはいえません。セッション内のCookieの存続期間は制限する必要があります。たとえば、ユーザーがログインし、昼食のためにブラウザ・セッションを起動したまま席を外したとします。こうした状況でのセキュリティ侵害の可能性を最小限に抑えるために、管理者は、rwservlet.propertiesファイル内でcookie要素の属性としてCOOKIEEXPIREパラメータを指定できます。
たとえば次のように、rwservlet.propertiesファイルにcookie要素を指定できます。
<cookie cookieexpire="30" encryptionkey="reports"/>
rwservletでジョブ・リクエストが受信されると、Cookieに保存された時間と現在のシステム時間が比較されます。この時間が環境変数で定義された時間(たとえば、30分)を超えていると、Cookieは否定され、ユーザーには認証情報を提供する必要が生じます。
このシナリオでは、Single Sign-Onが無効で保護されたReports Serverにレポート・リクエストが送信されます。非SSO認証方法には、Oracle Internet Directoryベース、ファイルベース、および埋め込みIDストアが含まれます。この場合、rwservletまたはJSPレポートは、ブックマークを使用してコールすることも、Oracle Portalコンポーネントからコールすることもできます。
次の各手順の番号は、図15-3の番号に対応しています。
ユーザーがURLを使用してレポート・リクエストを送信します。
ユーザーは、Webページ上のリンクやブックマークなどを通じて、レポート・リクエストを送信するURLにアクセスし、そこでURLを選択する必要があります。
Oracle HTTP Serverでは、Oracle WebLogic Serverにデプロイされたrwservletにリクエストがルーティングされます。
rwservletがユーザーの資格証明(ユーザー名とパスワード)を要求します。
rwservletは、URL内のAUTHIDパラメータまたは既存のOracle Reports AUTHID Cookieを探します。AUTHIDパラメータを見つけると、それを使用してユーザーを認証します。AUTHIDパラメータが見つからない場合、既存のOracle Reports AUTHID Cookieを探します(レポートがOracle Portalから起動された場合、AUTHIDがURLに自動的に追加されます。)AUTHIDパラメータもOracle Reports AUTHID Cookieも見つからない場合、rwservletはユーザーに表示するシステム認証ページをOracle HTTP Serverに送信します。
Oracle HTTP Serverがユーザーにログイン・ページを表示し、ユーザーがユーザー名とパスワードを入力します。
ログイン・ページでは、ユーザーがユーザー名とパスワードを入力する必要があります。この情報は、後で参照するためにOracle Reports AUTHID Cookieに保存されます。
ユーザー名とパスワードがrwservletに渡されます。
データ・ソース証明書の一部だけがURLに指定されている場合(たとえば、USERID=scott@orqa)は、データベース認証ページにその一部の証明書が表示されます。ユーザーは、証明書の残りの部分を指定しないと、先に進めません。どのデータベース認証ページを使用するかは、rwservlet.propertiesファイルのDBAUTHパラメータで制御できます。データ・ソース証明書が指定されていない場合は、データベース認証ページが表示されず、レポートにはデータ・ソースが不要であると見なされます。
データ・ソース証明書は、後で参照するためにOracle Reports USERID Cookieに保存されます。プラガブル・データ・ソース(PDS)証明書は、Oracle Reports USERID Cookieには保存されないことに注意してください。
rwservletがユーザー名とパスワードをReports Serverに転送します。
rwservletは、これまでの手順で取得した必要な情報でコマンドラインを作成し、これをReports Serverに渡します。
Reports ServerがIDストアに対してユーザーを認証(ユーザー名とパスワードを確認)します。
Reports Serverは、IDストア(Oracle Internet Directory、埋め込みIDストア、またはファイルベースのOracle Internet Directory)に対してユーザーの資格証明を検証します。この妥当性チェックがなんらかの理由で失敗した場合、ユーザーに対してエラーが返され、この処理が終了します。
この項では、次の認証シナリオについて説明します。
ReportsがJPSセキュリティおよび、IDストアとしてのJPS-OIDを使用している場合
|
注意: デフォルトでは、インプロセス・サーバーは、IDストアとしてOracle WebLogic Serverの埋め込みIDストアを使用し、ポリシー・ストアとしてsystem-jazn-data.xmlファイルを使用します。スタンドアロン・サーバーは、IDストアとしても、ポリシー・ストアとしてのDBとしてもsystem-jazn-data.xmlファイルを使用します。 |
埋め込みIDストアのような現在のIDストア内のユーザーを、LDAPベースのIDストアであるOracle Internet Directoryに移動することをお薦めします。その後で、ユーザーをアプリケーション・ロールにマップできるようになります。Oracle Internet Directoryへのユーザーの移動については、Oracle Platform Security Servicesによるアプリケーションの保護の「手動によるIDの移行」を参照してください。ユーザーのアプリケーション・ロールへのマッピングの詳細は、「アプリケーション・ロールへのユーザーのマッピング」を参照してください。
Oracle Internet Directory内のユーザーをデフォルトのアプリケーション・ロールにマップする必要があります。ユーザーのアプリケーション・ロールへのマッピングの詳細は、「アプリケーション・ロールへのユーザーのマッピング」を参照してください。
|
注意: 前述の認証シナリオで、Single Sign-Onが有効の場合、「シングル・サインオン」画面が表示されます。Single Sign-Onが無効の場合、Reportsのsysauth画面が表示されます。どちらの場合も、ユーザーはOracle Internet Directoryに対して認証されます。ユーザーをOracle Internet Directoryに移動していない場合には、ユーザーはインプロセス・サーバー用の埋め込みIDストアに対して認証されます。スタンドアロン・サーバーでは、そのようなユーザーはファイルベースのIDストア対して認証されます。 |
Portalペース・セキュリティを使用している場合、Oracle Internet Directoryベースの認証が使用されます。
ユーザーをアプリケーション・ロールにマップできます。ユーザーのアプリケーション・ロールへのマッピングの詳細は、「アプリケーション・ロールへのユーザーのマッピング」を参照してください。
|
注意: 前述の認証シナリオで、Single Sign-Onが有効の場合、「シングル・サインオン」画面が表示されます。Single Sign-Onが無効の場合、Reportsのsysauth画面が表示されます。どちらの場合も、ユーザーはOracle Internet Directoryに対して認証されます。 |
