15.3 Oracle Reportsにおける認証

この項では、Oracle Reportsに固有の認証の機能、タスクおよび概念について説明します。

この項には、次の項目があります。

• OracleAS Single Sign-On認証

• 非SSO認証

• JPSベース・セキュリティの認証シナリオ

• Portalベース・セキュリティの認証シナリオ

認証方法

Oracle Reports 11gリリース1（11.1.1）では、次の認証方法をサポートしています。

• OracleAS Single Sign-On。詳細は、「OracleAS Single Sign-On認証」を参照してください。

• 非SSO。これには次のものが含まれます。

  • Oracle Internet Directory（rwsec、または構成済のJPS-OID）

  • 埋め込みIDストア（インプロセス・サーバー）

  • JAZN-XMLファイルベースのIDストア（スタンドアロン・サーバー）

  
  

  注意: 非SSO認証方法の詳細は、「非SSO認証」を参照してください。

  
  

次の表は、Oracle ReportsがサポートしているJPSベース・セキュリティの認証方法をまとめたものです。

表15-2 JPSベース・セキュリティの認証方法

Reports Serverのタイプ	Oracle Internet Directory	WebLogic IDストア	Single Sign-On	ファイルベース
インプロセス・サーバー				×
スタンドアロン・サーバー		×

次の表は、Oracle ReportsがサポートしているPortalベース・セキュリティの認証方法をまとめたものです。

表15-3 Portalベース・セキュリティの認証方法

Reports Serverのタイプ	Oracle Internet Directoryに基づく認証	Single Sign-On
インプロセス・サーバー
スタンドアロン・サーバー

15.3.1 OracleAS Single Sign-On認証

OracleAS Single Sign-Onでは、暗号化されたCookieを使用して、認証済アプリケーション・ユーザーを追跡管理します。保護されたReports Server上でのレポート実行を指示するユーザー・リクエストをReports Servletで受け取ると、そのユーザーがOracleAS Single Sign-Onを通じてログインしているかどうか（そのユーザーのSingle Sign-On Cookieが存在するかどうか）を確認するために、Oracle HTTP ServerにgetRemoteUserメソッドでコールして問い合せます。

• ユーザーがログインしている場合（Cookieが存在する場合）、Reports Servletがユーザーの識別情報をOracle HTTP Serverから取得します。

• ユーザーがログインしていない場合（Cookieが存在していない場合）、Oracle HTTP ServerがユーザーをOracleAS Single Sign-Onにリダイレクトし、OracleAS Single Sign-Onがユーザーにログインを求めます。ユーザーが認証されると、Single Sign-On Cookieが作成され、そのユーザーはReports Servletにリダイレクトされます。その後、ユーザーがすでにログインしている場合（Cookieが存在する場合）と同様の処理が行われます。

15.3.1.1 Single Sign-Onを使用するレポート・リクエスト・フロー

このシナリオでは、Single Sign-Onが有効で保護されたReports Serverにレポート・リクエストが送信されます。

図15-1 Single Sign-Onを使用する認証プロセス

「図15-1 Single Sign-Onを使用する認証プロセス」の説明

次の各手順の番号は、図15-2の番号に対応しています。

1. ユーザーがURLを使用してレポート・リクエストを送信します。

   レポート・リクエストは、次のいずれかの方法で行われます。

   • レポートをリクエストするURLを含むWebページ上のリンクやブックマークをユーザーが選択します。

     
     

     注意: このURLには、必要に応じて、次の形式の値を持つSingle Sign-Onパラメータ（SSOCONN）が格納されます。または、このURLでキー・マップ・ファイルを介して、そのパラメータを参照します。 key_name/data_source_type/parameter_name Oracleデータベースの場合、Single Sign-On値は次のようになります。 mykey/OracleDB/userid データソース・タイプおよびパラメータ名を指定しない場合は、Oracleデータベースであると見なされます。

     
     

   • Oracle Portal（構成されている場合）の内部から、ユーザーが「実行」リンクをクリックするなどして、レポート・オブジェクトの実行をリクエストします。ユーザーは、Oracle Portalにログインする必要があります。つまり、OracleAS Single Sign-Onにログインする必要があります。Oracle Portalでは、セキュリティの一環として、レポート・オブジェクトの参照に必要なセキュリティ権限がユーザーに付与されていることを確認します。たとえば、あるページ上にレポート・オブジェクトが存在する場合、ユーザーには、そのページとレポート・オブジェクトを参照するための適切な権限が必要です。その権限がない場合、Oracle Portalではユーザーに対してそのページやレポート・オブジェクトが表示されません。

2. Oracle HTTP Serverでは、Oracle WebLogic Serverにデプロイされたrwservletにリクエストがルーティングされます。

   URLでは、このレポートをReports Servlet経由で実行するか、JSP経由で実行するかの設定に応じて、ユーザーをReports ServletまたはJSPにリダイレクトします。

3. Reports Servletは、OracleAS Single Sign-Onにユーザーの認証を要求します。

4. OracleAS Single Sign-Onサーバーがユーザー名とパスワードを要求します。

5. Oracle HTTP Serverがユーザーにログイン・ページを表示し、ユーザーがユーザー名とパスワードを入力します。

6. ユーザー名とパスワードがOracleAS Single Sign-Onに渡されます。

7. OracleAS Single Sign-Onが証明書をOracle Internet Directoryに確認します。

8. ユーザーが認証されると、OracleAS Single Sign-Onサーバーがユーザーが認証されましたというメッセージをReports Servletに渡します。

   URLでSSOCONNを使用した場合、Reports Servletが、Oracle Internet DirectoryでSingle Sign-Onキーを照合して、Single Sign-Onキーがデータソース接続文字列（たとえば、scott/tiger@my_or_db）にマッピングされているかどうかを確認します。

   SSOCONNを使用しており、そのキーに関連付けられている接続文字列がOracle Internet Directoryに存在する場合、Reports Servletではその接続文字列をレポートのデータソース接続に使用します。

   
   

   注意: この機能により、異なるデータソース接続文字列を使用する多くのユーザーが、同じレポートのURLを使用できるようになります。

   
   

   SSOCONNを使用していても、そのキーに対する接続文字列がOracle Internet Directoryに存在しない場合、Oracle Delegated Administration Servicesの「リソースの作成」ページが表示され、ユーザーはそこにデータソース接続文字列を入力します。図15-3を参照してください。

   この文字列は今後の使用のために、Oracle Delegated Administration ServicesによってOracle Internet Directoryに格納され、Reports Servletが、新しく入力された接続文字列をレポートのデータソース接続文字列として使用します。

   図15-3 Oracle Delegated Administration Servicesの「リソースの作成」

   
   「図15-2 Oracle Delegated Administration Servicesの「リソースの作成」」の説明
   
   

15.3.2 非SSO認証

Oracle Internet Directory、JPSベース・セキュリティの場合のファイルベース、および埋め込みIDストアに基づいて、いずれかの非SSO認証方法が使用される場合、Reports Serverのセキュアなインスタンスにユーザーがアクセスする際、独自の認証メカニズムを使用してrwservletまたはReportsクライアントにより識別情報を渡す必要があります。

表15-4 非SSO認証方法

IDストア	認証
Oracle Internet Directory（rwsec、または構成済のJPS-OID）	Oracle Internet Directoryに対する認証
埋め込みIDストア（インプロセス・サーバー）	WebLogic Serverの埋め込みIDストアに対する認証
JAZN-XMLファイルベースのIDストア（スタンドアロン・サーバー）	ファイルベースのIDストアに対する認証

HTTP 1.0プロトコルはステートレスであるため（つまり、サーバーへの各コールは事実上独立しているので）、Cookieが保持されていないかぎり、レポート・リクエストのたびにユーザーの認証が必要になる場合があります。セッションごとに1度の認証で済むように、rwservletには独自のクライアント側Cookie（AUTHID）が格納されます。ここには、現行セッションに必要な認証情報が保存されます。一度ユーザーが認証されると、暗号化されたCookieがブラウザで作成され、ユーザーはリクエストごとに認証を受けることなく、複数のレポート・ジョブを実行できます。

注意: 特定のレポートに対してユーザーに認証を要求する場合は、SHOWAUTHコマンドライン・キーワードを使用できます。または、キー・マップ・ファイル内の対応するレポート・エントリに%Sを使用することもできます。このファイルは通常cgicmd.datと呼ばれ、$DOMAIN_HOME/config/fmwconfig/servers/<WLS_SERVER_NAME>/applications/reports_<version>/configuration/cgicmd.datにあります。%Sを使用すると、ユーザーはレポートをコールするたびに、ユーザー名とパスワードの入力が要求されます。詳細は、第18.13項「キー・マップ・ファイルの使用」を参照してください。

ユーザーがブラウザ・セッションを終了するとAUTHID Cookieも終了しますが、この方法だけでCookieを終了するのは十分とはいえません。セッション内のCookieの存続期間は制限する必要があります。たとえば、ユーザーがログインし、昼食のためにブラウザ・セッションを起動したまま席を外したとします。こうした状況でのセキュリティ侵害の可能性を最小限に抑えるために、管理者は、rwservlet.propertiesファイル内でcookie要素の属性としてCOOKIEEXPIREパラメータを指定できます。

たとえば次のように、rwservlet.propertiesファイルにcookie要素を指定できます。

<cookie cookieexpire="30" encryptionkey="reports"/>

rwservletでジョブ・リクエストが受信されると、Cookieに保存された時間と現在のシステム時間が比較されます。この時間が環境変数で定義された時間（たとえば、30分）を超えていると、Cookieは否定され、ユーザーには認証情報を提供する必要が生じます。

関連項目: COOKIEEXPIREパラメータとrwservlet.propertiesファイルの詳細は、第8.3項「Oracle Reports Servlet構成ファイル」を参照してください。

15.3.2.1 非SSO（Oracle Internet Directoryベース、ファイルベース、または埋め込みIDストア）を使用するレポート・リクエスト・フロー

このシナリオでは、Single Sign-Onが無効で保護されたReports Serverにレポート・リクエストが送信されます。非SSO認証方法には、Oracle Internet Directoryベース、ファイルベース、および埋め込みIDストアが含まれます。この場合、Reports ServletまたはJSPレポートは、ブックマークを使用してコールしたり、Oracle Portalコンポーネントからコールできます。

図15-3 Single Sign-Onを使用しない認証プロセス

「図15-3 Single Sign-Onを使用しない認証プロセス」の説明

次の各手順の番号は、図15-4の番号に対応しています。

1. ユーザーがURLを使用してレポート・リクエストを送信します。

   ユーザーは、Webページ上のリンクやブックマークなどを通じて、レポート・リクエストを送信するURLにアクセスし、そこでURLを選択する必要があります。

2. Oracle HTTP Serverでは、Oracle WebLogic Serverにデプロイされたrwservletにリクエストがルーティングされます。

3. Reports Servletがユーザーの証明書（ユーザー名とパスワード）を要求します。

   Reports Servletは、URLまたは既存のOracle Reports AUTHID Cookieで、AUTHIDパラメータがないかどうかを調べます。AUTHIDパラメータを見つけると、それを使用してユーザーを認証します。AUTHIDパラメータが見つからない場合、既存のOracle Reports AUTHID Cookieを探します（レポートがOracle Portalから起動された場合、AUTHIDがURLに自動的に追加される）。AUTHIDパラメータとOracle Reports AUTHID Cookieのどちらも見つからない場合、Reports Servletが「システム認証」ページをOracle HTTP Serverに送信し、ユーザーに表示します。

4. Oracle HTTP Serverがユーザーにログイン・ページを表示し、ユーザーがユーザー名とパスワードを入力します。

   ログイン・ページでは、ユーザーがユーザー名とパスワードを入力する必要があります。この情報は、後で参照するためにOracle Reports AUTHID Cookieに保存されます。

5. ユーザー名とパスワードがReports Servletに渡されます。

   データソース証明書の一部だけがURLに指定されている場合（たとえば、USERID=scott@orqa）は、データベース認証ページにその一部の証明書が表示されます。ユーザーは、証明書の残りの部分を指定しないと、先に進めません。どのデータベース認証ページを使用するかは、rwservlet.propertiesファイルのDBAUTHパラメータで制御できます。データソース証明書が指定されていない場合は、データベース認証ページが表示されず、レポートにはデータソースが不要であると見なされます。

   
   

   関連項目: DBAUTHパラメータとrwservlet.propertiesファイルの詳細は、第8.3項「Oracle Reports Servlet構成ファイル」を参照してください。

   
   

   データソース証明書は、後で参照するためにOracle Reports USERID Cookieに保存されます。プラッガブル・データ・ソース（PDS）証明書は、Oracle Reports USERID Cookieには保存されないことに注意してください。

6. Reports Servletがユーザー名とパスワードをReports Serverに転送します。

   Reports Servletは、これまでの手順で取得した必要な情報でコマンドラインを作成し、これをReports Serverに渡します。

7. Reports ServerがIDストアに対してユーザーを認証（ユーザー名とパスワードを確認）します。

   Reports Serverは、IDストア（Oracle Internet Directory、埋め込みIDストア、またはファイルベースのOracle Internet Directory）に対してユーザーの資格証明を検証します。この妥当性チェックがなんらかの理由で失敗した場合、ユーザーに対してエラーが返され、この処理が終了します。

15.3.3 JPSベース・セキュリティの認証シナリオ

この項では、次の認証シナリオについて説明します。

• ReportsがJPSセキュリティ、セキュリティ・ポリシー用JPS-OID、および埋め込みIDストアを使用している場合

• ReportsがJPSセキュリティおよび、IDストアとしてのJPS-OIDを使用している場合

  
  

  注意: デフォルトでは、インプロセス・サーバーは、IDストアとしてOracle WebLogic Serverの埋め込みIDストアを使用し、ポリシー・ストアとしてsystem-jazn-data.xmlファイルを使用します。スタンドアロン・サーバーは、IDストアとしてもポリシー・ストアとしてもsystem-jazn-data.xmlファイルを使用します。

  
  

15.3.3.1 ReportsがJPSセキュリティ、セキュリティ・ポリシー用JPS-OID、および埋め込みIDストアを使用している場合

埋め込みIDストアのような現在のIDストア内のユーザーを、LDAPベースのIDストアであるOracle Internet Directoryに移動することをお薦めします。その後で、ユーザーをアプリケーション・ロールにマップできるようになります。Oracle Internet Directoryへのユーザーの移動については、Oracle Fusion Middlewareセキュリティ・ガイドの手動でのIDの移行に関する項を参照してください。ユーザーのアプリケーション・ロールへのマッピングの詳細は、ユーザーのアプリケーション・ロールへのマッピングを参照してください。

15.3.3.2 ReportsがJPSセキュリティおよび、IDストアとしてのJPS-OIDを使用している場合

Oracle Internet Directory内のユーザーをデフォルトのアプリケーション・ロールにマップする必要があります。ユーザーのアプリケーション・ロールへのマッピングの詳細は、ユーザーのアプリケーション・ロールへのマッピングを参照してください。

注意: 前述の認証シナリオで、Single Sign-Onが有効の場合、「シングル・サインオン」画面が表示されます。Single Sign-Onが無効の場合、Reportsのsysauth画面が表示されます。どちらの場合も、ユーザーはOracle Internet Directoryに対して認証されます。ユーザーをOracle Internet Directoryに移動していない場合には、ユーザーはインプロセス・サーバー用の埋め込みIDストアに対して認証されます。スタンドアロン・サーバーでは、そのようなユーザーはファイルベースのIDストア対して認証されます。

15.3.4 Portalベース・セキュリティの認証シナリオ

Portalペース・セキュリティを使用している場合、Oracle Internet Directoryベースの認証が使用されます。

ユーザーをアプリケーション・ロールにマップできます。ユーザーのアプリケーション・ロールへのマッピングの詳細は、ユーザーのアプリケーション・ロールへのマッピングを参照してください。

注意: 前述の認証シナリオで、Single Sign-Onが有効の場合、「シングル・サインオン」画面が表示されます。Single Sign-Onが無効の場合、Reportsのsysauth画面が表示されます。どちらの場合も、ユーザーはOracle Internet Directoryに対して認証されます。