1. Oracle Enterprise Data Qualityの保護
  2. WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合

6 WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合

この章では、WeblogicおよびOPSSを使用したLDAPとの統合について説明します。内容は次のとおりです。
  • セキュリティ・レルム、プロバイダおよび制御フラグの理解
    WebLogicドメインには、1つ以上のセキュリティ・レルムを含めることができます。各レルムでは、セキュリティ構成、ユーザーおよびグループを定義します。一度にアクティブにできるレルムは1つのみで、通常は追加のレルムを作成する利点はありません。WebLogicドメインのデフォルト・レルムの名前は、'myrealm'です。
  • LDAPを使用するためのWebLogicの構成
    この項では、前提条件およびWebLogicの構成手順について説明します。

セキュリティ・レルム、プロバイダおよび制御フラグの理解

WebLogicドメインには、1つ以上のセキュリティ・レルムを含めることができます。各レルムでは、セキュリティ構成、ユーザーおよびグループを定義します。一度にアクティブにできるレルムは1つのみで、通常は追加のレルムを作成する利点はありません。WebLogicドメインのデフォルト・レルムの名前は、'myrealm'です。

各レルムには、複数のセキュリティ・プロバイダが含まれます。プロバイダは、ユーザー認証やユーザー・ストアを処理するオーセンティケータであるか、X.509証明書やSAMLトークンなど、リクエストに埋め込まれたデータからユーザー・アイデンティティを特定できるアイデンティティ・アサータです。OAM統合で使用されるOracle Access Managerアイデンティティ・アサータは、「WebLogic構成」で説明します。

デフォルト・セキュリティ・レルムには、1つのオーセンティケータと2つのアイデンティティ・アサータが含まれます。

DefaultAuthenticatorは、内部WebLogicストアのユーザーを処理します。

各オーセンティケータ・プロバイダには、制御フラグ設定があります。このフラグにより、ユーザーの認証においてプロバイダが果たす役割が決定されます。使用可能なフラグ値は4つありますが、重要なものは次の2つです。

REQUIRED: プロセス全体が完了するためには、このプロバイダの認証が成功する必要があります。

SUFFICIENT: 他のオーセンティケータにREQUIRED制御フラグがないかぎり、このプロバイダの認証が成功すると、プロセス全体が成功します。

DefaultAuthenticatorは、制御フラグがREQUIREDに設定されて事前構成されているため、LDAP認証プロバイダが構成されていても成功する必要があります。LDAPサポートの構成プロセスの一環として、この値をSUFFICIENTに変更します。

プロバイダの順序も重要です。複数のオーセンティケータが有効化され、適切な制御フラグで構成されている場合、オーセンティケータのいずれかによってサポートされるユーザーは、WebLogicリモート・コンソールにログインできます。ただし、EDQは、リストの最初のオーセンティケータのみにアクセスでき、リストでそれより下位のオーセンティケータのユーザーは、認識されません。したがって、LDAPオーセンティケータを追加する場合、それをリストの一番上に移動することが重要です。これも後で説明します。

親トピック: WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合

LDAPを使用するためのWebLogicの構成

この項では、前提条件およびWebLogicの構成手順について説明します。

親トピック: WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合

前提条件

構成プロセスを開始する前に、次の情報を収集する必要があります。

  • 使用しているLDAPサーバーのタイプ。WebLogicには、Microsoft Active Directory、OpenLDAP、Oracle Internet Directoryなど、複数のタイプのLDAPサーバーに応じたオーセンティケータがあります。直接サポートされないサーバー(AD-LDSなど)で使用できる汎用のLDAPオーセンティケータもあります。

  • LDAPサーバーのホスト名およびポート。現在の環境に高可用性対応のサーバーが複数含まれる場合、構成内で複数のホストを使用できます。デフォルトのLDAPポートは389です。

  • 接続して検索を実行できるLDAPユーザーのアイデンティティおよびパスワード。ユーザー・アイデンティティは、通常、完全な識別名(DN)ですが、Active Directoryでは短縮形式も使用できます。

  • ユーザーとグループを検出できるLDAPツリー(ベースDN)内の場所。

  • ログイン時にユーザーを識別するユーザー・レコードのLDAP属性。ほとんどのLDAPユーザー・スキーマには標準のユーザー名属性がありますが、組織ではそれ以外のものを使用できます。

  • グループを識別するグループ・レコードのLDAP属性。ほとんどのインストールで、これは共通名(cn)というグループになります。

  • EDQを操作するすべてのユーザーが含まれるLDAPグループの名前。グループは、EDQの問題の割当てなどに表示されるユーザーのリストをフィルタするために使用されます。このフィルタがないと、LDAPサーバーのすべてのユーザーが表示されるため、一般的には推奨されません。

親トピック: LDAPを使用するためのWebLogicの構成

Active Directoryとの統合

この項の残りでは、Active Directoryとの統合に関する詳細なステップについて説明します。このステップは、他のタイプのLDAPサーバーとほぼ同じです。初期構成ではSSLを使用しません。

手順の説明では、次の設定を使用します。

  • Active Directoryドメイン: EXAMPLE.COM

  • ドメイン・コントローラ(LDAPサーバー): dc1.example.com。デフォルトの非SSLのポート389が使用されます。

  • LDAPユーザー: cn=netuser,cn=users,dc=example,dc=com。このユーザーのADユーザー名が'netuser'であるとすると、netuser@example.comまたはexample\netuserも使用できます。

  • ユーザー・ベースDN: dc=example,dc=com。ここでのベースとは、完全なLDAPツリーのルートです。すべてのユーザーがサブツリーに含まれる場合、cn=users,dc=example,dc=comなどを使用できます。

  • グループ・ベースDN: dc=example,dc=com。同様に、適切な場合はサブツリーを使用できます。

  • ユーザー名属性: sAMAccountName。これは、短いログイン名を格納する標準のAD属性です。「Active Directoryユーザーとコンピュータ」アプリケーションでは、Windows 2000より前のログイン名として表示されます。

  • グループ名属性: cn

  • すべてのEDQユーザー・グループ: edqusers

親トピック: LDAPを使用するためのWebLogicの構成

EDQの構成

この項では、EDQの構成手順について説明します。

親トピック: LDAPを使用するためのWebLogicの構成

ユーザー・グループ

EDQユーザーを含むグループを定義するには、次のステップを実行します。

  1. EDQドメインをホストするサーバーにログインし、EDQの'local'構成ディレクトリに移動します。

    これは、DOMAIN_HOME/config/fmwconfig/edq/oedq.local.homeにあります。

  2. ローカル・セキュリティ・ディレクトリを作成し、このディレクトリにデフォルトのログイン構成をコピーします。

    $ mkdir security
$ cp ../oedq.home/security/login.properties security/

  3. security/login.propertiesで新しいローカル構成を編集し、次の行を追加します。 

    opss.prof.defaultusergroup = edqusers

親トピック: EDQの構成

権限

login.propertiesの事前定義されたグループ・マッピングによって、外部管理者グループがEDQ管理者グループにマップされます。これは、内部WebLogicユーザー・ストアを使用する場合には有効なマッピングです(内部管理者グループには、標準の'weblogic'管理コンソール・ユーザーが含まれるため)。

ただし、Active Directoryの管理者グループには、ドメイン・レベルの管理者が含まれており、このグループのユーザーはEDQを使用または管理しない可能性があります。EDQ Webコンソールを使用して外部EDQ関連グループから別のグループ・マッピングを追加するには、管理者としてEDQにログインする必要があります。これは、Active Directory管理者が使用できる場合にのみ、事前定義されたデフォルトのグループ・マッピングで可能です。他のユーザーがEDQ管理者になることを許可するには、次の2つのアプローチがあります。

  • 事前定義されたマッピングを編集します。

    ローカルのlogin.propertiesを編集し、xgmap行を変更して別のLDAPグループをEDQ管理者グループにマップします。たとえば、EDQ管理ユーザーを含めるためにActive Directoryで'edqadmins'というグループが作成されている場合、次のように行を編集します。 

    opss.xgmap = edqadmins -> Administrators

  • 内部レルムを有効にします。

    ローカルのlogin.propertiesを編集して次のようにrealms行を変更します。 

    realms = internal, opss

    これにより、EDQ内部ユーザー・ストアが有効になり、ユーザー'dnadmin'としてログインし、Webコンソールを使用して必要な外部グループ・マッピングを設定できます。マッピングが完了したら、内部レルムを再度無効にすることができます。

    これらの変更が完了したら、EDQ管理対象サーバーを起動してActive Directoryユーザーとしてログインできます。アプリケーション・ログインに成功するには、外部グループ・マッピングを完了させて必要な権限を付与する必要があることに注意してください。

親トピック: EDQの構成

グループのフィルタ

大規模な組織のLDAPストアには、数千に及ぶ別個のグループが含まれることがあり、追加フィルタがなければ、EDQ Webコンソールの外部グループのマッピング・リストにすべて表示されます。グループ・リストを管理可能なサイズにフィルタするには、LDAPグループ・フィルタをlogin.propertiesに追加します。

フィルタを追加する前に、ローカル構成領域に必ずこれのコピーを作成してください。フィルタを追加するには、次の行を編集して追加します。

opss.prof.groupfilter = LDAPGROUPFILTER

ここで、LDAPGROUPFILTERは、グループを選択するためのLDAPスタイルのフィルタです。フィルタでは、LDAP固有の属性のかわりに汎用のOPSS属性名を使用します。'name'を使用して、グループの名前を示します。フィルタでは、事前定義されたマッピングで使用されるすべてのグループを戻す必要があります。

EXAMPLE.COM設定では、EDQで使用されるすべてのグループが接頭辞'edq'で始まるため、フィルタは次のようになります。

opss.prof.groupfilter = (name=edq*)

親トピック: LDAPを使用するためのWebLogicの構成

SSLを使用したLDAPへの接続

SSLを使用してLDAPサーバーへの接続を保護する場合、LDAPプロバイダの「プロバイダ固有」タブにある「SSLの有効化」チェック・ボックスを選択して、SSLポート(通常は636)を入力します。

ノート:

WebLogicの現在のバージョンでは、初期構成後に「プロバイダ固有」ページに変更を加える場合、LDAPパスワードを再度入力する必要があります。元のパスワードは不明瞭化されますが、このバージョンはその後保存されます。

次に、WebLogicからLDAPサーバーへの正常な接続を有効にして、ユーザーとグループのリストを表示し、LDAPユーザーとしてWebLogicにログインできるようにするには、LDAPサーバー証明書またはルートCAを、WebLogicの実行に使用されるJREのトラスト・ストアに追加する必要があります。Java keytoolコマンドを使用して、JREのcacertsファイルを更新します。keytoolのドキュメントは次の場所にあります。

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

現状で、WebLogic認証のためにEDQで使用されるOPSSライブラリは、cacertsストアを使用しません。かわりに、新しいキーストアを作成する必要があります。EDQ管理対象サーバーは停止しますが、管理サーバーは実行を継続します。WebLogicが実行されているサーバーにログインし、次の環境変数を設定します。

JAVA_HOME=java install location
WL_HOME=WLSHOME/wlserver
ORACLE_HOME=WLSHOME

その後、次を実行します。

$ WLSHOME/oracle_common/bin/libovdconfig.sh -host HOST -port PORT -userName weblogic -domainPath DOMAIN_HOME -createKeystore

ここで、WLSHOMEはWebLogicのインストール・ディレクトリ、HOSTは管理サーバーが実行されているホストの名前、PORTは管理ポート(通常は7001)、DOMAIN_HOMEはWebLogicドメインの場所です。

このコマンドにより、weblogicユーザーのパスワードと、新しいキーストアのパスワードの入力を求められます。これは任意に指定できます。

正常に完了すると、新しいキーストアが次の場所に作成されます。

DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks

Java keytoolを使用して、サーバーまたはCA証明書を新規作成したキーストアに追加します。

$ keytool -import -keystore DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks -alias ALIAS -file CERTFILE

証明書を指定するキーストアでALIASを置き換え、証明書ファイルの場所でCERTFILEを置き換えます。

このコマンドにより、キーストア・パスワードの入力を求められます(キーストアの作成時に指定したパスワードを入力します)。

EDQ管理対象サーバーを再起動すると、LDAPユーザーはログインすることができます。WebLogicとLDAP間のトラフィックは、SSLで保護されます。

親トピック: LDAPを使用するためのWebLogicの構成