| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド 12c (12.2.1.4.0) E96104-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド 12c (12.2.1.4.0) E96104-05 |
|
|
前 |
次 |
この章では、デフォルトのOracle WebLogic Server LDAPディレクトリではなく代替ディレクトリ・サーバーを認証に使用するように、Oracle Business Intelligenceを構成する方法を説明します。
セキュリティ設定ステップの詳細なリストは、「Oracle Business Intelligenceでセキュリティを設定するためのプロセス」を参照してください。
この章の構成は、次のとおりです。
代替認証プロバイダを使用する場合、通常はプロバイダ・ベンダーが提供する管理ツールを使用してユーザーおよびグループを設定します。これらのユーザーおよびグループをBIサービス・インスタンスで定義されたアプリケーション・ロールに割り当てることができます。
「Fusion Middleware Controlを使用したアプリケーション・ロールおよびアプリケーション・ポリシーの管理」を参照してください。
セキュリティ・モデルのその他の領域を管理するには、引き続き、他のOracle Business Intelligenceツール(Oracle BI管理ツール、Fusion Middleware Control、プレゼンテーション・サービスの管理ページなど)を使用します。
現在サポートされている、Oracle Business Intelligenceで使用できる認証プロバイダおよびディレクトリ・サーバーのリストを表示するには、「新しい認証プロバイダの作成」ページの「タイプ」リストで認証プロバイダを選択します。「システム要件と動作保証」を参照してください。
サポートされている認証プロバイダを1つ以上構成できます。「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」を参照してください。
デフォルトのWebLogic LDAPサーバー以外のディレクトリ・サーバーを使用している場合は、Oracle WebLogic Server管理コンソールに、他のディレクトリ・サーバーのユーザーおよびグループを表示できます。ただし、使用しているディレクトリ・サーバーのインタフェースでユーザーおよびグループを管理する必要があります。たとえば、Oracle Internet Directory (OID LDAP)を使用している場合、OIDコンソールを使用して、ユーザーおよびグループの作成と編集を行う必要があります。
これらのステップは、代替認証プロバイダを構成するための汎用ガイドとして使用します。
「代替認証プロバイダのグループおよびユーザーの設定」、「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」および「アプリケーション・ロールのメンバーの追加または削除」を参照してください。
代替認証プロバイダを使用する前に、適切なグループおよびユーザーを構成する必要があります。BIサービス・インスタンス内のアプリケーション・ロールに関連付けます。これらのステップに従って、代替認証プロバイダを設定します。
Oracle Business Intelligenceでは特定のユーザーまたはグループを必要としないため、本番環境の企業のアイデンティティ・ストア(Oracle Internet Directory (OID)など)は組織に関連するユーザーおよびグループが通常すでに含まれています。ただし、サンプル・アプリケーションLiteまたは初期アプリケーションに基づく簡単なシステムの設定方法の例は、「ユーザー、グループおよびアプリケーション・ロールのセキュリティ設定の例」を参照してください。
これらのオプションに従って、デフォルトのOracle WebLogic Server LDAPディレクトリのかわりに1つ以上の認証プロバイダを使用するようにOracle Business Intelligenceを構成します。
この項では、次の項目について説明します。
ノート:
単一のLDAPアイデンティティ・ストアにユーザーおよびグループを格納することで十分です。ただし、拡張インストールの場合、複数のLDAPアイデンティティ・ストアまたはデータベース・アイデンティティ・ストアのユーザーが必要になる場合があります。アイデンティティ・ストアの仮想化を使用してこれらを有効化します。「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」を参照してください。
ノート:
Oracle Unified DirectoryをLDAP代替認証プロバイダとして構成する場合は、『Oracle WebLogic Serverセキュリティの管理』の他のLDAPサーバーへのアクセスに関する項およびOracle Unified Directory認証プロバイダの構成に関する項を参照してくださいこれらのステップを使用して、Oracle Internet Directory (OID) LDAPを認証プロバイダとして最構成します。
ノート:
ユーザー名属性またはグループ名属性がOracle Internet Directoryのcn以外の値に構成されている場合、Oracle WebLogic Server管理コンソールの対応する値を変更する必要があります。OracleInternetDirectoryAuthenticatorおよびActiveDirectoryAuthenticatorを含め、LDAPオーセンティケータのユーザー名およびグループ名の属性は、デフォルトでcnに設定されています。uidやmailなど、ユーザー名に代替属性を使用できます。
「プロバイダ固有」タブの値について学習するには、「Oracle Internet Directoryオーセンティケータ固有のリファレンス」を参照してください。
次を参照してください。
『Oracle WebLogic Serverセキュリティの管理』のWebLogic Serverでの認証プロバイダの構成に関する項。
次のタスクを完了する必要もあります。
前述のタスクを完了した後、チェンジ・センターで「変更のアクティブ化」をクリックし、Oracle WebLogic Serverを再起動します。
この表を参照して、Oracle Internet Directory (OID)オーセンティケータに必要な値を入力します。
この表を使用して、MyOIDDirectoryの「設定」の「プロバイダ設定」ページ内のフィールドの詳細を参照します。「認証プロバイダとしてのOracle Internet Directoryの再構成」を参照してください。
| セクション名 | フィールド名 | 説明 |
|---|---|---|
| 接続 |
ホスト |
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検索フィルタ。詳細は、「詳細」をクリックします。 これはActive Directoryオーセンティケータのデフォルト値であるため、空白のままにします。 「すべてのユーザーのフィルタ」に追加するすべてのフィルタは、すべてのユーザー検索に追加されます。 |
| ユーザー |
名前指定によるユーザー・フィルタ |
LDAP検索フィルタ。詳細は、「詳細」をクリックします。 |
| ユーザー |
ユーザー名属性 |
認証に使用する属性(cn、uid、mailなど)。たとえば、ユーザーの電子メール・アドレスを使用して認証を行うには、この値を 指定する値は、認証プロバイダで使用しているユーザー名属性と一致している必要があります。 |
| ユーザー |
取得したユーザー名をプリンシパルとして使用する |
LDAPサーバーから取得されるユーザー名が、サブジェクトのプリンシパルとして使用されるかどうかを指定します。 大文字小文字を統一できるので、このチェック・ボックスは選択することをお薦めします。たとえば、LDAPユーザー名がJSmithである場合、jsmith (小文字のみ)でログインした場合でも、プリンシパルはJSmith (大文字小文字混合)になります。これはつまり、グループを間接的に介すのではなく、ユーザーに直接付与されるアプリケーション・ロール・メンバーシップが認証時に一貫して適用されるということです。 |
この手順に従って、Microsoft Active Directoryを使用するよう、Oracle Business Intelligenceインストールを再構成します。
この項のデータ例では、内部ユーザー用にOracle Business IntelligenceのSSOを設定するXYZ Corporationという架空の企業を使用します。
この例では、次の情報が使用されます。
Active Directoryドメイン
XYZ Corporationには、xyzcorp.comというActive Directoryドメインがあり、このドメインはすべての内部ユーザーを認証します。この企業ネットワークにログインすると、ログイン先はこのActive Directoryドメインになります。ドメイン・コントローラはaddc.xyzcorp.comで、これによってActive Directoryドメインが制御されます。
Oracle BI EE WebLogicドメイン
XYZ Corporationでは、bieesvr1.xyz2.comというネットワーク・サーバー・ドメインに、bi (デフォルト名)というWebLogicドメインがインストールされています。
システム管理者およびテスト・ユーザー
次のシステム管理者およびドメイン・ユーザーが構成のテストを行います。
システム管理者ユーザー
Jo Smith (login=jsmith、hostname=xyz1.xyzcorp.com)
ドメイン・ユーザー
Bob Jones (login=bjones hostname=xyz47.xyzcorp.com)
『Oracle WebLogic Serverセキュリティの管理』のWebLogic Serverでの認証プロバイダの構成に関する項を参照してください。
「JAAS制御フラグ・オプションの設定」および「ユーザー名属性の構成」を参照してください。
OracleInternetDirectoryAuthenticatorおよびActiveDirectoryAuthenticatorを含め、WebLogicで提供されているLDAPオーセンティケータは、cnをユーザー名およびグループ名の属性として使用するようにデフォルトで設定されています。
uidやmailなど、ユーザー名に代替属性を使用することが必要な場合があります。異なるグループ名属性の使用が必要になることは、あまりありません。この項では、ユーザー名とグループ名を再構成する方法について説明します。
この項の内容は次のとおりです。
この項では、mailをユーザー名属性として使用するためなど、OracleInternetDirectoryAuthenticator (OID)を再構成する方法について説明します。
「ユーザー」セクションには、値mailを使用して構成されたユーザー名属性が表示されます。
代替認証プロバイダのUserNameAttributeは、通常、値cnの値に設定されています。UserNameAttributeがcnに設定されていない場合は、AllUsersFilterおよびUserFromNameFilterの設定が、表に示すとおりに正しく構成されていることを確認する必要があります。次の表に、値cnを使用したデフォルト設定、および属性AnOtherUserAttributeに新しい値を使用した、必要となる新しい設定を示します。
| 属性名 | デフォルト設定 | 必要となる新しい設定 |
|---|---|---|
UserNameAttribute |
cn |
|
AllUsersFilter |
(&(cn=*)(objectclass=person)) |
|
UserFromNameFilter |
(&(cn=%u)(objectclass=person)) |
|
「プロバイダ固有」タブで、AnOtherGroupAttribute設定を独自の値で置換し、変更します。「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」を参照してください。
cn以外のグループ名を使用するように、ActiveDirectoryAuthenticatorを構成できます。
Active Directoryサーバーのグループ名がデフォルト値cn以外の値に設定されている場合、グループ名を変更する必要があります。この値を変更する場合、AllGroupsFilterおよびGroupFromNameFilterの値をAnOtherGroupAttribute属性のように変更する必要もあります。
| 属性名 | デフォルト設定 | 必要となる新しい設定 |
|---|---|---|
StaticGroupNameAttribute/DynamicGroupNameAttribute |
cn |
AnOtherGroupAttribute |
AllGroupsFilter |
|
(&(AnOtherGroupAttribute =*)(objectclass=person)) |
GroupFromNameFilter |
|
|
「プロバイダ固有」タブで、表内の値を使用してAnOtherGroupAttribute設定を独自の値で置換し、変更します。「プロバイダ固有」タブを表示するには、「認証プロバイダとしてのMicrosoft Active Directoryの再構成」を参照してください。
この項の例では、Oracle Internet Directory (OID LDAP)およびサンプル・データベース・スキーマを使用します。ただし、OID LDAPをLDAPアイデンティティ・ストアとして使用したり、サンプルと同じデータベース・スキーマを使用したりする必要はありません。
Oracle Business Intelligenceでは、この方法の使用を可能にする、BISQLGroupProviderというWebLogic Server用の認証プロバイダが提供されます。この認証プロバイダでは、エンド・ユーザーの資格証明は認証されませんが、データベース表に保持された外部のグループ・メンバーシップを認証済ユーザーのIDに提供できます。
この項では、次の項目について説明します。
この項の説明に従ってLDAP認証の構成を試みる前に、次の前提条件を満たす必要があります。
Oracle Business Intelligence Enterprise Editionリリース12.2.1.0 (またはそれ以降)がインストールされ、実行されている必要があります。
Oracle BI EE 12.2.1.0システムにすべての関連するパッチを適用する必要があります。
必要なグループを含む1つ以上の表が格納された適切なデータベース・スキーマ、およびそれらのグループをLDAPによって認証されるユーザーの名前にマップするマッピング表が実行され、かつ、Oracle BI EEが実行されているOracle WebLogic Serverからアクセスできる必要があります。
ユーザーを格納するアイデンティティ・ストアとして使用するために、サポートされているLDAPサーバーが構成に含まれている必要があります。
Oracle Business Intelligenceからアプリケーション・ロールのメンバーにコンテンツを配信する必要がある場合、次の制約が適用されます。
ペアにできるのは、単一のLDAP認証プロバイダと単一のBISQLGroupProviderのみです。
複数のLDAP認証プロバイダを構成し、BISQLGroupProviderからグループ・メンバーシップを取得する必要がある場合、コンテンツをアプリケーション・ロールのすべてのメンバーに配信できません。この構成では、Oracle BIデリバーでユーザーおよびグループ・メンバーシップに基づいてアプリケーション・ロールのメンバーシップを解決できません。
複数のアイデンティティ・ストアで同じグループは定義できません。
LDAPおよびデータベース・グループ表の両方で同じ名前のグループを使用できません。これを行った場合、Oracle BIデリバーによって起動されるセキュリティ・コードでアプリケーション・ロールのメンバーシップを解決できなくなります。
ここで説明するサンプル・スキーマは意図的に単純化されており、スキーマを使用するようOracle Business Intelligenceを構成する方法についてのみ説明します。
ACME_BI_GROUPSサンプル・スキーマには、2つの表とビューが含まれます。GROUPS表では、外部グループのリストが定義されています。GROUPMEMBERS表およびGROUPMEMBERS_VWビューでは、プライマリ・アイデンティティ・ストア内に存在するユーザーのグループ・メンバーシップが記述されます。
図に示すものと同じ表またはビューを定義することの利点は、BISQLGroupProviderの構成で、「BISQLGroupProvider SQLオーセンティケータの構成」の表に概説されたデフォルトのSQLを使用できることです。
LDAPストア内のユーザーを、データベース表のグループにログイン名でマップする必要があります。この図では、GROUPMEMBERS表のG_MEMBERの値が、LDAPオーセンティケータに指定されているように、ログインに使用されるLDAP属性の値(uid、cn、mailなど)と一致する必要があります。たとえば、ログイン属性がmailのときに、データベース・グループをuidでマップしないようにする必要があります。GROUPMEMBERS表とGROUPS表の間の外部結合を使用して、GROUPMEMBERS_VWビューを作成します。
Oracle WebLogic Server管理コンソールを使用して、データ・ソースとBISQLGroupProviderを次のように構成します。
リンク先の手順を使用して、ユーザー移入をOID LDAPに対して認証するようにWebLogicを構成します。
「認証プロバイダとしてのOracle Internet Directoryの再構成」を参照してください。
ノート:
このタスクのステップに従うときに、OID LDAPオーセンティケータの「プロバイダ固有」構成ページに表示される「ユーザー・ベースDN」および「ユーザー名属性」の値を、後で使用するためにノートにとっておいてください。「グループ情報を取得するためのデータベース・アダプタの構成」を参照してください。
BISQLGroupProvider認証プロバイダを構成する前に、まず認証プロバイダが格納されたJARファイルbi-sql-group-provider.jarをインストールする必要があります。ファイルは次の場所にあります。
ORACLE_HOME/bi/plugins/security/bi-sql-group-provider.jar
ファイルを次の場所にコピーする必要があります。
ORACLE_HOME/wlserver/server/lib/mbeantypes
ファイルを指定された場所にコピーした後、管理サーバーを再起動して、使用可能な認証プロバイダのリストに新しいプロバイダが表示されるようにする必要があります。
ノート:
インストールしてクラスタ環境を作成した場合、そのインストールでは、スケールが拡大された管理対象サーバーを再起動できません。これは、bi-sql-group-provider.jarファイルが使用できないためです。インストール中にこの状況が発生した場合は、JARファイルを正しい場所にコピーし、インストーラで「再試行」をクリックします。
これらのステップにより、Oracle WebLogic Server管理コンソールを使用してデータ・ソースを構成できます。
ノート:
この例で使用するデータベースの名前はBIDatabaseGroupDSです。
これらのステップに従って、例の表の構造を使用し、BIDatabaseGroupDSデータ・ソースに対してBISQLGroupProviderを作成します。
このタスクでは、「グループおよびグループ・メンバーのサンプル・スキーマの作成」で概説した例の表の構造を使用し、BIDatabaseGroupDSデータ・ソースに対してBISQLGroupProviderを作成する方法について説明します。構造が例と異なる場合は、使用するSQL文(表や列名)の変更が必要になる可能性があります。
ノート:
データベースにはユーザーに関連付けられるグループが格納されるのみであるため、データベースに対する認証はありません。認証はLDAPに対して発生し、Oracle WebLogic Server管理コンソールでBISQLGroupProviderによってグループがアプリケーション・ロールに割り当てられたときに、データベースが公開されます。
『Oracle WebLogic Serverセキュリティの管理』のWebLogic Serverでの認証プロバイダの構成に関する項を参照してください。
Oracle WebLogic Server管理コンソールにWebLogic管理者としてログインし、チェンジ・センターで「ロックして編集」をクリックします。
左ペインで「セキュリティ・レルム」を選択し、「myrealm」をクリックします。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
「プロバイダ」タブを表示し、「認証」サブタブを表示します。
「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。
「新しい認証プロバイダの作成」ページで、次のように値を入力します。
名前: 認証プロバイダの名前を入力します。たとえば、MySQLGroupProviderと入力します。
「タイプ」リストからBISQLGroupProviderを選択します。
「OK」をクリックし、変更を保存して、新しい認証プロバイダで更新された認証プロバイダ・リストを表示します。
認証プロバイダの表の「名前」列でMySQLGroupProviderをクリックし、「設定」ページを表示します。
「プロバイダ固有」タブを表示して、データベース表に対して問合せおよび認証を行うために使用するSQL文を指定します。
「データ・ソース名」を指定します。たとえば、BIDatabaseGroupDSです。
必要なすべてのSQL文を、使用する認証プロバイダに入力します。
SQLでは大/小文字が区別されます。
「保存」をクリックします。
次のステップに従って認証プロバイダを並べ替えます。
「プロバイダ」タブを表示します。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します
「BISQLGroupProvider」を選択し、矢印ボタンを使用してこれをリストの最初に移動します。
「OK」をクリックして、変更を保存します。
次のステップを実行し、BISQLGroupProviderの「制御フラグ」設定を構成します。
メインの「myrealmの設定」ページで、「プロバイダ」タブ→「認証」サブタブを表示し、「BISQLGroupProvider」を選択して、その構成ページを表示します。
「構成」→「共通」タブを表示し、「制御フラグ」リストで「OPTIONAL」を選択します。
「保存」をクリックします。
チェンジ・センターで、変更のアクティブ化をクリックします。
管理サーバーが再起動したらFusion Middleware Controlを使用して、Oracle Business Intelligenceコンポーネント、Oracle WebLogic Serverおよび管理対象サーバーを再起動します。
ノート:
「ユーザーとグループ」タブをチェックして、データベースのユーザーとグループが表示されていることを確認します。
仮想アイデンティティ・ストアを次のように構成します。
仮想化を有効化するようにアイデンティティ・ストアを構成し、これにより、アイデンティティ・ストア・サービスで複数のアイデンティティ・ストアを使用できるようにします。
様々な認証プロバイダ(アイデンティティ・ストア)全体に関するユーザー・プロファイル情報を分割できます。「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」を参照してください。
SSL(一方向SSLのみ)で通信するためにLDAP認証プロバイダを構成した場合、仮想化(libOVD)機能で使用される追加キーストアに、該当するLDAPサーバーのルート証明書を配置する必要があります。
「複数認証プロバイダ使用時のSSLの構成」を参照してください。
LDAPサーバーのように認識されるようにデータベース・アダプタを構成します。これにより、仮想アイデンティティ・ストア・プロバイダは、そのデータベース・アダプタを使用してグループ情報をデータベースから取得できます。
このタスクでは、データベース表をアイデンティティ・ストアとして使用してグループをマップする方法を指定する、アダプタ・テンプレートの要素を含むファイルを作成します。このファイルは、GROUPMEMBERS_VWビューから仮想LDAPストアへのマッピングを記述します。このビューでは外部結合を使用して、複数の表のフィールドをデータベース・アダプタで参照できるようにします。
bi_sql_groups_adapter_template.xmlという名前のファイルを作成します。
自分の表と列の属性が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="groupnameattr" table="GROUPMEMBERS" 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" field="G_NAME" type=""/>
</objectClass>
</mapping>
<useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
<connectionWaitTimeout>10</connectionWaitTimeout>
<oracleNetConnectTimeout>0</oracleNetConnectTimeout>
<validateConnection>false</validateConnection>
</dataBase>
</adapters>
次の要素について、適切なセクションをカスタマイズします。
ReplaceAttribute
グループで一意のメンバーを定義する方法を指定します。%uniquemember%は、ユーザーがグループのメンバーかどうかをルックアップする際の実行時に渡される値のプレースホルダです。
この要素について変更する唯一の点は、ユーザーのルートの指定です。概念的には、libovdadapterconfigスクリプトをステップ7で実行する際にユーザー移入のルートとして指定するものにデフォルトで一致する必要があります。
groupofuniquenenames
グループ属性がデータベース・フィールドにどのようにマップされるかを指定します。
次の属性をマップする必要があります。
cnは、グループの一意の名前にマップします。
uniquememberは、データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップします。
次の属性のマップはオプションです。
descriptionはオプションです。
その他の属性は構成できません。
アダプタ・ファイルを次のフォルダにコピーします。
ORACLE_HOME/oracle_common/modules/oracle.ovd/templates/
次の場所でコマンド・プロンプトまたはターミナルを開きます。
ORACLE_HOME/oracle_common/bin
次の環境変数のように設定されていることを確認します。
ORACLE_HOME=oraclehome
WL_HOME=ORACLE_HOME/wlserver/
JAVA_HOME=ORACLE_HOME/jdk/jre
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 9500 -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にログインします。
既存のデータベース・アダプタは修正しないでください。アダプタの作成で使用するテンプレートやlibovdadapterコマンドでエラーが発生した場合は、アダプタを削除してから再作成する必要があります。
「アダプタの削除および再作成によるデータベース・アダプタ・エラーの修正」を参照してください。
この項では、SQLAuthenticatorおよび仮想アイデンティティ・ストア・データベース・アダプタを使用することで、データベースを認証プロバイダとして使用するようにOracle Business Intelligenceを構成する方法について説明します。この項の内容は次のとおりです。
ユーザー・ロールとプロファイル情報は、データベースをLDAPサーバーのように表示できるアダプタを使用してデータベースに格納できます。仮想アイデンティティ・ストア・プロバイダは、このデータベース・アダプタを介してユーザー・プロファイル情報をデータベースから取得できます。
このトピックでは、SQLAuthenticatorおよび仮想アイデンティティ・ストア・プロバイダ(データベース・アダプタを含む)を使用するようにOracle Business Intelligenceを構成する方法について説明します。両方とも適切なデータベース・スキーマに対して実行します。ここに示す例は説明のためのものであり、実際のデータベース・スキーマに、ここで説明するサンプルと同じ値を指定してはいけません。
この手順は、ユーザーをデータベース・スキーマに対して認証する必要がある場合に使用します。認証に優先されるアイデンティティ・ストアは、Oracle Internet Directory (OID LDAP)などのLDAPディレクトリ・サービスです。
ここで説明するデータベース認証のアプローチには、それぞれにユーザーおよびパスワードを格納する2つのデータベース列が必要です。データベース・ユーザー・アカウントには基づきません。
Oracle Business Intelligence Enterprise Editionリリース11.1.1.5、11.1.1.6および11.1.1.7 (またはそれ以降)がインストールされ、実行されている必要があります。ただし、リリース11.1.1.5および11.1.1.6の場合、Oracle Fusion Middlewareパッチ13826887も適用する必要があります。『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceシステムのパッチ適用に関する項を参照してください。
以前のOracle BI EEインストールで使用していたスキーマを使用します。このサンプル・スキーマは、このスキーマを使用するようにシステムを構成する方法を示すことを目的としています。
ノート:
認証に必要なユーザー、資格証明およびグループを含むデータベース・スキーマを使用する必要があり、このスキーマには、Oracle BI EEが実行されているWebLogic Serverからアクセスできます。
次の図に、表USERS、USER_VW、GROUPMEMBERS、GROUPSおよびGROUPMEMBERS_VWを示します。USER_VWはUSERS表のビューであり、GROUPMEMBERS_VWはGROUPMEMBERS表とGROUPS表を結合したビューです。
ユーザーまたはグループの情報が複数の表に存在する場合は、USER_VWを削除し、各種情報の表について1つのビューを作成する必要があります。
GROUPS表での外部結合とGROUPMEMBERS表での内部結合を使用してGROUPMEMBERS表とGROUPS表のビュー(GROUPMEMBERS_VWなど)を作成し、ユーザーが割り当てられていない場合でもFusion Middleware Controlでグループを確認できるようにします。図に示すビューをデータベース・アダプタに提示するには、「データベース・アダプタの構成」に示す構成に従うことが必要となる場合があります。
Oracle WebLogic Server管理コンソールを使用して、データ・ソースとSQLオーセンティケータを次のように構成します。
これらのステップを使用して、Oracle WebLogic Server管理コンソールを使用してデータ・ソースを構成します。
表のスキーマ所有者は、「ユーザーおよびグループのサンプル・スキーマの作成」で定義されています。
「Oracle WebLogic Server管理コンソールの使用」を参照してください。
適切な権限を付与されたユーザーは、WebLogicデータベース・オーセンティケータを使用してOracle WebLogic Server管理コンソールにログインできます。
SQLオーセンティケータを作成する場合は、読取り専用SQLオーセンティケータを選択します。読取り専用認証プロバイダ・タイプでは、データベースに書き戻されることはありません。
「プロバイダ固有」タブにSQL文を入力する際にパスワード列がプレーンテキストである場合(「SQL - ユーザー・パスワードの取得」列に対して返された問合せの結果がハッシュ化または暗号化されていない場合)、「プレーンテキスト・パスワードの有効化」オプションを選択します。
「プレーンテキスト・パスワードの有効化」オプションがクリアされている場合、SQLAuthenticatorでは、SHA-1 (デフォルトの暗号化アルゴリズム)を使用してパスワードがハッシュされていると想定されます。サポートされる暗号化アルゴリズムの詳細は、ベースSQLAuthenticator Mbean PasswordAlgorithm属性に関するドキュメントを参照してください。
このタスクの完了後、デフォルト・オーセンティケータ制御フラグを構成し、認証プロバイダを並べ替えて、サーバーを再起動する必要があります。
SQL認証プロバイダを実装する際のSQL文の作成に使用可能なオプションについて学習します。
SQLオーセンティケータを作成する場合は、「プロバイダ固有」タブで、データベース表に対する問合せおよび認証に使用するSQL文を指定します。「Oracle WebLogic Server管理コンソールの使用によるSQL認証プロバイダの構成」を参照してください。
次の表に、「ユーザーおよびグループのサンプル・スキーマの作成」で概説したサンプル・スキーマのSQL文を示します。
異なる表構造を使用する場合は、自分のスキーマの表または列の名前に合うように、これらのSQL文を変更することが必要になる場合があります。ユーザー名やグループ名をハードコードするかわりに、疑問符(?)をランタイム問合せのプレースホルダとして使用する必要があります。
| 問合せ | SQL | ノート |
|---|---|---|
| SQL - ユーザー・パスワードの取得 |
|
このSQL文は、ユーザーのパスワードをルックアップします。このSQL文にはユーザー名のパラメータが1つ必要であり、このSQL文は、パスワードを含む最大1つのレコードを格納した |
| SQL - ユーザーが存在 |
|
このSQL文は、ユーザーをルックアップします。このSQL文にはユーザー名のパラメータが1つ必要であり、このSQL文は、ユーザーを含む最大1つのレコードを格納した |
| SQL - ユーザーのリスト |
|
このSQL文は、特定のワイルドカード検索に一致するユーザーを取得します。このSQL文にはユーザー名のパラメータが1つ必要であり、このSQL文は、一致したユーザー名を格納した |
| SQL - グループのリスト |
|
このSQL文は、ワイルドカードに一致するグループ名を取得します。このSQL文にはグループ名のパラメータが1つ必要であり、このSQL文は、一致したグループを格納した |
| SQL - グループが存在 |
|
このSQL文は、グループをルックアップします。このSQL文にはグループ名のパラメータが1つ必要であり、このSQL文は、グループを含む最大1つのレコードを格納した |
| SQL - メンバーかどうか |
|
このSQL文は、グループのメンバーをルックアップします。このSQL文には2つのパラメータ(グループ名とメンバーまたはグループ名)が必要です。このSQL文は、 |
| SQL - メンバー・グループのリスト |
|
このSQL文は、ユーザーまたはグループのグループ・メンバーシップをルックアップします。このSQL文にはユーザー名またはグループ名のパラメータが1つ必要であり、このSQL文は、基準に一致したグループの名前を格納した |
| SQL - ユーザーの説明の取得 |
|
このSQL文は、特定のユーザーの説明を取得します。このSQL文は、 |
| SQL - グループの説明の取得 |
|
このSQL文は、グループの説明を取得します。このSQL文は、 |
各プロバイダのJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの扱いを制御します。
新しいオーセンティケータを追加した後、「認証プロバイダ」表を並べ替えることができます。
仮想アイデンティティ・ストアを次のように構成します。
これらのステップに従って、データベースがLDAPサーバーのように認識されるようにデータベース・アダプタを構成します。これにより、仮想アイデンティティ・ストア・プロバイダでは、このデータベース・アダプタを使用してユーザー・プロファイル情報をデータベースから取得できます。
このタスクは、データベース表をアイデンティティ・ストアとして使用する方法を指定する、アダプタ・テンプレートを編集して適用する方法を示しています。ここに示す例は、「認証プロバイダとしてのデータベースの構成」全体を通じて使用されるサンプル・スキーマ用です。
adapter_template_usergroup1.xmlファイルをカスタマイズする場合、仮想LDAPスキーマで使用されるクラスおよび属性をデータベース内の列と照合して、要素をマップします。この仮想スキーマはWebLogicの組込み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>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="GUID" type=""/>
</objectClass>
</mapping>
<useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
<connectionWaitTimeout>10</connectionWaitTimeout>
<oracleNetConnectTimeout>0</oracleNetConnectTimeout>
<validateConnection>false</validateConnection>
</dataBase>
</adapters>
<objectClass>要素:
name="person"およびrdn="cn"の値は、LDAP personオブジェクト・クラスのマッピングを宣言します。
cn属性は相対識別名(RDN)として使用されます。
子要素は、データベース内の表および列へのLDAP属性マッピングを宣言します。次に例を示します。
<attribute ldap="uid" table="USER_VW" field="USER_ID" type=""/>の行では、USER_VW表のUSER_IDフィールドを、標準のLDAP属性であるuid (ユーザーごとに一意のユーザーID)にマップします。
USER_VWビューには、adapter_template_usergroup1.xmlのGUID列にマップされるorclguid属性と一致するGUID列が含まれている必要があります。次に例を示します。
USER_VWビューを次のように作成または置換できます。
SELECT U_NAME, MAIL_ADDRESS, U_PASSWORD, U_DESCRIPTION, RPAD(U_NAME, 16, '0') AS GUID FROM USERS;
| 属性 | 例 |
|---|---|
| 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 |
| manager |
uid=mary.jones,ou=people,ou=myrealm,dc=wc_domain |
| preferredLanguage |
en |
| departmentNumber |
tools |
| 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="groupofuniquenames" ...>要素で、グループに一意のメンバーを定義します。%uniquemember%値は、ユーザーがグループのメンバーかどうかを判断するためにルックアップする際の実行時に渡される値のプレースホルダです。この要素について変更する唯一の点は、ユーザーのルートの指定です。%uniquemember%値は、libovdadapterconfigスクリプトを実行する際のユーザー移入のルートと一致します。
groupofuniquenamesオブジェクト・クラスは、ユーザー同様、グループ属性をデータベース・フィールドにマップする方法を指定します。この属性は、Weblogicの組込みLDAPのデフォルトに対応します。次の属性をマップする必要があります。
cnは、グループの一意の名前にマップします。
uniquememberは、データベース・スキーマのユーザー/グループ・マッピング表におけるユーザーの一意の名前にマップします。
orclguidは、データベース・スキーマで使用可能な場合には一意のIDにマップします。
description属性のマップはオプションです。
この項では、SQLオーセンティケータのトラブルシューティング情報について、次のトピックで説明します。
データベース・ユーザーを使用してOracle Business Intelligenceにログインできない場合は、この診断テストを使用できます。
データベース・ユーザーを使用してOracle Business Intelligenceにログインできない場合に役立つ診断テストとして、そのユーザーがWebLogicにログインできるかどうかを確認することがあります。WebLogicコンテナ認証を利用する他のアプリケーションがWebLogic Server上にない場合は、ユーザーを(一時的に) WebLogicのグローバルAdminロールに追加し、そのユーザーがOracle WebLogic Server管理コンソールにログインできるかどうかを確認することで、SQLAuthenticatorが正しく動作していることをテストします。
ユーザーがコンソールにログインできるがOracle Business Intelligenceにログインできない場合、SQLAuthenticatorは正しく動作していますが、アイデンティティ・ストア・サービスに問題がある可能性があります。「Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化の構成」でvirtualize=trueとOPTIMIZE_SEARCH=trueプロパティが指定してあることを確認し、「データベース・アダプタの構成」で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)
「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コマンドまたはテンプレートでエラーが発生した場合は、アダプタを削除してから再作成する必要があります。
これらのステップを使用して、Fusion Middleware Controlを使用したアイデンティティ・ストアの仮想化を構成します。
SSLでLDAPと通信している場合(一方向SSLのみ)は、「複数認証プロバイダ使用時のSSLの構成」を参照してください。
「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」の説明に従って、サポートされている認証プロバイダを構成します。
この項では、1つの認証プロバイダが失敗した場合に、他の認証プロバイダを使用するユーザーはOracle Business Intelligenceにログインできるように認証プロバイダを構成する方法について説明します。
複数の認証プロバイダを使用するようにOracle Business Intelligenceを構成している場合で、1つの認証プロバイダが使用できなくなれば、他の認証プロバイダを使用するユーザーもOracle Business Intelligenceにログインできなくなります。
「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にログインできるようになります。
複数の認証プロバイダを構成する際、各プロバイダのJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの扱いを制御します。JAAS制御フラグはOracle WebLogic Server管理コンソールで設定できます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJAAS制御フラグの設定に関する項を参照してください。Oracle 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認証プロバイダに適用できます。
WebLogic Server LDAPのデフォルトの認証メソッドを無効にするプロセスを開始する前に、まずシステムをバックアップすることを強くお薦めします。バックアップしないと、構成時に間違えた場合に、システムからロックアウトされたり、システムを再起動できなくなることがあります。
再構成フェーズでバックアップおよびリカバリを有効にするには、ORACLE_HOME\user_projects\domains\bi\configディレクトリにあるconfig.xmlファイルのコピーを作成します。
変更を行う際は、このファイルのコピーを保持しておきます。
デフォルトのWebLogic Server認証プロバイダを削除し、代替LDAPソース(OID LDAPなど)を使用するには、WebLogic Serverと代替メソッドの両方を使用するようにシステムを構成する必要があります。
「代替認証プロバイダを使用するためのOracle Business Intelligenceの構成」を参照してください。WebLogic Server LDAPユーザー(デフォルト・オーセンティケータ)と新しい代替LDAPユーザーがともにOracle Business Intelligenceにアクセスできるように構成されている状態から開始します。
WebLogic Server LDAPユーザーとしてもOID LDAPユーザーとしてもログオンできるようにシステムを構成したら、次の各タスクの説明のとおり、WebLogic Serverのデフォルト認証プロバイダを削除するステップに進みます。
表に示す必須ユーザーが、WebLogic Server LDAPからOID LDAPに移行されていることを確認する必要があります。
| 標準のWebLogic Serverユーザー | OID LDAPで新たに必要とされるユーザー |
|---|---|
LCMManager,User |
OID_LCMManagerUser (任意の既存OID LDAPユーザーを使用できます)。 |
例: weblogic |
OID_Weblogic (任意の既存OID LDAPユーザーを使用できます)。 |
OracleSystemUser |
OracleSystemUser (このユーザーは、OWSMの固定要件として、OID LDAPにおいてこの名前で存在する必要があります)。 |
インストール時に次の3つのユーザーが作成されます。
weblogicまたはインストール時やアップグレード時に指定される項目。このため、異なる場合があります。
この管理者ユーザーはインストール時に作成されます(weblogicと呼ばれることもありますが、任意の名前でかまいません)。OID LDAPで同等のユーザーを特定または作成する必要がありますが、このユーザーはAdministratorsというグループの一部である必要がある任意の名前でかまいません。
OracleSystemUser
このユーザーは、Oracle Web Services Manager (OWSM)で特にグローバル・ロール・マッピングのために必要です。このユーザーは、正確にこの名前を使用して、OID LDAPで作成する必要があります。
OID LDAPグループにマップして、グローバル・ロールを構成します。
| グローバル・ロール | 現在の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オーセンティケータを無効にする前に、(Oracle WebLogic Server管理コンソールに表示されている)表のグローバル・ロールと、置換OID LDAPグループを関連付ける必要があります。
デフォルトのセキュリティ・レルムはmyrealmという名前です。
AnonymousおよびOracle Systemロールには、新しい条件を追加しないでください。どちらも変更されないままになることがあります。
デフォルトのWebLogic Server認証を無効にした後、古いWebLogic Serverグループを削除できます。「タスク8 - WebLogic Serverロールの削除」を参照してください
OID LDAPで新しいユーザーおよびグループを作成し、WebLogic Server LDAPで自動的に作成されたユーザーおよびグループをレプリケートしたため、次に、これらのユーザーおよびグループが、OID LDAPにおいても、表に示すとおり正しいグループ・メンバーシップを持っていることを確認する必要があります。
| 新しいOID LDAPユーザー | メンバーとなる新しいOID LDAPグループ |
|---|---|
OID_Weblogic |
OID_Administrators OID_BIServiceAdministrators |
OracleSystemUser 正確にこの名前のユーザーがOID LDAPに存在する必要があります。 |
OracleSystemGroup 正確にこの名前のグループがOID LDAPに存在する必要があります |
ノート:
表に示すユーザーとグループのメンバーシップを実現するには、OID LDAPサーバーを更新できる適切なアクセス権を持つか、別の担当者がかわりにグループのメンバーシップを更新できる必要があります。これでデフォルトの認証プロバイダを削除する準備が整いました。
このタスクを実行する前に、LDAPソースにマップするLDAPオーセンティケータを作成しておく必要があります。「タスク2 - WebLogic Serverおよび代替認証プロバイダを使用するためのシステムの構成」を参照してください。
「JAAS制御フラグ・オプションの設定」を参照してください。
これでBIサービスを再起動する準備が整いました。インストール時に作成したOracle WebLogic Server管理者ユーザーは削除され、すべてのユーザーが単一OIDソースに存在するため、新しいOID管理者ユーザー(OID_Weblogicなど)を使用する必要があります。OID管理者ユーザーには、WebLogicを起動するために十分な権限が必要です(グローバルAdminロールによって付与されます)。
ノート:
オンラインで管理ツールにログインする際は、リポジトリ・パスワードとともにOID LDAPユーザーとパスワード(OID_Weblogicなど)を指定する必要があります。すべて正常に機能している場合、このタスクを完了させます。
この手順を使用して削除するWebLogic Serverロールの例は、次のとおりです。
「タスク4 - WebLogicコンソールでのOID LDAPグループとグローバル・ロールとの関連付け」を参照してください。
このステップを実行する前に、config.xmlファイルをバックアップします。「タスク1 - バックアップおよびリカバリの有効化」を参照してください。
OR句から削除します。USER変数を削除する必要があり、メタデータ・リポジトリで初期化ブロックを更新することが必要な場合があります。
Oracle Business Intelligenceでは、様々な形式の認証方法を一度に適用できます。望ましい機能にも思えますが、セキュリティ上のリスクも伴います。単一ソースの認証を実装するには、初期化ブロックを使用する認証方法をメタデータ・リポジトリから削除する必要があります。
Oracle BI管理ツールを使用して、初期化ブロックを介したアクセスを停止します。正常に認証するにはユーザー名が必要です。初期化ブロックでは、USERシステム・セッション変数を使用してユーザー名を移入します。
初期化ブロックを無効にする場合、依存する初期化ブロックもすべて無効になります。
これで、初期化ブロック認証を使用して試みられるアクセスは成功しなくなります。ただし、すべての初期化ブロックをチェックする必要があります。
単一ソースとしてOracle Internet Directory LDAP認証を構成すると、次のエラーが発生する場合があります。
<クリティカル> <WebLogicServer> <BEA-000386> <サーバー・サブシステムに障害が発生しました。
Reason: weblogic.security.SecurityInitializationException: User <oidweblogic> is not permitted to boot the server. The server policy may have changed in such a way that the user is no longer able to boot the server. Reboot the server with the administrative user account or contact the system administrator to update the server policy definitions.
ソリューション
新しいWebLogic OID LDAP管理者(oidweblogic)としてシステムを再起動した場合に、ロックアウトされ、メッセージが表示された場合は、oidweblogicユーザーに十分な権限がなかったことが原因です。oidweblogicユーザーにはグローバルAdminロールが必要です。これにより、OID LDAP Administratorグループに所属することが可能になります。この問題を解決するには、BIServiceAdministratorsグループ(またはOID LDAPの同等グループ)をグローバルAdminロールに追加します。
ノート:
以前の作業構成をリストアするには、最新の更新されたバージョンのconfig.xmlファイルを、構成を変更する前に作成しておいたバックアップ・バージョンに置き換える必要があります。「タスク1 - バックアップおよびリカバリの有効化」を参照してください。バックアップ・バージョンのconfig.xmlファイルのリストアを完了するには、OID LDAPユーザーではなく、元のWebLogic管理者ユーザーとしてOracle Business Intelligenceを再起動します。
