Oracle® Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド 11g リリース 1 (11.1.1) B61375-04 |
|
![]() 前 |
![]() 次 |
この項では、Oracle Reportsに固有の認証の機能、タスクおよび概念について説明します。
ここでは、次の項目について説明します。
認証方法
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ストア(スタンドアロン・サーバー)
次の表は、Oracle ReportsがサポートしているJPSベース・セキュリティの認証方法をまとめたものです。
表15-2 JPSベース・セキュリティの認証方法
Reports Serverのタイプ | Oracle Internet Directory | WebLogic IDストア | シングル・サインオン | ファイルベース |
---|---|---|---|---|
インプロセス・サーバー |
はい |
はい |
はい |
いいえ |
スタンドアロン・サーバー |
はい |
いいえ |
はい |
はい |
次の表は、Oracle ReportsがサポートしているPortalベース・セキュリティの認証方法をまとめたものです。
表15-3 Portalベース・セキュリティの認証方法
Reports Serverのタイプ | Oracle Internet Directoryに基づく認証 | シングル・サインオン |
---|---|---|
インプロセス・サーバー |
はい |
はい |
スタンドアロン・サーバー |
はい |
はい |
OracleAS Single Sign-Onでは、暗号化されたCookieを使用して、認証済アプリケーション・ユーザーを追跡管理します。保護されたReports Server上でのレポート実行を指示するユーザー・リクエストをrwservlet
が受け取ると、そのユーザーがOracleAS Single Sign-Onを通じてすでにログインしているかどうか(そのユーザーのSingle Sign-On Cookieが存在するかどうか)を確認するために、Oracle HTTP ServerにgetRemoteUser
メソッドでコールして問い合せます。
ユーザーがすでにログインしている場合(Cookieが存在する場合)、rwservlet
がユーザーの識別情報をOracle HTTP Serverから取得します。
ユーザーがまだログインしていない場合(Cookieが存在しない場合)、Oracle HTTP ServerがユーザーをOracleAS Single Sign-Onにリダイレクトし、OracleAS Single Sign-Onがユーザーにログインを求めます。ユーザーが認証されると、Single Sign-On Cookieが作成され、そのユーザーはrwservlet
にリダイレクトされます。その後、ユーザーがすでにログインしている場合(Cookieが存在する場合)と同様の処理が行われます。
このシナリオでは、Single Sign-Onが有効で保護されたReports Serverにレポート・リクエストが送信されます。
次の各手順の番号は、図15-2の番号に対応しています。
ユーザーがURLを使用してレポート・リクエストを送信します。
レポート・リクエストは、次のいずれかの方法で行われます。
レポートをリクエストするURLを含むWebページ上のリンクやブックマークをユーザーが選択します。
注意: このURLには、必要に応じて、次の形式の値を持つSingle Sign-Onパラメータ(
Oracleデータベースの場合、Single Sign-On値は次のようになります。
データソース・タイプおよびパラメータ名を指定しない場合は、Oracleデータベースであると見なされます。 |
Oracle Portal(構成されている場合)の内部から、ユーザーが「実行」リンクをクリックするなどして、レポート・オブジェクトの実行をリクエストします。ユーザーは、Oracle Portalにログインする必要があります。つまり、OracleAS Single Sign-Onにログインする必要があります。Oracle Portalでは、セキュリティの一環として、レポート・オブジェクトの参照に必要なセキュリティ権限がユーザーに付与されていることを確認します。たとえば、あるページ上にレポート・オブジェクトが存在する場合、ユーザーには、そのページとレポート・オブジェクトを参照するための適切な権限が必要です。その権限がない場合、Oracle Portalではユーザーに対してそのページやレポート・オブジェクトが表示されません。
Oracle HTTP Serverが、Oracle WebLogic Serverにデプロイされたrwservlet
にリクエストをルーティングします。
URLでは、このレポートをrwservlet
経由で実行するか、JSP経由で実行するかの設定に応じて、ユーザーをrwservlet
またはJSPにリダイレクトします。
rwservlet
がOracleAS Single Sign-Onにユーザーの認証を要求します。
OracleAS Single Sign-Onサーバーがユーザー名とパスワードを要求します。
Oracle HTTP Serverがユーザーにログイン・ページを表示し、ユーザーがユーザー名とパスワードを入力します。
ユーザー名とパスワードがOracleAS Single Sign-Onに渡されます。
OracleAS Single Sign-Onが資格証明をOracle Internet Directoryに確認します。
ユーザーが認証されると、OracleAS Single Sign-onサーバーが「ユーザーが認証されました」というメッセージをrwservlet
に渡します。
URLでSSOCONN
を使用した場合、rwservlet
が、Oracle Internet DirectoryでSingle Sign-Onキーを照合して、Single Sign-Onキーがデータソース接続文字列(たとえば、scott/tiger@my_or_db
)にすでにマッピングされているかどうかを確認します。
SSOCONN
を使用しており、そのキーに関連付けられている接続文字列がOracle Internet Directoryにすでに存在する場合、rwservlet
ではその接続文字列をレポートのデータソース接続に使用します。
注意: この機能により、異なるデータソース接続文字列を使用する多くのユーザーが、同じレポートのURLを使用できるようになります。 |
SSOCONN
を使用していても、そのキーに対する接続文字列がOracle Internet Directoryに存在しない場合、Oracle Delegated Administration Servicesの「リソースの作成」ページが表示され、ユーザーはそこにデータソース接続文字列を入力します。図15-3を参照してください。
この文字列は今後の使用のために、Oracle Delegated Administration ServicesによってOracle Internet Directoryに格納され、rwservlet
が、新しく入力された接続文字列をレポートのデータソース接続文字列として使用します。
図15-3 Oracle Delegated Administration Servicesの「リソースの作成」
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がブラウザで作成され、ユーザーはリクエストごとに認証を受けることなく、複数のレポート・ジョブを実行できます。
注意: 特定のレポートに対してユーザーに認証を要求する場合は、 |
ユーザーがブラウザ・セッションを終了すると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-4の番号に対応しています。
ユーザーが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ストアを使用し、ポリシー・ストアとして |
埋め込みIDストアのような現在のIDストア内のユーザーを、LDAPベースのIDストアであるOracle Internet Directoryに移動することをお薦めします。その後で、ユーザーをアプリケーション・ロールにマップできるようになります。Oracle Internet Directoryへのユーザーの移動については、『Oracle Fusion Middlewareセキュリティ・ガイド』の手動による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に対して認証されます。 |