| Oracle® Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド 11g リリース2(11.1.2) B70751-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド 11g リリース2(11.1.2) B70751-01 |
|
前 |
次 |
この項では、Oracle Reportsに固有の認証の機能、タスクおよび概念について説明します。
ここでは、次の項目について説明します。
認証方法
Oracle Reports 11gリリース2(11.1.2)では、次の認証方法をサポートしています。
シングル・サインオン。詳細は、「シングル・サインオン認証」を参照してください。
非SSO。これには次のものが含まれます。
Oracle Internet Directory(rwsec、または構成済のJPS-OID)
埋め込みIDストア(インプロセス・サーバー)
JAZN-XMLファイルベースのIDストア(スタンドアロン・サーバー)
次の表は、Oracle ReportsがサポートしているJPSベース・セキュリティの認証方法をまとめたものです。
表14-2 JPSベース・セキュリティの認証方法
| Reports Serverのタイプ | Oracle Internet Directory | WebLogic IDストア | シングル・サインオン | ファイルベース |
|---|---|---|---|---|
|
インプロセス・サーバー |
はい |
はい |
はい |
いいえ |
|
スタンドアロン・サーバー |
はい |
いいえ |
はい |
はい |
次の表は、Oracle ReportsがサポートしているPortalベース・セキュリティの認証方法をまとめたものです。
表14-3 Portalベース・セキュリティの認証方法
| Reports Serverのタイプ | Oracle Internet Directoryに基づく認証 | シングル・サインオン |
|---|---|---|
|
インプロセス・サーバー |
はい |
はい |
|
スタンドアロン・サーバー |
はい |
はい |
Oracle Reports Servicesアプリケーションは、Oracle Single Sign-On Server 10g(OSSO)との連動に加えて、Oracle Access Manager 11g(OAM)およびOracle Internet Directory(OID)を使用してシングル・サインオン環境で実行できるようになり、同じユーザー・セッション中に多くのアプリケーションにアクセスするための追加または別のログインの必要がなくなりました。Oracle FMW 11gリリース2のOracle Reports Servicesアプリケーションは、シングル・サインオン環境内の次のいずれかの認証サーバーにより保護されます。
Oracle Single Sign-On Server(OSSO)10g
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つで、認証と認可のためのシングル・サインオン・ソリューションです。
OracleAS Single Sign-On Serverでは、暗号化された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 Serverにリダイレクトし、OracleAS Single Sign-On Serverがユーザーにログインを求めます。ユーザーが認証されると、Single Sign-On Cookieが作成され、そのユーザーはrwservletにリダイレクトされます。その後、ユーザーがすでにログインしている場合(Cookieが存在する場合)と同様の処理が行われます。
図14-1に、Oracle Sign-On Server(OSSO)を使用する認証プロセスを示します。
図14-1 OracleAS Single Sign-On Serverを使用する認証プロセス
次の各手順の番号は、図14-2の番号に対応しています。
ユーザーがURLを使用してレポート・リクエストを送信します。
レポート・リクエストは、次のいずれかの方法で行われます。
レポートをリクエストするURLを含むWebページ上のリンクやブックマークをユーザーが選択します。
|
注意: このURLには、必要に応じて、次の形式の値を持つSingle Sign-Onパラメータ(SSOCONN)が格納されます。または、このURLでキー・マップ・ファイルを介して、そのパラメータを参照します。
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の「リソースの作成」ページが表示され、ユーザーはそこにデータソース接続文字列を入力します。図14-4を参照してください。
この文字列は今後の使用のために、Oracle Delegated Administration ServicesによってOracle Internet Directoryに格納され、rwservletが、新しく入力された接続文字列をレポートのデータソース接続文字列として使用します。
図14-2 Oracle Delegated Administration Servicesの「リソースの作成」
図14-3に、認証サーバーとして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クライアントにより識別情報を渡す必要があります。
表14-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がブラウザで作成され、ユーザーはリクエストごとに認証を受けることなく、複数のレポート・ジョブを実行できます。
|
注意: 特定のレポートに対してユーザーに認証を要求する場合は、SHOWAUTHコマンドライン・キーワードを使用できます。または、キー・マップ・ファイル内の対応するレポート・エントリに%Sを使用することもできます。このファイルは通常cgicmd.datと呼ばれ、$DOMAIN_HOME/config/fmwconfig/servers/<WLS_SERVER_NAME>/applications/reports_<version>/configuration/cgicmd.datにあります。%Sを使用すると、ユーザーはレポートをコールするたびに、ユーザー名とパスワードの入力が要求されます。詳細は、第17.13項「キー・マップ・ファイルの使用」を参照してください。 |
ユーザーがブラウザ・セッションを終了すると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コンポーネントからコールすることもできます。
次の各手順の番号は、図14-5の番号に対応しています。
ユーザーが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ストアとしてもポリシー・ストアとしてもsystem-jazn-data.xmlファイルを使用します。 |
埋め込み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に対して認証されます。 |
