| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド 11g リリース1 (11.1.1) B63030-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド 11g リリース1 (11.1.1) B63030-05 |
|
前 |
次 |
この章では、デフォルトのOracle WebLogic Server LDAPディレクトリではなく代替ディレクトリ・サーバーを認証に使用するように、Oracle Business Intelligenceを構成する方法を説明します。また、Oracle Internet Directory、Active Directoryおよびその他の認証プロバイダを使用するようにOracle Business Intelligenceを設定する方法や、OID LDAPをポリシー・ストアおよび資格証明ストアとして使用する方法についても説明します。
この章には次の項が含まれます:
代替認証プロバイダを使用する場合、通常はプロバイダ・ベンダーが提供する管理ツールを使用してユーザーおよびグループを設定します。その後、これらのユーザーおよびグループを、事前定義済のアプリケーション・ロール(BIConsumer、BIAuthors、BIAdministratorなど)や作成した任意のアプリケーション・ロールに割り当てることができます。アプリケーション・ロールへのユーザーおよびグループの割当ての詳細は、第2.4項「Fusion Middleware Controlの使用によるアプリケーション・ロールおよびアプリケーション・ポリシーの管理」を参照してください。
セキュリティ・モデルのその他の領域を管理するには、引き続き、他のOracle Business Intelligenceツール(Oracle BI管理ツール、Fusion Middleware Control、プレゼンテーション・サービスの「管理」ページなど)を使用します。
現在サポートされている、Oracle Business Intelligenceで使用できる認証プロバイダおよびディレクトリ・サーバーのリストを表示するには、「新しい認証プロバイダの作成」ページの「タイプ」リストで認証プロバイダを選択します。詳細は、「システム要件と動作要件」を参照してください。
サポートされている認証プロバイダを複数構成できます。詳細は、第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」を参照してください。
デフォルトのWebLogic LDAPサーバー以外のディレクトリ・サーバーを使用している場合は、Oracle WebLogic Server管理コンソールに、他のディレクトリ・サーバーのユーザーおよびグループを表示できます。ただし、使用しているディレクトリ・サーバーのインタフェースでユーザーおよびグループを管理する必要があります。たとえば、Oracle Internet Directory (OID LDAP)を使用している場合、OIDコンソールを使用して、ユーザーおよびグループの作成と編集を行う必要があります。
代替認証プロバイダを構成するには:
前提条件: 管理サーバーのみ稼動していることを確認します。
第3.3項「代替認証プロバイダを使用するための前提条件」の説明に従って、Oracle Business Intelligenceを有効にして代替認証プロバイダを使用するよう、グループおよびユーザーを設定および構成します。
第3.4項「代替認証プロバイダの構成」の説明に従って、認証プロバイダを使用するよう、Oracle Business Intelligenceを構成します。
第3.5項「アイデンティティ・ストアでのユーザーおよびグループ名属性の構成」の説明に従って、認証プロバイダのユーザー名属性と一致するように、アイデンティティ・ストアのユーザー名属性を構成します。
myrealmの「ユーザーとグループ」タブに移動し、代替認証プロバイダのユーザーおよびグループが正しく表示されていることを確認します。ユーザーおよびグループが正しく表示されていたら、ステップ5に進みます。正しく表示されていない場合は、構成を設定しなおし、再度表示を試みます。
第3.7項「新しい信頼できるユーザー(BISystemUser)の構成」の説明に従って、代替認証プロバイダのユーザーの新しい信頼できるユーザー・アカウントを、DefaultAuthenticatorのアカウントに一致するように構成します。
第3.8項「ユーザーGUIDのリフレッシュ」の説明に従って、ユーザーGUIDを代替認証プロバイダでの値に更新します。
Fusion Middleware Controlを使用して、アプリケーション・ロールを新しいアイデンティティ・ストアの適切なグループ(エンタープライズ・ロール)に割り当てます。
詳細は、第2.4.4.2項「アプリケーション・ロールのメンバーの追加または削除」を参照してください。
代替認証プロバイダを使用するようにOracle Business Intelligenceインストールを構成する前に、代替認証プロバイダにグループおよびユーザーが存在し、これらが正しく構成されていることを確認する必要があります。これで、Oracle Business Intelligenceインストールにすでに存在している、対応するracle Business Intelligenceアプリケーション・ロールに、これらを関連付けることができます。
代替認証プロバイダでユーザーおよびグループを設定するには:
代替認証プロバイダでグループを作成します。これらは、既存のOracle Business Intelligenceアプリケーション・ロールに割り当てることができます。例:
BIAdministrators、BISystemUsers、BIAuthors、BIConsumers
代替認証プロバイダで、ステップ1で作成したグループに対応するユーザーを作成します。例:
BIADMIN、BISYSTEM、BIAUTHOR、BICONSUMER。
代替認証プロバイダで、ユーザーをそれぞれのグループに割り当てます。
たとえば、BIADMINユーザーをBIAdministratorsグループに、BISYSTEMユーザーをBISystemUsersグループに割り当てます。
代替認証プロバイダで、BIAuthorsグループをBIConsumersグループの一部にします。
このグループ化により、BIAuthorsはBIConsumersの権限を継承できます。
次の手順では、デフォルトのOracle WebLogic Server LDAPディレクトリではなく、1つ以上の認証プロバイダを構成する方法を説明します。
|
注意: この項では特定の認証プロバイダの設定について説明します。ただし、他の認証プロバイダを構成するための汎用ガイドとしてもご利用いただけます。 |
この手順では、Oracle Internet Directory (OID LDAP)を使用するよう、Oracle Business Intelligenceインストールを再構成する方法を示します。
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
「プロバイダ」タブを表示し、「認証」サブタブを表示します。
「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。
「新しい認証プロバイダの作成」ページで、次のように値を入力します。
名前: 認証プロバイダの名前を入力します。例: MyOIDDirectory。
タイプ: リストから、「OracleInternetDirectoryAuthenticator」を選択します。
「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。
「認証プロバイダ」表の「名前」列で「MyOIDDirectory」をクリックし、「設定」ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択して「保存」をクリックします。
詳細は、第3.4.7項「JAAS制御フラグ・オプションの設定」を参照してください。
「プロバイダ固有」タブを使用して、次の値を指定します。
| セクション名 | フィールド名 | 説明 |
|---|---|---|
|
接続 |
ホスト |
Oracle Internet Directoryサーバーのホスト名。 |
|
接続 |
ポート |
Oracle Internet Directoryサーバーがリスニングしているポート番号。 |
|
接続 |
プリンシパル |
Oracle Internet Directoryサーバーへの接続に使用されるOracle Internet Directoryユーザーの識別名(DN)。例: cn=OIDUser、cn=users、dc=us、dc=mycompany、dc=com。 |
|
接続 |
資格証明 |
プリンシパルとして入力されたOracle Internet Directoryユーザーのパスワード。 |
|
グループ |
グループ・ベースDN |
グループを含むOracle Internet Directoryサーバー・ツリーのベース識別名(DN)。 |
|
ユーザー |
ユーザー・ベースDN |
ユーザーを含むOracle Internet Directoryサーバー・ツリーのベース識別名(DN)。 |
|
ユーザー |
すべてのユーザーのフィルタ |
LDAP検索フィルタ。詳細は、「詳細」をクリックします。 |
|
ユーザー |
名前指定によるユーザー・フィルタ |
LDAP検索フィルタ。詳細は、「詳細」をクリックします。 |
|
ユーザー |
ユーザー名属性 |
認証に使用する属性(cn、uid、mailなど)。たとえば、ユーザーの電子メール・アドレスを使用して認証を行うには、この値を 注意: 次のタスク、第3.5.1項「ユーザー名属性の構成」の説明のとおり、ここで指定する値は、認証プロバイダで使用しているユーザー名属性と一致する必要があります。 |
|
一般 |
GUID属性 |
OID LDAPでオブジェクトGUIDの定義に使用する属性。 orclguid 注意: 通常は、このデフォルト値を変更しないでください。変更する場合は、Fusion Middleware Controlでも、第3.6項「アイデンティティ・ストアでのGUID属性の構成」タスクで説明しているとおり、変更した値を指定する必要があります。 |
図3-1は、「プロバイダ固有」タブのユーザー領域を示しています。
Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
「保存」をクリックします。
次の手順を実行し、DefaultAuthenticatorの「制御フラグ」を設定します。
メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「DefaultAuthenticator」を選択して、その構成ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択します。
詳細は、第3.4.7項「JAAS制御フラグ・オプションの設定」を参照してください。
「保存」をクリックします。
次の手順に従ってプロバイダを並べ替えます。
メインの「myrealmの設定」ページで「プロバイダ」タブを表示し、「認証」サブタブを表示します。
図wls07.gifの説明
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「MyOIDDirectory」を選択し、矢印ボタンを使用してこれをリストの最初に移動し、「OK」をクリックします。
|
注意: MyOIDDirectoryではなく、DefaultAuthenticatorでBISystemUserがホストされている場合は、DefaultAuthenticatorをリストの一番上にしたままMyOIDDirectoryを2番目にした方がよいです。このようにすると、OIDディレクトリにBISystemUserに対する認証リクエストで負担をかけることがまったくありません。ただし、BISQLGroupProviderもデプロイされる場合は、これを常に最初(およびOPTIONAL)にする必要があります。 |
「OK」をクリックして変更内容を保存します。
並べ替えた順序で認証プロバイダが表示されます。
「保存」をクリックします。
チェンジ・センターで、変更のアクティブ化をクリックします。
Oracle WebLogic Serverを再起動します。
この手順は、Active Directoryを使用するようにOracle Business Intelligenceインストールを構成する方法を示します。
この項のデータ例では、内部ユーザー用にOracle Business IntelligenceのWNA SSOを設定するXYZ Corporationという架空の企業を使用します。
この例では、次の情報が使用されます。
Active Directoryドメイン
XYZ Corporationには、xyzcorp.comというActive Directoryドメインがあり、このドメインはすべての内部ユーザーを認証します。Windowsコンピュータからこの企業ネットワークにログインすると、ログイン先はこのActive Directoryドメインになります。ドメイン・コントローラはaddc.xyzcor.copで、これによってActive Directoryドメインが制御されます。
Oracle BI EE WebLogicドメイン
XYZ Corporationでは、bieesvr1.xyz2.comというネットワーク・サーバー・ドメインに、bifoundation_domain(デフォルト名)というWebLogicドメインがインストールされています。
システム管理者およびテスト・ユーザー
次のシステム管理者およびドメイン・ユーザーが構成のテストを行います。
システム管理者ユーザー
Jo Smith (login=jsmith、hostname=xyz1.xyzcorp.com)
ドメイン・ユーザー
Bob Jones (login=bjones hostname=xyz47.xyzcorp.com)
認証プロバイダとしてActive Directoryを構成するには:
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
「プロバイダ」タブを表示し、「認証」サブタブを表示します。
「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。
「新しい認証プロバイダの作成」ページで、次のように値を入力します。
名前: 認証プロバイダの名前を入力します。例: ADAuthenticator。
タイプ: リストから、「ActiveDirectoryAuthenticator」を選択します。
「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。
「名前」列で「DefaultAuthenticator」をクリックし、「設定」ページを表示します。
「共通認証プロバイダ設定」ページで、「制御フラグ」を「REQUIRED」から「SUFFICIENT」に変更し、「保存」をクリックします。
詳細は、第3.4.7項「JAAS制御フラグ・オプションの設定」を参照してください。
認証プロバイダの表の「名前」列で「ADDirectory」をクリックし、「設定」ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択して「保存」をクリックします。
「プロバイダ固有」タブを表示し、Active Directory LDAP認証ストアへの接続に適用するオプションにアクセスします。
「プロバイダ固有」タブを使用して、次の値を指定します。
| セクション名 | フィールド名 | 説明 |
|---|---|---|
|
接続 |
ホスト |
Active Directoryサーバーaddc.xyzcorp.comの名前。 |
|
接続 |
ポート |
Active Directoryサーバーがリスニングしているポート番号(389)。 |
|
接続 |
プリンシパル |
LDAPユーザーの情報を取得する際、Active Directoryに接続するユーザーのLDAP DN。例: cn=jsmith、cn=users、dc=us、dc=xyzcorp、dc=com。 |
|
接続 |
資格証明/資格証明の確認 |
プリンシパルのパスワード(welcome1など)。 |
|
グループ |
グループ・ベースDN |
AD内でグループの検索に使用するLDAP問合せ。 注意: このパスの下に定義されているグループのみをWebLogicに表示できます。 (CN=Builtin、DC=xyzcorp、DC=com) |
|
ユーザー |
ユーザー・ベースDN |
AD内でユーザーの検索に使用するLDAP問合せ。CN=Users、DC=xyzcorp、DC=com |
|
ユーザー |
ユーザー名属性 |
AD内でユーザー名の指定に使用する属性。デフォルト値はcnです。 ユーザー名に別の属性を使用するようにActive Directoryが構成されていることがわかっている場合以外は、この値を変更しないでください。変更する場合は、第3.5.1項「ユーザー名属性の構成」を参照してください。 |
|
ユーザー |
すべてのユーザーのフィルタ |
LDAP検索フィルタ。詳細は、「詳細」をクリックします。 |
|
ユーザー |
名前指定によるユーザー・フィルタ |
LDAP検索フィルタ。詳細は、「詳細」をクリックします。 |
|
ユーザー |
ユーザー・オブジェクト・クラス |
ユーザーの名前。 |
|
ユーザー |
取得したユーザー名をプリンシパルとして使用する |
LDAPサーバーから取得されるユーザー名が、サブジェクトのプリンシパルとして使用されるかどうかを指定します。詳細は、「詳細」をクリックします。 大文字小文字を統一できるので、このチェック・ボックスは選択することをお薦めします。たとえば、LDAPユーザー名がJSmithである場合、jsmith (小文字のみ)でログインした場合でも、プリンシパルはJSmith (大文字小文字混合)になります。これはつまり、グループを間接的に介すのではなく、ユーザーに直接付与されるアプリケーション・ロール・メンバーシップが認証時に一貫して適用されるということです。 |
|
一般 |
GUID属性 |
AD内でオブジェクトGUIDの定義に使用する属性。 objectguid 注意: 通常は、このデフォルト値を変更しないでください。変更する場合は、Fusion Middleware Controlでも、第3.6項「アイデンティティ・ストアでのGUID属性の構成」タスクで説明しているとおり、変更した値を指定する必要があります。 |
Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
「保存」をクリックします。
メインの「myrealmの設定」ページで「プロバイダ」タブを表示し、「認証」サブタブを表示します。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「ADDirectory」を選択し、矢印ボタンを使用してこれをリストの最初に移動し、「OK」をクリックします。
|
注意: ADDirectoryではなく、DefaultAuthenticatorでBISystemUserがホストされている場合は、DefaultAuthenticatorをリストの一番上にしたままADDirectoryを2番目にした方がよいです。このようにすると、ADディレクトリにBISystemUserに対する認証リクエストで負担をかけることがまったくありません。ただし、BISQLGroupProviderもデプロイされる場合は、これを最初(およびOPTIONAL)にする必要があります。 |
チェンジ・センターで、変更のアクティブ化をクリックします。
Oracle WebLogic Serverを再起動します。
この項では、SQLAuthenticatorおよび仮想アイデンティティ・ストア・データベース・アダプタを使用することで、データベースを認証プロバイダとして使用するようにOracle Business Intelligenceを構成する方法について説明します。この項の内容は次のとおりです。
複数のアイデンティティ・ストアを構成し、仮想化を使用することで、ユーザー・ロールとプロファイル情報を異なるアイデンティティ・ストア(LDAPやデータベース・アイデンティティ・ストアなど)に分散できます。
ユーザー・ロールとプロファイル情報は、データベースをLDAPサーバーのように表示できるアダプタを使用してデータベースに格納できます。仮想アイデンティティ・ストア・プロバイダは、このデータベース・アダプタを介してユーザー・プロファイル情報をデータベースから取得できます。
ここで説明するデータベース認証の方法は、リリース11.1.1.5 (またはそれ以降)でのみ使用可能です。それ以前のリリースでは初期化ブロックを使用する必要があります。
このトピックでは、SQLAuthenticatorおよび仮想アイデンティティ・ストア・プロバイダ(データベース・アダプタを含む)を使用するようにOracle Business Intelligenceを構成する方法について説明します。両方とも適切なデータベース・スキーマに対して実行します。ここに示す例は説明のためのものであり、実際のデータベース・スキーマに、ここで説明するサンプルと同じ値を指定してはいけません。
この手順は、ユーザーをデータベース・スキーマに対して認証する必要がある場合に使用します。認証に優先されるアイデンティティ・ストアは、Oracle Internet Directory (OID LDAP)などのLDAPディレクトリ・サービスです。
ここで説明するデータベース認証のアプローチには、それぞれにユーザーおよびパスワードを格納する2つのデータベース列が必要です。データベース・ユーザー・アカウントには基づきません。
Oracle Business Intelligence Enterprise Editionリリース11.1.1.5.0 (以上)がインストールされ、実行している必要があります。また、Oracle Fusion Middlewareパッチ13826887が適用されていることも必要です(詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceシステムのパッチ適用に関する項を参照)。
実際には、以前のOracle BI EEインストールで使用しているユーザー独自のスキーマを使用することになります。ここで説明するサンプル・スキーマは意図的に単純化されており、スキーマを使用するようシステムを構成する方法についてのみ説明します。
|
注意: 認証に必要なユーザー、資格証明およびグループを含むデータベース・スキーマは、Oracle BI EEが稼動するWebLogic Serverからアクセスできる必要があります。 |
図3-2には、表USERS、USER_VW、GROUPMEMBERS、GROUPSおよびGROUPMEMBERS_VWが示されており、USER_VWはUSERS表のビューであり、GROUPMEMBERS_VWはGROUPMEMBERS表とGROUPS表を結合したビューです。
ユーザーまたはグループの情報が複数の表に存在する場合は、各種情報の表について1つのビューを作成する必要があります。
USERS表のビュー(USER_VWなど)を作成し、RPAD(USER_ID, 16, 'X')と定義したGUIDフィールドを追加する必要があります。この構成の結果、一意の16文字のGUID値がorclguid属性にマップされます。これは自動的に16進32文字に変換され、Oracle Business Intelligenceでは16文字の文字列が想定されているため、有効なGUIDとして認識されます。
GROUPS表での外部結合とGROUPMEMBERS表での内部結合を使用してGROUPMEMBERS表とGROUPS表のビュー(GROUPMEMBERS_VWなど)を作成し、ユーザーが割り当てられていない場合でもFusion Middleware Controlでグループを確認できるようにします。図3-2に示すビューをデータベース・アダプタに渡すには、第3.4.3.4.2項「データベース・アダプタの構成」に示す構成を実行する必要があります。
Oracle WebLogic Server管理コンソールを使用して、データ・ソースとSQL認証プロバイダを次のように構成します。
Oracle WebLogic Server管理コンソールを使用してデータ・ソースを構成するには:
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「サービス」をクリックし、「データ・ソース」をクリックします。
データ・ソースの概要ページで「新規」をクリックし、「汎用データ・ソース」を選択します。
「JDBCデータ・ソースのプロパティ」ページで、次のプロパティの値を入力または選択します。
名前: たとえば、UserGroupDSと入力します。
基礎となる構成ファイル(config.xml)および管理コンソール全体で、このデータ・ソースを参照するときに必ず使用される名前。
JNDI名: たとえば、jdbc/User GroupDSと入力します。
このJDBCデータ・ソースのバインド先のJNDIパス。
データベース・タイプ: たとえば、「Oracle」を選択します。
接続先のデータベースのDBMS。
「次へ」をクリックします。
「データベース・ドライバ」ドロップダウン・リストからデータベース・ドライバを選択します。
たとえば、Oracleのサービス接続用ドライバ(Thin)、リリース9.0.1以降を選択します。
「次へ」をクリックします。
「次へ」をクリックします。
「 接続プロパティ 」ページで、次のプロパティの値を入力します。
データベース名: たとえば、ora11gと入力します。
接続先のデータベースの名前。
ホスト名: たとえば、mymachine.example.comと入力します。
データベースのホストとなるサーバーのDNS名またはIPアドレス。
Port: たとえば、1521と入力します。
データベース・サーバーが接続リクエストをリスニングするポート。
データベース・ユーザー名
一般には、第3.4.3.2項で定義される表のスキーマ所有者。
「パスワード」/「パスワードの確認」
「データベース・ユーザー名」用のデータベース・パスワード。
「次へ」をクリックします。
ページの内容が正しいことを確認して、「構成のテスト」をクリックします。
「次へ」をクリックします。
「ターゲットの選択」ページで、データ・ソースのデプロイ先となるサーバーまたはクラスタを選択します。
管理サーバーおよび管理対象サーバーをターゲットとして選択する必要があります。次に例を示します。
「サーバー」ペイン:
「AdminServer」チェック・ボックスを選択します。
「クラスタ」ペイン:
「bi_server1」オプションを選択します。
「終了」をクリックします。
チェンジ・センターで、変更のアクティブ化をクリックします。
Oracle WebLogic Serverを再起動します。
このタスクを実行することで、適切な権限を付与されたユーザーが、WebLogicデータベース認証プロバイダを使用してOracle WebLogic Server管理コンソールにログインできるようになります。
Oracle WebLogic Server管理コンソールを使用してSQL認証プロバイダを構成するには:
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
「プロバイダ」タブを表示し、「認証」サブタブを表示します。
「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。
「新しい認証プロバイダの作成」ページで、次のように値を入力します。
名前: 認証プロバイダの名前を入力します。たとえば、UserGroupDBAuthenticatorと入力します。
タイプ: リストから、「ReadOnlySQLAuthenticator」を選択します。
これにより読取り専用のSQL認証プロバイダが作成され、WebLogicからデータベースに書き戻されることはありません。
「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。
認証プロバイダの表の「名前」列で「UserGroupDBAuthenticator」をクリックし、「設定」ページを表示します。
「プロバイダ固有」タブを表示し、「データ・ソース名」に、第3.4.3.3.1項で作成したデータ・ソースの名前を入力します。
たとえば、UserGroupDSと入力します。
「プロバイダ固有」タブで、データベース表に対して問合せおよび認証を行うために使用するSQL文を指定します。
表3-1は、第3.4.3.2項で概説したサンプル・スキーマのSQL文を示しています。
表3-1 サンプル・スキーマのSQL文
| 問合せ | SQL | 注意 |
|---|---|---|
|
SQL - ユーザー・パスワードの取得(認証に使用) |
SELECT U_PASSWORD FROM USERS WHERE U_NAME = ? |
ユーザーのパスワードをルックアップするためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。パスワードを含む最大1つのレコードを格納したresultSetが戻されます。 |
|
SQL - ユーザーが存在するかどうか |
SELECT U_NAME FROM USERS WHERE U_NAME = ? |
ユーザーをルックアップするためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。ユーザーを含む最大1つのレコードを格納したresultSetが戻されます。 |
|
SQL - ユーザーのリスト |
SELECT U_NAME FROM USERS WHERE U_NAME LIKE ? |
特定のワイルドカード検索に一致するユーザーを取得するためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。一致したユーザー名を格納したresultSetが戻されます。 |
|
SQL - グループのリスト |
SELECT G_NAME FROM GROUPS WHERE G_NAME LIKE ? |
ワイルドカードに一致するグループ名を取得するためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。一致したグループを格納したresultSetが戻されます。 |
|
SQL - グループが存在するかどうか |
SELECT G_NAME FROM GROUPS WHERE G_NAME = ? |
グループをルックアップするためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。グループを含む最大1つのレコードを格納したresultSetを返します。 |
|
SQL - メンバーかどうか |
SELECT G_MEMBER FROM GROUPMEMBERS WHERE G_NAME=?AND G_MEMBER LIKE ? |
グループのメンバーをルックアップするためのSQL文。このSQL文には2つのパラメータ(グループ名とメンバーまたはグループ名)が必要です。resultSetを返します。 |
|
SQL - メンバー・グループのリスト |
SELECT G_NAME FROM GROUPMEMBERS WHERE G_MEMBER = ? |
ユーザーまたはグループが属しているグループをルックアップするためのSQL文。このSQL文にはユーザー名またはグループ名のパラメータが1つ必要です。一致するグループの名前を格納したresultSetを戻します。 |
|
SQL - ユーザーの説明の取得(「サポートされている説明」が有効な場合) |
SELECT U_DESCRIPTION FROM USERS WHERE U_NAME = ? |
特定のユーザーの説明を取得するためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。ユーザーの説明を含む最大1つのレコードを格納したresultSetが戻されます。 |
|
SQL - グループの説明の取得(「サポートされている説明」が有効な場合) |
SELECT G_DESCRIPTION FROM GROUPS WHERE G_NAME = ? |
グループの説明を取得するためのSQL文。「サポートされている説明」が有効になっている場合にのみ有効です。このSQL文にはグループ名のパラメータが1つ必要です。グループの説明を含む最大1つのレコードを格納したresultSetが戻されます。 |
|
注意: 異なる表構造を使用する場合は、これらのSQL文(表および列の名前)を独自のスキーマに合せて変更する必要がある場合があります。また疑問符(?)を、(ユーザー名やグループ名をハードコードするかわりに)ランタイム問合せのプレースホルダとして維持する必要もあります。 |
Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
必要なすべてのSQL文を、使用する認証プロバイダに入力します。
SQLでは大/小文字が区別されます。
パスワード列がプレーンテキストの場合(つまり、「SQL - ユーザー・パスワードの取得」列に対して返された問合せの結果がハッシュ化/暗号化されていない場合)、「プレーンテキスト・パスワードの有効化」オプションを選択します。
「プレーンテキスト・パスワードの有効化」オプションが選択されていない場合、SQLAuthenticatorではSHA-1(デフォルトの暗号化アルゴリズム)を使用してパスワードがハッシュされていると想定されます。サポートされる暗号化アルゴリズムの詳細は、ベースSQLAuthenticator Mbean PasswordAlgorithm属性に関するドキュメントを参照してください。
「保存」をクリックします。
次の手順を実行し、デフォルト認証プロバイダの「制御フラグ」設定を構成します。
メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「DefaultAuthenticator」を選択して、その構成ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択します。
詳細は、第3.4.7項「JAAS制御フラグ・オプションの設定」を参照してください。
「保存」をクリックします。
次の手順に従って認証プロバイダを並べ替えます。
「プロバイダ」タブを表示します。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「UserGroupDBAuthenticator」を選択し、矢印ボタンを使用してこれをリストの最初に移動します。
「OK」をクリックして変更内容を保存します。
チェンジ・センターで、変更のアクティブ化をクリックします。
(管理サーバーが再起動したらFusion Middleware Controlを使用して) Oracle Business Intelligenceコンポーネント、Oracle WebLogic Serverおよび管理対象サーバーを再起動します。
信頼できるシステム・ユーザーの資格証明をポイントするように資格証明ストアの資格証明を置換して、このシステム・ユーザーがデータベースに存在することを確認するには、第3.7項「新しい信頼できるユーザー(BISystemUser)の構成」の説明に従います。
資格証明は、構成しようとしている認証対象のデータベース・テーブルで指定されている適切なユーザー・アカウントのものである必要があります。
|
注意: 「ユーザーとグループ」タブをチェックして、データベースのユーザーとグループが表示されていることを確認します。 |
仮想アイデンティティ・ストアを次のように構成します。
アイデンティティ・ストアを構成して仮想化を有効にする必要があります。これにより、アイデンティティ・ストア・サービスで複数のアイデンティティ・ストアを使用できるようになり、ユーザー・プロファイル情報を様々な認証プロバイダ(アイデンティティ・ストア)に分散できます。
詳細は、第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」を参照してください。
LDAPサーバーのようにデータベースが表示されるようデータベース・アダプタを構成します。これにより、仮想アイデンティティ・ストア・プロバイダは、そのデータベース・アダプタを使用してユーザー・プロファイル情報をデータベースから取得できます。
データベース・アダプタを構成するには:
このタスクは、データベース表をアイデンティティ・ストアとして使用する方法を指定する、アダプタ・テンプレートを編集して適用する方法を示しています。
adapter_template_usergroup1.xmlという名前のファイルを作成します。
このファイルは、ユーザー表から仮想LDAPストアへのマッピングを記述します。
ファイルに次の内容が含まれていることを確認します。
|
注意: 太字で示しているセクションは、独自の表の列がLDAPサーバー内の属性と一致するように変更する必要があります。ここに示す例は、第3.4.3項全体で使用するサンプル・スキーマを対象としたものです。 |
<?xml version = '1.0' encoding = 'UTF-8'?>
<adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
<dataBase id="directoryType" version="0">
<root>%ROOT%</root>
<active>true</active>
<serverType>directoryType</serverType>
<routing>
<critical>true</critical>
<priority>50</priority>
<inclusionFilter/>
<exclusionFilter/>
<plugin/>
<retrieve/>
<store/>
<visible>Yes</visible>
<levels>-1</levels>
<bind>true</bind>
<bind-adapters/>
<views/>
<dnpattern/>
</routing>
<pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
<plugins>
<plugin>
<name>DBGUID</name>
<class>oracle.ods.virtualization.engine.chain.plugins.dbguid.DBGuidPlugin</class>
<initParams>
<param name="guidAtribute" value="orclguid"/>
</initParams>
</plugin>
</plugins>
<default>
<plugin name="DBGUID"/>
</default>
<add/>
<bind/>
<delete/>
<get/>
<modify/>
<rename/>
</pluginChains>
<driver>oracle.jdbc.driver.OracleDriver</driver>
<url>%URL%</url>
<user>%USER%</user>
<password>%PASSWORD%</password>
<ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
<includeInheritedObjectClasses>true</includeInheritedObjectClasses>
<maxConnections>10</maxConnections>
<mapping>
<joins/>
<objectClass name="person" rdn="cn">
<attribute ldap="cn" table="USER_VW" field="U_NAME" type=""/>
<attribute ldap="uid" table="USER_VW" field="U_NAME" type=""/>
<attribute ldap="usernameattr" table="USER_VW" field="U_NAME" type=""/>
<attribute ldap="loginid" table="USER_VW" field="U_NAME" type=""/>
<attribute ldap="description" table="USER_VW" field="U_NAME" type=""/>
<attribute ldap="orclguid" table="USER_VW" field="orclguid" type=""/>
</objectClass>
</mapping>
<useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
<connectionWaitTimeout>10</connectionWaitTimeout>
<oracleNetConnectTimeout>0</oracleNetConnectTimeout>
<validateConnection>false</validateConnection>
</dataBase>
</adapters>
この例でカスタマイズが必要なのは太字で示しているセクションのみですが、その要素は、仮想LDAPスキーマで使用されている属性/クラスを、それらに対応するデータベースの列と一致させることでマップする必要があります。この仮想スキーマはWebLogicの組込みLDAPの仮想スキーマと同じであり、表3-2に示す任意の属性にデータベース列をマップできます。
表3-2 データベース列にマップする属性の例
| 属性 | 例 |
|---|---|
|
description |
John Doe |
|
cn |
john.doe |
|
uid |
john.doe |
|
sn |
Doe |
|
userpassword |
welcome1 |
|
displayName |
John Doe |
|
employeeNumber |
12345 |
|
employeeType |
Regular |
|
givenName |
John |
|
homePhone |
650-555-1212 |
|
|
john.doe@example.com |
|
title |
マネージャ |
|
manager |
uid=mary.jones,ou=people,ou=myrealm,dc=wc_domain |
|
preferredLanguage |
en |
|
departmentNumber |
ツール |
|
facsimiletelephonenumber |
650-555-1200 |
|
mobile |
650-500-1200 |
|
pager |
650-400-1200 |
|
telephoneNumber |
650-506-1212 |
|
postaladdress |
200 Oracle Parkway |
|
l |
Redwood Shores |
|
homepostaladdress |
123 Main St., Anytown 12345 |
最初の外側の要素(<objectClass name="person" rdn="cn">)を使用して、LDAPオブジェクト・クラスpersonのマッピングを宣言します。
cn属性はRDN(相対識別名)として使用されます。次にサブ要素で、どのLDAP属性をデータベースのどの表および列にマップするのかを宣言します。たとえば、「<attribute ldap="uid" table="USERS" field="USER_ID" type=""/>」の行では、USER_VW表のUSER_IDフィールドを、標準のLDAP属性であるuid (つまり、ユーザーごとに一意のユーザーID)にマップします。
次に、同じ方法を使用してグループをマップします。
adapter_template_usergroup2.xmlという名前のファイルを作成します。
このファイルは、グループ表から仮想LDAPストアへのマッピングを記述します。
次の内容をファイルに追加します。
太字で示したセクションをカスタマイズして、ユーザー独自の表にある列と一致させる必要があります。ここに示すサンプルの内容は、この例全体で使用するサンプル・スキーマに一致します。
<?xml version = '1.0' encoding = 'UTF-8'?>
<adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
<dataBase id="directoryType" version="0">
<root>%ROOT%</root>
<active>true</active>
<serverType>directoryType</serverType>
<routing>
<critical>true</critical>
<priority>50</priority>
<inclusionFilter/>
<exclusionFilter/>
<plugin/>
<retrieve/>
<store/>
<visible>Yes</visible>
<levels>-1</levels>
<bind>true</bind>
<bind-adapters/>
<views/>
<dnpattern/>
</routing>
<pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
<plugins>
<plugin>
<name>VirtualAttribute</name>
<class>oracle.ods.virtualization.engine.chain.plugins.virtualattr.VirtualAttributePlugin</class>
<initParams>
<param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>
</initParams>
</plugin>
</plugins>
<default>
<plugin name="VirtualAttribute"/>
</default>
<add/>
<bind/>
<delete/>
<get/>
<modify/>
<rename/>
</pluginChains>
<driver>oracle.jdbc.driver.OracleDriver</driver>
<url>%URL%</url>
<user>%USER%</user>
<password>%PASSWORD%</password>
<ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
<includeInheritedObjectClasses>true</includeInheritedObjectClasses>
<maxConnections>10</maxConnections>
<mapping>
<joins/>
<objectClass name="groupofuniquenames" rdn="cn">
<attribute ldap="cn" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
<attribute ldap="description" table="GROUPMEMBERS_VW" field="G_NAME type=""/>
<attribute ldap="uniquemember" table="GROUPMEMBERS_VW" field="G_MEMBER" type=""/>
<attribute ldap="orclguid" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
</objectClass>
</mapping>
<useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
<connectionWaitTimeout>10</connectionWaitTimeout>
<oracleNetConnectTimeout>0</oracleNetConnectTimeout>
<validateConnection>false</validateConnection>
</dataBase>
</adapters>
次の要素について、太字で示した適切なセクションをカスタマイズします。
ReplaceAttribute
グループで一意のメンバーを定義する方法を指定します(%uniquemember%は、ユーザーがグループのメンバーかどうかをルックアップする際の実行時に渡される値のプレースホルダ)
この要素について変更する唯一の点は、ユーザーのルートの指定です。概念的には、libovdadapterconfigスクリプトをステップ10で実行する際にユーザー移入のルートとして指定するものにデフォルトで一致する必要があります。
groupofuniquenames
ユーザー同様、グループ属性をデータベース・フィールドにマップする方法を指定します。この属性は、Weblogicの組込みLDAPのデフォルトに対応します。
次の属性をマップする必要があります。
cn (グループの一意の名前にマップする)
uniquemember (データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップする)
orclguid (データベース・スキーマで利用可能な場合は一意のIDにマップする)
次の属性のマップはオプションです。
descriptionはオプション(ただし明らかに有用な情報です)
その他の属性は、ユーザーは構成できません。
2つのアダプタ・ファイルを次のフォルダにコピーします。
<MW_HOME>/oracle_common/modules/oracle.ovd_11.1.1/templates/
次の場所でコマンド・プロンプトまたはターミナルを開きます。
<MW_HOME>/oracle_common/bin
次の環境変数が設定されていることを確認します。
ORACLE_HOME=<MW_HOME>/Oracle_BI1
WL_HOME=<MW_HOME>/wlserver_10.3/
JAVA_HOME=<MW_HOME>/jdk/
libovdadapterconfigスクリプトを実行し、テンプレート・ファイルから2つのアダプタをそれぞれ作成します。次に構文を示します。
libovdadapterconfig -adapterName <name of adapter> -adapterTemplate <name (NOT including path) of template file which defines adapter> -host localhost -port <Admin Server port> -userName <user id of account which has administrative privileges in the domain> -domainPath <path to the BI domain> -dataStore DB -root <nominal specification of a pseudo-LDAP query to treat as the "root" of this adapter - must match that specified in template for adapter 2 above> -contextName default -dataSourceJNDIName <JNDI name for DataSource which points at the database being mapped>
例:
./libovdadapterconfig.sh -adapterName userGroupAdapter1 -adapterTemplate adapter_template_usergroup1.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/UserGroupDS ./libovdadapterconfig.sh -adapterName userGroupAdapter2 -adapterTemplate adapter_template_usergroup2.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/UserGroupDS
スクリプトはエラーなしで終了する必要があります。
WebLogic管理サーバーおよび管理対象サーバーを再起動します。
これで、データベースに格納された資格証明を使用して、WebLogicおよびOracle Business Intelligenceにログインできるはずです。
この項では、SQL認証プロバイダのトラブルシューティング情報を示します。この項の内容は次のとおりです。
データベース・ユーザーを使用してOracle Business Intelligenceにログインできない場合に役立つ診断テストとして、そのユーザーがWebLogicにログインできるかどうかを確認することがあります。WebLogicコンテナ認証を利用する他のアプリケーションがWebLogic Server上にない場合は、ユーザーを(一時的に) WebLogicのグローバルAdminロールに追加し、そのユーザーがOracle WebLogic Server管理コンソールにログインできるかどうかを確認することで、SQLAuthenticatorが正しく動作していることをテストします。
Oracle WebLogic Server管理コンソールを使用してグローバルAdminロールにユーザーを追加するには:
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
「ロールとポリシー」タブを表示し、「レルム・ロール」サブタブを表示します。
ロールのリストでプラス記号をクリックして「グローバル・ロール」→「ロール」を展開し、Adminロールの「ロール条件の表示」リンクをクリックします。
指定されている条件が、直接、または所属するグループに基づいて、ユーザーに一致することを確認します。
たとえば、条件にはUser=myadminaccountやGroup=Administratorsなどがあります。
変更したら、「保存」をクリックします。
変更はただちに適用されます。
これで、問題のユーザーがOracle WebLogic Server管理コンソール(http://<bi server address>:<AdminServer Port>/console)にログインできるかどうかを確認できます(例: http://example.com:7001/console)。
ユーザーがコンソールにログインできるがOracle Business Intelligenceにログインできない場合、SQLAuthenticatorは正しく動作していますが、アイデンティティ・ストア・サービスに問題がある可能性があります。第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」でvirtualize=trueプロパティとOPTIMIZE_SEARCH=trueプロパティが指定してあることを確認し、第3.4.3.4.2項「データベース・アダプタの構成」でDBAdapterテンプレートが正しいことを確認します。
SQLAuthenticatorのデータ・ソース・フィールドに正しくない名前を指定した場合、次のようなエラーが管理サーバーおよび管理対象サーバーのログ・ファイルに記録されます。
Caused by: javax.security.auth.login.FailedLoginException: [Security:090761]Authentication failed for user jsmith java.sql.SQLException: [Security:090788]"Problem with DataSource/ConnectionPool configuration, verify DataSource name wrongdsname is correct and Pool configurations are correct"
at weblogic.security.providers.authentication.shared.DBMSAtnLoginModuleI
mpl.login(DBMSAtnLoginModuleImpl.java:318)
第3.4.3.3.1項「Oracle WebLogic Server管理コンソールの使用によるデータ・ソースの構成」で示した例のとおり、データ・ソース名を使用します。
SQLAuthenticatorを構成するときに指定するSQL問合せの構文が正しいこと、および正しい表を参照していることを確認します。たとえば、パスワード問合せに正しくない表名が指定されると、次のエラーがAdministration Server.logファイルに記録されます。
####<Jul 7, 2011 4:03:27 PM BST> <Error> <Security> <gbr20020> <AdminServer> <[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <de7dd0dc53f3d0ed:e0ce69e:131007c1afe:-8000-00000000000007fa> <1310051007798> <BEA-000000> <[Security:090759]A SQLException occurred while retrieving password information
java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:457)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405)
at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:889)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:476)
既存のデータベース・アダプタは修正しないでください。アダプタの作成で使用するテンプレートやlibovdadapterコマンドでエラーが発生した場合は、次の手順を使用してアダプタを削除してから、再作成する必要があります。
アダプタを削除および再作成してデータベース・アダプタ・エラーを修正するには:
WLSTスクリプトを実行して、WSLTコンソールにログインします。
例:
MW_HOME/oracle_common/common/bin/wlst.sh (UNIX)
MW_HOME\oracle_common\common\bin\wlst.cmd (Windows)
次の構文を使用して管理サーバーに接続します。
connect ('<WLS admin user name>','<WLS admin password>','t3://<admin server host>:<admin server port>')
例:
connect('weblogic','weblogic','t3://myserver:7001')
次の構文を使用して、適切に構成されていないアダプタを削除します。
deleteAdapter(adapterName='<AdapterName>')
例:
deleteAdapter(adapterName='userGroupAdapter2')
exit()コマンドを使用してWLSTコンソールを終了し、第3.4.3.4.2項「データベース・アダプタの構成」の手順に従って適切な設定でアダプタを再作成します。
この項では、LDAPアイデンティティ・ストアに対して認証を行うようにOracle Business Intelligenceを構成し、グループ情報をデータベースに格納する方法について説明します。この項の例では、Oracle Internet Directory (OID LDAP)およびサンプル・データベース・スキーマを使用します。ただし、OID LDAPをLDAPアイデンティティ・ストアとして使用したり、サンプルと同じデータベース・スキーマを使用したりする必要はありません。
Oracle Business Intelligenceでは、この方法の使用を可能にする、BISQLGroupProviderというWebLogic Server用の認証プロバイダが提供されます。この認証プロバイダでは、エンド・ユーザーの資格証明は認証されませんが、データベース表に保持された外部のグループ・メンバーシップを認証済ユーザーのIDに提供できます。
この項には次のトピックが含まれます:
この項の説明に従ってLDAP認証の構成を試みる前に、次の前提条件を満たす必要があります。
Oracle Business Intelligence Enterprise Editionリリース11.1.1.5.0 (またはそれ以降)がインストールされ、稼動している必要があります。
Oracle BI EE 11.1.1.5.0システムにすべての関連するパッチを適用する必要があります。
必要なグループを含む1つ以上の表が格納された適切なデータベース・スキーマ、およびそれらのグループをLDAPによって認証されるユーザーの名前にマップするマッピング表が稼動していて、Oracle BI EEが稼動するWebLogic Serverからアクセスできる必要があります。
ユーザーを格納するアイデンティティ・ストアとして使用するために、サポートされているLDAPサーバーが構成に含まれている必要があります。
Oracle Business Intelligenceからアプリケーション・ロールのメンバーにコンテンツを配信する必要がある場合、次の制約が適用されます。
ペアにできるのは、単一のLDAP認証プロバイダと単一のBISQLGroupProviderのみです。
複数のLDAP認証プロバイダを構成し、BISQLGroupProviderからグループ・メンバーシップを取得する必要がある場合、コンテンツをアプリケーション・ロールのすべてのメンバーに配信できません。この構成では、Oracle BIデリバーでユーザーおよびグループ・メンバーシップに基づいてアプリケーション・ロールのメンバーシップを解決できません。
複数のアイデンティティ・ストアで同じグループは定義できません。
たとえば、LDAPおよびデータベース・グループの両方の表で、BIAdministratorsというグループは保持できません。これを行った場合、Oracle BIデリバーによって呼び出されるセキュリティ・コードでアプリケーション・ロールのメンバーシップを解決できなくなります。
ここで説明するサンプル・スキーマは意図的に単純化されており、スキーマを使用するようOracle Business Intelligenceを構成する方法についてのみ説明します。
サンプル・スキーマの名前はACME_BI_GROUPSで、2つの表と1つのビューで構成されます。外部グループのリストが定義されるGROUPS表、GROUPMEMBERS表、プライマリ・アイデンティティ・ストア内に存在するユーザーのグループ・メンバーシップが記述されるGROUPMEMBERS_VWビューです。
図3-3と同じ表(またはビュー)を定義することの利点は、BISQLGroupProviderの構成で、表3-3に概説されたデフォルトのSQLを使用できることです。
図3-3には、表GROUPSおよびGROUPMEMBERSと、ビューGROUPMEMBERS_VWが示されています。
LDAPストア内のユーザーを、データベース表のグループにログイン名でマップする必要があります。図3-3では、GROUPMEMBERS表のG_MEMBERの値が、LDAP認証プロバイダに指定されているように、ログインに使用されるLDAP属性の値(uid、cn、mailなど)と一致する必要があります。たとえば、ログイン属性がmailのときに、データベース・グループをuidでマップしないようにする必要があります。GROUPMEMBERS表とGROUPS表間の外部結合を使用してGROUPMEMBERS_VWビューを作成します。
Oracle WebLogic Server管理コンソールを使用して、データ・ソースとBISQLGroupProviderを次のように構成します。
第3.4.4.3.1項「Oracle WebLogic Serverの使用によるプライマリ・アイデンティティ・ストアとしてのOracle Internet Directoryの構成」
第3.4.4.3.4項「Oracle WebLogic Server管理コンソールの使用によるBISQLGroupProvider SQL認証プロバイダの構成」
リンク先の手順に従って、ユーザー移入をOID LDAPに対して認証するようにWebLogicを構成できます。
詳細は、第3.4.1項「認証プロバイダとしてのOracle Internet Directoryの構成」を参照してください。
|
注意: このタスクの手順に従うときに、OID LDAP認証プロバイダの「プロバイダ固有」構成ページに表示される「ユーザー・ベースDN」および「ユーザー名属性」の値をメモしておいてください。これらの値は、後の手順で必要になります。詳細は、第3.4.4.4.3項「グループ情報を取得するためのデータベース・アダプタの構成」を参照してください。 |
BISQLGroupProvider認証プロバイダを構成する前に、まず認証プロバイダが格納されたJARファイルBISecurityProviders.jarをインストールする必要があります。ファイルは、パッチ適用前のOracle Business Intelligenceリリース11.1.1.6.0 (またはそれ以降)およびパッチ適用後のOracle Business Intelligenceリリース11.1.1.5.0のどちらを使用する場合でも、次の場所で入手できます(ただしファイルを正しい場所にコピーする必要があります)。
MW_HOME/ORACLE_HOME/bifoundation/security/providers
ファイルを次の場所にコピーする必要があります。
MW_HOME/wlserver_10.3/server/lib/mbeantypes
ファイルを指定された場所にコピーした後、管理サーバーを再起動して、使用可能な認証プロバイダのリストに新しいプロバイダが表示されるようにする必要があります。
|
注意: エンタープライズ・インストールを実行してクラスタ環境を作成した場合、そのインストールでは、スケールが拡大された管理対象サーバーを再起動できません。これは、BISecurityProviders.jarファイルが使用できないためです。インストール中にこの状況が発生した場合は、JARファイルを正しい場所にコピーし、インストーラで「再試行」をクリックします。 |
Oracle WebLogic Server管理コンソールを使用してデータ・ソースを構成するには:
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「サービス」をクリックし、「データ・ソース」をクリックします。
データ・ソースの概要ページで「新規」をクリックし、「汎用データ・ソース」を選択します。
「JDBCデータ・ソースのプロパティ」ページで、次のプロパティの値を入力または選択します。
名前: たとえば、BIDatabaseGroupDSと入力します。
基礎となる構成ファイル(config.xml)およびOracle WebLogic Server管理コンソール全体で、このデータ・ソースを参照するときに必ず使用される名前。
JNDI名: たとえば、jdbc/BIDatabaseGroupDSと入力します。
このJDBCデータ・ソースのバインド先のJNDIパス。
データベース・タイプ: たとえば、「Oracle」を選択します。
接続先のデータベースのDBMS。
「次へ」をクリックします。
「データベース・ドライバ」ドロップダウン・リストからデータベース・ドライバを選択します。
たとえば、Oracleのサービス接続用ドライバ(Thin)、バージョン9.0.1以降を選択します。
|
注意: Oracleデータベースを使用している場合は、Oracleのサービス接続用ドライバ(Thin)、リリース9.0.1以降を選択します。 |
「次へ」をクリックします。
「次へ」をクリックします。
「 接続プロパティ 」ページで、次のプロパティの値を入力します。
データベース名: たとえば、ora11gと入力します。
接続先のデータベースの名前。
ホスト名: たとえば、mymachine.example.comと入力します。
データベースのホストとなるサーバーのDNS名またはIPアドレス。
|
注意: クラスタを使用する場合は、localhostを使用しないでください。 |
Port: たとえば、1521と入力します。
データベース・サーバーが接続リクエストをリスニングするポート。
データベース・ユーザー名
一般には、第3.4.4.2項で定義される表のスキーマ所有者。
たとえば、MYUSERと入力します。
「パスワード」/「パスワードの確認」
「データベース・ユーザー名」用のデータベース・パスワード。
たとえば、mypasswordと入力します。
「次へ」をクリックします。
ページの内容が正しいことを確認して、「構成のテスト」をクリックします。
「次へ」をクリックします。
「ターゲットの選択」ページで、デプロイ先のデータ・ソースのサーバーまたはクラスタを選択します。
管理サーバーおよび管理対象サーバーをターゲットとして選択する必要があります。次に例を示します。
「サーバー」ペイン:
「AdminServer」オプションを選択します。
「クラスタ」ペイン:
「bi_server1」チェック・ボックスを選択し、クラスタにデプロイします(この操作は簡易インストールには適用されません)。
「終了」をクリックします。
チェンジ・センターで、変更のアクティブ化をクリックします。
|
注意: この例で使用するデータベースの名前はBIDatabaseGroupDSです。 |
このタスクでは、第3.4.4.2項「グループおよびグループ・メンバーのサンプル・スキーマの作成」で概説した例の表の構造を使用し、BIDatabaseGroupDSデータ・ソースに対してBISQLGroupProviderを作成する方法について説明します。構造が例と異なる場合は、使用するSQL文(表や列名)の変更が必要になる可能性があります。
|
注意: データベースにはユーザーに関連付けられるグループが格納されるのみであるため、データベースに対する認証はありません。認証はLDAPに対して発生し、Oracle WebLogic Server管理コンソールでBISQLGroupProviderによってグループがアプリケーション・ロールに割り当てられたときに、データベースが公開されます。 |
Oracle WebLogic Server管理コンソールを使用してBISQLGroupProvider SQL認証プロバイダを構成するには:
Oracle WebLogic Server管理コンソールにWebLogic管理者としてログインし、チェンジ・センターで「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
「プロバイダ」タブを表示し、「認証」サブタブを表示します。
「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。
「新しい認証プロバイダの作成」ページで、次のように値を入力します。
名前: 認証プロバイダの名前を入力します。たとえば、MySQLGroupProviderと入力します。
タイプ: リストから、「BISQLGroupProvider」を選択します。
「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。
認証プロバイダの表の「名前」列で「MySQLGroupProvider」をクリックし、「設定」ページを表示します。
「プロバイダ固有」タブを表示して、データベース表に対して問合せおよび認証を行うために使用するSQL文を指定します。
「データ・ソース名」を指定します。これはデータ・ソース名ではなく、JNDI名である必要があります。たとえば、jdbc/BIDatabaseGroupDSです。
表3-3は、第3.4.4.2項で概説したサンプル・スキーマのSQL文を示しています。
表3-3 サンプル・スキーマのSQL文
| 問合せ | SQL | 注意 |
|---|---|---|
|
SQL - グループのリスト |
SELECT G_NAME FROM GROUPS WHERE G_NAME LIKE ? |
ワイルドカードに一致するグループ名を取得するためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。一致したグループを格納したresultSetが戻されます。 |
|
SQL - グループが存在するかどうか |
SELECT G_NAME FROM GROUPS WHERE G_NAME = ? |
グループをルックアップするためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。グループを含む最大1つのレコードを格納したresultSetを返します。 |
|
SQL - メンバーかどうか |
SELECT G_MEMBER FROM GROUPMEMBERS WHERE G_NAME = ?AND G_MEMBER = ? |
グループのメンバーをルックアップするためのSQL文。このSQL文には2つのパラメータ(グループ名とメンバーまたはグループ名)が必要です。一致するグループ名を格納したresultSetが戻されます。 |
|
SQL - メンバー・グループのリスト |
SELECT G_NAME FROM GROUPMEMBERS WHERE G_MEMBER = ? |
ユーザーまたはグループが属しているグループをルックアップするためのSQL文。このSQL文にはユーザー名またはグループ名のパラメータが1つ必要です。一致するグループの名前を格納したresultSetを戻します。 |
|
SQL - グループの説明の取得(「サポートされている説明」が有効な場合) |
SELECT G_DESCRIPTION FROM GROUPS WHERE G_NAME = ? |
グループの説明を取得するためのSQL文。「サポートされている説明」が有効になっている場合にのみ有効です。このSQL文にはグループ名のパラメータが1つ必要です。グループの説明を含む最大1つのレコードを格納したresultSetが戻されます。 |
|
注意: 異なる表構造を使用する場合は、これらのSQL文(表および列の名前)を独自のスキーマに合せて変更する必要がある場合があります。また疑問符(?)を、(ユーザー名やグループ名をハードコードするかわりに)ランタイム問合せのプレースホルダとして維持する必要もあります。 |
Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
必要なすべてのSQL文を、使用する認証プロバイダに入力します。
SQLでは大/小文字が区別されます。
「保存」をクリックします。
次の手順に従って認証プロバイダを並べ替えます。
「プロバイダ」タブを表示します。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「BISQLGroupProvider」を選択し、矢印ボタンを使用してこれをリストの最初に移動します。
「OK」をクリックして変更内容を保存します。
次の手順を実行し、BISQLGroupProviderの「制御フラグ」設定を構成します。
メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「BISQLGroupProvider」を選択して、その構成ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「OPTIONAL」を選択します。
詳細は、第3.4.7項「JAAS制御フラグ・オプションの設定」を参照してください。
「保存」をクリックします。
チェンジ・センターで、変更のアクティブ化をクリックします。
(管理サーバーが再起動したらFusion Middleware Controlを使用して) Oracle Business Intelligenceコンポーネント、Oracle WebLogic Serverおよび管理対象サーバーを再起動します。
|
注意: 「ユーザーとグループ」タブをチェックして、データベースのユーザーとグループが表示されていることを確認します。 |
仮想アイデンティティ・ストアを次のように構成します。
アイデンティティ・ストアを構成して仮想化を有効にすることにより、アイデンティティ・ストア・サービスで複数のアイデンティティ・ストアを使用できるようになり、ユーザー・プロファイル情報を様々な認証プロバイダ(アイデンティティ・ストア)に分散できます。
詳細は、第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」を参照してください。
SSL(一方向SSLのみ)で通信するためにLDAP認証プロバイダを構成した場合、仮想化(libOVD)機能で使用される追加キーストアに、該当するLDAPサーバーのルート証明書を配置する必要があります。
詳細は、第5.4.9項「複数認証プロバイダ使用時のSSLの構成」を参照してください。
LDAPサーバーのように表示されるようデータベース・アダプタを構成します。これにより、仮想アイデンティティ・ストア・プロバイダは、そのデータベース・アダプタを使用してグループ情報をデータベースから取得できます。
グループ情報を取得するようデータベース・アダプタを構成するには:
このタスクは、データベース表をアイデンティティ・ストアとして使用し、グループをマップする方法を指定する、アダプタ・テンプレートを編集して適用する方法を示しています。
bi_sql_groups_adapter_template.xmlという名前のファイルを作成します。
このファイルは、GROUPMEMBERS_VWビューから仮想LDAPストアへのマッピングを記述します。このビューでは外部結合を使用して、複数の表のフィールドをデータベース・アダプタで参照できるようにします。
ファイルに次の内容が含まれていることを確認します。
|
注意: 要素: <param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>の場合 これはメイン認証プロバイダのユーザー属性およびルート・ユーザーDNと一致する必要があります。たとえば、デフォルトの認証プロバイダの場合は次のとおりです。 uid=%uniquemember%,ou=people,ou=myrealm,dc=bifoundation_domain |
<?xml version = '1.0' encoding = 'UTF-8'?>
<adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
<dataBase id="directoryType" version="0">
<root>%ROOT%</root>
<active>true</active>
<serverType>directoryType</serverType>
<routing>
<critical>true</critical>
<priority>50</priority>
<inclusionFilter/>
<exclusionFilter/>
<plugin/>
<retrieve/>
<store/>
<visible>Yes</visible>
<levels>-1</levels>
<bind>true</bind>
<bind-adapters/>
<views/>
<dnpattern/>
</routing>
<pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
<plugins>
<plugin>
<name>VirtualAttribute</name>
<class>oracle.ods.virtualization.engine.chain.plugins.virtualattr.VirtualAttributePlugin</class>
<initParams>
<param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>
</initParams>
</plugin>
</plugins>
<default>
<plugin name="VirtualAttribute"/>
</default>
<add/>
<bind/>
<delete/>
<get/>
<modify/>
<rename/>
</pluginChains>
<driver>oracle.jdbc.driver.OracleDriver</driver>
<url>%URL%</url>
<user>%USER%</user>
<password>%PASSWORD%</password>
<ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
<includeInheritedObjectClasses>true</includeInheritedObjectClasses>
<maxConnections>10</maxConnections>
<mapping>
<joins/>
<objectClass name="groupofuniquenames" rdn="cn">
<attribute ldap="cn" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
<attribute ldap="description" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
<attribute ldap="uniquemember" table="GROUPMEMBERS_VW" field="G_MEMBER" type=""/>
<attribute ldap="orclguid" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
</objectClass>
</mapping>
<useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
<connectionWaitTimeout>10</connectionWaitTimeout>
<oracleNetConnectTimeout>0</oracleNetConnectTimeout>
<validateConnection>false</validateConnection>
</dataBase>
</adapters>
次の要素について、太字で示した適切なセクションをカスタマイズします。
ReplaceAttribute
グループで一意のメンバーを定義する方法を指定します(%uniquemember%は、ユーザーがグループのメンバーかどうかをルックアップする際の実行時に渡される値のプレースホルダ)
この要素について変更する唯一の点は、ユーザーのルートの指定です。概念的には、libovdadapterconfigスクリプトをステップ10で実行する際にユーザー移入のルートとして指定するものにデフォルトで一致する必要があります。
groupofuniquenenames
グループ属性がデータベース・フィールドにどのようにマップされるかを指定します。
次の属性をマップする必要があります。
cn (グループの一意の名前にマップする)
uniquemember (データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップする)
orclguid (データベース・スキーマで利用可能な場合はGUIDにマップするが、それ以外の場合は'cn'と同じ)
次の属性のマップはオプションです。
descriptionはオプション(ただし明らかに有用な情報です)
その他の属性は、ユーザーは構成できません。
アダプタ・ファイルを次のフォルダにコピーします。
<MW_HOME>/oracle_common/modules/oracle.ovd_11.1.1/templates/
次の場所でコマンド・プロンプトまたはターミナルを開きます。
<MW_HOME>/oracle_common/bin
次の環境変数が設定されていることを確認します。
ORACLE_HOME=<MW_HOME>/Oracle_BI1
WL_HOME=<MW_HOME>/wlserver_10.3/
JAVA_HOME=<MW_HOME>/jdk/
libovdadapterconfigスクリプトを実行し、テンプレート・ファイルからデータベース・アダプタを作成します。次に構文を示します。
libovdadapterconfig -adapterName <name of adapter> -adapterTemplate <name (NOT including path) of template file which defines adapater> -host localhost -port <Admin Server port> -userName <user id of account which has administrative privileges in the domain> -domainPath <path to the BI domain> -dataStore DB -root <nominal specification of a pseudo-LDAP query to treat as the "root" of this adapter - must match that specified in template for adapter 2 above> -contextName default -dataSourceJNDIName <JNDI name for DataSource which points at the database being mapped>
例:
./libovdadapterconfig.sh -adapterName biSQLGroupAdapter -adapterTemplate bi_sql_groups_adapter_template.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/BIDatabaseGroupDS
|
注意: dataSourceJNDINameは単なるDS名ではなく、JNDI名である必要があります。 |
|
注意: rootパラメータの値は、アダプタ・テンプレートの<param name="replaceattribute"要素に指定されたroot dnと一致する必要があります。たとえば、デフォルトの認証プロバイダにユーザーが指定されている場合、rootは通常ou=people, ou=myrealm, dc=bifoundation_domainに設定されます。 |
スクリプトはエラーなしで終了する必要があります。
WebLogic管理サーバーおよび管理対象サーバーを再起動します。
|
注意: WebLogicを起動するときに次の警告が表示されますが、これは無視できます。「警告: BISQLGroupsProvider: 接続プールが使用できません。」 |
これで、データベースに格納された資格証明を使用して、WebLogicおよびOracle Business Intelligenceにログインできるはずです。
アプリケーション・ロールにデータベース・グループを追加することによって構成をテストするには:
Fusion Middleware Controlにログインし、ページの左側にあるナビゲーション・メニューでWebLogicドメインを開き、bifoundation_domainを開きます。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
「bifoundation_domain」を右クリックして「セキュリティ」→「アプリケーション・ロール」を選択し、「アプリケーション・ロール構成」ページを表示します。
LDAPユーザーを含むデータベース・グループを、ユーザーに現在アクセス権が付与されていない、いずれかのアプリケーション・ロール(BIAdministratorなど)に追加します。
アプリケーション・ロールに新しく追加されたグループのメンバーであるユーザーとして、Oracle Business Intelligenceにログインします。
ページの右上に、「<user id>としてログイン」というテキストが表示されます。
ユーザーIDをクリックしてドロップダウン・メニューを表示します。
メニューから「マイ・アカウント」を選択します。
「ロールおよびカタログ・グループ」タブを表示し、ユーザーに新しいアプリケーション・ロールが割り当てられていることを確認します。
既存のデータベース・アダプタは修正しないでください。アダプタの作成で使用するテンプレートやlibovdadapterコマンドでエラーが発生した場合は、アダプタを削除してから再作成する必要があります。
詳細は、第3.4.3.6項「アダプタの削除および再作成によるデータベース・アダプタ・エラーの修正」を参照してください。
この項では、Fusion Middleware Controlを使用して、複数の認証プロバイダを使用するためにOracle Business Intelligenceを構成する方法について説明します。
Fusion Middleware Controlを使用して複数の認証プロバイダを構成するには:
SSLでLDAPと通信している場合(一方向SSLのみ)は、第5.4.9項「複数認証プロバイダ使用時のSSLの構成」を参照してください。
(オプション)サポートされている認証プロバイダがまだ構成されていない場合は、第3.4項の説明に従って構成します。
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
ナビゲーション・ペインから「WebLogicドメイン」フォルダを展開し、「bifoundation_domain」を選択します。
「bifoundation_domain」を右クリックして「セキュリティ」→「セキュリティ・プロバイダ構成」を選択し、「セキュリティ・プロバイダ構成」ページを表示します。
「アイデンティティ・ストア・プロバイダ」領域で「構成」をクリックし、「アイデンティティ・ストア構成」ページを表示します。
「カスタム・プロパティ」領域で「追加」オプションを使用し、次のカスタム・プロパティを追加します。
プロパティ名=virtualize
値=true
プロパティ名=OPTIMIZE_SEARCH
値=true
|
注意: プロパティ名 |
|
注意: virtualizeカスタム・プロパティ値をtrueに設定する場合、BISystemUserは1つのアイデンティティ・ストアのみに存在することを必要とします。 |
|
注意: 複数の認証プロバイダを使用している場合は、第3.4項「代替認証プロバイダの構成」に移動して、「制御フラグ」設定を次にように構成します。
|
「OK」をクリックして変更を保存します。
管理サーバーおよび管理対象サーバーを再起動します。
複数の認証プロバイダを使用するようにOracle Business Intelligenceを構成している場合で、1つの認証プロバイダが使用できなくなれば、他の認証プロバイダを使用するユーザーもOracle Business Intelligenceにログインできなくなります。この項では、1つの認証プロバイダが失敗した場合に、他の認証プロバイダを使用するユーザーはOracle Business Intelligenceにログインできるように認証プロバイダを構成する方法について説明します。詳細は、第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」を参照してください。
1つの認証プロバイダが使用不可になったためにログインできない場合、次のエラー・メッセージが表示されます。
Unable to Sign In An error occurred during authentication. Try again later or contact your system administrator
1つの認証プロバイダ(構成されている複数の認証プロバイダのうちの1つ)が使用不可になっている可能性があり、これがクリティカルな認証プロバイダでない場合、次の手順により、ユーザーは他の認証プロバイダからOracle Business Intelligenceにログインできるようになります。
1つの認証プロバイダが失敗した場合でも、他の認証プロバイダからOracle Business Intelligenceにログインできるように複数の認証プロバイダを構成するには:
ファイルadapters.os_xmlを編集のために開きます。
たとえば、Windows上では、このファイルは次の場所にあります。
MW_HOME\user_projects\domains\bifoundation_domain\config\fmwconfig\ovd\default
ファイルから次の要素を見つけます。
<critical>true</critical>>
adapters.os_xmlファイル内で、クリティカルでない各認証プロバイダについて、<critical>要素の値をfalseに変更します。
<critical>false</critical>
ファイルを保存して閉じます。
WebLogic管理サーバーと管理対象サーバーを再起動します。
複数の認証プロバイダを構成する際、各プロバイダのJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの扱いを制御します。JAAS制御フラグはOracle WebLogic Server管理コンソールで設定できます。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプでJAAS制御フラグの設定に関する項を参照してください。WebLogic Scripting ToolやJava Management Extensions (JMX) APIを使用しても、認証プロバイダに対してJAAS制御フラグを設定できます。
認証プロバイダの制御フラグの属性を設定すると、認証プロバイダの実行順序が決まります。制御フラグ属性に使用可能な値は次のとおりです。
REQUIRED - このLoginModuleは成功する必要があります。失敗した場合でも、認証は、構成された認証プロバイダのLoginModulesリストの下位方向へ進みます。この設定がデフォルトです。
REQUISITE - このLoginModuleは成功する必要があります。他の認証プロバイダが構成されていて、このLoginModuleが成功した場合、認証はLoginModulesリストを下位方向へ進みます。それ以外の場合は、制御がアプリケーションに戻ります。
SUFFICIENT - このLoginModuleは成功する必要はありません。成功した場合、制御はアプリケーションに戻ります。失敗した場合、他の認証プロバイダが構成されていれば、認証はLoginModuleリストを下位方向に進みます。
OPTIONAL - このLoginModuleは成功でも失敗でもかまいません。ただし、JAAS制御フラグがOPTIONALに設定されたセキュリティ・レルムですべての認証プロバイダが構成されている場合は、ユーザーは構成されたいずれかのプロバイダの認証テストに合格する必要があります。
既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。各認証プロバイダが認証シーケンスで適切に動作するよう、必要に応じて制御フラグの設定と認証プロバイダの順序を変更します。
このトピックでは、デフォルトのWebLogic Server LDAP認証プロバイダを無効にして、単一のLDAP認証プロバイダを使用するようOracle Business Intelligenceを再構成する方法を説明します。
Oracle Business Intelligenceをインストールすると、システムは自動的に、デフォルトの認証プロバイダとしてWebLogic Server LDAPを使用するように構成されます。インストール・プロセスでは、WebLogic Server LDAPで必要なユーザーおよびグループが自動的に生成されます。ただし、独自のLDAPディレクトリ(Oracle Internet Directoryなど)があり、それをデフォルトの認証プロバイダとして使用することも、WebLogic Serverのデフォルト認証プロバイダを無効にすることもできます。単一ソースの認証プロバイダを持つことにより、ユーザー名およびパスワードを複数の認証ソースから取得しないようにすることができます。複数の認証ソースから取得すると、複数の攻撃点が生じたり、認可されていないユーザーの侵入が可能になる場合があります。
このトピックには、次の項が含まれています。
この項に示す例はOracle Internet Directory (OID LDAP)を構成するためのものですが、若干変更を加えることによって、他のLDAP認証プロバイダに簡単に適用できます。
唯一の認証プロバイダとしてOracle Internet DirectoryのLDAP認証を構成するには:
WebLogic Server LDAPのデフォルトの認証メソッドを無効にするプロセスを開始する前に、まずシステムをバックアップすることを強くお薦めします。バックアップしないと、構成時に間違えた場合に、システムからロックアウトされたり、システムを再起動できなくなることがあります。
再構成フェーズでバックアップおよびリカバリを有効にするには、<BIEE_HOME>\user_projects\domains\bifoundation_domain\configディレクトリにあるconfig.xmlファイルのコピーをとります。
変更を行う際は、このファイルのコピーを保持しておくことをお薦めします。
デフォルトのWebLogic Server認証プロバイダを削除し、代替LDAPソース(OID LDAPなど)を使用するには、WebLogic Serverと代替メソッドの両方を使用するようにシステムを構成する必要があります。詳細は、第3.4項「代替認証プロバイダの構成」を参照してください。WebLogic Server LDAPユーザー(デフォルトの認証プロバイダ)と新しい代替LDAPユーザーがともにOracle Business Intelligenceにアクセスできるように構成されている状態から開始します。
WebLogic Server LDAPユーザーとしてもOID LDAPユーザーとしてもログオンできるようにシステムを構成したら、次の各タスクの説明のとおり、WebLogic Serverのデフォルト認証プロバイダを削除する手順に進みます。
表3-4に示す必須ユーザーが、WebLogic Server LDAPからOID LDAPに移行されていることを確認する必要があります。
表3-4 OID LDAPでの必須ユーザー
| 標準のWebLogic Serverユーザー | OID LDAPで新たに必要とされるユーザー |
|---|---|
|
BISystemUser |
OID_BISystemUser (任意の既存OID LDAPユーザーにできます) |
|
WebLogic |
OID_Weblogic (任意の既存OID LDAPユーザーにできます) |
|
OracleSystemUser |
OracleSystemUser (このユーザーはOID LDAPにおいてこの名前で存在する必要があります - OWSMの固定要件) |
インストール時に次の3つのユーザーが作成されます。
BISystemUser
このユーザーはWebLogic Serverに作成され、Presentation ServicesおよびOracle Business Intelligenceのコンポーネント間の通信に使用されます。OID LDAPで同等なユーザーを作成または特定する必要があります(OID_BISystemUserなど)。ここで使用するパスワードは、セキュリティ・パスワードの規格に準拠したものにしてください(welcome1などは使用しないでください)。
Weblogic (インストール時またはアップグレード時に指定されるため、異なる場合があります)
この管理者ユーザーはインストール時に作成されます(Weblogicと呼ばれることもありますが、任意の名前でかまいません)。OID LDAPで同等のユーザーを特定または作成する必要がありますが、このユーザーは任意の名前でかまいません。
OracleSystemUser
このユーザーは、(Oracle Web Services Manager (OWSM)で)特にグローバル・ロール・マッピングのために必要です。このユーザーは、OID LDAPでこの名前で作成する必要があります。
表3-5に示す必須グループは、OID LDAPディレクトリで必要です。
表3-5 必須グループ
| 自動的に作成されるWebLogic Serverグループ | 新たに必要とされるOID LDAPグループ |
|---|---|
|
Administrators |
OID_Administrators |
|
AdminChannelUsers |
OID_AdminChannelUsers |
|
AppTesters |
OID_AppTesters |
|
CrossDomainConnectors |
OID_CrossDomainConnectors |
|
Deployers |
OID_Deployers |
|
Monitors |
OID_Monitors |
|
Operators |
OID_Operators |
|
OracleSystemGroup |
OracleSystemGroup (固定要件) |
|
BIAdministrator |
OID_BIAdministrators |
|
BIAuthor |
OID_BIAuthors |
|
BIConsumer |
OID_BIConsumers |
表3-5のグループは、デフォルトのOracle Business Intelligenceインストール・プロセスの際にWebLogic Serverで自動的に作成されます。
デフォルトのWebLogic Server認証を削除する前に、WebLogic Serverグループに替わるOID LDAPグループを特定する必要があります。(表3-5の) WebLogic Serverグループごとに個別のOID LDAPグループを持つか、単一のOID LDAPグループを使用して1つまたは多数のWebLogic Serverグループと置換するかを選択できます。
現在唯一の特定の要件として、OID LDAPでOracleSystemGroupとしてこの名前でグループを定義する必要があります(OWSM要件)。
表3-6に示すグローバル・ロール・マッピングを、OID LDAPで構成する必要があります。
表3-6 WebLogic管理コンソールでのグローバル・ロール・マッピング
| グローバル・ロール | 現在のWebLogic Serverグループ | 新たに必要とされるOID LDAPグループ |
|---|---|---|
|
Admin |
Administrators |
OID_Administrators |
|
AdminChannelUsers |
AdminChannelUsers |
OID_AdminChannelUsers |
|
AppTester |
AppTesters |
OID_AppTesters |
|
CrossDomainConnector |
CrossDomainConnectors |
OID_CrossDomainConnectors |
|
Deployer |
Deployers |
OID_Deployers |
|
Monitor |
Monitors |
OID_Monitors |
|
Operator |
Operators |
OID_Operators |
|
OracleSystemRole |
OracleSystemGroup |
OracleSystemGroup (固定要件) |
デフォルトのWebLogic Server認証プロバイダを無効にする前に、(WebLogic Server管理コンソールに表示されている)表3-6のグローバル・ロールと、(タスク4で定義した)置換OID LDAPグループを関連付ける必要があります。
Oracle WebLogic Server管理コンソールでOID LDAPグループとグローバル・ロールを関連付けるには:
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
「レルム・ロール」をクリックします。
「グローバル・ロール」をクリックし、「ロール」を開きます。
次のように、各ロールに対し、新しい条件を追加します。
|
注意: AnonymousおよびOracle Systemロールには、新しい条件を追加しないでください。どちらも変更されないままになることがあります。 |
「ロール条件の表示」をクリックします。
「述部リスト」ドロップダウンからグループを選択します。
表3-5の新たに関連付けられるOID LDAPグループを入力します。
たとえば、AdminロールをOID_Administratorsロールに関連付けます。
|
注意: デフォルトのWebLogic Server認証を正常に無効にしたら、ここに戻って古いWebLogic Serverグループを削除できます(たとえばここでは、グループAdministratorsを削除します)。詳細は、タスク12「WebLogic Serverロールの削除」を参照してください。 |
変更内容を保存します。
OID LDAPで新しいユーザーおよびグループを作成し、WebLogic Server LDAPで自動的に作成されたユーザーおよびグループをレプリケートしたので、次に、これらのユーザーおよびグループが、OID LDAPにおいても、表3-7に示すとおり正しいグループ・メンバーシップを持っていることを確認する必要があります。
表3-7 OID LDAPで必要なユーザーからグループへのメンバーシップ
| 新しいOID LDAPユーザー | メンバーとなる新しいOID LDAPグループ |
|---|---|
|
OID_Weblogic |
OID_Administrators OID_BIAdministrators |
|
OracleSystemUser 注意: この名前のユーザーがOID LDAPに存在する必要があります。 |
OracleSystemGroup 注意: この名前のグループがOID LDAPに存在する必要があります。 |
|
注意: 表3-7に示すユーザーとグループのメンバーシップを実現するには、OID LDAPサーバーを更新できる適切なアクセス権を持つか、別の担当者がかわりにグループのメンバーシップを更新できる必要があります。 |
Fusion Middleware Controlを使用して、(表3-8にある)作成したばかりのOID LDAPユーザーおよびグループを既存のアプリケーション・ロールのメンバーとして追加する必要があります。
表3-8 必要なOID LDAPユーザーおよびグループのアプリケーション・ロール・メンバーシップ
| 既存のWebLogic Serverアプリケーション・ロールのメンバー | 新しいOID LDAPユーザーおよびグループ |
|---|---|
|
BISystem |
OID_BISystemUser (OIDユーザー) |
|
BIAdministrator |
OID_BIAdministrators (OIDグループ) |
|
BIAuthor |
OID_BIAuthors (OIDグループ) |
|
BIConsumer |
OID_BIConsumers (OIDグループ) |
Fusion Middleware Controlを使用して必要なOID LDAPユーザーおよびグループのアプリケーション・ロール・メンバーシップを設定するには:
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
ナビゲーション・ペインから「Business Intelligence」フォルダを展開し、「coreapplication」を選択します。
Oracle Business Intelligenceの「アプリケーション・ロール」を表示します。
詳細は、第2.4.1項「Fusion Middleware Controlの使用によるアプリケーション・ポリシーおよびアプリケーション・ロールの表示」を参照してください。
表3-8で示されているように、追加のOIDメンバーのユーザーとグループをアプリケーション・ロールに割り当てます。
注意: グループをBISystemアプリケーション・ロールに割り当てることはできますが、セキュリティ保護のため、このロールにはユーザーのみを割り当ててください。
|
注意: この時点でBISystemUserをBISystemアプリケーション・ロールのメンバーから削除することをお薦めします。 |
OID LDAPでBISystemUserに対して作成したユーザー名およびパスワードは、タスク3「OID LDAPでの必須ユーザーの特定または作成」で作成したもの(OID_BISystemUser用など)と同じである必要があります。
新しいOID_BISystemUserの資格証明ストア・パスワードを更新するには:
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
ナビゲーション・ペインから「WebLogicドメイン」フォルダを展開し、「bifoundation_domain」を選択します。
メイン・ペインで「WebLogicドメイン」をクリックしてメニューを表示し、「セキュリティ」→「資格証明」を選択して、「資格証明」ページを表示します。
「oracle.bi.system」を開き、「system.user」を選択します。
「編集」をクリックし、「キーの編集」ダイアログを表示します。
新しいユーザー名およびパスワードを入力します。
「OK」をクリックします。
これでデフォルトの認証プロバイダを削除する準備が整いました。
デフォルトの認証プロバイダを削除するには:
まずLDAPソースにマップするLDAP認証プロバイダを作成しておく必要があります(詳細は、タスク2「WebLogic Serverおよび代替認証プロバイダを使用するためのシステムの構成」を参照)。
Oracle WebLogic Server管理コンソールで、「制御フラグ」を「SUFFICIENT」から「REQUIRED」に変更します。
詳細は、第3.4.7項「JAAS制御フラグ・オプションの設定」を参照してください。
変更を保存します。
他の認証プロバイダを削除し、OID LDAP認証プロバイダが単一ソースとなるようにします。
初めてOID LDAPを使用している場合、つまり、(11gにアップグレードした)10g LDAP認証からOID LDAP認証に移行している場合は、このタスクを実行します。これにより、システム・ユーザーGUID (Global Unique Identifier)を再同期します。再同期しない場合、ログインできず、次のエラー・メッセージが表示されます。
ユーザー{username}のGUIDは、リポジトリのユーザー参照GUIDと一致しません。リポジトリの旧ユーザー参照の削除を管理者に依頼し、再度ログインしてください。
古いGUID参照を削除するには:
すべてのOracle Business Intelligenceサービスを停止します。
Windowsで「BIサービスの停止」メニュー・オプションを使用し、インストール時に指定した元の管理ユーザー名およびパスワード(weblogic/welcome1など)を指定します。
管理ツールで、11gで使用しているリポジトリ・ファイルをオフライン・モードで開きます。
メニューから「管理」および「アイデンティティ」を選択します。
「BIリポジトリ」をクリックし、「ユーザー」タブを表示します。
すべてのユーザーを選択し、これらを削除します。
|
注意: 特定ユーザーのリポジトリ・ファイルで定義された特定の権限がある場合、これらは失われます。この場合、Business Intelligenceシステムを起動する際、LDAP (OID)ソースでユーザー・レベルの権限をこれらのユーザーに再度関連付ける必要があります。これにより、同じ名前の(同一人物ではない)ユーザーが、別のユーザーとして正しく識別されます。 |
これでBIサービスを再起動する準備が整いました。インストール時に作成したWebLogic Server管理ユーザーは削除され、すべてのユーザーが単一OIDソースに存在するため、新しいOID管理者ユーザー(OID_Weblogicなど)を使用する必要があります。OID管理ユーザーには、WebLogicを起動するために十分な権限が必要です(グローバルAdminロールによって付与されます)。
|
注意: オンラインで管理ツールにログインする際は、リポジトリ・パスワードとともにOID LDAPユーザーとパスワード(OID_Weblogicなど)を指定する必要があります。 |
すべて正常に機能している場合、このタスクを完了させます。
自動的に作成されたすべてのWebLogic ServerロールをOR句から削除するには:
グローバル・ロールを編集します。
詳細は、タスク5「WebLogicコンソールでのOID LDAPグループとグローバル・ロールとの関連付け」を参照してください。
自動的に作成されたすべてのWebLogic ServerロールをOR句から削除します。
例:
Admin
AdminChannelUsers
AppTester
CrossDomainConnector
Deployer
Monitor
Operator
変更内容を保存します。
Oracle Business Intelligenceでは、様々な形式の認証方式を一括適用できます。望ましい機能にも思えますが、セキュリティ上のリスクも伴います。単一ソースの認証を実装するには、初期化ブロックを使用する認証メソッドをメタデータ・リポジトリから削除する必要があります。
すべての初期化ブロック認証アクセスを停止するには:
Oracle BI管理ツールを使用して、初期化ブロックを介したアクセスを停止します。正常な認証を行うにはユーザー名が必要です。初期化ブロックでは、USERという特殊なシステム・セッション変数を使用してユーザー名を移入します。
メタデータ・リポジトリからシステム変数USERを削除します。
メタデータ・リポジトリの初期化ブロックで「認証のために必要」チェック・ボックスが選択されていないことを確認します。
システム・セッション変数PROXYおよびPROXYLEVELを設定するメタデータ・リポジトリの初期化ブロックが、ユーザーにセキュリティの無視を許可していないことを確認します。
システム変数PROXYおよびPROXYLEVELは、一度接続されたユーザーが他のユーザーのセキュリティ・プロファイルでそのユーザーになりすますことを許可します。このメソッドは、偽装されたユーザー・アカウントの方が低い権限を持っている場合は受け入れられますが、このアカウントの方が高い権限を持っている場合はセキュリティの問題となる可能性があります。
注意: 初期化ブロックを無効にする場合、依存する初期化ブロックも無効になります。
これで、初期化ブロック認証を使用して試みられるアクセスは成功しなくなります。ただし、すべての初期化ブロックをチェックする必要があります。
単一ソースとしてOracle Internet Directory LDAP認証を構成すると、次のエラーが発生する場合があります。
<クリティカル> <WebLogicServer> <BEA-000386> <サーバー・サブシステムに障害が発生しました。
理由: weblogic.security.SecurityInitializationException: ユーザー<oidweblogic>はサーバーの起動を許可されていません。ユーザーがサーバーを起動できなくなるようにサーバーのポリシーが変更されていることが考えられます。管理ユーザー・アカウントでサーバーを再起動するか、システム管理者に連絡してサーバーのポリシー定義を更新してください。
解決方法
新しいWebLogic OID LDAP管理者(oidweblogic)としてシステムを再起動した場合に、ロックアウトされ、メッセージが表示された場合は、oidweblogicユーザーに十分な権限がなかったことが原因です。oidweblogicユーザーにはグローバルAdminロールが必要です。これにより、OID LDAP Administratorグループに所属することが可能になります。この問題を解決するには、BIAdministratorsグループ(またはOID LDAPの同等グループ)をグローバルAdminロールに追加します。
|
注意: 以前の作業構成をリストアするには、最新の更新されたバージョンのconfig.xmlファイルを、構成を変更する前に作成しておいたバックアップ・バージョンに置き換える必要があります(詳細は、タスク1「バックアップおよびリカバリの有効化」を参照)。 バックアップ・バージョンのconfig.xmlファイルのリストアを完了するには、OID LDAPユーザーではなく、元のWebLogic管理者ユーザーとしてOracle Business Intelligenceを再起動します。 |
OracleInternetDirectoryAuthenticatorおよびActiveDirectoryAuthenticatorを含め、WebLogicで提供されているLDAP認証プロバイダは通常、'cn'をユーザー名およびグループ名の属性として使用するようにデフォルトで設定されています。ユーザー名に対して代替属性('uid'や'mail'など)の使用が必要になることはよくありますが、別のグループ名属性の使用が必要になることはあまり一般的ではありません。この項では、両属性の再構成の方法について説明します。
このトピックには、次の項が含まれています。
この項では、mailをユーザー名属性として使用するためなど、OracleInternetDirectoryAuthenticatorを再構成する方法について説明します。
図3-4に、値mailで構成された「ユーザー名属性」を示します。
代替認証プロバイダのUserNameAttributeは、通常、cnの値に設定されています。このように設定されていない場合、AllUsersFilterおよびUserFromNameFilterの設定が表3-9のとおり正しく構成されていることを確認する必要があります。表3-9は、デフォルトの設定(cnの値を使用)および、必要となる新しい設定(属性AnOtherUserAttributeで新しい値を使用)を示しています。
表3-9 ユーザー名属性の変更
| 属性名 | デフォルト設定 | 必要となる新しい設定 |
|---|---|---|
|
UserNameAttribute |
cn |
AnOtherUserAttribute |
|
AllUsersFilter |
(&(cn=*)(objectclass=person)) |
(&(AnOtherUserAttribute =*)(objectclass=person)) |
|
UserFromNameFilter |
(&(cn=%u)(objectclass=person)) |
(&(AnOtherUserAttribute =%u)(objectclass=person)) |
「プロバイダ固有」タブで、表3-9を使用して変更を行います(AnOtherGroupAttribute設定を独自の値で置換します)。「プロバイダ固有」タブの表示方法の詳細は、第3.4項「代替認証プロバイダの構成」を参照してください。
この項では、cn以外のグループ名を使用するために、ActiveDirectoryAuthenticatorを再構成する方法について説明します。
図3-5に、グループ設定を示します。
たとえば、アクティブ・ディレクトリ・サーバーのグループ名がデフォルト値"cn"以外の値に設定されている場合、変更する必要があります。この値を変更する場合、表3-10に示すとおり、AllGroupsFilterおよびGroupFromNameFilterの値も変更する必要があります(例は、AnOtherGroupAttributeという属性に保存されているグループ名を示しています)。
表3-10 グループ名属性の変更
| 属性名 | デフォルト設定 | 必要となる新しい設定 |
|---|---|---|
|
StaticGroupNameAttribute/DynamicGroupNameAttribute |
cn |
AnOtherGroupAttribute |
|
AllGroupsFilter |
(&(cn=*)(objectclass=person)) |
(&(AnOtherGroupAttribute =*)(objectclass=person)) |
|
GroupFromNameFilter |
(&(cn=%u)(objectclass=person)) |
(&(AnOtherGroupAttribute =%u)(objectclass=person)) |
「プロバイダ固有」タブで、表3-10を使用して変更を行います(AnOtherGroupAttribute設定を独自の値で置換します)。「プロバイダ固有」タブの表示方法の詳細は、第3.4.2項「認証プロバイダとしてのActive Directoryの構成」を参照してください。
この項には次のトピックが含まれます:
Oracle Internet Directory (OID LDAP)やActive Directory (AD)などの代替認証プロバイダを構成し、GUID属性をデフォルト値から変更する場合、アイデンティティ・ストアで使用する値と代替認証プロバイダで使用する変更済の値を一致させる必要があります。
たとえば、OID LDAPを使用しており、GUID属性のデフォルト値をorclguidからnewvalueに変更した場合、アイデンティティ・ストアと認証プロバイダの両方で、値をnewvalueに設定する必要があります。
新しいGUID属性を構成するには:
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
ナビゲーション・ペインから「WebLogicドメイン」フォルダを展開し、「bifoundation_domain」を選択します。
「bifoundation_domain」を右クリックして「セキュリティ」、「セキュリティ・プロバイダ構成」の順に選択し、「セキュリティ・プロバイダ構成」ページを表示します。
「アイデンティティ・ストア・プロバイダ」領域で「構成」をクリックし、「アイデンティティ・ストア構成」ページを表示します。
「カスタム・プロパティ」領域で「追加」をクリックし、表3-11に記載されているカスタム・プロパティを追加します。
表3-11 カスタム・プロパティ - PROPERTY_ATTRIBUTE_MAPPING
| プロパティ名 | 値 |
|---|---|
|
PROPERTY_ATTRIBUTE_MAPPING |
認証プロバイダで設定されているGUID属性値を指定します。たとえば、認証プロバイダでGUID属性が |
|
注意: プロパティ名は大文字( |
図3-6は、PROPERTY_ATTRIBUTE_MAPPINGという新しいプロパティ(値はGUID=newvalue)を含むカスタム・プロパティのサンプル・セットを示しています。
「OK」をクリックして変更を保存します。
(オプション)複数の認証プロバイダのGUIDを構成するには(virtualizeがtrueに設定されている場合)、詳細は、第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」を参照してください。
次に示す手順では、次のパラメータを使用してadapters.os_xmlに指定されている認証プロバイダのGUIDマッピングを更新します。
<param name="mapAttribute" value="orclguid=<guid attribute>'"/>
次のWebLogic Scripting Tool (WLST)コマンドを使用してすべてのアダプタをリストします。
listAdapters()
構成する認証プロバイダのアダプタ名を書き留めます。
ADAPTER_NAMEをターゲット・アダプタ名で置き換えて次のコマンドを実行し、ターゲット認証プロバイダのGUIDマッピングを更新します。
removePluginParam(adapterName=<ADAPTER_NAME>, pluginName='UserManagement', paramKey='mapAttribute') addPluginParam(adapterName='<ADAPTER_NAME>, pluginName='UserManagement', paramKeys='mapAttribute', 'paramValues='<orclguid=the_name_of_the_guid_attribute>')
管理サーバー、管理対象サーバーおよびOracle Business Intelligenceコンポーネントを再起動します。
システム・パラメータoracle.bi.security.guid.validation.formatをsetDomainEnv.shファイルに追加して、GUIDと想定されていないGUIDフィールド形式(電子メール・アドレスなど)を受け入れるようにLDAP認証プロバイダを構成できます。
|
注意: GUIDとアプリケーション・ロール名は、それぞれまったく異なる必要があります。ユーザーGUIDと一致するように作成するパターンは、すべてのアプリケーション・ロール名を除外するように作成する必要があります。 |
GUIDと想定されていないGUIDフィールド形式を受け入れるようにLDAP認証プロバイダを構成するには:
次のフォルダにあるsetDomainEnv.shファイルを開きます。
<MW_HOME>/user_projects/domain/bifoundation_domain/bin
oracle.bi.security.guid.validation.formatパラメータを次の形式で追加します。
EXTRA_JAVA_PROPERTIES="-Doracle.bi.security.guid.validation.format=<RegEx> ${EXTRA_JAVA_PROPERTIES}" export EXTRA_JAVA_PROPERTIES
<RegEx>は、正規表現の書式マスクを表します。
たとえば、OIDを認証プロバイダとして使用しているのに、ユーザーのメール・アドレスをGUIDとしてfirstname.lastname@company.qualifierの書式で使用する場合、これを実現するには、RegEx書式マスク: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+[a-zA-Z]{2,4}$を使用してformatパラメータを追加します。
変更が構成されると、scott.tiger@example.comなどの電子メールの入力を有効なGUIDとして使用できます。
結果としてsetDomainEnv.shファイルのパラメータは、次のようになります。
EXTRA_JAVA_PROPERTIES="-Doracle.bi.security.guid.validation.format=^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+[a-zA-Z]{2,4}$ ${EXTRA_JAVA_PROPERTIES}" export EXTRA_JAVA_PROPERTIES
ファイルを保存します。
WebLogic管理サーバーと管理対象サーバーを再起動します。
Oracle Business Intelligenceでは、内部通信用に構成された認証プロバイダに、特定のユーザーを使用します。たとえば、代替認証プロバイダ(Oracle Internet Directory、Active Directoryなど)を使用するようにOracle Business Intelligenceを構成している場合、代替認証プロバイダで、この目的用に使用する新規ユーザーを作成(または既存ユーザーを選択)して、必要な権限をそのユーザーに付与する必要があります。選択したユーザーへの必要な権限の付与は、これらのユーザーを既存のBISystemアプリケーション・ロールのメンバーにすることによって行います。複数の認証プロバイダを構成する場合は(詳細は、第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」を参照)、このユーザーは1つのアイデンティティ・ストアのみに存在している必要があります。
代替認証プロバイダのユーザーで新しい信頼できるユーザー・アカウントを構成するには:
信頼できるユーザー・アカウントの資格証明は、system.userキーの下の資格証明ストアに格納されます。system.userキーが認証プロバイダ(Oracle Internet Directory、Active Directoryなど)で使用できる一連の資格証明を指すようにする必要があります。
既存のユーザーを使用しても新しいユーザーを作成しても、system.userキーの資格証明を構成するプロセスは同じです。
代替認証プロバイダで、信頼できるユーザー用のユーザーを作成または識別します。
この信頼できるユーザーにBISystemUserという名前を付け、その目的を明確にすることがベスト・プラクティスですが、任意の名前(OID_BISystemUserなど)を選択することもできます。
|
注意: 名前BISystemUserを使用する場合は、このユーザーをデフォルトの認証プロバイダから削除するか、手順に従ってデフォルトの認証プロバイダを削除する(詳細は、第3.4.8.1項を参照)必要があります。 |
外部認証プロバイダのプリンシパル・ユーザーと同じになるように、外部認証プロバイダのBISystemUserを構成しないでください。そのようにすると、認証プロバイダ・ポリシー競合を招き、ユーザー・アカウントがロックされる可能性があります。理想では、プリンシパル・ユーザーとBISystemUserは2つの別個のユーザーとします。
終了すると、Oracle WebLogic Server管理コンソールの「ユーザー」表は図3-7のようになります(記載された例はOracle Internet Directory用です)。
次に、信頼できるユーザーの資格証明を、oracle.bi.system資格証明マップに追加します。
Fusion Middleware Controlのターゲット・ナビゲーション・ペインからファームを開き、「WebLogicドメイン」を開いて「bifoundation_domain」を選択します。
「WebLogicドメイン」メニューで、「セキュリティ」→「資格証明」を選択します。
「oracle.bi.system」 資格証明マップを開き、「system.user」 を選択して「編集」をクリックします。
「キーの編集」ダイアログの「ユーザー名」フィールドで、BISystemUser (または選択した名前)を入力します。「パスワード」フィールドで、認証プロバイダ(Oracle Internet Directory、Active Directoryなど)に含まれる信頼できるユーザーのパスワードを入力します。
「OK」をクリックします。
次に、新しい信頼できるユーザーをBISystemアプリケーション・ロールのメンバーにする必要があります。
Fusion Middleware Controlのターゲット・ナビゲーション・ペインで、Oracle Business IntelligenceがインストールされているOracle WebLogic Serverドメインに移動します。たとえば、bifoundation_domainです。
「WebLogicドメイン」メニューからセキュリティ・ロールおよびアプリケーション・ロールを選択し、「アプリケーション・ロール」ページを表示します。
「検索するアプリケーション・ストライプの選択」ラジオ・ボタンをクリックし、リストから「obi」を選択します。「ロール名」フィールドの右の検索矢印をクリックします。
Oracle Business Intelligenceアプリケーション・ロールが表示されます。これは図3-8のようになります。
「BISystem」アプリケーション・ロールを選択し、「編集」をクリックします。
「アプリケーション・ロールの編集」ページの「メンバー」セクションで、「追加」をクリックします。
「プリンシパルの追加」ダイアログで、「タイプ」リストから「ユーザー」を選択し、「表示名」フィールドの隣の検索ボタンをクリックして、代替認証プロバイダ(Oracle Internet Directoryなど)で作成された信頼できるユーザーを検索します。
「OK」をクリックします。
代替認証プロバイダ(Oracle Internet Directory、Active Directoryなど)に含まれる信頼できるユーザー(BISystemUser)は、これでBISystemアプリケーション・ロールのメンバーになりました。
新しいシステム・ユーザーを構成する次の段階は、そのユーザーがWebLogic ServerのグローバルAdminロールの一部であることを確認することです。
Oracle WebLogic Server管理コンソールで「myrealm」をクリックして「<レルム>の設定」ページを表示し、「ロールとポリシー」タブを表示します。
ロールのリストでプラス記号をクリックして「グローバル・ロール」→「ロール」を開き、Adminロールの「ロール条件の表示」リンクをクリックします。
グローバルAdminロールに新しい信頼できるユーザーを追加します。
指定された条件が、直接、または所属するグループに基づいて、ユーザーと一致することを確認します(条件は、たとえば、User = BISystemUserまたはGroup=Administratorsのようになります)。
「保存」をクリックします。
信頼できるユーザー名をBISystemUser以外の値に変更する場合、BI Publisher JMSモジュールの対応するユーザー名も変更する必要があります。
信頼できるユーザー・アカウント名をBISystemUser以外の値に変更している場合、JMSモジュールのユーザー名も、次のように信頼できる新しいユーザーの値に変更する必要があります。
Oracle WebLogic Server管理コンソールにログインし、「チェンジ・センター」で「ロックして編集」をクリックします。
詳細は、第1.6.1項「Oracle WebLogic Server管理コンソールの使用」を参照してください。
左ペインで「サービス」→「メッセージング」→「JMSモジュール」を選択します。
「BipJmsResource」を選択します。
「セキュリティ」タブに移動し、「ポリシー」サブタブを表示します。
BISystemUserを新しい信頼できるユーザーの名前で置換します。
「変更のアクティブ化」をクリックします。
管理対象サーバーを起動します。
このようにシステム・ユーザーの資格証明を変更した場合は、次のようにBIサーバーとPresentation Servicesを再起動します。
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
「可用性」ページに移動し、「プロセス」タブを表示します。
ページの「ヘルプ」ボタンをクリックして、要素に関するページレベルのヘルプを表示します。
「すべて再起動」をクリックします。
認証プロバイダ(Oracle Internet Directory、Active Directoryなど)の新しい信頼できるユーザーが、Oracle Business Intelligence用に構成されます。
Oracle Business Intelligence 11g リリース1(11.1.1)では、ユーザーはその名前ではなくGlobal Unique Identifier (GUID)で認識されます。GUIDは、特定のユーザーに対する一意の識別子です。GUIDを使用してユーザーを識別することにより、特定のユーザーのデータとメタデータが、ユーザー名に関係なく一意に保護されるので、セキュリティ・レベルが向上します。
GUIDのリフレッシュ(GUIDの同期化またはGUIDの再生成とも呼ばれる)は、メタデータ・リポジトリおよびOracle BIプレゼンテーション・カタログのユーザーGUIDへのメタデータ参照を更新します。GUIDのリフレッシュ・プロセスでは、各ユーザー名がアイデンティティ・ストアで検索されます。その後、アイデンティティ・ストアで、そのユーザー名に関連付けられたGUIDへのすべてのメタデータ参照がそのGUIDに置換されます。
GUIDのリフレッシュは、Oracle Business Intelligenceが同一ユーザーに対して異なるGUIDを持つアイデンティティ・ストアに再度関連付けられる場合に必要となります。このような状況は、Oracle Business Intelligenceを異なるタイプのアイデンティティ・ストアと再度関連付ける際、または本番環境で異なるアイデンティティ・ストアを使用する場合にテスト環境から本番環境に移行する際に発生することがありますが、まれです。
Oracleのベスト・プラクティスが実施されず、Oracle Business Intelligenceリポジトリ・データが、同一ユーザーに対して異なるGUIDを持つシステム間で移行される場合、システムを機能させるには、GUIDをリフレッシュする必要があります。これは、あるユーザー(たとえば、2週間前に退社したJohn Smith)に対して保護されているデータおよびメタデータが、別のユーザー(たとえば先週入社したJohn Smith)に対してアクセス可能になる危険が高まるため、推奨されるものではありません。可能なかぎりアプリケーション・ロールを使用して、開発から本番までのライフサイクル全体を通じて一貫してGUIDを使用することにより、この問題の発生を防ぐことができます。
ユーザーGUIDをリフレッシュするには:
このタスクでは、Oracle BIサーバーおよびプレゼンテーション・サービスが再起動時にGUIDをリフレッシュするように、構成ファイルを手動で編集する必要があります。GUIDのリフレッシュが完了したら、これらのファイルを編集してその変更を削除します。Oracle Business Intelligenceの構成ファイルの場所は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の構成ファイルの場所に関する項を参照してください。
ユーザーGUIDをリフレッシュするには、次の手順をAPPHOST1とAPPHOST2で実行します。GUIDのリフレッシュは、一度に1つのノードのみが動作している状態で行う必要があることに注意してください。
ユーザーGUIDをリフレッシュしているノード以外のすべてのノード上でOracle BIサーバーおよびプレゼンテーション・サービスを停止します。例:
cd MW_HOME/instances/instancen/bin ./opmnctl stopproc ias-component=coreapplication_obips1./opmnctl stopproc ias-component=coreapplicaiton_obis1
NQSConfig.INIのFMW_UPDATE_ROLE_AND_USER_REF_GUIDSパラメータを更新します。
次の場所にあるNQSConfig.INIを開いて編集します。
ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
FMW_UPDATE_ROLE_AND_USER_REF_GUIDS パラメータを見つけ、これを次のようにYESに設定します。
FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES;
ファイルを保存して閉じます。
instanceconfig.xmlで、カタログ要素を更新します。
次の場所にあるinstanceconfig.xmlを開いて編集します。
ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/ coreapplication_obipsn
カタログ要素を見つけ、これを次のように更新します。
<Catalog>
<UpgradeAndExit>false</UpgradeAndExit>
<UpdateAccountGUIDs>UpdateAndExit</UpdateAccountGUIDs>
</Catalog>
ファイルを保存して閉じます。
opmnctlを使用してOracle BIサーバーおよびプレゼンテーション・サービスを再起動します。
cd MW_HOME/instances/instancen/bin ./opmnctl stopproc ias-component=coreapplication_obips1 ./opmnctl stopproc ias-component=coreapplication_obis1 ./opmnctl startproc ias-component=coreapplication_obis1
Oracle BI Serverが実行されていることを確認したら、プレゼンテーション・サービスを起動します。
./opmnctl startproc ias-component=coreapplication_obips1
GUIDがリフレッシュされ、UpdateAccountGUIDs設定のためにプレゼンテーション・サービスは停止します。プレゼンテーション・サービスを再起動するには、残りの手順を完了する必要があります。
NQSConfig.INIのFMW_UPDATE_ROLE_AND_USER_REF_GUIDSパラメータをNOに戻します。
重要: システムを確実にセキュアな状態にするには、この手順を実行する必要があります。
instanceconfig.xmlのカタログ要素を更新し、UpdateAccountのGUIDエントリを削除します。
opmnctlを使用して、Oracle Business Intelligenceシステム・コンポーネントを再起動します。
cd MW_HOME/instances/instancen/bin ./opmnctl stopall ./opmnctl startall
セキュリティ・ストアとしてOracle Internet Directory (LDAP)を使用するようOracle Business Intelligenceを再構成するには、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのOPSSセキュリティ・ストアの再関連付けに関する項にある手順に従ってください。
注意
このリリースにおいてこの用途でサポートされているLDAPサーバーはOracle Internet Directoryのみです。詳細は、「システム要件と動作要件」を参照してください。
LDAPベースの資格証明ストアを使用するための前提条件は、LDAPベースのポリシー・ストアを使用するための前提条件と同様です。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPベースのOPSSセキュリティ・ストアの使用に関する項を参照してください。
Oracle Entitlements Server Basic (OES Basic)は、Oracle Platform Security Services (OPSS)内の組込み認可エンジンに置き換わるものであり、基本的なロールベースのアクセス制御、およびJava2またはJAASの権限に基づいた認可ポリシーの定義、強制および監査に使用されます。同梱されているOracle Entitlements Server Basicのライセンスは、このコンポーネントがそれぞれのライセンス・ドキュメントにリストされたOracle製品でのみ使用できます。
視覚的な変更はなく、OPSSに関する記述も引き続き使用されますが、今後順次OES Basicに関する記述に置き換えられます。
Oracle Entitlements Server Basicの詳細は、Oracle Fusion Middlewareのライセンスに関する情報を参照してください。
この項では、セキュリティ・ストア(資格証明ストア、ポリシー・ストア、キー・ストア)としてデータベースを構成する方法について説明します。この目的に対応するデータベースは、Oracle 11gデータベースのみです。
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのDBベースのOPSSセキュリティ・ストアの使用に関する項を参照してください。
|
注意: データベース・セキュリティ・ストア(ブートストラップ)への接続に必要な資格証明は、ファイル・ベースのブートストラップ・ウォレットに格納されます。 |
この項の内容は次のとおりです。
OPSSスキーマを構成するには:
(オプション) OracleデータベースでOPSSスキーマを作成します。
このステップは、新しいデータベースをセキュリティ・ストアとして作成する場合にのみ実行します。既存のデータベース・セキュリティ・ストアを使用する場合は、次のステップに進みます。
リポジトリ作成ユーティリティ(RCU)を実行し、「AS共通スキーマ」で「Oracle Platform Security Services」を選択します。これは、Oracle Business Intelligenceのインストール後に、BIPLATFORMスキーマおよびMDSスキーマを作成するのと同時に行うことも、後で行うこともできます。
このステップを完了すると、2つのスキーマ・セット(1つはBIPlatformおよびMDS用、もう1つはOPSSおよびMDS用)ができ、各スキーマには独自の接頭辞が付いています。
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのOracleデータベースでのOPSSスキーマの作成に関する項を参照してください。
OPSSスキーマを作成したら、このスキーマを指すJDBCおよびODBCのデータ・ソースを作成する必要があります。
|
注意: JDBC接続はOPSSがデータベース・ポリシーおよび資格証明ストアとやり取りする主な手段であり、ODBC接続は(WebLogic Serverで実行されないため、WebLogic Serverで定義されているJDBCリンクにアクセスできない)Oracle BIサーバーおよびOracle BIプレゼンテーション・サービスで資格証明ストアとのやり取りに使用されます。 |
RCUで作成したOPSSスキーマ・ユーザー資格証明を指定します。
Oracle WebLogic Server管理コンソールを使用して、JDBCデータ・ソースを管理サーバーおよび管理対象サーバーにデプロイします。
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのデータ・ソース・インスタンスの作成に関する項を参照してください。
サーバー・プロセスでは、ODBCを使用してデータ・ソースを消費します。起動時にOPMNによって設定されるODBCINI環境変数に設定されたodbc.ini共有ファイルを指すようにそれらを構成します。
nqsserver BI Serverプロセスについて、このタスクで説明するステップでは次のサーバー・プロセスも有効にします。
sawserver (coreapplication_obips) - Oracle BIプレゼンテーション・サーバー・プロセス
javahost (coreapplication_obijh) - JavaHostプロセス
JavaHostプロセスには、プレゼンテーション・サービスでJSE Javaコードをコールし、JDBCを使用してそのデータ・ソースを消費する機能があります。JDBC URLおよびドライバの詳細は、再関連付け時にjps_config.xml構成ファイルに追加されます。
nqsclustercontroller (coreapplication_obiccs) - クラスタ・コントローラ・プロセス
nqscheduler (coreapplication_obisch) - スケジューラ・プロセス
OPSSスキーマを指すODBCデータ・ソース・インスタンスを作成するには:
次の場所にあるodbc.iniファイルを開きます。
ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup/odbc.ini.
[ODBC Data Sources]エントリをデータ・ソースを指すように更新します。
エントリには、データベース・ドライバおよびデータ・ソース接続の詳細が含まれている必要があります。Oracleデータベース・クライアントおよびデータ・ソース・ドライバのみがサポートされています。
UNIXの場合の例:
[ODBC Data Sources] ... opss_datasource=DataDirect 5.3 Oracle Wire Protocol [opss] Driver=/mw_home/OracleBI1/common/ODBC/Merant/5.3/lib/ARora23.so Description=DataDirect 5.3 Oracle Wire Protocol HostName=example.com PortNumber=1521 SID=orcl
Driver=のフル・パスを入力する必要があります。
Oracle BIプレゼンテーション・サービスとOracle BIサーバー(現在のMerant)と同じODBCドライバを使用する必要があります。
拡張オプション(ファイルを手動で編集しない場合にWindowsおよびUNIXのodbc.iniツールを使用する方法を含む)については、次の場所にあるMerantの参考資料を参照してください。
ORACLE_HOME\common\ODBC\Merant\<Version>\help
Driver=に入力する値を見つけるには、次のようにします。
次の場所にあるopmn.xmlファイルを開きます。
MW_HOME\ORACLE_INSTANCE\config\OPMN\opmn\opmn.xml.
適切なMerant odbcドライバへのPATH変数をセクション<ias-component id="coreapplication_obis1">に指定します。
たとえば、次のように指定します。
$ORACLE_HOME\common\ODBC\Merant\5.3\Drivers
$ORACLE_HOMEがc:\mw_home\OracleBI1だった場合、odbc.iniファイルの[ODBC Data Sources]セクションには次のように入力します。
Driver=c:\mw_home\OracleBI1\common\ODBC\Merant\5.3\Drivers\ARora23.dll
odbc.iniファイルを保存して閉じます。
WebLogic ServerおよびOracle Business Intelligenceシステム・コンポーネントを再起動します。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の「Oracle Business Intelligenceの起動と停止」を参照してください。
たとえば、ファイルベースのsystem-jazn-data.xmlセキュリティ・ストアをOracleデータベースで置き換えるとします。
Oracleデータベースを使用するようにセキュリティ・ストアを再度関連付けるには:
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
ナビゲーション・ペインから「WebLogicドメイン」フォルダを展開し、「bifoundation_domain」を選択します。
「bifoundation_domain」を右クリックしてメニューから「セキュリティ」、「セキュリティ・プロバイダ構成」の順に選択し、「セキュリティ・プロバイダ構成」ページを表示します。
「ストア・タイプの変更」をクリックして「セキュリティ・ストアの構成」ページを表示します。
「ストア・タイプ」フィールドで「Oracle Database」を選択します。
既存のセキュリティ・ストアと再度関連付ける場合は、「新規ドメインの作成」チェック・ボックスの選択を解除し、暗号化キーを指定します(詳細は、タスク5「(オプション)既存のDBセキュリティ・ストア・ドメインの結合」を参照)。
「新規ドメインの作成」チェック・ボックスを選択するのは、新しいデータベース・セキュリティ・ストアに既存のセキュリティ・ストアの内容を移入する場合(デフォルトのファイルベースのプロバイダからデータベース・セキュリティ・ストアに移行する場合など)のみです。
リストからデータ・ソースを選択し、JDBCドライバを選択します(URLの詳細は自動的に追加されます)。
OPSSスキーマへの接続に必要なODBC DSN名と資格証明を入力し、cn=jpsrootのルートDNを指定します。
あるいは、オンライン・モードで使用できるWebLogic Scripting Tool (WLST)のreassociateSecurityStore()コマンドを(スクリプトまたはコマンドラインで)使用することもできます。例:
reassociateSecurityStore(domain="bifoundation_domain", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="jdbc/opss_datasource", admin="adminuser", password="adminpassword", jdbcurl="jdbc:oracle:thin:@example.com:1521:orcl", dbUser="myusername", dbPassword="mypassword", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource", odbcdsn="opssds", join="false")
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのOPSSセキュリティ・ストアの再関連付けに関する項を参照してください。
WebLogic ServerおよびOracle Business Intelligenceシステム・コンポーネントを再起動します。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の「Oracle Business Intelligenceの起動と停止」を参照してください。
|
注意: データベース・セキュリティ・ストアを別のセキュリティ・ストア(LDAPや代替データベースなど)に移行する場合は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのOPSSセキュリティ・ストアの再関連付けに関する項で説明されているドメインの再関連付け手順を実行します。 |
既存のデータベース・セキュリティ・ストア・ドメインを結合するには、ストア内のデータ保護に使用する暗号化キーを指定する必要があります。
抽出コマンドにより、暗号化キーはファイルに挿入されるため、新しいデータベース・セキュリティ・ストアに再度関連付ける前にOracle Business Intelligence環境にインポートできます。
既存のデータベース・セキュリティ・ストア・ドメインを結合するには:
WebLogic Scripting Tool (WLST)のexportEncryptionKey()コマンドを使用して、暗号化キーをファイルewallet.p12に抽出します。
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのexportEncryptionKeyに関する項を参照してください。
WebLogic Scripting Tool (WLST)のimportEncryptionKey()コマンドを使用して、ファイルewallet.p12をOracle Business Intelligence環境にインポートします。
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのimportEncryptionKeyに関する項を参照してください。
オンライン・モードで使用できるWebLogic Scripting Tool (WLST)のreassociateSecurityStore()コマンドを(スクリプトまたはコマンドラインで)使用します。例:
reassociateSecurityStore(domain="bifoundation_domain", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="jdbc/opss_datasource", admin="adminuser", password="adminpassword", jdbcurl="jdbc:oracle:thin:@example.com:1521:orcl", dbUser="myusername", dbPassword="mypassword", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource", odbcdsn="opssds", join="false")
詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのOPSSセキュリティ・ストアの再関連付けに関する項を参照してください。
WebLogic ServerおよびOracle Business Intelligenceシステム・コンポーネントを再起動します。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の「Oracle Business Intelligenceの起動と停止」を参照してください。
ODBCデータ・ソース名プロパティをjps_config.xmlに追加して、資格証明ストア・インスタンスと関連付けます(jps-config.xmlはJSEプロセスで使用されます)。
ODBCデータ・ソース名プロパティをjps_config.xmlに追加するには:
ODBCデータ・ソースの場合、必要な手順はプラットフォーム固有です。
次の場所にあるjps-config.xmlを開きます。
/mw_home/user_projects/domains/bifoundation_domain/config/fmwconfig/jps-config.xml
次のように<propertySet>要素を更新します。
<propertySet name="props.db.1"> … <property name="odbc.dsn" value="opss_datasource"/> </propertySet>
Essbaseサーバー・プロセス(エージェントではなく)は、このデータ・ソースのコンシューマです。データ・ソースはODBCを使用して消費されます。プライベート・ユーザーと、起動時にOPMNプロセスによって設定されるODBCINI環境変数およびODBCINST環境変数に設定されたシステムODBC構成ファイルを指すようにデータ・ソースを構成します。essbase.cfgファイルは、正しく構成されたOracleデータ・ソース・ドライバを指す必要があります。
EssbaseコンポーネントでODBCデータ・ソースを消費できるようにするには:
opmn.xmlを開きます。
たとえば、次の場所にあります。
/mw_home/instances/instance1/config/OPMN/opmn/opmn.xml
ODBCおよびodbcinstの変数が正しいことを確認します。
<ias-component id="essbaseserver1">
<process-type id="Essbase" module-id="ESS">
<environment>
…
<variable id="ODBCINI" value="$ARBORPATH/bin/.odbc.ini"/>
<variable id="ODBCINST" value="$HYPERION_HOME/common/ODBC/Merant/5.3/odbcinst.ini"/>[ODBC Data Sources]
DSNをodbc.iniに手動で追加します。
たとえば、次の場所にあります。
mw_home/instances/instance1/Essbase/essbaseserver1/bin/.odbc.ini
[opss_datasource] Driver=/mw_home/OracleBI1/common/ODBC/Merant/5.3/lib/ARora23.so Description=DataDirect 5.3 Oracle Wire Protocol HostName=example.com PortNumber=1521 SID=orcl
Essbase.cfgで正しいODBCドライバが構成されていることを確認します。
たとえば、次の場所にあります。
mw_home/instances/instance1/Essbase/essbaseserver1/bin/Essbase.cfg
…BPM_Oracle_DriverDescriptor "DataDirect 5.3 Oracle Wire Protocol"
odbcinst.iniでODBCドライバが詳細に設定されていることを確認します。
BIインストーラでは、<install_location>が展開されません。Oracleホームの正しいパスで更新する必要があります。
たとえば、次の場所にあるodbcinst.iniを開きます。
mw_home/OracleBI1/common/ODBC/Merant/5.3/odbcinst.ini
[ODBC Drivers] DataDirect 5.3 Oracle Wire Protocol=Installed … [DataDirect 5.3 Oracle Wire Protocol] Driver=/mw_home/OracleBI1/common/ODBC/Merant/5.3/lib/ARora23.so APILevel=1 ConnectFunctions=YYY DriverODBCVer=3.52 FileUsage=0 HelpRootDirectory=/mw_home/OracleBI1/common/ODBC/Merant/5.3/help Setup=/mw_home/OracleBI1/common/ODBC/Merant/5.3/lib/ARora23.so SQLLevel=1
Oracle BI EEコンポーネントは、コンポーネントごとに構成されたJDBC (JSE)またはODBCを使用して新しいデータ・ソースを消費します。
タスク1からタスク7までを完了したら、変更後のものを消費するために、WebLogic ServerおよびOracle Business Intelligenceシステム・コンポーネントを再起動する必要があります。
