プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebCenter Portalの管理
12c (12.2.1.1)
E77296-01
目次へ移動
目次

前
次

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

この章では、アイデンティティ・ストアを、デフォルトの組込みLDAPアイデンティティ・ストアではなく外部のLDAPと再度関連付ける方法について説明します。また、Oracle WebCenter Content Server用のLDAPサーバーを構成する方法についても説明します。

この章の内容は次のとおりです。

注意:

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

  • config.xml

  • jps-config.xml

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

権限

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

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

26.1 外部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によってサポートされているLDAPのチューニングとパフォーマンスの詳細は、『パフォーマンスのチューニング』のアイデンティティ・ストア構成のチューニングに関する項を参照してください。

注意:

(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.xmlvirtualizeプロパティを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. 変更が有効になるように、管理サーバーと管理対象サーバーを再起動します。

26.2 外部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

26.3 組込み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に自己登録した新規ユーザーは、アイデンティティ・ストアに直接追加されます。自己登録の詳細は、「自己登録の有効化」を参照してください。

注意:

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

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

26.3.1 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」をクリックして変更を保存し、ユーザーを追加します。

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

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

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

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

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

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

組込みLDAPのアクセス資格証明をリセットする手順は次のとおりです。

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

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

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

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

  4. 「資格証明」フィールドに新しいパスワードを入力し、「資格証明の確認」フィールドに再度入力します。
  5. 「保存」をクリックして設定を保存します。
  6. WebLogicサーバーを再起動します。

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

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

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

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

26.3.2.2 LDIFファイルの作成

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

  • person

  • inetOrgPerson

  • organizationalPerson

  • wlsUser

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

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

図26-1の説明が続きます
「図26-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: 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

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

注意:

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

  • orclTimeZone

  • orclDateOfBirth

  • maidenName

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

26.3.2.3 ユーザーの追加

次の例では、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:
        john.doe@example.com
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

26.4 外部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に設定されていることを確認してください。このオプションを選択する場合は、「外部LDAPを使用するためのディスカッション・サーバーの移行」の手順に従って、追加の手順を実行する必要もあります。

    注意:

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

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

    注意:

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

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

26.4.1 外部LDAPを使用するためのディスカッション・サーバーの移行

ディスカッション・サーバーをインストールしており、管理者アカウントを外部LDAPに移行しない場合(「外部LDAPサーバーへの管理者アカウントの移行」を参照)、WebLogic Serverでオーセンティケータの順序を変更する前に、ディスカッション・サーバーで新しい管理者アカウントを識別するために追加の手順を実行する必要があります。

  1. ディスカッション・サーバーの管理者にするユーザー・アカウントを外部LDAPから選択します。
  2. 外部LDAPから選択したユーザー・アカウントに一致する管理者アカウントをDefaultAuthenticator(組込みLDAP)に作成します。組込みLDAPと外部LDAPサーバーのアカウント名は一致する必要があります。

    組込みLDAPへのユーザーの追加の詳細は、「組込みLDAPアイデンティティ・ストアへのユーザーの追加」を参照してください。

  3. ディスカッション・サーバー管理コンソールに起動アイデンティティ・アカウント(weblogic)でログインし、次にアクセスします。
    http://host:port/owc_discussions/admin
    

    hostportWLS_Services管理対象サーバーのホストIDとポート番号です。

  4. 「設定」→管理者/モデレータをクリックします。

    「管理者およびモデレータ」ページが表示されます(図26-2を参照)。

    図26-2 「管理者およびモデレータ」ページ

    図26-2の説明が続きます
    「図26-2 「管理者およびモデレータ」ページ」の説明
  5. 新規権限の付与をクリックします。

    新規権限の付与ペインが表示されます(図26-3を参照)。

    図26-3 新規権限の付与ペイン

    図26-3の説明が続きます
    「図26-3 新規権限の付与ペイン」の説明
  6. 作成したユーザーにシステム管理者権限を付与します(図26-4を参照)。

    図26-4 「新規権限の付与」ペインでの新規ユーザーの入力

    図26-4の説明が続きます
    「図26-4 「新規権限の付与」ペインでの新規ユーザーの入力」の説明
  7. 「システム」→「システム・プロパティ」をクリックします。

    「Jiveプロパティ」ページが表示されます(図26-5を参照)。

    図26-5 「Jiveプロパティ」ページ

    図26-5の説明が続きます
    「図26-5 「Jiveプロパティ」ページ」の説明
  8. 赤でマークされたプロパティが追加され、図26-5のように設定されていることを確認します。
  9. WebLogic Server管理コンソールにログインします。

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

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

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

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

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

  12. 「プロバイダ」タブを選択し、「認証」サブタブを選択したら、外部LDAPのオーセンティケータがリストの先頭に表示されるように認証プロバイダの順序を変更します(図26-6の例を参照)。

    図26-6 認証プロバイダの順序変更後の「プロバイダ」タブ

    図26-6の説明が続きます
    「図26-6 認証プロバイダの順序変更後の「プロバイダ」タブ」の説明
  13. ドメインの管理サーバーとディスカッション・サーバーを再起動します。
  14. まだ実行していない場合は、外部LDAPでユーザーを作成し、そのユーザーにWebCenter Portal管理者ロールを付与します(「WebCenter Portal管理者ロールの付与」を参照)。

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

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の管理権限が付与されます。

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

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

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

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

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

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

注意:

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

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

26.6.1 アイデンティティ・ストアに完全なユーザー・プロファイルが存在する場合の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」は実際の値に置き換えてください。

26.6.2 アイデンティティ・ストアに部分的なユーザー・プロファイルが存在する場合の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.basesgroup.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管理サーバーと管理対象サーバーを再起動します。

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

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

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

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

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

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

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

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

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

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

注意:

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

26.7.1 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

26.7.2 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を使用したOracle Internet Directoryの管理に関する項を参照してください。

  2. 「移動先」リストで「データ・ブラウザ」を選択します。
  3. データ・ブラウザで「新規エントリ」アイコンをクリックします。
  4. DNを指定して、オブジェクト・クラスorclDynamicGroupおよびgroupOfUniqueNamesを追加します。
  5. 「必須プロパティ」タブで、CN属性を指定します。
  6. 「オプション・プロパティ」タブで、labeleduriの属性を指定します。
  7. 「OK」をクリックして、動的グループの定義を完了します。

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

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

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

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

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

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

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

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

図26-7の説明が続きます
「図26-7 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はレスポンスを使用して、エンド・ユーザーにページを表示します。

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

この項では、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. すべてのサーバーを再起動します。

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

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

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

  1. WebLogic管理コンソールに管理者としてログインします。
  2. 「セキュリティ・レルム」→「myrealm」に移動します。
  3. 「プロバイダ」タブを開き、「認証」サブタブを開きます。

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

  4. 新しいアサータの「名前」を入力します(例: TrustServiceIdAsserter)。
  5. アサータの「タイプ」TrustServiceIdentityAsserterを選択します。

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

  6. OK」をクリックして、変更を保存します。
  7. すべての管理対象サーバーを再起動します。