この章の内容は次のとおりです。
注意:
アイデンティティ・ストアを再度関連付ける前に、次の関連する構成ファイルを必ずバックアップしてください。
config.xml
jps-config.xml
念のため、ドメインの管理サーバーのboot.properties
ファイルもバックアップしてください。
権限
この章のタスクを実行するには、Oracle WebLogic Server管理コンソールでWebLogic ServerのAdmin
ロールが付与されている必要があります。Monitor
またはOperator
ロールを持つユーザーは、セキュリティ情報を表示できますが変更することはできません。
「管理操作、ロールおよびツールの理解」も参照してください。
ほとんどの場合、アイデンティティ・ストアは、デフォルトの組込み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に再度関連付ける手順は次のとおりです。
この項では、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に追加するには、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に自己登録した新規ユーザーは、アイデンティティ・ストアに直接追加されます。自己登録の詳細は、「自己登録の有効化」を参照してください。
注意:
アイデンティティ・ストアへのユーザーの追加は、一般にシステム管理者のタスクであり、アプリケーションレベルの管理者は必要な権限を持っていてもこのタスクを実行できない場合があります。
この項では、次の内容について説明します。
WebLogic Server管理コンソールから組込みLDAPアイデンティティ・ストアにユーザーを追加するには:
LDIFファイルを使用して組込みLDAPアイデンティティ・ストアにユーザーを直接追加する手順は次のとおりです。LDIFファイルを使用すると、WebLogic Server管理コンソールからでは使用できない追加のユーザー属性を指定できます。組込みLDAPサーバーはLDAPに準拠したサーバーであるため、LDAPコマンドを使用してユーザーを追加または変更できます。また、ディレクトリを検索することもできます。これは、ユーザー・アカウントをエクスポートおよびインポートする場合に役立ちます。
LDIFファイルを使用して組込みLDAPにユーザーを追加するには、次のタスクを実行する必要があります。
LDAPアクセス資格証明は、WebLogic Serverのインストール時にランダム値として設定され、config.xml
ファイルに暗号化されます。外部LDAPアクセスを有効にするには、組込みLDAPのアクセス資格証明をリセットする必要があります。
組込みLDAPのアクセス資格証明をリセットする手順は次のとおりです。
LDIFファイルは任意のテキスト・エディタで作成できます。また、LDIFファイルには、組込みLDAPディレクトリに該当する任意の属性を含めることができます。WebLogic Serverの組込みLDAPサーバーのデフォルトでサポートされているobjectclasses
は次のとおりです。
person
inetOrgPerson
organizationalPerson
wlsUser
組込みLDAPサーバーと正常に対話するには、ディレクトリ情報ツリー(DIT)のデフォルト・レイアウトを理解しておく必要があります。組込みLDAPディレクトリのデフォルト・レイアウトを図26-1に示します。
注意:
組込み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アイデンティティ・ストアには追加できません。
次の例では、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
外部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サービスの保護とポリシーの管理』のデフォルト・ユーザーの変更に関する項を参照してください。
この項には次のトピックが含まれます:
ディスカッション・サーバーをインストールしており、管理者アカウントを外部LDAPに移行しない場合(「外部LDAPサーバーへの管理者アカウントの移行」を参照)、WebLogic Serverでオーセンティケータの順序を変更する前に、ディスカッション・サーバーで新しい管理者アカウントを識別するために追加の手順を実行する必要があります。
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グローバル管理ロールのロール定義を更新する手順は次のとおりです。
WebCenter Content Serverは、WebCenter Portalと同じアイデンティティ・ストアLDAPサーバーを使用するように構成する必要があります。WebCenter Contentの構成の詳細は、「Oracle WebCenter Content Serverへの接続の管理」を参照し、『Oracle Platform Security Servicesによるアプリケーションの保護』のLDAPアイデンティティ・ストア・サービスの構成に関する項も参照してください。
複数のアイデンティティ・ストアを持つサイトでは、libOVDを使用してそのユーザー・プロファイル情報を集約できます。次の2つのシナリオの構成手順を説明します。
それぞれに完全なユーザー・プロファイル情報が存在する個別のアイデンティティ・ストアでユーザーを有効にする場合。
それぞれに部分的な属性が存在する2つのアイデンティティ・ストアで同一ユーザーを有効にする場合。
注意:
Active Directoryによる自己登録をサポートする場合は、「Active Directoryを使用してWebCenter Portalを構成するとユーザーが自己登録できない」に記載されているトラブルシューティングを必ず参照してください。
この項では、次の項目について説明します。
各アイデンティティ・ストアに完全なユーザー・プロファイルが存在する場合にlibOVDを構成する手順は次のとおりです。
各アイデンティティ・ストアに部分的なユーザー・プロファイルのみが存在する場合にlibOVDを構成するには:
例
オーセンティケータ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アプリケーション内では、静的グループと動的グループは区別されません。動的グループはすべて、アイデンティティ・ストアに構成され(構成内容は使用するLDAP実装に固有のものになります)、静的グループと同様に公開されます(事実上、動的グループは、静的なメンバー・リストと、動的に決定されるメンバーシップで構成されています)。
グループの動的メンバーシップを定義するには、グループのlabeledURI
属性に適切なLDAP問合せフィルタを設定します。問合せフィルタには、グループのメンバーシップを定義するユーザー・セットが定義されています。
Oracle Internet Directoryで動的グループを作成するには、LDIFファイルとldapadd
コマンドを使用するか、またはOracle Directory Services Manager (ODSM)を使用します。これら2つのオプションについて、次の各項で説明します。
注意:
OVDが使用されている場合を除き、動的グループはOID以外のLDAPではサポートされません。
この項では、RESTサービス用のアイデンティティ・アサータを構成する方法について説明します。WebCenter PortalでRESTサービス(RESTサービスAPIを含む)を使用する場合は、WebCenterドメインのアイデンティティ・ストアにRESTサービス用のアイデンティティ・アサータを構成する必要があります。次の項では、Oracle WebLogic ServerでOPSSトラスト・サービス・インスタンスとアイデンティティ・アサータを構成する方法について説明します。
この項では、次の項目について説明します。
WebCenter Portalおよび他のOracle WebLogicアプリケーションでは、それらのアプリケーションで必要な方法でREST APIを使用して情報を表示できますが、そのようなコールは中間層から発信されるため、ユーザーはログイン資格証明を再度入力するよう求められます。これに対処するには、ユーザー・アイデンティティがHTTPヘッダーに伝播され、OPSSトラスト・サービス・アサータによってアサートされるときに境界認証を使用します。
ユーザー・アイデンティティをアプリケーション間で正常に伝幡するには、それらのアプリケーションでトラスト・サービス・インスタンスを正しく構成して使用する必要があります。図26-7 に、アイデンティティ伝幡とアサーションに関連する各種コンポーネントを示します。
次に、RESTのアイデンティティ伝幡とアサーションに関連した一連のイベントを示します。
エンド・クライアント(ブラウザ、スマートフォン・アプリケーション)は、WebCenter Portalアプリケーションに接続します。
アプリケーション・ページは、REST APIからデータを問い合せ、それをもとに独自のUIを構築するため、RESTエンド・ポイントをコールする必要があります。
アプリケーションは、WebCenter Security API (WCSecurityUtility.issueTrustServiceSecurityToken
)をコールして、ユーザー・アイデンティティを安全に伝幡するために使用するトークンを発行します。このトークンはトラスト・サービスの組込みプロバイダを使用して生成されます。生成されたトークンは、トークン・サイズを最適化するために圧縮され、トークンが安全に転送されるようにHTTPヘッダーを使用してBASE64にエンコードされます。
アプリケーションは、発行されたトークンを受け取り、「Authorization」セキュリティ・ヘッダーに追加します。クライアントは、そのトークンをREST URIに対するコールの一部としてディスパッチします。
WebLogic Serverは、特定のトークン・タイプのアイデンティティ・アサータが存在するかどうかを確認します。
アイデンティティ・アサータは、トークンを解析して、OPSSトラスト・サービスAPIが使用されていることを確認します。
アサータがユーザー名をWLSユーザー名にマップすると、ユーザーのサブジェクトが確立され、RESTアプリケーションにコールが到達します。
RESTアプリケーションは、そのユーザーがすでに認証済のユーザーであることを認識し、レスポンスを送信します。WebCenter Portalはレスポンスを使用して、エンド・ユーザーにページを表示します。
この項では、RESTサービス・アイデンティティ・アサータ用にクライアントを構成する方法について説明します。
RESTサービス・アイデンティティ・アサータ用にクライアントを構成するには:
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());
「WebCenter Portalドメイン・キーストアの作成」の説明に従ってキーストアを作成および構成し、アイデンティティ・アサータ用にWebLogic Serverを構成します。クライアント証明書および秘密鍵用のキーストアがまずプロビジョニングされます。このクライアント証明書はエクスポートされ、トラスト・キーストアにインポートされます。
jps-config.xml
構成ファイルを編集します。
DOMAIN_HOME/config/fmwconfig
ディレクトリに移動し、テキスト・エディタでjps-config.xml
ファイルを開きます。
jps-config.xml
ファイルに次のものが含まれていることを確認します。
<serviceInstance name="keystore" provider="keystore.provider" location="./default-keystore.jks">
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
は、トラスト・トークンの発行および署名に使用した秘密鍵をトークン発行者が検索する際に検索される別名です。
クライアントとRESTアプリケーションのドメインが異なる場合は、両方のドメインで前述の手順を実行します。
すべてのサーバーを再起動します。