Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド 11gリリース1(11.1.1) B63030-03 |
|
前 |
次 |
この章では、デフォルトの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.6項「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.6項「JAAS制御フラグ・オプションの設定」を参照してください。
「保存」をクリックします。
次の手順に従ってプロバイダを並べ替えます。
メインの「myrealmの設定」ページで「プロバイダ」タブを表示し、「認証」サブタブを表示します。
図wls07.gifの説明
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「MyOIDDirectory」を選択し、矢印ボタンを使用してこれをリストの最初に移動し、「OK」をクリックします。
「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.6項「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検索フィルタ。詳細は、「詳細」をクリックします。 |
ユーザー |
ユーザー・オブジェクト・クラス |
ユーザーの名前。 |
一般 |
GUID属性 |
AD内でオブジェクトGUIDの定義に使用する属性。 objectguid 注意: 通常は、このデフォルト値を変更しないでください。変更する場合は、Fusion Middleware Controlでも、第3.6項「アイデンティティ・ストアでのGUID属性の構成」タスクで説明しているとおり、変更した値を指定する必要があります。 |
Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
「保存」をクリックします。
メインの「myrealmの設定」ページで「プロバイダ」タブを表示し、「認証」サブタブを表示します。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「ADDirectory」を選択し、矢印ボタンを使用してこれをリストの最初に移動し、「OK」をクリックします。
チェンジ・センターで、変更のアクティブ化をクリックします。
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 BI EEインストールで使用しているユーザー独自のスキーマを使用することになります。ここで説明するサンプル・スキーマは意図的に単純化されており、スキーマを使用するようシステムを構成する方法についてのみ説明します。
注意: 認証に必要なユーザー、資格証明およびグループを含むデータベース・スキーマは、Oracle BI EEが稼動するWebLogic Serverからアクセスできる必要があります。 |
図3-2には、USER、GROUPおよびUSER_GROUPの各表が記載されており、USER_GROUPは他の2つの表を結合します。
USER、USER_GROUPまたはGROUPのいずれかの情報が複数の表に存在する場合は、各タイプの情報を格納する表に対してビューを作成する必要があります。これにより、ビューをデータベース・アダプタに渡すことができます(第3.4.3.3.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.mycompany.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 PASSWORD FROM USER WHERE USER_ID = ? |
ユーザーのパスワードをルックアップするためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。パスワードを含む最大1つのレコードを格納したresultSetが戻されます。 |
SQL - ユーザーが存在するかどうか |
SELECT USER_ID FROM USER WHERE USER_ID = ? |
ユーザーをルックアップするためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。ユーザーを含む最大1つのレコードを格納したresultSetが戻されます。 |
SQL - ユーザーのリスト |
SELECT USER_ID FROM USER WHERE USER_ID LIKE ? |
特定のワイルドカード検索に一致するユーザーを取得するためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。一致したユーザー名を格納したresultSetが戻されます。 |
SQL - グループのリスト |
SELECT GROUP_ID FROM GROUP WHERE GROUP_ID LIKE ? |
ワイルドカードに一致するグループ名を取得するためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。一致したグループを格納したresultSetが戻されます。 |
SQL - グループが存在するかどうか |
SELECT GROUP_ID FROM GROUP WHERE GROUP_ID = ? |
グループをルックアップするためのSQL文。このSQL文にはグループ名のパラメータが1つ必要です。グループを含む最大1つのレコードを格納したresultSetを返します。 |
SQL - メンバーかどうか |
SELECT GROUP_ID FROM USER_GROUP WHERE GROUP_ID=?AND USER_ID LIKE ? |
グループのメンバーをルックアップするためのSQL文。このSQL文には2つのパラメータ(グループ名とメンバーまたはグループ名)が必要です。resultSetを返します。 |
SQL - メンバー・グループのリスト |
SELECT GROUP_ID FROM USER_GROUP WHERE USER_ID = ? |
ユーザーまたはグループが属しているグループをルックアップするためのSQL文。このSQL文にはユーザー名またはグループ名のパラメータが1つ必要です。一致するグループの名前を格納したresultSetを戻します。 |
SQL - ユーザーの説明の取得(「サポートされている説明」が有効な場合) |
SELECT USER_NAME FROM USER WHERE USER_ID = ? |
特定のユーザーの説明を取得するためのSQL文。このSQL文にはユーザー名のパラメータが1つ必要です。ユーザーの説明を含む最大1つのレコードを格納したresultSetが戻されます。 |
SQL - グループの説明の取得(「サポートされている説明」が有効な場合) |
SELECT GROUP_DESCRIPTION FROM GROUP WHERE GROUP_ID = ? |
グループの説明を取得するためのSQL文。「サポートされている説明」が有効になっている場合にのみ有効です。このSQL文にはグループ名のパラメータが1つ必要です。グループの説明を含む最大1つのレコードを格納したresultSetが戻されます。 |
注意: 異なる表構造を使用する場合は、これらのSQL文(表および列の名前)を独自のスキーマに合せて変更する必要がある場合があります。また疑問符(?)を、(ユーザー名やグループ名をハードコードするかわりに)ランタイム問合せのプレースホルダとして維持する必要もあります。 |
Oracle WebLogic Serverでの認証プロバイダの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
必要なすべてのSQL文を、使用する認証プロバイダに入力します。
パスワード列がプレーンテキストの場合(つまり、「SQL - ユーザー・パスワードの取得」列に対して返された問合せの結果がハッシュ化/暗号化されていない場合)、「プレーンテキスト・パスワードの有効化」チェック・ボックスを選択します。
「プレーンテキスト・パスワードの有効化」チェック・ボックスが選択されていない場合、SQLAuthenticatorではSHA-1(デフォルトの暗号化アルゴリズム)を使用してパスワードがハッシュされていると想定されます。サポートされる暗号化アルゴリズムの詳細は、ベースSQLAuthenticator Mbean PasswordAlgorithm属性に関するドキュメントを参照してください。
「保存」をクリックします。
次の手順を実行し、デフォルト認証プロバイダの「制御フラグ」設定を構成します。
メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「DefaultAuthenticator」を選択して、その構成ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「SUFFICIENT」を選択します。
詳細は、第3.4.6項「JAAS制御フラグ・オプションの設定」を参照してください。
「保存」をクリックします。
次の手順に従って認証プロバイダを並べ替えます。
「プロバイダ」タブを表示します。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「UserGroupDBAuthenticator」を選択し、矢印ボタンを使用してこれをリストの最初に移動します。
「OK」をクリックして変更内容を保存します。
第3.7項「新しい信頼できるユーザー(BISystemUser)の構成」の説明に従って、信頼できるシステム・ユーザーがデータベースに構成されていることと、このユーザーの資格証明をポイントするように資格証明ストアの資格証明を置換していることを確認する必要があります。
チェンジ・センターで、変更のアクティブ化をクリックします。
(管理サーバーが再起動したらFusion Middleware Controlを使用して)Oracle BIコンポーネント、Oracle WebLogic Serverおよび管理対象サーバーを再起動します。
注意: 「ユーザーとグループ」タブをチェックして、データベースのユーザーとグループが表示されていることを確認します。 |
仮想アイデンティティ・ストアを次のように構成します。
アイデンティティ・ストアを構成して仮想化を有効にする必要があります。これにより、アイデンティティ・ストア・サービスで複数のアイデンティティ・ストアを使用できるようになり、ユーザー・プロファイル情報を様々な認証プロバイダ(アイデンティティ・ストア)に分散できます。
詳細は、第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="guidAttribute" 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="inetorgperson" rdn="cn"> <attribute ldap="cn" table="USER" field="USER_NAME" type=""/> <attribute ldap="uid" table="USER" field="USER_ID" type=""/> <attribute ldap="usernameattr" table="USER" field="USER_NAME" type=""/> <attribute ldap="loginid" table="USER" field="USER_ID" type=""/> <attribute ldap="description" table="USER" field="USER_NAME" type=""/> <attribute ldap="orclguid" table="USER" field="USER_ID" 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="inetorgperson" rdn="cn">)を使用して、LDAPオブジェクト・クラスinetorgpersonのマッピングを宣言します。
cn属性はRDN(相対識別名)として使用されます。次にサブ要素で、どのLDAP属性をデータベースのどの表および列にマップするのかを宣言します。たとえば、「<attribute ldap="uid" table="USER" field="USER_ID" type=""/>」の行では、USER表の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="USER_GROUP" field="GROUP_ID" type=""/> <attribute ldap="description" table="USER_GROUP" field="GROUP_ID" type=""/> <attribute ldap="uniquemember" table="USER_GROUP" field="USER_ID" type=""/> <attribute ldap="orclguid" table="USER_GROUP" field="USER_ID" 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 (データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップする)
次の属性のマップはオプションです。
descriptionはオプション(ただし明らかに有用な情報です)
orclguid (データベース・スキーマで利用可能な場合はUIDにマップする)
その他の属性は、ユーザーは構成できません。
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>/jdk160_24/
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 jdbcUserGroupsDS ./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 jdbcUserGroupsDS
スクリプトはエラーなしで終了する必要があります。
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://mybiserver:7001/console)。
ユーザーがコンソールにログインできるがOracle Business Intelligenceにログインできない場合、SQLAuthenticatorは正しく動作していますが、アイデンティティ・ストア・サービスに問題がある可能性があります。第3.4.3.4項「仮想アイデンティティ・ストアの構成」でvirtualize=trueプロパティを指定してあり、DBAdapterテンプレートが正しいことを確認します。
SQLAuthenticatorのデータ・ソース・フィールドに正しくないJNDI名を指定した場合、次のようなエラーが管理サーバーおよび管理対象サーバーのログ・ファイルに記録されます。
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)
データ・ソースのNameフィールドではなく、完全修飾JNDI名を使用する必要があります。第3.4.3.3.1項「Oracle WebLogic Server管理コンソールの使用によるデータ・ソースの構成」に示した例では、データ・ソースの名前はUserGroupDSでしたが、JNDI名はjdbc/UserGroupDSでした。完全修飾された形式を使用します。
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 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つの表を含みます。GROUPSでは外部グループのリストが定義され、GROUPMEMBERSにはプライマリ・アイデンティティ・ストア内に存在するユーザーのグループ・メンバーシップが記述されます。
図3-3と同じ表(またはビュー)を定義することの利点は、BISQLGroupProviderの構成で、表3-3に概説されたデフォルトのSQLを使用できることです。
図3-3は、表GROUPSおよびGROUPMEMBERSを示しています。
LDAPストア内のユーザーを、データベース表のグループにログイン名でマップする必要があります。図3-3では、GROUPMEMBERS表のG_MEMBERの値が、LDAP認証プロバイダに指定されているように、ログインに使用されるLDAP属性の値(uid、cn、mailなど)と一致する必要があります。たとえば、ログイン属性がmailのときに、データベース・グループをuidでマップしないようにする必要があります。
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.mycompany.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文を、使用する認証プロバイダに入力します。
「保存」をクリックします。
次の手順に従って認証プロバイダを並べ替えます。
「プロバイダ」タブを表示します。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「BISQLGroupProvider」を選択し、矢印ボタンを使用してこれをリストの最初に移動します。
「OK」をクリックして変更内容を保存します。
次の手順を実行し、BISQLGroupProviderの「制御フラグ」設定を構成します。
メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「BISQLGroupProvider」を選択して、その構成ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「OPTIONAL」を選択します。
詳細は、第3.4.6項「JAAS制御フラグ・オプションの設定」を参照してください。
「保存」をクリックします。
チェンジ・センターで、変更のアクティブ化をクリックします。
(管理サーバーが再起動したらFusion Middleware Controlを使用して) Oracle Business Intelligenceコンポーネント、Oracle WebLogic Serverおよび管理対象サーバーを再起動します。
注意: 「ユーザーとグループ」タブをチェックして、データベースのユーザーとグループが表示されていることを確認します。 |
仮想アイデンティティ・ストアを次のように構成します。
アイデンティティ・ストアを構成して仮想化を有効にすることにより、アイデンティティ・ストア・サービスで複数のアイデンティティ・ストアを使用できるようになり、ユーザー・プロファイル情報を様々な認証プロバイダ(アイデンティティ・ストア)に分散できます。
詳細は、第3.4.5項「Fusion Middleware Controlの使用による複数の認証プロバイダの構成」を参照してください。
SSL(一方向SSLのみ)で通信するためにLDAP認証プロバイダを構成した場合、仮想化(libOVD)機能で使用される追加キーストアに、該当するLDAPサーバーのルート証明書を配置する必要があります。
詳細は、第5.4.6項「複数認証プロバイダ使用時のSSLの構成」を参照してください。
LDAPサーバーのように表示されるようデータベース・アダプタを構成します。これにより、仮想アイデンティティ・ストア・プロバイダは、そのデータベース・アダプタを使用してグループ情報をデータベースから取得できます。
グループ情報を取得するようデータベース・アダプタを構成するには:
このタスクは、データベース表をアイデンティティ・ストアとして使用し、グループをマップする方法を指定する、アダプタ・テンプレートを編集して適用する方法を示しています。
bi_sql_groups_adapter_template.xmlという名前のファイルを作成します。
このファイルは、GROUPMEMBERS表から仮想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" field="G_NAME" type=""/> <attribute ldap="description" table="GROUPMEMBERS" field="G_NAME" type=""/> <attribute ldap="uniquemember" table="GROUPMEMBERS" field="G_MEMBER" type=""/> </objectClass> </mapping> <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch> <connectionWaitTimeout>10</connectionWaitTimeout> <oracleNetConnectTimeout>0</oracleNetConnectTimeout> <validateConnection>false</validateConnection> </dataBase> </adapters>
次の要素について、太字で示した適切なセクションをカスタマイズします。
ReplaceAttribute
グループで一意のメンバーを定義する方法を指定します(%uniquemember%は、ユーザーがグループのメンバーかどうかをルックアップする際の実行時に渡される値のプレースホルダ)
この要素について変更する唯一の点は、ユーザーのルートの指定です。概念的には、libovdadapterconfigスクリプトをステップ10で実行する際にユーザー移入のルートとして指定するものにデフォルトで一致する必要があります。
groupofuniquenenames
ユーザー同様、グループ属性をデータベース・フィールドにマップする方法を指定します。この属性は、Weblogicの組込みLDAPのデフォルトに対応します。
次の属性をマップする必要があります。
cn (グループの一意の名前にマップする)
uniquemember (データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップする)
次の属性のマップはオプションです。
descriptionはオプション(ただし明らかに有用な情報です)
orclguid (データベース・スキーマで利用可能な場合はUIDにマップする)
その他の属性は、ユーザーは構成できません。
アダプタ・ファイルを次のフォルダにコピーします。
<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>/jdk160_24/
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.6項「複数認証プロバイダ使用時のSSLの構成」を参照してください。
(オプション)サポートされている認証プロバイダがまだ構成されていない場合は、第3.4項の説明に従って構成します。
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
ナビゲーション・ペインから「WebLogicドメイン」フォルダを展開し、「bifoundation_domain」を選択します。
「bifoundation_domain」を右クリックして「セキュリティ」→「セキュリティ・プロバイダ構成」を選択し、「セキュリティ・プロバイダ構成」ページを表示します。
「アイデンティティ・ストア・プロバイダ」領域で「構成」をクリックし、「アイデンティティ・ストア構成」ページを表示します。
「カスタム・プロパティ」領域で「追加」オプションを使用し、次のように新しいカスタム・プロパティを追加します。
プロパティ名=virtualize
値=true
注意: 複数の認証プロバイダを使用している場合は、第3.4項「代替認証プロバイダの構成」に移動して、「制御フラグ」設定を次にように構成します。
|
「OK」をクリックして変更を保存します。
管理サーバーおよび管理対象サーバーを再起動します。
複数の認証プロバイダを構成する場合、各プロバイダに対して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「単一OID LDAP認証後の設定タスク」を参照してください。 |
変更内容を保存します。
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の使用によるアプリケーション・ポリシーおよびアプリケーション・ロールの表示」を参照してください。
次のようにメンバーをアプリケーション・ロールに割り当てます。
注意: グループを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.6項「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を再起動します。 |
このトピックには、次の項が含まれています。
Oracle Internet Directory (OID LDAP)やActive Directory (AD)などの代替認証プロバイダを構成する場合、アイデンティティ・ストアで使用するユーザー名属性と代替認証プロバイダで使用するユーザー名属性を一致させる必要があります。
たとえば、ユーザーの電子メール・アドレスを使用して認証するには、アイデンティティ・ストアと認証プロバイダの両方で、ユーザー名属性をmail
に設定します。
図3-4は、OID LDAP認証プロバイダの「ユーザー名属性」が「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項「代替認証プロバイダの構成」を参照してください。
注意: UserName属性についてのみ、次のタスクを使用して2つのプロパティ(user.login.attrおよびusername.attr)をアイデンティティ・ストア構成に追加する必要があります。この指定により、アイデンティティ・ストアにユーザー名の取得元となる属性が伝達されます。属性が指定されていない場合、デフォルトではuidになります。 |
アイデンティティ・ストアでユーザー名属性を構成するには:
Fusion Middleware Controlにログインします。
詳細は、第1.6.2項「Oracle Fusion Middleware Controlの使用」を参照してください。
ナビゲーション・ペインから「WebLogicドメイン」フォルダを展開し、「bifoundation_domain」を選択します。
「bifoundation_domain」を右クリックして「セキュリティ」→「セキュリティ・プロバイダ構成」を選択し、「セキュリティ・プロバイダ構成」ページを表示します。
「アイデンティティ・ストア・プロバイダ」領域で「構成」をクリックし、「アイデンティティ・ストア構成」ページを表示します。
「カスタム・プロパティ」領域で「追加」をクリックし、表3-10に記載されているカスタム・プロパティを追加します。
表3-10 カスタム・プロパティ
プロパティ名 | 値 |
---|---|
user.login.attr |
認証プロバイダで設定されているユーザー名属性を指定します。たとえば、認証プロバイダでユーザー名属性が |
username.attr |
認証プロバイダで設定されているユーザー名属性を指定します。たとえば、認証プロバイダでユーザー名属性が |
図3-5は、ユーザー名属性がmail
に設定されたカスタム・プロパティの例を示しています。
「OK」をクリックして変更を保存します。
管理サーバーを再起動します。
注意: 第3.2項「代替認証プロバイダを構成するための大まかな手順」の手順4の説明に従って、認証プロバイダ(OID LDAPやADなど)のユーザーおよびグループがWebLogicコンソールに表示されていることを確認します。 |
Active Directoryサーバーでデフォルト値cn以外のグループ名属性を使用する場合は、それを変更する必要があります。この属性を変更する場合、表3-11に示すとおり、AllGroupsFilterおよびGroupFromNameFilterの設定も変更する必要があります(例は、AnOtherGroupAttributeという属性に保存されているグループ名を示しています)。
表3-11 グループ名属性の変更
属性名 | デフォルト設定 | 必要となる新しい設定 |
---|---|---|
StaticGroupNameAttribute/DynamicGroupNameAttribute |
cn |
AnOtherGroupAttribute |
AllGroupsFilter |
(&(cn=*)(objectclass=person)) |
(&(AnOtherGroupAttribute =*)(objectclass=person)) |
GroupFromNameFilter |
(&(cn=%u)(objectclass=person)) |
(&(AnOtherGroupAttribute =%u)(objectclass=person)) |
「プロバイダ固有」タブで、表3-11を使用して変更を行います(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-12に記載されているカスタム・プロパティを追加します。
表3-12 カスタム・プロパティ
プロパティ名 | 値 |
---|---|
PROPERTY_ATTRIBUTE_MAPPING |
認証プロバイダで設定されているGUID属性値を指定します。たとえば、認証プロバイダでGUID属性が |
図3-6は、GUID属性値がGUID=newvalue
に設定されたPROPERTY_ATTRIBUTE_MAPPINGという新しいプロパティを含む、一連のカスタム・プロパティの例を示しています。
「OK」をクリックして変更を保存します。
管理サーバー、管理対象サーバーおよびOracle BIコンポーネントを再起動します。
Oracle Business Intelligenceでは、内部通信用に構成された認証プロバイダに、特定のユーザーを使用します。たとえば代替認証プロバイダ(Oracle Internet Directory、Active Directoryなど)を使用するようにOracle BIを構成する場合、その代替認証プロバイダでこの目的に使用する新しいユーザーを作成(または既存のユーザーを選択)し、そのユーザーに必要な権限を与えます。選択したユーザーへの必要な権限の付与は、これらのユーザーを既存のBISystemアプリケーション・ロールのメンバーにすることによって行います。複数の認証プロバイダを構成する場合(詳細は、第3.4.5項を参照)、このユーザーが存在する必要があるアイデンティティ・ストアは、いずれか1つのみです。
代替認証プロバイダのユーザーで新しい信頼できるユーザー・アカウントを作成するには:
信頼できるユーザー・アカウントの資格証明は、system.userキーの下の資格証明ストアに格納されます。system.userキーが認証プロバイダ(Oracle Internet Directory、Active Directoryなど)で使用できる一連の資格証明を指すようにする必要があります。
既存のユーザーを使用しても新しいユーザーを作成しても、system.userキーの資格証明を構成するプロセスは同じです。
代替認証プロバイダで、信頼できるユーザーのためのユーザーを作成または特定します。
この信頼できるユーザーにBISystemUserという名前を付け、その目的を明確にすることがベスト・プラクティスですが、任意の名前を選択することもできます。
終了すると、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など)で作成された信頼できるユーザーを検索します。シャトル・コントロールを使用して、信頼できるユーザー名(BISystemUser)を「使用可能なユーザー」リストから「選択したユーザー」リストに移動します。
「OK」をクリックします。
代替認証プロバイダ(Oracle Internet Directory、Active Directoryなど)に含まれる信頼できるユーザー(BISystemUser)は、これでBISystemアプリケーション・ロールのメンバーになりました。
新しいシステム・ユーザーを構成する次の段階は、そのユーザーがWebLogic ServerのグローバルAdminロールの一部であることを確認することです。
Oracle WebLogic Server管理コンソールで「myrealm」をクリックして「<レルム>の設定」ページを表示し、「ロールとポリシー」タブを表示します。
ロールのリストでプラス記号をクリックして「グローバル・ロール」→「ロール」を開き、Adminロールの「ロール条件の表示」リンクをクリックします。
グローバルAdminロールに新しい信頼できるユーザーを追加します。
指定された条件が、直接、または所属するグループに基づいて、ユーザーと一致することを確認します(条件は、たとえば、User = BISystemUserまたはGroup=Administratorsのようになります)。
「保存」をクリックします。
信頼できるユーザー名をBISystemUser以外の値に変更する場合、Oracle Business Intelligence Publisher JMSモジュールの対応するユーザー名も変更する必要があります。
Oracle Business Intelligence Publisher JMSモジュールは、デフォルトでBISystemUserを使用します。したがって、信頼できるユーザー・アカウント名を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リポジトリおよび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をリフレッシュするように、構成ファイルを手動で編集する必要があります。完了したら、これらのファイルを編集してその変更を削除します。Oracle Business Intelligenceの構成ファイルの場所は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の構成ファイルの場所に関する項を参照してください。
ユーザーGUIDをリフレッシュするには、次の手順をAPPHOST1とAPPHOST2で実行します。GUIDのリフレッシュは、一度に1つのノードのみが動作している状態で行う必要があることに注意してください。
ユーザーGUIDをリフレッシュしているノード以外のすべてのノード上でOracle BIサーバーおよびプレゼンテーション・サービスを停止します。例:
cd ORACLE_HOME/admin/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 ORACLE_HOME/admin/instancen/bin ./opmnctl stopproc ias-component=coreapplication_obips1 ./opmnctl stopproc ias-component=coreapplicaiton_obis1 ./opmnctl startproc ias-component=coreapplicaiton_obis1
Oracle BI Serverが実行されていることを確認したら、プレゼンテーション・サービスを起動します。
./opmnctl startproc ias-component=coreapplicaiton_obips1
NQSConfig.INIのFMW_UPDATE_ROLE_AND_USER_REF_GUIDS
パラメータをNO
に戻します。
重要: システムを確実にセキュアな状態にするには、この手順を実行する必要があります。
instanceconfig.xmlのカタログ要素を更新し、UpdateAccountのGUIDエントリを削除します。
opmnctlを使用して、Oracle Business Intelligenceシステム・コンポーネントを再起動します。
cd ORACLE_HOME/admin/instancen/bin ./opmnctl stopall ./opmnctl startall
資格証明ストアおよびポリシー・ストア・プロバイダとしてOracle Internet Directory (OID 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に関する記述に置き換えられます。
OIDを使用するようにポリシー・ストアを再度関連付けることができる場合、Fusion Middleware ControlではなくOESユーザー・インタフェースを使用してポリシー・ストアを管理することもできます(OES Basicのライセンス条件に従います)。
Oracle Entitlements Server Basicの詳細は、Oracle Fusion Middlewareのライセンスに関する情報を参照してください。