| Oracle® Fusion Middleware Oracle WebCenter Portal管理者ガイド 11g リリース1 (11.1.1.7.0) B72085-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portal管理者ガイド 11g リリース1 (11.1.1.7.0) B72085-02 |
|
前 |
次 |
この章では、アイデンティティ・ストアを、デフォルトの組込みLDAPアイデンティティ・ストアではなく、外部LDAPに再度関連付ける方法について説明します。また、LDAPサーバーをOracle WebCenter Content Server用に構成する方法についても説明します。この章の内容は次のとおりです。
|
注意: アイデンティティ・ストアを再度関連付ける前に、次の関連する構成ファイルを必ずバックアップしてください。
念のため、ドメインの管理サーバーの |
Frameworkアプリケーションでは、外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行の手順は不要です。アイデンティティ・ストアの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
対象読者
この章の内容は、Fusion Middleware管理者(Oracle WebLogic Server管理コンソールを使用してAdminロールを付与されたユーザー)を対象としています。MonitorまたはOperatorロールを持つユーザーは、セキュリティ情報を表示できますが変更することはできません。第1.8項「管理操作、ロールおよびツールの理解」も参照してください。
ほとんどの場合、アイデンティティ・ストアは、デフォルトの組込みLDAPは使用せずに、外部LDAPサーバーに再度関連付ける必要があります。様々なタイプのLDAPサーバーを使用できますが(サポートされているLDAPのリストはOracle Fusion Middleware Applicationアプリケーション・セキュリティ・ガイドのサポートされているLDAPアイデンティティ・ストアのタイプに関する項を参照)、この項では、Oracle Internet Directory (OID)を使用するようにアイデンティティ・ストアを構成する方法を説明します。
|
注意: 外部LDAPサーバーへのアイデンティティ・ストアの再関連付けは、ドキュメント・サービスおよびディスカッション・サービスを使用している場合にのみ必須で、その場合は |
サポートされている他のLDAPのGUID属性については、第30.2項「外部LDAPアイデンティティ・ストア用のGUID属性の構成」を参照してください。サポートされているLDAPサーバーの他のユーザー属性マッピングについては、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPディレクトリへのユーザー属性のマッピングに関する項を参照してください。WebCenter PortalでサポートされるLDAPのチューニングおよびパフォーマンスに関する情報は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「アイデンティティ・ストアのパフォーマンス・チューニング」を参照してください。
|
注意: 本番環境の外部LDAPアイデンティティ・ストア(OIDなど)を別の外部LDAPストアに再度関連付けすることはサポートされていません。ビジネス要件によりそのような再関連付けを行う場合は、プロセス中にユーザー情報やアーティファクトが失われる可能性があるため、実施前にOracleサポートにご連絡ください。 |
アイデンティティ・ストアをOIDに再度関連付ける手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
「名前」列で、アイデンティティ・ストアを再度関連付けるレルムをクリックします。
「レルムの設定」ペインが表示されます。
「プロバイダ」タブを開きます。
プロバイダの設定ペインが表示されます。
「新規」をクリックして、新しいプロバイダを追加します。
「新しい認証プロバイダの作成」ペインが表示されます。
プロバイダの名前を入力します(OIDAuthenticatorなど、Oracle Internet Directoryに対してユーザーを認証するプロバイダの名前)を入力します。
LDAPディレクトリに適したオーセンティケータをオーセンティケータのリストから選択します。
一般的なDefaultAuthenticatorを選択するのではなく、構成するLDAPに関連付けられたオーセンティケータを選択してください。たとえば、OIDの場合はOracleInternetDirectoryAuthenticator、iPlanetの場合はIPlanetAuthenticatorを選択します。
「OK」をクリックして、設定を保存します。
設定ペインに新規の認証プロバイダが表示されます。
「認証プロバイダ」のリストで、新しく作成したプロバイダをクリックします。
新規の認証プロバイダの設定ペインが表示されます。
「制御フラグ」をSUFFICIENTに設定します。
「制御フラグ」をSUFFICIENTに設定すると、このオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。
|
注意: 認証に失敗した場合、その認証は連鎖内の次のオーセンティケータに渡されます。そのため、後続のすべてのオーセンティケータについても、制御フラグが |
「保存」をクリックして、設定を保存します。
「プロバイダ固有」タブを選択して、LDAPサーバーの詳細を入力します。
「プロバイダ固有」ペインが表示されます。
使用するLDAPサーバーに固有の詳細を入力します。
|
注意: OIDの場合の適切な値を次の表に示します。Active Directoryなど、他のLDAPの許容値については、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の付録「OPSSのシステム・プロパティおよび構成プロパティ」を参照してください。 |
| パラメータ | 値 | 説明 |
|---|---|---|
|
ホスト: |
LDAPサーバーのサーバーID(例: |
|
|
ポート: |
LDAPサーバーのポート番号(例: |
|
|
プリンシパル: |
LDAPサーバーへの接続に使用されるLDAPユーザーDN(例: |
|
|
資格証明: |
LDAPサーバーへの接続に使用されるパスワード |
|
|
ユーザー・ベースDN: |
ユーザーの基点となるDN(例: |
|
|
グループ・ベースDN: |
グループ・ノードを示すDNを指定します(例: |
|
|
取得したユーザー名をプリンシパルとして使用する |
選択 |
有効にしておく必要があります。 |
|
すべてのユーザーのフィルタ: |
|
「ユーザー・ベースDN」内のすべてのユーザーを検索するための検索フィルタ |
|
名前指定によるユーザー・フィルタ: |
|
|
|
ユーザー名属性: |
|
「保存」をクリックします。
「プロバイダ」タブに戻り、リストの先頭に新しい認証プロバイダ、その次に他のオーセンティケータ、最後にDefaultAuthenticatorが表示されるようにプロバイダを並べ替えます。
すべてのオーセンティケータの制御フラグをSUFFICIENTに設定し、新しいプロバイダからDefaultAuthenticator(デフォルトのファイルベースの組込みLDAPのみで使用)に至るまで、後続のオーセンティケータで渡されたアイデンティティを認証できるようにする必要があります。たとえば、デフォルトの管理者アカウントなどのログインは通常、LDAPディレクトリ内に作成されませんが、サーバーを起動するためには認証が必要です。DefaultAuthenticatorにアイデンティティが渡されない場合、デフォルトの管理者アカウントは認証されません。DefaultAuthenticatorおよびデフォルトの管理者アカウントの詳細は、第30.4項「外部LDAPサーバーへの管理者アカウントの移行」を参照してください。
|
注意: 複数のオーセンティケータを使用する場合は、REQUIRED制御フラグを使用しないでください。オーセンティケータのリストでREQUIRED制御フラグが見つかった場合、その位置に関係なく、後続のオーセンティケータは調査されません。 |
変更が有効になるように、管理サーバーと管理対象サーバーを再起動します。
この項では、Oracle LDAP以外の実装で使用される様々なGUID属性について説明します。サポートされている他のLDAPサーバーの他のユーザー属性マッピングについては、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPディレクトリへのユーザー属性のマッピングに関する項を参照してください。
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スキーマ問合せに対して正しい属性タイプを返しません。DNがVMM IDとして返されます。VMMのデフォルトのID設定を上書きするには、次の行をwimconfig.xmlファイルの<config:attributeConfiguration>セクションに追加します。
<config:externalIdAttributes name="dominoUNID"/>
Sun Java™ System Directory Server:
nsuniqueid
eNovell Directory Server:
GUID
orclGuid属性を使用しないLDAPアイデンティティ・ストア(IBM Tivoliなど)を使用する場合は、GUID属性がアイデンティティ・ストアと一致するように手動でマップする必要があります。たとえば、IBM Tivoliの場合、jps-config.xmlファイルのGUID=ibm-entryUUIDを次のように設定します。
MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config.xmlファイルをテキスト・エディタで開きます。
GUIDプロパティを次のように設定します。
<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap.0">
<!-- existing props ... ->
<property name="PROPERTY_ATTRIBUTE_MAPPING"
value="GUID=ibm-entryUUID"/>
<extendedProperty>
... ...
</extendedProperty>
</serviceInstance>
すべてのサーバーを再起動します。
ユーザーを組込みLDAPに追加するには、WebLogic Server管理コンソールを使用するか、またはLDIFファイルとLDAPコマンドを使用します。LDIFファイルを使用すると、WebLogic Server管理コンソールからでは使用できない属性を追加できます。
|
注意: 組込みLDAPサーバーは、テストや概念実証の目的のみに使用してください。本番用には、Oracle Internet DirectoryやMicrosoft Active Directoryなど、OPSSユーザーおよびロールAPIでサポートされている外部アイデンティティ・ストアを使用することをお薦めします。 |
Oracle Internet Directoryでは通常、ユーザーはODSMを使用して管理されます(Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのディレクトリ・エントリの管理に関する項を参照してください)。
|
注意: アイデンティティ・ストアを外部LDAPに再度関連付けする予定がある場合は、再関連付けの手順(第30.1項「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」を参照)を先に実行してください。組込みLDAPをOIDや他の外部LDAP実装に再度関連付けする場合、ユーザーやユーザーのアーティファクトは移行できません。したがって、本番環境にユーザーを移行する場合を除き、組込みLDAPにはユーザーを追加しないでください。組込みLDAPは、テスト環境のみで使用することを目的としており、本番環境への移行が可能なステージング環境で使用することは意図していません。 |
Spacesでは自己登録がサポートされます。Spacesに自己登録した新規ユーザーは、アイデンティティ・ストアに直接追加されます。自己登録の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal: Spacesユーザーズ・ガイドの自己登録の許可に関する項を参照してください。
|
注意: アイデンティティ・ストアへのユーザーの追加は、一般にシステム管理者のタスクであり、アプリケーションレベルの管理者は必要な権限を持っていてもこのタスクを実行できない場合があります。 |
この項の内容は次のとおりです。
WebLogic Server管理コンソールから組込みLDAPアイデンティティ・ストアにユーザーを追加する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
「名前」列で、ユーザーを追加するレルムをクリックします。
「レルムの設定」ペインが表示されます。
「ユーザーとグループ」タブをクリックし、現行ユーザーのリストを表示します。
「新規」をクリックして、新しいユーザーを追加します。
「新しいユーザーの作成」ページで、「名前」フィールドに新しいユーザーのログイン名を入力します。
ユーザー名では大/小文字が区別されます。また、ユーザー名は一意である必要があります。カンマ、タブ、および次のカンマ区切りリスト内のその他の文字は使用しないでください。
< >, #, |, &, ?, ( ), { }
「説明」フィールドに、ユーザーの説明(たとえば、ユーザーのフル・ネーム)を入力します。
「プロバイダ」ドロップダウン・メニューからDefaultAuthenticatorを選択します。
「パスワード」フィールドに、ユーザーのパスワードを入力します。
WebLogic認証プロバイダで定義されたユーザーのパスワードは8文字以上です(他のLDAPプロバイダではパスワード長の要件が異なる場合があります)。本番のWebLogicでは、weblogic/weblogicなどのユーザー名とパスワードの組合せは使用しないでください。
「パスワードの確認」フィールドにパスワードを再入力します。
「OK」をクリックして変更を保存し、ユーザーを追加します。
追加したユーザーがユーザー・リストに表示されます。
LDIFファイルを使用して組込みLDAPアイデンティティ・ストアにユーザーを直接追加する手順は次のとおりです。LDIFファイルを使用すると、WebLogic Server管理コンソールからは使用できない追加のユーザー属性を指定できます。組込みLDAPサーバーはLDAPに準拠したサーバーであるため、LDAPコマンドを使用してユーザーの追加や変更ができます。また、ディレクトリを検索することもできます。これは、ユーザー・アカウントをエクスポートおよびインポートする場合に役立ちます。
LDIFファイルを使用して組込みLDAPにユーザーを追加するには、次のタスクを実行する必要があります。
外部LDAPアクセスの有効化
LDAPアクセス資格証明は、WebLogic Serverのインストール時にランダム値として設定され、config.xmlファイルに暗号化されます。外部LDAPアクセスを有効にするには、組込みLDAPのアクセス資格証明をリセットする必要があります。
組込みLDAPのアクセス資格証明をリセットする手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、wc_domainをクリックします。
wc_domainの「設定」ペインで「セキュリティ」タブをクリックし、「組込みLDAP」タブをクリックします。
wc_domainの「設定」ペインに組込みLDAP設定が表示されます。
「資格証明」フィールドに新しいパスワードを入力し、「資格証明の確認」フィールドに再度入力します。
「保存」をクリックして、設定を保存します。
WebLogicサーバーを再起動します。
これを行った後は、次の値を使用してLDAPサーバーにアクセスできるようになります。
管理アクセスのDN値は"cn=Admin"です。
パスワードは「資格証明」フィールドに入力した値です。
ポートは管理ポートと同じポート(デフォルトは7001)です。
LDIFファイルの作成
LDIFファイルは任意のテキスト・エディタで作成できます。また、LDIFファイルには、組込みLDAPディレクトリに該当する任意の属性を含めることができます。WebLogic Serverの組込みLDAPサーバーのデフォルトでサポートされているobjectclassesは次のとおりです。
person
inetOrgPerson
organizationalPerson
wlsUser
組込みLDAPサーバーと正常に対話するには、ディレクトリ情報ツリー(DIT)のデフォルト・レイアウトを理解しておく必要があります。組込みLDAPディレクトリのデフォルト・レイアウトを図30-1に示します。
次の例は、Spacesユーザーのプロフィール画面に表示される属性が指定された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: MyPassword1 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
複数のユーザー・エントリを含むファイルを作成するには、前述の行を必要な回数だけレプリケートし、エントリ間に空白行を入れます。
|
注意: Spacesのユーザー・プロファイルには、Oracle Internet Directoryのみで使用可能な属性が含まれます。これには、
これらの属性は、組込みLDAPアイデンティティ・ストアには追加できません。 |
ユーザーの追加
次の例では、ldappaddコマンドを使用しています。このコマンドは、Oracle Internet Directoryサーバーに付属のLDAPコマンドライン・ユーティリティに含まれます。ldappaddコマンドの使用方法の詳細は、Oracle Identity Managementユーザー・リファレンスのOracle Internet Directoryデータ管理ツールに関する項を参照してください。WebCenter PortalでサポートされるLDAPサーバーのユーザー属性マッピングの全リストは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の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サーバーを使用するようにドメインを構成する場合、必要に応じてFusion Middleware管理者アカウント(デフォルトではweblogic)をLDAPサーバーに移行することもできます。
Fusion Middleware管理者アカウントまたはLDAP内の他の適切なユーザーが「管理者」というLDAPグループに属する場合、このアカウントは、サーバーを管理するための権限を満たしています。また、DefaultAuthenticatorプロバイダを認証プロバイダのリストから削除できます。この場合、すべてのユーザー(管理者アカウントを含む)は外部LDAPに対して認証されます。
weblogic(デフォルト)ユーザーを外部LDAPディレクトリに作成できない場合は、2つのオプションがあります。次を実行できます。
DefaultAuthenticatorプロバイダを維持したまま、weblogicアカウントとローカルの組込みLDAPサーバーをWebLogic Serverで使用し、WebLogic Server管理コンソールからサーバーの起動と停止および他の管理者用操作を行います。DefaultAuthenticatorを維持する場合は、DefaultAuthenticationプロバイダの制御フラグがSUFFICIENTに設定されていることを確認してください。このオプションを選択する場合は、第30.4.1項「外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行」の手順に従って、追加の手順を実行する必要があります。
|
注意:
|
DefaultAuthenticatorを削除し、管理者用操作(サーバーの起動や停止など)で使用する有効なユーザー・アカウントを「管理者」グループに含めます。その他の名前のグループに含める場合は、そのグループにOIDまたは他の外部LDAPでドメインの管理を許可されたユーザーのリストが含まれている必要があります。「管理者」以外の名前を使用する場合は、WebLogic Serverグローバル管理者ロールの定義でグループ名を更新する必要があります。デフォルトでは、これは「管理者」というエンタープライズ・グループのメンバーシップとして定義されています。管理者グループ名の変更の詳細は、第30.4.2項「管理者グループ名の変更」を参照してください。
Oracle WebCenter Portalのディスカッション・サーバーをインストールしており、管理者アカウントを外部LDAPに移行しない場合(第30.4項「外部LDAPサーバーへの管理者アカウントの移行」を参照)、WebLogic Serverでオーセンティケータの順序を変更する前に、ディスカッション・サーバーで新しい管理者アカウントを識別するために追加の手順を実行する必要があります。
ディスカッション・サーバーの管理者にするユーザー・アカウントを外部LDAPから選択します。
外部LDAPから選択したユーザー・アカウントに一致する管理者アカウントをDefaultAuthenticator(組込みLDAP)に作成します。組込みLDAPと外部LDAPサーバーのアカウント名は一致する必要があります。
組込みLDAPへのユーザーの追加の詳細は、第30.3項「組込みLDAPアイデンティティ・ストアへのユーザーの追加」を参照してください。
Oracle WebCenter Portalのディスカッション・サーバー管理コンソールに起動アイデンティティ・アカウント(weblogic)でログインし、次にアクセスします。
http://host:port/owc_discussions/admin
hostとportはWLS_Services管理対象サーバーのホストIDとポート番号です。
「設定」→「管理者/モデレータ」をクリックします。
「管理者およびモデレータ」ページが表示されます(図30-2を参照)。
「新規権限の付与」をクリックします。
「新規権限の付与」ペインが表示されます(図30-3を参照)。
作成したユーザーにシステム管理者権限を付与します(図30-4を参照)。
「System」→「システム・プロパティ」をクリックします。
「Jiveプロパティ」ページが表示されます(図30-5を参照)。
赤でマークされたプロパティが追加され、図30-5のように設定されていることを確認します。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
「名前」列で、管理者グループ名を変更するレルムをクリックします。
「レルムの設定」ペインが表示されます。
「プロバイダ」タブを選択し、「認証」サブタブを選択したら、外部LDAPのオーセンティケータがリストの先頭に表示されるように認証プロバイダの順序を変更します(図30-6の例を参照)。
ドメインの管理サーバーとディスカッション・サーバーを再起動します。
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グローバル管理ロールのロール定義を更新する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
「名前」列で、管理者グループ名を変更するレルムをクリックします。
「レルムの設定」ペインが表示されます。
「ロールとポリシー」タブを開き、「レルム・ロール」サブタブを開きます。
「レルム・ロール」設定ペインが表示されます。
「グローバル・ロール」ノードを開き、「ロール」ノードを開きます。
Adminロールの「ロール条件の表示」をクリックします。
「グローバル・ロールの編集」ページが表示されます。
デフォルトでは、Oracle Internet Directory(または他の構成済アイデンティティ・ストア)のAdministratorsグループにはWebLogic Serverで管理者ロールを持つユーザーが定義されています。
「条件の追加」をクリックして、別のグループ名を追加します。
「グローバル・ロールの編集」ページに「述部リスト」が表示されます。
「述部リスト」からGroupを選択し、「次へ」をクリックします。
「グローバル・ロールの編集」ページに「引数」が表示されます。
新規管理者グループの名前を入力して、「追加」をクリックします。
選択した新規管理者グループを残したまま既存の管理者グループを削除するには、そのグループを選択して「削除」をクリックします。
「終了」をクリックして、変更を保存します。
この変更を行うと、指定した新規グループのすべてのメンバーにWebLogic Serverの管理権限が付与されます。
Oracle Content Server (OCS)は、Oracle Spacesと同じアイデンティティ・ストアLDAPサーバーを使用するように構成する必要があります。OCSの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の第11章「コンテンツ・リポジトリの管理」およびLDAPアイデンティティ・ストア・サービスの構成に関する項を参照してください。
複数のアイデンティティ・ストアを使用するサイトでは、libOVDを使用することによりユーザー・プロファイル情報を集約できます。次の2つのシナリオの構成手順を説明します。
それぞれに完全なユーザー・プロファイル情報が存在する個別のアイデンティティ・ストアでユーザーを有効にする場合。
それぞれに部分的な属性が存在する2つのアイデンティティ・ストアで同一ユーザーを有効にする場合。
|
注意: Active Directoryによる自己登録をサポートする場合は、第29.3.3項「Active Directoryを使用してSpacesを構成するとユーザーが自己登録できない」に記載されているトラブルシューティングを必ず参照してください。 |
この項の内容は次のとおりです。
各アイデンティティ・ストアに完全なユーザー・プロファイルが存在する場合にlibOVDを構成する手順は次のとおりです。
構成するアイデンティティ・ストアのWLS管理コンソールで必要なオーセンティケータを作成し、ドメインのWeblogic管理サーバーおよび管理対象サーバーを再起動します。または、jps-config.xmlでアイデンティティ・ストア情報を手動で構成することもできます。
アイデンティティ・ストア・サービス・インスタンスをjps-config.xmlで更新し、値がtrueであるvirtualizeプロパティを追加します。これは手動でjps-config.xmlファイルを編集するか、Fusion Middleware Controlを使用して実行できます。
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を構成する手順は次のとおりです。
構成するアイデンティティ・ストアのWLS管理コンソールで必要なオーセンティケータを作成し、ドメインのWeblogic管理サーバーおよび管理対象サーバーを再起動します。または、jps-config.xmlでアイデンティティ・ストア情報を手動で構成することもできます。
アイデンティティ・ストア・サービス・インスタンスをjps-config.xmlで更新し、値がtrueであるvirtualizeプロパティを追加します。これは手動でjps-config.xmlファイルを編集するか、Fusion Middleware Controlを使用して実行できます。
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」はそれぞれ、ユーザー作成ベースとグループ作成ベースです。構成時には実際の値に置き換えてください。
次のOVD WLSTコマンドを実行して、アイデンティティ・ストアの結合アダプタを構成します。$MWHOME/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管理サーバーと管理対象サーバーを再起動します。
単一オーセンティケータを復元するには結合アダプタ・ルールを削除します。これにより、第30.6.2項「アイデンティティ・ストアに部分的なユーザー・プロファイルが含まれる場合のlibOVDの構成」で実行した構成が取り消されます。
結合アダプタ・ルールを削除するには、Weblogic管理サーバーに接続して、次のWLSTコマンドを実行します。
deleteAdapter(adapterName="JoinAdapter1") modifyLDAPAdapter(adapterName="oid auth", attribute="Visible", value="Yes") modifyLDAPAdapter(adapterName="AD", attribute="Visible", value="Yes")
WebLogic管理サーバーと管理対象サーバーを再起動し、両方のアイデンティティ・ストアのユーザーがログインできることを確認します。
この項では、動的ロールをSpaces向けに構成する方法を説明します。
この項の内容は次のとおりです。
静的ロールの場合、メンバーシップ・リレーションシップに対するロールは静的です。このリレーションシップはプロビジョニング時に確立され、確立後にユーザーがログインすると、そのユーザーが直接的なメンバーであるロール、またはエンタープライズ・グループに基づいた間接的なメンバーであるロールがすべてサブジェクトに移入されます。
動的ロールはルールベースのロール・メンバーシップを提供します。アプリケーション・ロールへのメンバーシップは動的グループを介して提供されます。動的グループの定義にはユーザー・プロファイル属性の制約と日時を含めることができます。これによりアプリケーションへの柔軟なアクセスが可能になります。たとえば、移行時やメンテナンス期間中のみに、アプリケーションに対してユーザーがアクセスできるようにすることができます。その際、ユーザーに対して明示的にアクセス権を付与する必要はありません。セッション属性またはリクエスト属性に基づくルールは、このリリースではサポートされていません。
Oracle Entitlement Server (OES) 10gでは、動的ロールを制約付きのロールとして定義できます。OESで定義されるロールは、OVDプラグインを介してユーザーのエンタープライズ・グループ・プリンシパルに追加されます。ユーザーがログインすると、ユーザーのサブジェクトに動的グループ・プリンシパルを格納するかどうかを判断するためにポリシー・ルールが評価されます。図30-7に、OESとOVDプラグインで構成されたトポロジのログイン・プロセスを示します。
図30-8に、OESとOVDプラグインで構成されたトポロジの動的グループ問合せで行われる処理を示します。
OVDプラグインをインストールして構成する前に、Oracle Internet Directory(OID)、Oracle Virtual Directory(OVD) 11gおよびOracle Entitlement Server (OES) 10gをインストールして構成しておく必要があります。現時点で、OVDプラグインはOES 11gでは動作保証されていません。
OIDおよびOVDはOracle Identity Management 11gスイートの一部です。それらをまだインストールしていない場合はインストールします(Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのInstalling and Configuring Oracle Identity Management (11.1.1.6.0)のインストールと構成に関する項を参照してください)。config.shを実行してOVDを構成します(Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOracle Virtual Directory(OVD)の構成に関する項を参照してください)。
RMI-SSMと最新の累積パッチを使用してOES 10gをインストールします(SSMのインストールおよび構成ガイドのリモートSSMとプロキシの構成に関する項を参照)。
また、WebCenter Portalのパーソナライズに基づいて制約を組み込む予定がある場合は、第20章「WebCenter Portalのパーソナライズの管理」の説明に従って、パーソナライズ・サーバーのインストールと構成も行う必要があります。
Oracle Virtual Directory(OVD)はOracle Identity Management製品スイートの一部です。OVDを使用すると、複数の異機種間データ・ソースは、WebCenter PortalのLDAPクライアントから使用可能な1つの統合ビューとして提供されるため、これらのデータ・ソースの統合に関する問題を簡単に解決できます。OVDを経由することにより、Spacesが使用できる方法でOVDカスタム・アダプタを使用して、OESのデータを公開できます。このアダプタは、LDAP以外のデータをLDAPのようなツリー構造で表現できます。カスタム・アダプタの機能は、アダプタにアタッチ可能なプラグインに含まれています。
OVDプラグインをインストールする手順は次のとおりです。
次のフォルダでoes-ovd-plugin.zipファイルを探します。
WC_HOME/modules/oracle.webcenter.framework_11.1.1/oes-ovd-plugin.zip
oes-ovd-plugin.zipファイルのコピーを作成します。
OVDをインストールしたplugins/libディレクトリ(例: asinst_1/OVD/ovd1/plugins/lib)に移動します。
oes-ovd-plugin.zipファイルを解凍します。
webcenterNames.xmlをインスタンス・ホーム(例: <ORACLE_HOME>/asinst_1)にコピーします。
次のディレクトリを作成します。
mkdir pdpproxy mkdir keys
OESの次のjarをOES/rmi-ssmインストール・ディレクトリからlibディレクトリにコピーします。
EccpressoCore.jar antlr.jar api.jar asi_classes.jar asitools.jar commons-pool-1.3.jar connector.jar framework.jar jsafeFIPS.jar jsafeJCEFIPS.jar kodo-runtime.jar log4j.jar managementapi.jar orawsdl14.jar rmi-ssm.jar rmi-stubs.jar rmi-types.jar ssladapter.jar sslplus.jar webservice.jar webserviceclient.jar webservices.jar xbean.jar
作成したkeysディレクトリに移動し、このディレクトリにOESインストール(ales32-shared/keysディレクトリ)のすべてのキーをコピーします。
作成したpdpproxyディレクトリに移動し、PDP構成プロパティ・ファイルをOES (rmi-ssm/pdpproxy/PDPProxyConfiguration.properties)からコピーします。
次のコマンドを使用してOVDプロセスを再起動します。
./opmnctl stopall startall
制約を定義する際にパーソナライズを使用する場合は、次のようにp13nattributeRetrieverをインストールします。
<WebCenter Home>/webcenter/modules/oracle.webcenter.framework_11.1.1/attribute-retriever.jarファイルを見つけます。
OESインストールのrmi-ssm/lib/providersディレクトリを見つけて、そのディレクトリにattribute-retriever.jarファイルをコピーします。
rmi-ssmを再起動します。
この項では、OESおよびOVDプラグインを使用して動的ロールをサポートするようにSpaces環境を構成する方法について説明します。この項の構成手順を実行する前に、前提条件のアプリケーション(第30.7.2項「動的ロールの構成の前提条件」を参照)とOVDプラグイン(第30.7.3項「OVDプラグインのインストール」を参照)をインストールしておく必要があります。
この項の内容は次のとおりです。
Spacesで使用する動的ロールはすべて、単一のアンブレラ・リソースとアクションに定義する必要があります。次の手順では、WebCenterApp/WebCenterResourceをアンブレラ・リソース、browseをアクションとして使用します。動的ロールを作成すると、そのロールにはロール・マッピング・ポリシーによってリソースへの参照権限が付与されます。ロール・マッピング・ポリシーには、アイデンティティ・ストアまたはパーソナライズ属性に基づいて制約を追加することもできます。
動的グループにOESを構成する手順は次のとおりです。
ブラウザを開いて、管理者としてOESコンソールにログオンします。
https://<host>:<port>/asi
「Administration Console」ノードで 「Resources」をクリックすると、現在定義されているリソースのリストが「Resources」ページに表示されます(図30-9を参照)。
リソース・ルートを作成するには、javaapi_appノードを右クリックして「Add Resource」を選択し、「Create Resource」ダイアログを表示します。リソースの名前にWebCenterAppと入力し、「Type」でBindingを選択します(図30-10を参照)。
WebCenterAppを右クリックして、その下にWebCenterResourceという名前の新しいリソースを作成し、「Type」でResourceを選択します(図30-11を参照)。
「Resources」ノードの下で「Privileges」をクリックし、「Privileges」ページを表示します。
「New」をクリックしてbrowseという名前のアクションを作成します(図30-12を参照)。
「Identity」ノードを開き、「Roles」をクリックして「Roles」ページを表示します。
「New」をクリックし、「Create Role」ダイアログを使用して動的ロールを作成します(図30-13を参照)。
「Resources」ノードを開き、「Attributes」をクリックして「Resource Attributes」ページを表示します。
「New」をクリックし、「Create Resource Attribute」ダイアログで、制約で使用されるアイデンティティ・ストア属性と同じ名前のリソース属性(例: business_email、timezone)を作成します(図30-14を参照)。制約でパーソナライズ属性を使用する場合は、それらの属性も作成する必要があります。
「Policy」ノードを開き、「Role Mapping Policies」をクリックして「Role Mapping Policies」ページを表示します。
「New」をクリックして「Create Role Mapping Policy」ダイアログを表示し、アイデンティティ・ストア属性または組込みシステム属性(hour、dayなど)を使用してロール・マッピング・ポリシーと制約を作成します(図30-15を参照)。
「Policy」ノードの下で、「Authorization Policies」をクリックして「Authorization Policies」ページを表示します。
「New」をクリックし、「Create Authorization Policies」ダイアログを使用して新しい認可ポリシーを作成するか、認可ポリシーのサマリーからポリシーを選択して「Edit」をクリックし、ポリシーのリソースやポリシー・サブジェクトなどの詳細を編集および入力します(図30-16を参照)。
「Service Control Managers」の下で「Authorization」ノードを開き、「ASIAuthorizationProvider」をクリックしてから「Attribute Retrievers」タブを開きます(図30-17を参照)。
「Configure a new Custom Attribute Retriever」をクリックし、WebCenterP13nAttributeRetriever (oracle.webcenter.security.internal.plugins.oes.attributeretriever.WebCenterP13nAttributeRetriever)という名前のカスタム属性リトリーバを作成して、図30-18のようにクラスの詳細を追加します。
「Service Control Managers」の下で「Role Mapping」ノードを開き、「ASIRoleMapperProvider」をクリックして「Bindings」タブを開きます。WebCenterAppリソースを認可プロバイダにバインドします(図30-19を参照)。
「Deployment」をクリックし、「Configuration」タブを開いて構成の変更を配布します(図30-20を参照)。
「Policy」タブを開いて、ポリシーの変更を配布します(図30-21を参照)。
この項では、OVDプラグインの構成方法について説明します。
OVDプラグインを構成する手順は次のとおりです。
plugins/lib/pdpproxyディレクトリに移動し、ファイルPDPProxyConfiguration.propertiesを編集して、SSM構成ID、OESホスト名、RMISポートおよびトラスト・ストアの場所を指定します。値の例を次に示します。
SSMConfigID=JK_SM1 PDPTransport=RMI PDPAddress=rmis://example.com:9300 (the use of SSL port is always recommended) TrustStore=<OID_HOME>/asinst_1/OVD/ovd1/plugins/lib/keys/DemoTrust.jks
ファイル./config/OPMN/opmn/opmn.xmlを開いて、次のサンプルに示すように、正しいOVDホームパスを指定してOVDプロセスのjava-optionsとjava-classpathを変更します。
<data id="java-options" value="-server -Xms256m -Xmx256m -Dvde.soTimeoutBackend=0 -Didm.oracle.home=$ORACLE_HOME -Dcommon.components.home=$ORACLE_HOME/../oracle_common -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml -Djavax.net.ssl.trustStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/DemoTrust.jks -Dpdp.configuration.properties.location=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/pdpproxy/PDPProxyConfiguration.properties -Dwles.ssl.identityKeyAlias=wles-admin -Dwles.ssl.identityKeyPasswordAlias=wles-admin -Dwles.ssl.identityKeyStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/identity.jceks -Dwles.ssl.trustedCAKeyStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/trust.jks -Dwles.ssl.passwordFile=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/password.xml -Dwles.ssl.passwordKeyFile=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/password.key"/> <data id="java-classpath" value="$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/jsafeFIPS.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/jsafeJCEFIPS.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/scmapi.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/sslplus.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/ssladapter.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/asitools.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/webserviceclient.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/EccpressoCore.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/webservice.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/kodo-runtime.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/kodo-runtime.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/commons-pool-1.3.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/oes-ovd-plugin.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/xbean.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/antlr.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/log4j.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/api.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/asi_classes.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/framework.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/rmi-types.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/rmi-ssm.jar: $ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
ブラウザでOracle Directory Service Manager (ODSM)を開きます。
http://host:port/odsm
ODSMポートを確認するには、OIDインストールのopmnctl statusコマンドを使用します。デフォルト・ポートは7005です。
LDAP Adapterタイプのアダプタを作成して、LDAPホストおよびポートの詳細を指定します(図30-22のサンプルを参照)。
DNを選択し、DNのマッピング名を指定します。
デフォルト以外の属性にマップする必要がある場合は、アダプタの「Plug-ins」タブを開いてUserManagementアダプタを追加します。たとえば、Active DirectoryをOVDのバックエンド・ディレクトリ・サーバーとして使用する場合は、UserManagementアダプタを追加して、次のパラメータ・マッピングを指定します。
<param name="directoryType" value="ActiveDirectory"/> <param name="mapAttribute" value="orclguid=objectguid"/> <param name="mapAttribute" value="cn=sAMAccountName"/> <param name="mapAttribute" value="uniquemember=member"/> <param name="mapAttribute" value="OESRole=OESRole"/> <param name="mapObjectclass" value="orclGroup=group"/> <param name="mapObjectclass" value="groupofurls=group"/> <param name="mapObjectclass" value="groupofuniquenames=group"/> <param name="mapObjectclass" value="person=user"/> <param name="mapRDNAttribute" value="uniquemember=member"/>
UserManagementアダプタの構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのUserManagementプラグインに関する項を参照してください。
OES10gUserEntitlementsPluginを追加し、次の例に示すように、すべてのプラグイン・パラメータを追加して、ホストおよびポートの詳細をローカル環境のBLMおよびパーソナライズ(p13n)用に置き換えます。
<param name="ldap_group_basedn" value="cn=Groups,dc=us,dc=oracle,dc=com"/> <param name="ldap_user_basedn" value="cn=Users,dc=us,dc=oracle,dc=com"/> <param name="ldap_admin_user" value="cn=Administrator"/> <param name="oes_admin_user" value="admin"/> <param name="OrclOVDEncrypted_oes_admin_pass" value="<password>"/> <param name="oes_config_name" value="JK_SM1"/> <param name="oes_policy_domain" value="JK_SM1"/> <param name="oes_resource_action" value="browse"/> <param name="oes_resource_name" value="WebCenterApp/WebCenterResource"/> <param name="oes_resource_namespace" value="webcenterResource”/> <param name="oes_roles_cache_interval" value="180000"/> <param name="oes_action_namespace" value="webcenterAction"/> <param name="p13n_admin_user" value="weblogic"/> <param name="OrclOVDEncrypted_p13n_admin_pass" value="<password>"/> <param name="oes_blm_host" value="example.com"/> <param name="oes_blm_port" value="7011"/> <param name="oes_p13n_index_url" value="example.com/> <param name="oes_p13n_prop_url" value="example.com"/> <param name="ldap_eqmatch" value="equalityMatch"/> <param name="ldap_loginattr" value="sAMAccountName"/> <param name="ldap_loginattr" value="mail"/> <param name="ldap_loginattr" value="cn"/>
プラグイン・パラメータとして入力されたパスワードは、暗号化されてサーバーに格納されます。
次のコマンドを使用してOVDプロセスを再起動します。
./opmnctl stopall startall
処理を続ける前に、OVDプロセスの再起動時にエラーが発生していないことを確認します。 エラーが発生している場合は、次のエントリを追加すると、プラグインでロギングをオンにできます。
<INSTANCE_HOME>/config/OVD/ovd1/ovd-logging.xmlovd-logging.xml
<logger name='oracle.webcenter.security.internal.plugins.ovd' level='TRACE:1' useParentHandlers='false'>
<handler name='OVDHandler'/>
</logger>
SSL対応のパーソナライズ属性が必要な場合は、パーソナライズ・サーバーの公開鍵を含む証明書をOVDのトラスト・ストアにインポートします。通常、この証明書はJDKのcacertsファイルです。
パーソナライズ属性を制約の一部として使用する場合は、『Oracle Fusion Middleware Oracle WebCenter Portal開発者ガイド』のプロパティ・サービスを使用したネームスペース内のプロパティ・セットの表示の手順に従って属性を構成してください。WebCenter Portalのパーソナライズの詳細は、第20章「WebCenter Portalのパーソナライズの管理」を参照してください。
この項では、OES 10gで定義されている動的ロールをSpacesで使用できるようにするための方法を説明します。
デフォルトでは、アイデンティティ・ストアで定義されている静的エンタープライズ・ロールのみがSpacesに適用されます。OES (Oracle Entitlements Server)内で定義されている動的ロールを使用するには、OVDプラグインをオーセンティケータとして追加する必要があります。その後OVDプラグインによって、アイデンティティ・ストアの静的ロールとOESの動的ロールが統合されます。
Spacesで動的ロールを使用するための構成手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「タイプ」がOracle Virtual Directoryのオーセンティケータを追加して、OVD接続の詳細およびグループ・ベースdnとユーザー・ベースdnを指定します。
残りの設定はデフォルト値のままにします。ディレクトリ固有のマッピングを行うには、そのアダプタでUserManagementプラグインを使用する必要があります。UserManagementアダプタの構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのUserManagementプラグインに関する項を参照してください。
すべてのサーバーを再起動します。
OIDのユーザーとしてSpacesにログオンし、スペースを作成します。
「メンバーの追加」→「グループ」→「検索」に移動し、メンバーとして使用するエンタープライズ・ロールをグループ・スペースに追加します(図30-23を参照)。
OVDをオーセンティケータとして使用する場合は、動的グループ(OES)と静的グループの両方が表示されるはずです。図30-23では、ESTUsers、DayUsersおよびISTUsersが動的グループで、その他はOIDの静的グループです。
動的グループとは、動的に移入される静的グループです。動的グループは、ロールに割り当てて、Spaces内で静的グループと同様に使用できます。
Spacesアプリケーション内では、静的グループと動的グループは区別されません。動的グループはすべて、アイデンティティ・ストアに構成され(構成内容は使用するLDAP実装に固有のものになります)、静的グループと同様に公開されます(事実上、動的グループは、静的なメンバー・リストと、動的に決定されるメンバーシップで構成されています)。
グループの動的メンバーシップを定義するには、グループのlabeledURI属性に適切なLDAP問合せフィルタを設定します。問合せフィルタには、グループのメンバーシップを定義するユーザー・セットが定義されています。
Oracle Internet Directoryで動的グループを作成するには、LDIFファイルとldapaddコマンドを使用するか、またはOracle Directory Services Manager (ODSM)を使用します。これら2つのオプションについて、次の各項で説明します。
LDIFファイルを使用して動的グループを作成する手順は次のとおりです。
テキスト・エディタでLDIFファイルを作成します。次の例では、デフォルトのユーザー検索ベース内で役職が「Manager」のユーザーをすべて表す動的グループを定義する方法を示します。
例30-1 LDIFファイルを使用した動的グループの定義
dn: cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=oracle,dc=comlabeleduri: ldap://myserver.example.com:12061/cn=users,dc=us,dc=mybiz,dc=com??sub?(title=Manager)description: Dynamic Group of Managerscn: Managersorclisvisible: trueobjectclass: orclDynamicGroupobjectclass: orclGroupobjectclass: topobjectclass: groupOfUniqueNamesdisplayname: Managersowner: cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com
|
注意: LDAP URLの 動的グループは、属性または条件に対して定義できますが、LDAP URLとして表現可能かつ |
ファイルを保存してから、ldapaddコマンドを発行してOIDサーバーを更新します。次に例を示します。
例30-2 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
ODSMを使用して動的グループを作成する手順は次のとおりです。
Oracle Directory Services Manager (ODSM)を起動してOracle Internet Directoryサーバーに接続します。
Oracle Directory Services Managerの起動および使用の詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのOracle Directory Services Managerの使用に関する項を参照してください。
「移動先」リストで「データ・ブラウザ」を選択します。
データ・ブラウザで「新規エントリ」アイコンをクリックします。
DNを指定して、オブジェクト・クラスorclDynamicGroupおよびgroupOfUniqueNamesを追加します。
「必須プロパティ」タブで、CN属性を指定します。
「オプション・プロパティ」タブで、labeleduriの属性を指定します。
「OK」をクリックして、動的グループの定義を完了します。
ツリー・ビューをリフレッシュすると、作成した新しいグループが表示されるはずです。ODSMにはグループ・メンバーは表示されません。
この項では、RESTサービス用のアイデンティティ・アサータを構成する方法について説明します。WebCenter PortalアプリケーションでRESTサービス(RESTサービスAPIを含む)を使用する場合は、WebCenterドメインのアイデンティティ・ストアにRESTサービス用のアイデンティティ・アサータを構成する必要があります。次の項では、Oracle WebLogic ServerでOPSSトラスト・サービス・インスタンスとアイデンティティ・アサータを構成する方法について説明します。
この項の内容は次のとおりです。
WebCenter Portalアプリケーションや他のOracle WebLogicアプリケーションでは、それらのアプリケーションで必要な方法でREST APIを使用して情報を表示できますが、そのようなコールは中間層から発信されるため、ユーザーはログイン資格証明を再度入力するよう求められます。これに対処するには、ユーザー・アイデンティティがHTTPヘッダーに伝播され、OPSSトラスト・サービス・アサータによってアサートされるときに境界認証を使用します。
ユーザー・アイデンティティをアプリケーション間で正常に伝幡するには、それらのアプリケーションでトラスト・サービス・インスタンスを正しく構成して使用する必要があります。図30-24に、アイデンティティ伝幡とアサーションに関連する各種コンポーネントを示します。
次に、RESTのアイデンティティ伝幡とアサーションに関連した一連のイベントを示します。
エンド・クライアント(ブラウザ、スマートフォン・アプリケーション)は、WebCenter Portalアプリケーションに接続します。
アプリケーション・ページは、REST APIからデータを問い合せ、それをもとに独自のUIを構築するため、RESTエンド・ポイントをコールする必要があります。
WebCenter Portalアプリケーションは、WebCenter Security API (WCSecurityUtility.issueTrustServiceSecurityToken)をコールして、ユーザー・アイデンティティを安全に伝幡するために使用するトークンを発行します。このトークンはトラスト・サービスの組込みプロバイダを使用して生成されます。生成されたトークンは、トークン・サイズを最適化するために圧縮され、トークンが安全に転送されるようにHTTPヘッダーを使用してBASE64にエンコードされます。
WebCenter Portalアプリケーションは、発行されたトークンを受け取り、「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 + " " + b64tok);
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());
キーストアを作成して構成します。
ドメインのキーストアを作成して、アイデンティティ・アサータ用にWebLogic Serverを構成します。クライアント証明書および秘密鍵用のキーストアがまずプロビジョニングされます。このクライアント証明書はエクスポートされ、トラスト・キーストアにインポートされます。
キーストアを作成します(第35.1.2.1項「WebCenter Portalドメイン・キーストアの作成」を参照)。
キーストアを構成します(第35.1.2.2項「WLSTを使用したキーストアの構成」または第35.1.2.3項「Fusion Middleware Controlを使用したキーストアの構成」を参照)。
jps-config.xml構成ファイルを編集します。
domain_home/config/fmwconfigディレクトリに移動します。
テキスト・エディタでjps-config.xmlファイルを開きます。
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アプリケーションのドメインが異なる場合は、両方のドメインで前述の手順を実行します。
すべてのサーバーを再起動します。
この項では、WebLogic Serverトラスト・サービス・アサータを構成する方法について説明します。
WebLogic Serverトラスト・サービス・アサータを構成する手順は次のとおりです。
WebLogic管理コンソールに管理者としてログインします。
「セキュリティ・レルム」→「myrealm」に移動します。
「プロバイダ」タブを開き、「認証」サブタブを開きます。
「新しい認証プロバイダの作成」ページが表示されます。
新しいアサータの「名前」を入力します(例: TrustServiceIdAsserter)。
アサータの「タイプ」にTrustServiceIdentityAsserterを選択します。
このアサータは、受信リクエストのトークンをデコードおよび検証するためにトラスト・サービスAPIをコールし、アサートされたサブジェクトを確立する際にユーザー名をWebLogicに渡します。
「OK」をクリックして、変更を保存します。
