21 アイデンティティ・ストアの構成

アイデンティティ・ストアを、デフォルトの組込みLDAPアイデンティティ・ストアではなく、外部LDAPに関連付け、LDAPサーバーをOracle WebCenter Content Server用に構成し、Oracle Identity Cloud ServiceをWebCenter Portalのアイデンティティ・ストアとして使用します。

ノート: Oracle WebCenter Portalでは、Jive機能(お知らせおよびディスカッション/ディスカッション・フォーラム)のサポートが非推奨となりました。したがって、Jive機能は14.1.2インスタンスでは使用できません。

注意: アイデンティティ・ストアを再度関連付ける前に、次の関連する構成ファイルを必ずバックアップしてください:

• config.xml

• jps-config.xml

念のため、ドメインの管理サーバーのboot.propertiesファイルもバックアップしてください。

権限: この章のタスクを実行するには、Oracle WebLogic Server管理コンソールでWebLogic ServerのAdminロールが付与されている必要があります。MonitorまたはOperatorロールを持つユーザーは、セキュリティ情報を表示できますが変更することはできません。

「管理操作、ロールおよびツールの理解」も参照してください。

トピック:

• 外部LDAPサーバーへのアイデンティティ・ストアの再関連付け

• 外部LDAPアイデンティティ・ストア用のGUID属性の構成

• 組込みLDAPアイデンティティ・ストアへのユーザーの追加

• 外部LDAPサーバーへの管理者アカウントの移行

• Oracle WebCenter ContentとWebCenter Portalでアイデンティティ・ストアLDAPサーバーを共有するための構成

• libOVDを使用した複数のアイデンティティ・ストアLDAPサーバーの集約

• WebCenter Portalの動的グループの構成

• RESTサービス・アイデンティティ・アサータの構成

親トピック: セキュリティの管理

外部LDAPサーバーへのアイデンティティ・ストアの再関連付け

ほとんどの場合、アイデンティティ・ストアは、デフォルトの組込みLDAPは使用せずに、外部LDAPサーバーに再度関連付ける必要があります。様々なタイプのLDAPサーバーを使用できますが、この項では、Oracle Internet Directory (OID)を使用するようにアイデンティティ・ストアを構成する方法を説明します。

ノート: 外部LDAPサーバーへのアイデンティティ・ストアの再関連付けは、ドキュメントまたはディスカッション・ツールを使用している場合にのみ必須です。その場合には、WC_PortalサーバーとContent Serverすべてが同じ外部LDAPサーバーを使用するように構成する必要があります。

アイデンティティ・ストア用のLDAPサーバーで強力なパスワード・ポリシーを設定することをお薦めします。次の要件を満たすユーザー・パスワードが推奨されます。

• パスワードには、連続する3文字以上のユーザーのアカウント名またはユーザーのフル・ネームの一部を含めないでください。

• パスワードの長さは、6文字以上または最小パスワード長ポリシー設定で指定された文字数以上にする必要があります。

• 古いパスワードを再利用する前にユーザー・アカウントに関連付ける必要がある一意の新しいパスワードの数を決定する強制パスワード履歴ポリシー設定。この値は、0と24の間で設定できます(この値を0に設定した場合、強制パスワード履歴は無効になります。パスワード再利用によるセキュリティの脆弱性を防止するために、24などの大きい値を設定することをお薦めします)。

• パスワードには、英字の大文字(AからZ)、英字の小文字(aからz)、10進数の数字(0から9)、英数字以外の文字(!$#,%など)の4つのカテゴリのうち、少なくとも3つのカテゴリの文字を含める必要があります。

他のサポートされているLDAP用のGUID属性は、「外部LDAPアイデンティティ・ストア用のGUID属性の構成」を参照してください。サポートされているLDAPサーバーの他のユーザー属性マッピングは、『Oracle Platform Security Servicesによるアプリケーションの保護』のユーザーおよびロールAPIリファレンスを参照してください。

ノート: (WebCenter Portalのインストール時にそのデフォルト構成で作成されたデフォルトのデータベース・ストアではなく)既存のデータベースをアイデンティティ・ストアに使用するには、OVDを使用するか、ユーザーおよびロールAPIに基づいてカスタム・プロバイダを記述する必要があります。LibOVDをデータベース・アイデンティティ・ストアとともに使用しないでください。

注意:

本番環境の外部LDAPアイデンティティ・ストア(OIDなど)を別の外部LDAPストアに再度関連付けすることはサポートされていません。ビジネス要件によりそのような再関連付けを行う場合は、プロセス中にユーザー情報やアーティファクトが失われる可能性があるため、実施前にOracleサポートにご連絡ください。

アイデンティティ・ストアをOIDに再度関連付けるには:

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。

   「セキュリティ・レルムのサマリー」ペインが表示されます。

3. 「名前」列で、アイデンティティ・ストアを再度関連付けるレルムをクリックします。

   「レルムの設定」ペインが表示されます。

4. 「プロバイダ」タブを開きます。

   プロバイダの設定ペインが表示されます。

5. 「新規」をクリックして、新しいプロバイダを追加します。

   「新しい認証プロバイダの作成」ペインが表示されます。

6. プロバイダの名前を入力します(OIDAuthenticatorなど、Oracle Internet Directoryに対してユーザーを認証するプロバイダの名前)を入力します。

7. LDAPディレクトリに適したオーセンティケータをオーセンティケータのリストから選択します。

   一般的なDefaultAuthenticatorを選択するのではなく、構成するLDAPに関連付けられたオーセンティケータを選択してください。たとえば、OIDの場合はOracleInternetDirectoryAuthenticator、iPlanetの場合はIPlanetAuthenticatorを選択します。

   ノート: iPlanetを使用する場合は、./user_projects/domains/soainfra/config/fmwconfig/jps-config.xmlのvirtualizeプロパティをtrueに設定します。

   <serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
    <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/>
    <property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/>
    <property name="virtualize" value="true"/>
    <property name="OPTIMIZE_SEARCH" value="true"/>
   </serviceInstance>
   

8. 「OK」をクリックして設定を保存します。

   設定ペインに新規の認証プロバイダが表示されます。

9. 「認証プロバイダ」のリストで、新しく作成したプロバイダをクリックします。

   新規の認証プロバイダの設定ペインが表示されます。

10. 「制御フラグ」をSUFFICIENTに設定します。

    「制御フラグ」をSUFFICIENTに設定すると、このオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。

    ノート: 認証に失敗した場合、その認証は連鎖内の次のオーセンティケータに渡されます。そのため、後続のすべてのオーセンティケータについても、制御フラグがSUFFICIENTに設定されていることを確認します。

11. 「保存」をクリックしてこの設定を保存します。

12. 「プロバイダ固有」タブを開き、LDAPサーバーの詳細情報を入力します。

13. 使用するLDAPサーバーに固有の詳細を入力します。

    ノート: OIDの場合の適切な値を次の表に示します。Active Directoryなど、他のLDAPの許容値は、『Oracle Platform Security Servicesによるアプリケーションの保護』の付録「OPSSのシステム・プロパティおよび構成プロパティ」を参照してください。

    パラメータ	値	説明
    ホスト:		LDAPサーバーのサーバーID(たとえば、<ldap_host>example.com)
    ポート:		LDAPサーバーのポート番号(たとえば、3060)
    プリンシパル:		LDAPサーバーへの接続に使用されるLDAPユーザーDN(たとえば、cn=orcladmin)
    資格証明:		LDAPサーバーへの接続に使用されるパスワード
    ユーザー・ベースDN:		ユーザーの基点となるDNを指定します(たとえば、cn=users,dc=example,dc=com)
    グループ・ベースDN:		グループ・ノードを示すDNを指定します(たとえば、cn=groups,dc=example,dc=com)
    取得したユーザー名をプリンシパルとして使用する	選択済	有効にしておく必要があります。
    すべてのユーザーのフィルタ:	(&(uid=*)(objectclass=person))	「ユーザー・ベースDN」内のすべてのユーザーを検索するための検索フィルタ
    名前指定によるユーザー・フィルタ:	(&(uid=%u)(objectclass=person))
    ユーザー名属性:	uid

14. 「保存」をクリックします。

15. 「プロバイダ」タブに戻り、リストの先頭に新しい認証プロバイダ、その次に他のオーセンティケータ、最後にDefaultAuthenticatorが表示されるようにプロバイダを並べ替えます。

    すべてのオーセンティケータの制御フラグをSUFFICIENTに設定し、新しいプロバイダからDefaultAuthenticator(デフォルトのファイルベースの組込みLDAPのみで使用)に至るまで、後続のオーセンティケータで渡されたアイデンティティを認証できるようにする必要があります。たとえば、デフォルトの管理者アカウントなどのログインは通常、LDAPディレクトリ内に作成されませんが、サーバーを起動するためには認証が必要です。DefaultAuthenticatorにアイデンティティが渡されない場合、デフォルトの管理者アカウントは認証されません。DefaultAuthenticatorおよびデフォルトの管理者アカウントの詳細は、「外部LDAPサーバーへの管理者アカウントの移行」を参照してください。

    ノート: 複数のオーセンティケータを使用する場合は、REQUIRED制御フラグを使用しないでください。オーセンティケータのリストでREQUIRED制御フラグが見つかった場合、その位置に関係なく、後続のオーセンティケータは調査されません。

16. 変更が有効になるように、管理サーバーと管理対象サーバーを再起動します。

外部LDAPアイデンティティ・ストア用のGUID属性の構成

この項では、Oracle LDAP以外の実装で使用される様々なGUID属性について説明します。サポートされている他のLDAPサーバーの他のユーザー属性マッピングは、『Oracle Platform Security Servicesによるアプリケーションの保護』のユーザーおよびロールAPIリファレンスに関する項を参照してください。『Oracle Platform Security Servicesによるアプリケーションの保護』のLDAPディレクトリへのユーザー属性のマッピングも参照してください。「LDAPディレクトリへのユーザー属性のマッピング」の表に示されているように、すべての属性がWebLogic Server (WLS)に付属する組込みLDAPサーバーを含むすべてのLDAPサーバーで使用できるわけではありません。

ノート: orclGuid属性を使用しないLDAPアイデンティティ・ストア(IBM Tivoliなど)を使用する場合は、WLSオーセンティケータのGUID属性をマップして、WLSオーセンティケータが自動的に使用されるようにできます。

IBM Tivoli® Directory Server:

ibm-entryUUID

Microsoft® Active Directory:

objectGUID

Active Directoryを使用する場合、samAccountName属性は20文字に制限されます。また、Lotus Connectionsで使用される他のIDは256文字に制限されます。

Microsoft Active Directory Application Mode (ADAM):

objectGUID

objectSIDをADAMのデフォルトとして使用するには、次の行をwimconfig.xmlファイルの<config:attributeConfiguration>セクションに追加します。

<config:externalIdAttributes name="objectSID" syntax="octetString"/>

IBM Domino® Enterprise Server:

dominoUNID

Domino LDAPのバインドIDがDominoディレクトリに対して十分なマネージャ・アクセスができない場合、Virtual Member Manager (VMM)は、Dominoスキーマ問合せに対して正しい属性タイプを返さず、VMM IDとしてDNが返されます。VMMのデフォルトのID設定をオーバーライドするには、wimconfig.xmlファイルの<config:attributeConfiguration>セクションに次の行を追加します。

<config:externalIdAttributes name="dominoUNID"/>

Sun Java™ System Directory Server:

nsuniqueid

eNovell Directory Server:

GUID

組込みLDAPアイデンティティ・ストアへのユーザーの追加

開発またはテストを目的として、ユーザーを組込みLDAPに追加するには、WebLogic Server管理コンソールを使用するか、またはLDIFファイルとLDAPコマンドを使用します。LDIFファイルを使用すると、WebLogic Server管理コンソールからでは使用できない属性を追加できます。

ノート: 組込みLDAPサーバーは、テストや概念実証の目的のみに使用してください。本番用には、Oracle Internet DirectoryやMicrosoft Active Directoryなど、OPSSユーザーおよびロールAPIでサポートされている外部アイデンティティ・ストアを使用することをお薦めします。ユーザーおよびロール属性の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のLDAPディレクトリへのユーザー属性のマッピングに関する項を参照してください。

Oracle Internet Directoryでは、通常、ユーザーはODSMを使用して管理されます(『Oracle Internet Directoryの管理』のディレクトリ・エントリの管理を参照)。

ノート: アイデンティティ・ストアを外部LDAPに再度関連付けする予定がある場合は、再関連付けのステップ( 外部LDAPサーバーへのアイデンティティ・ストアの再関連付けを参照)を先に実行してください。組込みLDAPをOIDや他の外部LDAP実装に再度関連付けする場合、ユーザーやユーザーのアーティファクトが移行できないことがあるからです。したがって、本番環境にユーザーを移行する場合を除き、組込みLDAPにはユーザーを追加しないでください。組込みLDAPは、テスト環境のみで使用することを目的としており、本番環境への移行が可能なステージング環境で使用することは意図していません。

WebCenter Portalでは自己登録がサポートされます。WebCenter Portalに自己登録した新規ユーザーは、アイデンティティ・ストアに直接追加されます。自己登録の詳細は、「自己登録の有効化」を参照してください。

ノート: アイデンティティ・ストアへのユーザーの追加は、一般にシステム管理者のタスクであり、アプリケーションレベルの管理者は必要な権限を持っていてもこのタスクを実行できない場合があります。

この項では、次の内容について説明します。

• WLS管理コンソールを使用したアイデンティティ・ストアへのユーザーの追加

• LDIFファイルを使用したアイデンティティ・ストアへのユーザーの追加

WLS管理コンソールを使用したアイデンティティ・ストアへのユーザーの追加

WebLogic Server管理コンソールから組込みLDAPアイデンティティ・ストアにユーザーを追加するには:

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。

   「セキュリティ・レルムのサマリー」ペインが表示されます。

3. 「名前」列で、ユーザーを追加するレルムをクリックします。

   「レルムの設定」ペインが表示されます。

4. 「ユーザーとグループ」タブをクリックし、現行ユーザーのリストを表示します。

5. 「新規」をクリックして、新しいユーザーを追加します。

6. 「新しいユーザーの作成」ページで、「名前」フィールドに新しいユーザーのログイン名を入力します。

   ユーザー名では大/小文字が区別されます。また、ユーザー名は一意である必要があります。カンマ、タブ、および次のカンマ区切りリスト内のその他の文字は使用しないでください。

   < >、#、|、&、?、( )、{ }

7. 「説明」フィールドに、ユーザーの説明(たとえば、ユーザーのフル・ネーム)を入力します。

8. 「プロバイダ」ドロップダウン・メニューからDefaultAuthenticatorを選択します。

9. 「パスワード」フィールドに、ユーザーのパスワードを入力します。

   WebLogic認証プロバイダで定義されたユーザーのパスワードの最低限の長さは8文字です(他のLDAPプロバイダではパスワード長の要件が異なる場合があります)。本番環境では、weblogic/weblogicのようなユーザー名とパスワードの組合せは使用しないでください。

10. 「パスワードの確認」フィールドにパスワードを再入力します。

11. 「OK」をクリックして変更を保存し、ユーザーを追加します。

    追加したユーザーがユーザー・リストに表示されます。

12. jps-config.xml構成ファイルを編集します。

    1. DOMAIN_HOME/config/fmwconfigディレクトリに移動し、テキスト・エディタでjps-config.xmlファイルを開きます。

    2. idstore.ldap.providerのserviceInstanceエントリを検索し、次の2つのプロパティを追加します。

       <property name="username.attr" value="sAMAccountName"/> 
       <property name="user.login.attr" value="sAMAccountName"/> 
       

       次に、エントリの表示の例を示します。

       <serviceInstances> 
        <!-- JPS WLS LDAP Identity Store Service Instance --> 
        <serviceInstance name="idstore.ldap" provider="idstore.ldap.provider"> 
        <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/>
        <property name="username.attr" value="sAMAccountName"/> 
        <property name="user.login.attr" value="sAMAccountName"/> 
       </serviceInstance> 
       

    3. jps-config.xmlを保存します。

    4. 管理サーバーと管理対象サーバーを再起動します。

LDIFファイルを使用したアイデンティティ・ストアへのユーザーの追加

LDIFファイルを使用して組込みLDAPアイデンティティ・ストアにユーザーを直接追加する手順は次のとおりです。LDIFファイルを使用すると、WebLogic Server管理コンソールからでは使用できない追加のユーザー属性を指定できます。組込みLDAPサーバーはLDAPに準拠したサーバーであるため、LDAPコマンドを使用してユーザーを追加または変更できます。また、ディレクトリを検索することもできます。これは、ユーザー・アカウントをエクスポートおよびインポートする場合に役立ちます。

LDIFファイルを使用して組込みLDAPにユーザーを追加するには、次のタスクを実行する必要があります。

• 外部LDAPアクセスの有効化

• LDIFファイルの作成

• ユーザーの追加

外部LDAPアクセスの有効化

LDAPアクセス資格証明は、WebLogic Serverのインストール時にランダム値として設定され、config.xmlファイルに暗号化されます。外部LDAPアクセスを有効にするには、組込みLDAPのアクセス資格証明をリセットする必要があります。

組込みLDAPのアクセス資格証明をリセットするには:

1. WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで、WC_Domainをクリックします。

3. WC_Domainの「設定」ペインで「セキュリティ」タブをクリックし、「組込みLDAP」タブをクリックします。

   WC_Domainの「設定」ペインに組込みLDAP設定が表示されます。

4. 「資格証明」フィールドに新しいパスワードを入力し、「資格証明の確認」フィールドに再度入力します。

5. 「保存」をクリックして設定を保存します。

6. WebLogicサーバーを再起動します。

   これを行った後は、次の値を使用してLDAPサーバーにアクセスできるようになります。

   • 管理アクセスのDN値は「cn=Admin」です

   • パスワードは「資格証明」フィールドに入力した値です。

   • ポートは管理ポートと同じポート(デフォルトは7001)です。

LDIFファイルの作成

LDIFファイルは任意のテキスト・エディタで作成できます。また、LDIFファイルには、組込みLDAPディレクトリに該当する任意の属性を含めることができます。WebLogic Serverの組込みLDAPサーバーのデフォルトでサポートされているobjectclassesは次のとおりです。

• person

• inetOrgPerson

• organizationalPerson

• wlsUser

組込みLDAPサーバーと正常に対話するには、ディレクトリ情報ツリー(DIT)のデフォルト・レイアウトを理解しておく必要があります。組込みLDAPディレクトリのデフォルト・レイアウトを図21-1に示します。

図21-1 組込みLDAPのディレクトリ情報ツリー

ノート: 組込みLDAPのディレクトリ・ツリーでは、ユーザー・エントリのネーミング属性は「uid」です。これは、Oracle Internet Directory (OID)のデフォルトの構成(ネーミング属性は「cn」)とは異なります。また、このツリーにおけるユーザーの場所は「ou=people,ou=myrealm,dc=WC_Domain」です。

次の例は、WebCenter Portalユーザー・プロファイルの画面に表示される属性が指定されたLDIFファイルを示しています。

dn: uid=john.doe,ou=people,ou=myrealm,dc=`WC_Domain`
description: John Doe
cn: john.doe
uid: john.doe
sn: Doe
objectclass: wlsUser
objectclass: organizationalperson
objectclass: inetOrgPerson
objectclass: person
objectclass: top
userpassword: MyPassword
displayName: John Doe
employeeNumber: 12345
employeeType: Regular
givenName: John
homePhone: 650-555-1212
mail: [e-mail]
title: Manager
manager: uid=mary.jones,ou=people,ou=myrealm,dc=`WC_Domain`
preferredLanguage: en
departmentNumber: tools
facsimiletelephonenumber: 650-555-1200
mobile: [phone]
pager: 650-400-1200
telephoneNumber: 650-506-1212
postaladdress: 200 Oracle Parkway
l: Redwood Shores
homepostaladdress: 123 Main St., Anytown 12345

複数のユーザー・エントリを含むファイルを作成するには、前述の行を必要な回数だけレプリケートし、エントリ間に空白行を入れます。

ノート: WebCenter Portalのユーザー・プロファイルには、Oracle Internet Directoryのみで使用可能な属性が含まれます。これには、orclUserV2オブジェクト・クラスの次の属性があります。

• orclTimeZone

• orclDateOfBirth

• maidenName

これらの属性は、組込みLDAPアイデンティティ・ストアには追加できません。

ユーザーの追加

次の例では、ldappaddコマンドを使用しています。このコマンドは、Oracle Internet Directoryサーバーに付属のLDAPコマンド行ユーティリティに含まれます。ldappaddコマンドの使用の詳細は、『Oracle Identity Managementリファレンス』のOracle Internet Directoryデータ管理ツールを参照してください。WebCenter PortalでサポートされるLDAPサーバーのユーザー属性マッピングの全リストは、『Oracle Platform Security Servicesによるアプリケーションの保護』のLDAPサービスへのユーザー属性のマッピングを参照してください。

ldapadd -h weblogichost.example.com -p 7001 -D cn=Admin -w password -v -f newuser.ldif
 
add description:
        John Doe
add cn:
        john.doe
add uid:
        john.doe
add sn:
        Doe
add objectclass:
        wlsUser
        organizationalperson
        inetOrgPerson
        person
        top
add userpassword:
        password
add displayname:
        John Doe
add employeenumber:
        12345
add employeetype:
        Regular
add givenname:
        John
add homephone:
        650-555-1212
add mail:
        [e-mail]
add title:
        Manager
add manager:
        uid=mary.jones,ou=people,ou=myrealm,dc=`WC_Domain`
add preferredlanguage:
        en
add departmentnumber:
        tools
add facsimiletelephonenumber:
        650-555-1200
add mobile:
        650-500-1200
add pager:
        650-400-1200
add telephonenumber:
        650-506-1212
add postaladdress:
        200 Oracle Parkway
add l:
        Redwood Shores
add homepostaladdress:
        123 Main St., Anytown 12345
adding new entry uid=john.doe,ou=people,ou=myrealm,dc=`WC_Domain`
modify complete

外部LDAPサーバーへの管理者アカウントの移行

外部LDAPサーバーを使用するようにドメインを構成する場合、必要に応じてシステム管理者アカウント(デフォルトではweblogic)をLDAPサーバーに移行することもできます。

システム管理者アカウントまたはLDAP内の他の適切なユーザーが「管理者」というLDAPグループに属する場合、このアカウントは、サーバーを管理するための権限を満たしています。また、DefaultAuthenticatorプロバイダを認証プロバイダのリストから削除できます。この場合、すべてのユーザー(管理者アカウントを含む)は外部LDAPに対して認証されます。

ノート: WebCenter Portalは、最初のオーセンティケータによってマップされたアイデンティティ・ストア内のユーザーのみを認識します。WebCenter Portal管理者アカウントは当初は組込みのLDAPサーバーにのみ作成されるため、Oracle Internet Directoryなどの外部LDAPをWebCenter Portalのプライマリ・オーセンティケータとして構成する場合は、そのLDAP内にユーザーを作成し、そのユーザーにWebCenter Portal管理者ロールを付与する必要もあります。WebCenter Portal管理者ロールのユーザーへの付与の詳細は、「WebCenter Portal管理者ロールの付与」を参照してください。

weblogic(デフォルト)ユーザーを外部LDAPディレクトリに作成できない場合は、2つのオプションがあります。次のことを実行できます。

• DefaultAuthenticatorプロバイダを維持したまま、weblogicアカウントとローカルの組込みLDAPサーバーをWebLogic Serverで使用し、WebLogic Server管理コンソールからサーバーの起動と停止および他の管理者用操作を行います。DefaultAuthenticatorを維持する場合は、DefaultAuthenticationプロバイダの制御フラグがSUFFICIENTに設定されていることを確認してください。

  ノート: DefaultAuthenticatorからweblogicユーザー・アカウントを使用する場合は、WebCenter Portalにアクセスする際にこのアカウントを使用しないでください。アプリケーション・コードから外部LDAPストアのユーザーを検索できなくなります。

• DefaultAuthenticatorを削除し、管理者用操作(サーバーの起動や停止など)で使用する有効なユーザー・アカウントを「管理者」グループに含めます。その他の名前のグループに含める場合は、そのグループにOIDまたは他の外部LDAPでドメインの管理を許可されたユーザーのリストが含まれている必要があります。「管理者」以外の名前を使用する場合は、WebLogic Serverグローバル管理者ロールの定義でグループ名を更新する必要があります。デフォルトでは、これは「管理者」というエンタープライズ・グループのメンバーシップとして定義されています。管理者グループ名の変更の詳細は、「管理者グループ名の変更」を参照してください。

  ノート: OWSMはDefaultAuthenticatorによって指定されたOracleSystemUserおよびOracleSystemGroupエンティティに依存するため、組込みLDAPを削除した後、OWSMが動作するには、デフォルト・ユーザーを変更する必要があります。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のデフォルト・ユーザーの変更を参照してください。

この項には次のトピックが含まれます:

• 管理者グループ名の変更

管理者グループ名の変更

LDAPサーバーにドメインの管理権限を持つユーザーが含まれる場合、そのサーバーで有効な他のエンタープライズ・ロールにグループ名を変更できます。これにより、エンタープライズ内で特定のドメインの管理を委任できます。様々な管理グループをディレクトリに作成し、対応するドメインで管理者を定義する際に適切なグループが使用されるよう構成できます。

次の例のLDIFファイルでは、Oracle Internet Directoryに管理グループを作成します。

dn: cn=WC_Domain_Admin,cn=groups,dc=example,dc=com
cn: WC_Domain_Admin
uniquemember: cn=joe.admin,cn=users,dc=example,dc=com
owner: cn=orcladmin
displayname: WebLogic Administrators Group
description: WebLogic Administrators Group
objectclass: orclgroup
objectclass: groupofuniquenames

このグループの作成後に、WebLogic Server管理コンソールを使用してWebLogic Serverグローバル管理ロールのロール定義を更新する必要があります。

WebLogic Serverグローバル管理ロールのロール定義を更新するには:

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。

   「セキュリティ・レルムのサマリー」ペインが表示されます。

3. 「名前」列で、管理者グループ名を変更するレルムをクリックします。

   レルムの設定ペインが表示されます。

4. 「ロールとポリシー」タブを開き、「レルム・ロール」サブタブを開きます。

   「レルム・ロール」設定ペインが表示されます。

5. 「グローバル・ロール」ノードを開き、「ロール」ノードを開きます。

6. Adminロールの「ロール条件の表示」をクリックします。

   「グローバル・ロールの編集」ページが表示されます。

   デフォルトでは、Oracle Internet Directory(または他の構成済アイデンティティ・ストア)のAdministratorsグループにはWebLogic Serverで管理者ロールを持つユーザーが定義されています。

7. 「条件の追加」をクリックして、別のグループ名を追加します。

   「グローバル・ロールの編集」ページに「述部リスト」が表示されます。

8. 「述部リスト」からGroupを選択し、「次へ」をクリックします。

   「グローバル・ロールの編集」ページに「引数」が表示されます。

9. 新規管理者グループの名前を入力して、「追加」をクリックします。

10. 選択した新規管理者グループを残したまま既存の管理者グループを削除するには、そのグループを選択して「削除」をクリックします。

11. 「終了」をクリックして、変更内容を保存します。

    この変更を行うと、指定した新規グループのすべてのメンバーにWebLogic Serverの管理権限が付与されます。

Oracle WebCenter ContentとWebCenter Portalでアイデンティティ・ストアLDAPサーバーを共有するための構成

WebCenter Content Serverは、WebCenter Portalと同じアイデンティティ・ストアLDAPサーバーを使用するように構成する必要があります。WebCenter Contentの構成の詳細は、「Oracle WebCenter Content Serverへの接続の管理」を参照し、『Oracle Platform Security Servicesによるアプリケーションの保護』のLDAPアイデンティティ・ストア・サービスの構成に関する項も参照してください。

libOVDを使用した複数のアイデンティティ・ストアLDAPサーバーの集約

複数のアイデンティティ・ストアを持つサイトでは、libOVDを使用してそのユーザー・プロファイル情報を集約できます。次の2つのシナリオの構成ステップを説明します。

• それぞれに完全なユーザー・プロファイル情報が存在する個別のアイデンティティ・ストアでユーザーを有効にする場合。

• それぞれに部分的な属性が存在する2つのアイデンティティ・ストアで同一ユーザーを有効にする場合。

ノート: Active Directoryによる自己登録をサポートする場合は、Active Directoryを使用してWebCenter Portalを構成するとユーザーが自己登録できないに記載されているトラブルシューティング・ノートを必ず参照してください。

この項では、次の項目について説明します。

• アイデンティティ・ストアに完全なユーザー・プロファイルが存在する場合のlibOVDの構成

• アイデンティティ・ストアに部分的なユーザー・プロファイルが存在する場合のlibOVDの構成

• 単一オーセンティケータの復元

アイデンティティ・ストアに完全なユーザー・プロファイルが存在する場合のlibOVDの構成

各アイデンティティ・ストアに完全なユーザー・プロファイルが存在する場合にlibOVDを構成するには:

1. 構成するアイデンティティ・ストアのWLS管理コンソールで必要なオーセンティケータを作成し、ドメインのWeblogic管理サーバーおよび管理対象サーバーを再起動します。または、jps-config.xmlでアイデンティティ・ストア情報を手動で構成することもできます。

2. アイデンティティ・ストア・サービス・インスタンスをjps-config.xmlで更新し、値がtrueであるvirtualizeプロパティを追加します。これは手動でjps-config.xmlファイルを編集するか、Fusion Middleware Controlを使用して実行できます。

3. WebCenter Portalを使用すると、ユーザーは自己登録が可能です。これにより、新しいユーザーまたはグループがアイデンティティ・ストアに作成されます。複数のアイデンティティ・ストアが使用されるため、ユーザー作成ベースおよびグループ作成ベースをjps-config.xmlで明示的に指定する必要があります。このステップは、jps-config.xmlを直接編集して行う必要があります。

   構成後のjps-config.xmlファイルは、次の例のようになります。

   <serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
   <property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider" name="idstore.config.provider"/>
   <property value="oracle.security.idm.providers.stdldap.JNDIPool" name="CONNECTION_POOL_CLASS"/>
   <property value="true" name="virtualize"/>
   <extendedProperty>
          <name>user.create.bases</name>
           <values>
                <value>ou=people,ou=myrealm,dc=wc_domain</value>
           </values>
   </extendedProperty>
   <extendedProperty>
           <name>group.create.bases</name>
           <values>
                 <value>ou=groups,ou=myrealm,dc=wc_domain</value>
           </values>
   </extendedProperty>
   </serviceInstance>
   

   ユーザー作成ベース「ou=people,ou=myrealm,dc=wc_domain」およびグループ作成ベース「ou=groups,ou=myrealm,dc=wc_domain」は実際の値に置き換えてください。

アイデンティティ・ストアに部分的なユーザー・プロファイルが存在する場合のlibOVDの構成

各アイデンティティ・ストアに部分的なユーザー・プロファイルのみが存在する場合にlibOVDを構成するには:

1. 構成するアイデンティティ・ストアのWLS管理コンソールで必要なオーセンティケータを作成し、ドメインのWeblogic管理サーバーおよび管理対象サーバーを再起動します。または、jps-config.xmlでアイデンティティ・ストア情報を手動で構成することもできます。

2. アイデンティティ・ストア・サービス・インスタンスをjps-config.xmlで更新し、値がtrueであるvirtualizeプロパティを追加します。これは手動でjps-config.xmlファイルを編集するか、Fusion Middleware Controlを使用して実行できます。

3. WebCenter Portalを使用すると、ユーザーは自己登録が可能です。これにより、新しいユーザーまたはグループがアイデンティティ・ストアに作成されます。複数のアイデンティティ・ストアが使用されるため、ユーザー作成ベースおよびグループ作成ベースをjps-config.xmlで明示的に指定する必要があります。このステップは、jps-config.xmlを直接編集して行う必要があります。

   構成後のjps-config.xmlファイルは、次の例のようになります。

   <serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
   <property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider" name="idstore.config.provider"/>
   <property value="oracle.security.idm.providers.stdldap.JNDIPool" name="CONNECTION_POOL_CLASS"/>
   <property value="true" name="virtualize"/>
   <extendedProperty>
           <name>user.create.bases</name>
           <values>
                <value>ou=people,ou=myrealm,dc=wc_domain</value>
           </values>
   </extendedProperty>
   <extendedProperty>
           <name>group.create.bases</name>
           <values>
                 <value>ou=groups,ou=myrealm,dc=wc_domain</value>
           </values>
   </extendedProperty>
   </serviceInstance>
   

   前述の例の「ou=people,ou=myrealm,dc=wc_domain」および「ou=groups,ou=myrealm,dc=wc_domain」はそれぞれ、ユーザー作成ベースとグループ作成ベースです。構成時には実際の値に置き換えてください。

4. 次のOVD WLSTコマンドを実行して、アイデンティティ・ストアの結合アダプタを構成します。MW_HOME/oracle_common/common/binに移動してwlst.sh(Windowsの場合はwlst.cmd)を起動すると、WLSTプロンプトが表示されます。Weblogic管理サーバーに接続して、次のWLSTコマンドを実行します。

   createJoinAdapter(adapterName="<Join Adapter Name>",  root="<Namespace>", primaryAdapter="<Primary adapter Name>")
   
   addJoinRule(adapterName="<Join Adapter Name>", secondary="<Secondary Adapter Name>", condition="<Join Condition>")
   

   他にもセカンダリ・アイデンティティ・ストアがある場合は、それぞれのセカンダリ・アイデンティティ・ストアに対してaddJoinRuleコマンドを実行します。

   modifyLDAPAdapter(adapterName="<AuthenticatorName>", attribute="Visible", value="Internal")
   

   構成した各アイデンティティ・ストアに対して前述のmodifyLDAPAdapterコマンドを実行します。

例

オーセンティケータ1:

この例では、それぞれに部分的な属性が存在する2つのアイデンティティ・ストアで、同じユーザーが有効になります。たとえば、ADがプライマリ・ストアで、OIDがセカンダリ・ストアです。

オーセンティケータ名: AD

ユーザー・ベース: cn=users,dc=acme,dc=com

オーセンティケータ2:

オーセンティケータ名: OID

ユーザー・ベース: cn=users,dc=oid,dc=com

プライマリ・アダプタのネームスペースに対応するuser.create.basesとgroup.create.basesを指定して、前述のステップ1から3を実行します。

次のWLSTコマンドを実行します。

createJoinAdapter(adapterName="JoinAdapter1", root="dc=acme,dc=com", primaryAdapter="AD")
addJoinRule(adapterName="JoinAdapter1", secondary="OID", condition="uid=cn")

「uid=cn」は前述の例の結合条件です。これは、セカンダリ・アイデンティティ・ストア(OID)のユーザーのuid値とプライマリ・アイデンティティ・ストア(AD)のユーザーのcn値が一致した場合に、属性が結合されることを示します。

modifyLDAPAdapter(adapterName="OID", attribute="Visible", value="Internal")
modifyLDAPAdapter(adapterName="AD", attribute="Visible", value="Internal")

WebLogic管理サーバーと管理対象サーバーを再起動します。

単一オーセンティケータの復元

単一オーセンティケータを復元するには結合アダプタ・ルールを削除します。これにより、「アイデンティティ・ストアに部分的なユーザー・プロファイルが含まれる場合のlibOVDの構成」で実行した構成が取り消されます。

結合アダプタ・ルールを削除するには、Weblogic管理サーバーに接続して、次のWLSTコマンドを実行します。

deleteAdapter(adapterName="JoinAdapter1")
modifyLDAPAdapter(adapterName="oid auth", attribute="Visible", value="Yes")
modifyLDAPAdapter(adapterName="AD", attribute="Visible", value="Yes")

WebLogic管理サーバーと管理対象サーバーを再起動し、両方のアイデンティティ・ストアのユーザーがログインできることを確認します。

WebCenter Portalの動的グループの構成

動的グループとは、動的に移入される静的グループです。動的グループは、ロールに割り当てて、WebCenter Portal内で静的グループと同様に使用できます。

WebCenter Portalアプリケーション内では、静的グループと動的グループは区別されません。動的グループはすべて、アイデンティティ・ストアに構成され(構成内容は使用するLDAP実装に固有のものになります)、静的グループと同様に公開されます(事実上、動的グループは、静的なメンバー・リストと、動的に決定されるメンバーシップで構成されています)。

グループの動的メンバーシップを定義するには、グループのlabeledURI属性に適切なLDAP問合せフィルタを設定します。問合せフィルタには、グループのメンバーシップを定義するユーザー・セットが定義されています。

Oracle Internet Directoryで動的グループを作成するには、LDIFファイルとldapaddコマンドを使用するか、またはOracle Directory Services Manager (ODSM)を使用します。これら2つのオプションについて、次の各項で説明します。

• LDIFファイルを使用した動的グループの作成

• Oracle Directory Services Managerを使用した動的グループの作成

ノート: OVDが使用されている場合を除き、動的グループはOID以外のLDAPではサポートされません。

LDIFファイルを使用した動的グループの作成

LDIFファイルを使用して動的グループを作成するには:

1. テキスト・エディタでLDIFファイルを作成します。次の例では、デフォルトのユーザー検索ベース内で役職が「Manager」のユーザーをすべて表す動的グループを定義する方法を示します:

   例: LDIFファイルを使用した動的グループの定義

   dn: cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=oracle,dc=com
   labeleduri: ldap://myserver.example.com:12061/cn=users,dc=us,dc=mybiz,dc=com
   ??sub?(title=Manager)
   description: Dynamic Group of Managers
   cn: Managers
   orclisvisible: true
   objectclass: orclDynamicGroup
   objectclass: orclGroup
   objectclass: top
   objectclass: groupOfUniqueNames
   displayname: Managers
   owner: cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com
   

   ノート: LDAP URLのlabledURI構文はRFC 2255 (http://www.faqs.org/rfcs/rfc2255.html)に定義されています。前述の例は、DN cn=users,dc=us,dc=mybiz,dc=com内で属性title=Managerが設定されているすべてのエントリの検索を表しています。これは、サーバーmyserver.example.comのLDAPポート12061でサブツリー(sub)検索を使用して実行されます。

   動的グループは、属性または条件に対して定義できますが、LDAP URLとして表現可能かつlabeledURI属性で定義可能なものに限られます。また、動的グループは、ConnectByアサーションを使用して定義することもできます。このアサーションは、orclDynamicGroupオブジェクト・クラスに含まれます。この代替手段の詳細は、『Oracle Internet Directoryの管理』を参照してください。

2. ファイルを保存してから、ldapaddコマンドを発行してOIDサーバーを更新します。たとえば:

   例: ldapaddコマンドを使用したOIDの更新

   ldapadd -h myserver -p 12061 -D cn=fmwadmin -w mybiz1 –f managers.ldif –v
   add labeleduri: ldap://myserver.example.com:12061/cn=users,dc=us,dc=mybiz,dc=com??sub?(title=Manager)
   add description:
   Dynamic Group of Managers
   add cn:
   Managers
   add orclisvisible:
   true
   add objectclass:
   orclDynamicGroup
   orclGroup
   top
   groupOfUniqueNames
   add displayname:
   Managers
   add owner:
   cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com
   adding new entry cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=mybiz,dc=com
   modify complete
   

Oracle Directory Services Managerを使用した動的グループの作成

ODSMを使用して動的グループを作成するには:

1. Oracle Directory Services Manager (ODSM)を起動してOracle Internet Directoryサーバーに接続します。

   Oracle Directory Services Managerの起動および使用の詳細は、『Oracle Internet Directoryの管理』のOracle Directory Services Managerの使用を参照してください。

2. 「移動先」リストで「データ・ブラウザ」を選択します。

3. データ・ブラウザで「新規エントリ」アイコンをクリックします。

4. DNを指定して、オブジェクト・クラスorclDynamicGroupおよびgroupOfUniqueNamesを追加します。

5. 「必須プロパティ」タブで、CN属性を指定します。

6. 「オプション・プロパティ」タブで、labeleduriの属性を指定します。

7. 「OK」をクリックして、動的グループの定義を完了します。

ツリー・ビューをリフレッシュすると、作成した新しいグループが表示されるはずです。ODSMにはグループ・メンバーは表示されません。

RESTサービス・アイデンティティ・アサータの構成

この項では、RESTサービス用のアイデンティティ・アサータを構成する方法について説明します。WebCenter PortalでRESTサービス(RESTサービスAPIを含む)を使用する場合は、WebCenterドメインのアイデンティティ・ストアにRESTサービス用のアイデンティティ・アサータを構成する必要があります。次の項では、Oracle WebLogic ServerでOPSSトラスト・サービス・インスタンスとアイデンティティ・アサータを構成する方法について説明します。

この項では、次の項目について説明します。

• RESTサービス・インスタンスおよびアイデンティティ・アサータの理解

• クライアント・アプリケーションの設定

• WLSトラスト・サービス・アサータの構成

RESTサービス・インスタンスおよびアイデンティティ・アサータの理解

WebCenter Portalおよび他のOracle WebLogicアプリケーションでは、それらのアプリケーションで必要な方法でREST APIを使用して情報を表示できますが、そのようなコールは中間層から発信されるため、ユーザーはログイン資格証明を再度入力するよう求められます。これに対処するには、ユーザー・アイデンティティがHTTPヘッダーに伝播され、OPSSトラスト・サービス・アサータによってアサートされるときに境界認証を使用します。

ユーザー・アイデンティティをアプリケーション間で正常に伝幡するには、それらのアプリケーションでトラスト・サービス・インスタンスを正しく構成して使用する必要があります。図21-2(configuring-identity-store.md#CFHEIDCE)に、アイデンティティ伝幡とアサーションに関連する各種コンポーネントを示します。

図21-2 RESTのアイデンティティ伝幡とアサーション

次に、RESTのアイデンティティ伝幡とアサーションに関連した一連のイベントを示します。

1. エンド・クライアント(ブラウザ、スマートフォン・アプリケーション)は、WebCenter Portalアプリケーションに接続します。

2. アプリケーション・ページは、REST APIからデータを問い合せ、それをもとに独自のUIを構築するため、RESTエンド・ポイントをコールする必要があります。

3. アプリケーションは、WebCenter Security API (WCSecurityUtility.issueTrustServiceSecurityToken)をコールして、ユーザー・アイデンティティを安全に伝幡するために使用するトークンを発行します。このトークンはトラスト・サービスの組込みプロバイダを使用して生成されます。生成されたトークンは、トークン・サイズを最適化するために圧縮され、トークンが安全に転送されるようにHTTPヘッダーを使用してBASE64にエンコードされます。

4. アプリケーションは、発行されたトークンを受け取り、「Authorization」セキュリティ・ヘッダーに追加します。クライアントは、そのトークンをREST URIに対するコールの一部としてディスパッチします。

5. WebLogic Serverは、特定のトークン・タイプのアイデンティティ・アサータが存在するかどうかを確認します。

6. アイデンティティ・アサータは、トークンを解析して、OPSSトラスト・サービスAPIが使用されていることを確認します。

7. アサータがユーザー名をWLSユーザー名にマップすると、ユーザーのサブジェクトが確立され、RESTアプリケーションにコールが到達します。

8. RESTアプリケーションは、そのユーザーがすでに認証済のユーザーであることを認識し、レスポンスを送信します。WebCenter Portalはレスポンスを使用して、エンド・ユーザーにページを表示します。

クライアント・アプリケーションの設定

この項では、RESTサービス・アイデンティティ・アサータ用にクライアントを構成する方法について説明します。

RESTサービス・アイデンティティ・アサータ用にクライアントを構成するには:

1. JDeveloperを使用して、クライアント・アプリケーションを作成します。

   クライアント・アプリケーションとしてJSEまたはサーブレット・アプリケーションを作成できます。次の例では、サンプル・クライアント・アプリケーションのスケルトンを示します。

   // The authenticated username
   // String user = "weblogic"; 
   // URL of the target application
   URL url = "http://host:port/destinationApp"; 
   //-----------------------------------------
   
   String b64EncodedToken = WCSecurityUtility.issueTrustServiceSecurityToken()
   
   HttpURLConnection connection = (HttpURLConnection) url.openConnection();
   connection.setRequestMethod("GET");
   connection.setDoOutput(true);
   connection.setReadTimeout(10000);
   connection.setRequestProperty("Authorization", AUTH_TYPE_NAME + " " + b64EncodedToken); 
   connection.connect();
   BufferedReader rd = new BufferedReader(new InputStreamReader(
       connection.getInputStream()));
   StringBuilder sb = new StringBuilder();
   
   String line = null;
   while ((line = rd.readLine()) != null) {
       sb.append(line);
   }
   connection.disconnect();
   System.out.println(sb.toString());
   

2. 「WebCenter Portalドメイン・キーストアの作成」の説明に従ってキーストアを作成および構成し、アイデンティティ・アサータ用にWebLogic Serverを構成します。クライアント証明書および秘密キー用のキーストアがまずプロビジョニングされます。このクライアント証明書はエクスポートされ、トラスト・キーストアにインポートされます。

3. jps-config.xml構成ファイルを編集します。

   1. DOMAIN_HOME/config/fmwconfigディレクトリに移動し、テキスト・エディタでjps-config.xmlファイルを開きます。

   2. jps-config.xmlファイルに次のものが含まれていることを確認します。

      <serviceInstance name="keystore" provider="keystore.provider" location="./default-keystore.jks"> 
      

   3. trust.provider.embedded propertySetノードを次のように変更します。

      <propertySets>
          <propertySet name="trust.provider.embedded">
               ... existing entries
              <property value="orakey" name="trust.aliasName"/>
              <property value="orakey" name="trust.issuerName"/>
          </propertySet>
      </propertySets>
      

      ここで:

      trust.aliasNameは、アイデンティティ・アサータが構成済キーストアで検索する証明書の別名です。アサータはこの証明書を使用して、発行されたトラスト・トークンを検証します。

      trust.issuerNameは、トラスト・トークンの発行および署名に使用した秘密キーをトークン発行者が検索する際に検索される別名です。

4. クライアントとRESTアプリケーションのドメインが異なる場合は、両方のドメインで前述のステップを実行します。

5. すべてのサーバーを再起動します。

WLSトラスト・サービス・アサータの構成

この項では、WebLogic Serverトラスト・サービス・アサータを構成する方法について説明します。

WebLogic Serverトラスト・サービス・アサータを構成するには:

1. WebLogic管理コンソールに管理者としてログインします。

2. 「セキュリティ・レルム」→「myrealm」に移動します。

3. 「プロバイダ」タブを開き、「認証」サブタブを開きます。

   「新しい認証プロバイダの作成」ページが表示されます。

4. 新しいアサータの「名前」を入力します(たとえば、TrustServiceIdAsserter)。

5. アサータの「タイプ」にTrustServiceIdentityAsserterを選択します。

   このアサータは、受信リクエストのトークンをデコードおよび検証するためにトラスト・サービスAPIをコールし、アサートされたサブジェクトを確立する際にユーザー名をWebLogicに渡します。

6. 「OK」をクリックして、変更を保存します。

7. すべての管理対象サーバーを再起動します。