| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
この章では、Oracle Access Managementコンソールでデータ・ソースを登録および管理する手順について説明します。この情報は、Oracle Access Managementコンソールから使用可能なすべてのサービスに共通します。
この章には次の項が含まれます:
データ・ソースという用語はJava Database Connectivity (JDBC)のもので、Oracle Access Managementにおいてユーザー・アイデンティティ・ストアのコレクションまたはポリシーのデータベースを指すときに使用します。Oracle Access Managementは、通常、エンタープライズにインストールされるデータ・ソースのタイプをいくつかサポートしています。表5-1に示すように、各データ・ソースは様々な情報タイプのストレージ・コンテナです。
表5-1 Oracle Access Managementのデータ・ソース
| データ・ソース | 説明 |
|---|---|
|
データベース |
コンテンツのアクセスや管理、更新が簡単となるように、整理されて格納された情報のコレクション。
|
|
ユーザー・アイデンティティ・ストア |
一元化されたLDAPストレージで、ユーザー指向の集計データが系統だって維持管理されます。(Access Managerにはアイデンティティ・サービスは含まれず、ネイティブのユーザーやグループ、ロール・ストアはありません。)アイデンティティ・ストアは、Access Managerにインストールして登録する必要があります。こうすることで、ユーザーが保護されたリソースにアクセスしようとしたときに認証を可能にします(また、認証時に許可を受けたユーザーのみがリソースにアクセスできるようにします)。初回のデプロイメント・プロセス中(『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照)に、埋込みLDAPストアがユーザー・アイデンティティ・ストアとして使用されます。 変更にはOracle Access ManagementコンソールまたはWebLogic Scripting Tool (WLST)コマンドのみを使用することをお薦めします。oam-config.xmlは編集しないでください。 デフォルトでは、Access Managerは、WebLogic Serverドメインの埋込みLDAPをユーザー・アイデンティティ・ストアとして使用します。ただし、数多くの他の外部LDAPリポジトリをユーザー・アイデンティティ・ストアとして登録することも可能です。この場合、管理者ロールおよびユーザーを含むシステム・ストアとして1つのストアを指定する必要があります。 |
|
Oracle Access Management構成データ・ファイル: oam-config.xml |
初期デプロイメント・プロセス中、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』で説明されているように、Oracle Access Management構成データはXMLファイルoam-config.xmlに格納されます。 「oam-config.xml構成データ・ファイルについて」を参照してください。 |
|
キーストア |
Oracle Access Managementサービスには、「Oracle Access Managementキーストアの概要」で説明しているとおり、複数のキーストアが関連付けられています。
|
表5-2は、Oracle Access Managementサービスと、それぞれに使用されるデータ・ソースの情報へのリンクを示しています。
表5-2 Oracle Access Managementのサービスのデータ・ソース
| サービス | 説明 |
|---|---|
|
Access Manager |
Access Managerでは、複数のアイデンティティ・ストアをサポートし、データ・ソースを使用したSSO認証を提供します。 |
|
アイデンティティ・フェデレーション |
Identity Federationは、アイデンティティ・パートナ単位で割り当てることができる、複数のアイデンティティ・ストアをサポートします。各アイデンティティ・ストアはAccess Managerに登録されている必要があります。アイデンティティ・ストアがアイデンティティ・パートナで定義されていない場合は、指定されたデフォルト・ストアが使用されます。 |
|
セキュリティ・トークン・サービス |
セキュリティ・トークン・サービスでは、ユーザーIDに対して指定されたデフォルト・ストアのみを使用します。 |
|
Mobile and Social |
Mobile and Socialは、ユーザー認証やユーザー・プロファイル・サービス用のディレクトリ・サーバーを指す独自のアイデンティティ・ディレクトリ・サービス構成を提供します。Access Managerおよび他のOracle Access Managementサービスが依存するグローバル・データ・ソースには依存しません。 |
次の各項では、さらに詳細を説明します。
Oracle Access Managementには、Access Manager関連のシステム構成データをすべて含むXMLファイル(oam-config.xml)が用意されています。サーバーおよびエージェントの登録など、Access Managerデプロイメント構成に対して行われたすべての変更は、oam-config.xmlに格納され、各Access Managerサーバーに自動的に伝播されます。各Access Managerサーバーが、最新の構成XMLファイルのローカル・コピーを保持します。高可用性環境でフェイルオーバーが構成されているかどうかに関係なく、すべてのAccess Managerサーバーは常に最新のoam-config.xmlファイルを持ちます。
oam-config.xmlファイルは直接編集しないことをお薦めします。このファイルを手動で変更すると、データが失われたり、データ同期操作中にファイルが上書きされる可能性があります。ただし、oam-config.xmlの編集が必要な場合には、次のガイドラインに従ってください。
$DOMAIN_HOME/config/fmwconfig/にあるoam-config.xmlをバックアップし、使用する場合にはコピーを別の場所に保存します。
AdminServerを実行されているノードで、他のAdminServerユーザーによって発生する可能性がある競合ができるだけ少なくなるように変更を加えます。
Access Managerサーバーが実行されている場合は、ファイルの上部にある構成のバージョン番号に1を加えて変更に関連付けます。さらに、すべてのOAMサーバーにわたる自動伝搬と動的なアクティブ化を有効にします。たとえば、この例の最後から1つ手前の行を参照してください(既存値+1)。
<Setting Name="Version" Type="xsd:integer">
<Setting xmlns="http://www.w3.org/2001/XMLSchema"
Name="NGAMConfiguration" Type="htf:map:>
<Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
<Setting Name="Version" Type="xsd:integer">2</Setting>
</Setting>
デフォルトのLDAPグループAdministratorsは、「Oracle Access Managementコンソール管理者の指定」で説明されているように、Oracle Fusion Middleware構成ウィザードを使用した初回のデプロイメント時に設定されます。
この項では、Oracle Access Managementコンソールを使用してユーザー・アイデンティティ・ストアの登録を管理する上で必要な手順を説明します。
|
注意: アイデンティティ・データ・ストアへのアクセスには、従来のOAM IDストア機能ではなく、アイデンティティ・ディレクトリ・サービス・プロファイルを使用することをお薦めします。OAM IDストア機能は今後のリリースで非推奨になります。アイデンティティ・ディレクトリ・サービスについては、第5.3項「アイデンティティ・ディレクトリ・サービスのユーザー・アイデンティティ・ストアの管理」に記載されています。 |
ユーザー・アイデンティティ・ストアは一元化されたLDAPストアで、管理者およびユーザー指向の集計データが系統だって保持管理されます。Oracle Access Managementでは複数のLDAPベンダーがサポートされており、Oracle Access Managementとそのサービスによる使用のために複数のLDAPストアを登録できます。
Oracle Access Managementでは、アイデンティティ・ドメインとして各ユーザー移入とLDAPディレクトリ・ストアに対応しています。それぞれのアイデンティティ・ドメインは構成済のLDAPユーザー・アイデンティティ・ストアにマップされます。このストアはOracle Access Managementによって登録する必要があります。
Oracle Fusion Middleware構成ウィザードを使用したWebLogic Serverドメインの最初の構成時、組込みLDAPのみがユーザー・アイデンティティ・ストアとして構成されます。組込みLDAP内では、weblogicがデフォルトの管理者としてあらかじめ設定された管理者グループが作成されます。
|
関連項目: Oracle Fusion Middleware Oracle WebLogic Serverの保護 |
|
注意: 組込みLDAPは、ユーザーが10,000人未満のときにパフォーマンスが最も良くなります。ユーザーがこれより多い場合は、別のエンタープライズLDAPサーバーを考慮してください。高可用性構成では、ユーザー・アイデンティティ・ストアとして外部LDAPディレクトリを使用することをお薦めします。 |
ユーザーがAccess Managerに保護されたリソースにアクセスすると、指定したデフォルトのストアのみでなく、任意のストアに対して認証されます。ただし、いくつかの考慮事項があります。
システム・ストア: 1つのユーザー・アイデンティティ・ストアのみをシステム・ストアとして指定できます(さらに必ず指定する必要があります)。これは、Oracle Access Managementコンソール、リモート登録、およびWLSTのカスタム管理コマンドを使用するためにサインインする管理者の認証に使用されます。
リモート登録ユーティリティまたはOracle Access Managementコンソールを使用する管理者には、システム・ストアに保存されている資格証明が必要になります。
リモート・ユーザー・ストアをシステム・ストアとして定義すると、OAMAdminConsoleSchemeを変更して、同じリモート・ユーザー・ストア(システム・ストア)を参照するLDAP認証モジュールを使用する必要があります。
デフォルト・ストア: 名前が示すとおり、デフォルト・ストアとして指定されたLDAPストアは、モジュールまたはプラグインに別のストアの使用を構成しないかぎり、LDAP認証モジュールでの使用に対して自動的に選択されます。
セキュリティ・トークン・サービス: 指定されたデフォルト・ストアのみを使用します。トークン発行ポリシーにユーザー条件を追加するとき、たとえば、ユーザーを選択するアイデンティティ・ストアはデフォルト・ストアである必要があります。
|
注意: Access Managerに保護されたリソースにアクセスするユーザーは、認証スキームで登録および定義された任意のユーザー・アイデンティティ・ストアに対して認証できます。Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。 |
Oracle Access Managementコンソールでは、ユーザー・アイデンティティ・ストアの登録は、「データ・ソース」ノード(「システム構成」タブの「共通構成」セクション)の下にまとめられています。管理者は、Oracle Access Managementコンソールまたは『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』に記載されているカスタムWLSTコマンドを使用して、ユーザー・アイデンティティ・ストアの登録と、登録の表示、変更および削除が可能です。
管理者はOracle Access Managementに複数のユーザー・アイデンティティ・ストアをインストールおよび登録できます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。複数のアイデンティティ・ストアが登録されている場合、管理者は次を定義する必要があります。
システム・ストア: 管理者のログインはシステム・ストアに対してのみ実行する。
デフォルト・ストア: パッチ適用時と、Identity Federationおよびセキュリティ・トークン・サービスの使用時に起動する。
パッチ適用: パッチの適用前に、デフォルト・ストアとしてUserIdentityStore1を指定し、UserIdentityStore1(Weblogic Serverの組込みLDAP)を使用するようにLDAP認証モジュールを更新します。詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementアップグレード・ガイドを参照してください。
Identity Federation: IdPパートナ単位で複数のアイデンティティ・ストアをサポートします。指定したアイデンティティ・ストアは、別のストアと同じように登録する必要があります。アイデンティティ・ストアがIdPパートナで定義されていない場合は、デフォルト・ストアが使用されます。詳細は、「サービス・プロバイダとしてのIdentity Federationの管理」を参照してください。
セキュリティ・トークン・サービス: ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、セキュリティ・トークン・サービスにはLDAPサーバーが必要です。目的のLDAPサーバーが、「デフォルト・ストアおよびシステム・ストアの設定」に記載されているようにOracle Access Managementのデフォルト・アイデンティティ・ストアとして登録および構成されていることを確認します。詳細は、「構成の概要: ユーザー名トークンを使用したアイデンティティ伝播」を参照してください。
各LDAP認証モジュールまたはプラグイン(およびフォームまたは基本認証スキーム)とともに使用する特定のストア
外部LDAPリポジトリは、ユーザー、ロールおよびグループ・メンバーシップ情報を提供できます。たとえば、ユーザーのグループは、ログイン時に計算され、セッションの存続期間内に格納されます。情報は次のように使用されます。
認証中にポリシーを評価する場合
ポリシー内の認可条件に対するアイデンティティを評価する場合
認可ポリシーでの条件のアイデンティティを検索するために、LDAPを使用する場合
|
注意: ユーザーのグループ・メンバーシップ情報を消去し、後日Oracle Access Managementで再計算する方法はありません。 |
OAMでのユーザー・アイデンティティ・ストアの登録は、OAMサーバーとの接続性を提供するために必要です。アイデンティティ・ストアを登録した後、管理者はそれを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。
Oracle Access Managementでは、各ユーザー移入とディレクトリのそれぞれをアイデンティティ・ドメインとして対応可能です。各アイデンティティ・ドメインは、単に構成済アイデンティティ・ストア名にマップします。
最初のOracle Access Manager 11gリリースでは、ユーザーは単純なユーザー名/IDフィールドを使用して内部および外部の両方で識別されました。複数のアイデンティティ・レルムをサポートするには、ユーザーまたはグループのレルム間表現、またはアイデンティティ・ストア内に存在するエンティティが必要です。この表現は、正規識別子と呼ばれますが、Oracle Access Managementの様々なランタイムおよび管理コンポーネントに対する一意の識別子として機能します。
外部表現: アイデンティティ・ドメイン情報とともに単純なユーザー名を修飾します。
たとえば、Oracle Access Managementコンソールでユーザー名をリストする表には、それぞれのユーザーのアイデンティティ・ドメインを表示する列が含まれます。アイデンティティ・ドメインはアイデンティティ・ストア名にマップします。ユーザー情報を表示するすべての機能コンポーネント(コンソール、ポリシー、レスポンス、ロギング、セッション管理、監査など)は、アイデンティティ・ドメイン情報の場合と同様に修飾を開始します。
内部表現: 曖昧性解消をサポートするために、OAMは完全修飾名を格納および使用します(またはコンポジット・キーを形成するために両方のフィールドをそのまま使用します)。
たとえば、セッション管理エンジンはコンポジットを格納する必要をなくすためにこのようにしています。どちらの場合も、完全修飾名は表示されません。
認可ポリシー管理
認可ポリシー管理は、ユーザーまたはグループへの権限付与のオーサリングを許可します。管理者は、特定のユーザーまたはグループを選択し、アクセス権を付与または拒否して、特定のアイデンティティ・ストア内を検索できます。検索結果は、Access Manager認可ポリシーのアイデンティティ条件タイプのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。
ランタイム
認証および認可は、ポリシー・ランタイム・コンポーネントに基づきます。OAMIdentityは、認証されたユーザーおよびそのユーザーがメンバーとなっているグループ(存在する場合)のランタイム表現です。ポリシー評価中、OAMIdentity内の情報は、認可ポリシーのアイデンティティ制約の一部として格納されているものと照合されます。ドメインは、トークン内の名前修飾子としてアサートされます。
OAMプロキシの場合、既存のOAM_REMOTE_USERヘッダーに加えて、2番目のOAM_IDENTITY_DOMAINヘッダーを認証されているユーザーのすべてのリクエストに設定し、必要に応じて使用するアプリケーションがユーザーの曖昧性を解消できるようにします。
セッション
セッション管理検索は、ユーザー・アイデンティティ・ストアについて管理者に通知し、これは検索結果表にリストされます。
監査およびロギング
ユーザーが認証されているユーザー・アイデンティティ・ストアは、監査およびロギング中に考慮されます。
|
関連項目:
|
このトピックでは、「システム構成」タブの下の様々なユーザー・アイデンティティ・ストアの設定について説明します。
図5-1に、「ユーザー・アイデンティティ・ストアの作成」ページを示します。このページには、自分の環境に合せて編集できるストア設定とデフォルト設定の詳細の入力フィールドがあります。「ストア・タイプ」ドロップダウン・リストには、サポートされる選択項目が表示されます。
ページ上のアスタリスク(*)は必須の設定です。表5-3は、タイプ別の各要素を示します。
表5-3 ユーザー・アイデンティティ・ストアの要素
| 要素 | 説明 |
|---|---|
|
ストア名 |
この登録の一意の名称。名称は最大30文字までを使用できます。 |
|
ストア・タイプ |
サポートされているすべてのLDAPプロバイダのリスト。ここから選択できます。「複数のアイデンティティ・ストアの使用」で説明されているとおり、複数のアイデンティティ・ストアを使用できます。 
|
|
説明 |
オプション。 |
|
SSLの有効化 |
このボックスをクリックして選択すると、ディレクトリ・サーバーとOAMサーバーの間でSSLが有効であることを示します。 |
|
場所と資格証明 |
説明 |
|
ロケーション |
パート番号を含むLDAPホストのURL。Oracle Access Management 11gは、フェイルオーバー機能で複数のLDAP URLをサポートします。IDアサーション・プロバイダは、LDAP URLが表示される順序に基づいて次のLDAP URLにフェイルオーバーします。 1つの(または複数の)LDAP URLを localhost:myhost:7001 注: サポートされるURLの文字数は、ブラウザのバージョンに基づきます。Oracle Access Managementおよびブラウザが処理できる長さを超えたURLを、アプリケーションで使用しないようにしてください。 |
|
バインドDN |
接続プールのユーザーDNで、これを介して他のすべてのBINDが発生します。ユーザーおよびグループ・ベースのDNには、適切な読取りおよび検索の権限を持つ管理者以外のユーザーをお薦めします。 例: uid=amldapuser,ou=people,o=org |
|
パスワード |
プリンシパルのパスワードで、セキュリティのために暗号化されます。 |
|
ユーザーとグループ |
説明 |
|
ユーザー名属性 |
ユーザー名を識別する属性。 例: uid |
|
ユーザー検索ベース |
ディレクトリ情報ツリー(DIT)のノード。この下にユーザー・データが格納され、すべてのユーザー・データ検索の最も高いベースとなります。 例: ou=people,ou=myrealm,dc=base_domain |
|
ユーザー・フィルタのオブジェクト・クラス |
ユーザー・オブジェクト・クラス名のカンマ区切りリストで、ユーザーの検索結果に含めるオブジェクト・クラス。たとえば、 |
|
グループ名属性 |
グループ名を識別する属性。 デフォルト: cn |
|
グループ検索ベース |
現在は ディレクトリ情報ツリー(DIT)のノード。この下にグループ・データが格納され、すべてのグループ・データ検索の最も高いベースとなります。 例: ou=groups,ou=myrealm,dc=base_domain |
|
グループ・フィルタ・クラス |
グループ・オブジェクト・クラスのカンマ区切りリストで、グループの検索結果に含めるオブジェクト・クラス。例: groups、groupOfNamesなど。 |
|
グループ・キャッシュの有効化(サイズ) |
グループ・キャッシュのブーリアン値: trueまたはfalse デフォルト: true |
|
グループ・キャッシュ・サイズ |
グループ・キャッシュ・サイズの整数 デフォルト: 10000 |
|
グループ・キャッシュTTL(秒) |
グループ・キャッシュ要素、存続時間の整数(秒)。 デフォルト: 0 |
|
接続の詳細 |
説明 |
|
最小プール・サイズ |
接続プールに設定される最小サイズ。 デフォルト: 10 |
|
最大プール・サイズ |
接続プールに設定される最大サイズ。 デフォルト: 50 |
|
待機タイムアウト |
完全に利用されているプールで、接続リクエストがタイムアウトするまでの時間(秒)。 デフォルト: 120 |
|
非アクティブのタイムアウト |
完全に利用されているプールのイベントで、接続リクエストがタイムアウトするまで非アクティブになることができる時間(秒)。 |
|
結果タイム・リミット(秒) |
接続プールでのLDAPの検索およびバインド操作のタイム・リミット(秒)。 デフォルト: 0 |
|
再試行回数 |
接続の失敗があったときに、接続を再試行する回数。 デフォルト: 3 |
|
参照ポリシー |
次の値のいずれかです:
|
図5-2に、デフォルトとシステム・ストアの指定内容を示します。「アクセス・システム管理者」セクションを参照してください。定義済のシステム・ストアおよびストア自体内のみで、管理者ロールを追加または削除できます。
有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、Oracle Access Managementコンソールにより新しいユーザー・アイデンティティ・ストアを登録できます。
アイデンティティ・ストアを登録した後、それを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。また、認可ポリシーのアイデンティティ条件内にある特定のアイデンティティ・ストアを参照することもできます。
前提条件
Oracle Access Managementに登録しようとしているユーザー・アイデンティティ・ストアをインストールします。
Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドの説明に従って、Access ManagerのLDAPディレクトリ・スキーマを拡張します。
ベンダーのドキュメントの説明に従って、LDAPディレクトリにユーザーとグループを作成します。
新しいユーザー・アイデンティティ・ストアの定義を登録する手順
Oracle Access Managementコンソールの「起動パッド」で、「ユーザー・アイデンティティ・ストア」をクリックします。
「作成」をクリックします。
デプロイメントに適した値をフォームに入力し(表5-3)、「適用」をクリックして登録を送信します。
接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。
登録ページを閉じます。
管理者の追加: 「管理者ロールの管理」を参照してください。
ナビゲーション・ツリーで、登録ページを開くストア名をダブルクリックします。
「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。
「システム管理者ロールの追加」ダイアログ・ボックス(...)に入力します。
「適用」をクリックします。
デフォルト・ストアの設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。
「適用」をクリックして登録を送信してから、ページを閉じます。
次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。
有効なOracle Access Management管理者の資格証明を持つユーザーは、ユーザー・アイデンティティ・ストアの登録を表示または変更できます。
前提条件
登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。
ユーザー・アイデンティティ・ストアの閲覧または変更の手順
Oracle Access Managementコンソールの「起動パッド」で、「ユーザー・アイデンティティ・ストア」をクリックします。
目的の「ユーザー・アイデンティティ・ストア」登録ページをクリックして開きます。
必要に応じて値を変更します(表5-3を参照)。
「適用」をクリックして、登録を更新します(または変更を適用しないでページを閉じます)。
接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。
システム・ストアまたはデフォルト・ストアとして設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。
管理者ロールの管理: 「管理者ロールの管理」を参照してください。
次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。
終了する際はページを閉じます。
有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、Oracle Access Managementコンソールによりユーザー・アイデンティティ・ストアの登録を削除できます。
|
注意: デフォルト・ストアまたはシステム・ストアの登録は削除できません。 |
セカンダリ・ユーザー・アイデンティティ・ストア登録の削除の手順
削除するストアを参照しているLDAP認証モジュールを編集します(有効なアイデンティティ・ストアがモジュール内で参照されているか確認するため)。
Oracle Access Managementコンソールの「起動パッド」で、「ユーザー・アイデンティティ・ストア」をクリックします。
目的の「ユーザー・アイデンティティ・ストア」登録ページをクリックして開き、削除するストアであることを確認し(さらにデフォルトでないことを確認してから)、ページを閉じます。
希望するインスタンス名をクリックしてから、ツール・バーで「削除」ボタンをクリックします。
「確認」ウィンドウで「削除」ボタンをクリックします(または「取消」をクリックしてウィンドウを閉じ、インスタンスを保持します)。
定義がナビゲーション・ツリーにないことを確認します。
アイデンティティ・ディレクトリ・サービス(IDS)は、Access Managerが複数のアイデンティティ・データ・ストアにアクセスするために使用する柔軟で構成可能なサービスです。IDSの目的は、Access Manager自体とともにデプロイされていないアイデンティティ・ストアのユーザーまたはグループを管理できるようにすることです。次の各項で、詳細を説明します。
アイデンティティ・ディレクトリ・サービスでは、冗長な構成を排除し、アイデンティティ管理操作を簡素化する、アイデンティティ・ストア・アクセスのための一貫性のある合理化されたテクノロジを提供します。IDSには次のような利点があります。
ディレクトリにより管理されるネイティブのユーザー/パスワードの状態との統合など、様々なユーザー・ディレクトリ・タイプのサポート。
Oracle Identity Managementコンポーネント間で一貫した管理ユーザー・インタフェースおよび様々なアイデンティティ・ストアを使用するためのパラダイム。
組込みのフェイルオーバーおよびロード・バランシング機能。
論理属性から物理属性へのマッピングとエンティティ関係。
次に、サポートされているディレクトリ・サーバーのリストを示します。
Microsoft Active Directory
Novell eDirectory
Oracle Directory Server Enterprise Edition
Oracle Internet Directory
Oracle Unified Directory
Oracle Virtual Directory
OpenLDAP
IBM Tivoli Directory Server
WebLogic Server Embedded LDAP
|
注意: アイデンティティ・データ・ストアへのアクセスには、従来のOAM IDストア機能ではなく、アイデンティティ・ディレクトリ・サービス・プロファイルを使用することをお薦めします。OAM IDストア機能は今後のリリースで非推奨になります。 |
図5-3は、アイデンティティ・ディレクトリ・サービス・コンソールのページのスクリーン・キャプチャです。
|
注意: このページには、従来のOAM IDストアの構成パネルが含まれていることに注意してください。アイデンティティ・データ・ストアへのアクセスには、従来のOAM IDストア機能ではなく、アイデンティティ・ディレクトリ・サービス・プロファイルを使用することをお薦めします。OAM IDストア機能は今後のリリースで非推奨になります。 |
アイデンティティ・ディレクトリ・サービス・ストアの構成には、IDSプロファイルおよびIDSリポジトリのパラメータの構成が含まれます。IDSプロファイルでは、特定のタイプのアイデンティティ・ストアの全範囲の特性を指定します。これはリポジトリの論理構成で、次のデータが含まれます。
エンティティ定義
エンティティ関係定義
デフォルトの操作構成(テナントの検索/作成ベース、テナント・フィルタ、タイムアウトおよびキャッシュ構成を含む)
IDSリポジトリ構成は、実際のストアの場所を定義します。IDSリポジトリは、次のデータを含む物理構成です。
接続の詳細(ホスト・マシン、ポート番号および資格証明を含む) 接続プールの詳細 高可用性/フェイルオーバー構成 エンティティ属性マッピング
Identity Directory Serviceプロファイルを作成するには、次のようにします。
「起動パッド」で、「ユーザー・アイデンティティ・ストア」をクリックします。
「IDSプロファイル」の下の「作成」をクリックします。
図5-4に示すように、「IDSプロファイルの作成」ページが表示されます。
新しいIdentity Directory Serviceプロファイルの次の値を指定します。
名前: このユーザー・プロファイル・サービス・プロバイダに一意の名前を入力します。
説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。
「新規作成」または「既存のものを使用」を選択して、リポジトリのプロパティを構成します。
「新規作成」では、アイデンティティ・ディレクトリ・サービス接続の新しいリポジトリ・オブジェクト(つまり、LDAPディレクトリ・サーバーの参照)を定義します。「リポジトリ」セクションで値を定義した後に、「接続テスト」をクリックして、定義した値に間違いがないことを確認します。このオプションは、新しいアイデンティティ・ディレクトリ・サービス接続を定義している場合にのみ使用可能です。「既存のものを使用」を使用すると、以前に定義したリポジトリ・オブジェクトをドロップダウン・メニューから選択できるようになります。
(リポジトリの)「名前」: 新しい一意の名前を入力するか(作成する場合)、メニューから既存のものを選択します。新しい名前を入力した後には、アイデンティティ・ディレクトリ・サービス接続のプロパティを構成します。
ディレクトリ・タイプ: Microsoft Active DirectoryやOracle Internet Directoryなど、リポジトリをホストするディレクトリ・サーバー・ソフトウェアのタイプを選択します。ディレクトリがリストされない場合は、このフィールドを空白のままにします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。
ホスト情報: アイデンティティ・ディレクトリ・サービス・リポジトリが配置されているホスト・コンピュータに関する情報を格納します。ディレクトリ・サーバーがクラスタの一部である場合は、複数のホストを追加します。新しいホストを表に追加するには、「追加」をクリックします。「ホスト名」列に、IPアドレスまたはディレクトリ・サーバーが実行されているコンピュータ(または仮想コンピュータ)の名前を入力します。「ポート」列に、ディレクトリ・サーバーが使用するように構成されているポート番号を入力します。ホストがクラスタの一部である場合は、負荷分散列に、各ホストにダイレクトされる負荷の量をパーセントとして入力します。複数のホストの場合、量の合計が100%になる必要があります。ホストを削除するには、表でその行を選択し、「削除」をクリックします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。
可用性 - クラスタがフェイルオーバー操作用に構成されている場合はフェイルオーバーを選択し、クラスタが複数のホストに負荷を分散している場合はロード・バランスを選択します。既存のリポジトリを使用している場合、このフィールドは読取り専用です。
SSL - 接続がSSL用に構成されている場合は、「有効」を選択します。(SSL構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。)
バインドDN - ディレクトリ・サーバーから認証を受けるために使用するLDAP管理者の識別名(DN)を入力します。
バインド・パスワード - ディレクトリ・サーバーから認証を受けるために使用するバインドDNパスワードを入力します。
ベースDN - ユーザーおよびグループのデータが配置されているベース識別名(DN)を入力します。
ユーザーのプロパティを構成して、Mobile and Socialのユーザー・プロファイル・サービスのLDAPユーザー・オブジェクトを構成します。
|
注意: 既存のアイデンティティ・ディレクトリ・サービス接続を使用している場合、これらのフィールドは読取り専用です。 |
オブジェクト・クラス: ディレクトリ・サーバーで定義されている組織内の人々を表すカスタム・オブジェクト・クラスを追加するには、「追加」をクリックします。
RDN属性: ディレクトリ・サーバー上のユーザー・オブジェクトに対して指定されている相対識別名属性(cnなど)を入力します。
ベースDN: ディレクトリ・サーバー上のユーザー・オブジェクトのベースDNを(LDAP形式で)入力します。
ログインID属性: ユーザーを指定するログインIDの抽出元になるLDAP属性を入力します。
グループのプロパティを構成して、Mobile and Socialのユーザー・プロファイル・サービスのLDAPグループ・オブジェクトを構成します。
オブジェクト・クラス - ディレクトリ・サーバーで定義されている組織内の人々のグループを表すカスタム・オブジェクト・クラスを追加するには、「追加」をクリックします。
RDN属性: ディレクトリ・サーバー上のグループ・オブジェクトに対して指定されている相対識別名属性(cnなど)を入力します。
ベースDN: ディレクトリ・サーバー上のグループ・オブジェクトのベースDNを(LDAP形式で)入力します。
ID属性: グループ・オブジェクトに対して指定されているIDの抽出元になるLDAP属性を入力します。
「作成」をクリックします。
プロファイルが、「IDSプロファイル」リストに表示されます。
IDSプロファイルを編集または削除するには、表で名前を選択してから、ツールバーにある「編集」または「削除」をクリックします。プロファイルを編集することにより、アイデンティティ・ディレクトリ・サービス接続の追加構成プロパティが可能になります。
名前 - ドロップダウン・メニューから、ユーザー・プロファイル・サービス・プロバイダと関連付けるアイデンティティ・ディレクトリ・サービス接続を選択します。
デフォルトのアイデンティティ・ディレクトリ・サービスのいずれか(userroleまたはidxuserroleのいずれか)を選択すると、構成値の表示や編集はできなくなります。
管理者が作成したアイデンティティ・ディレクトリ・サービス接続を選択すると、構成値を必要に応じて表示および編集できるようになります。
一般およびリポジトリ - このタブのフィールドを使用して、Mobile and Socialがディレクトリ・サービスに接続するために使用するディレクトリ・サービスおよびリポジトリ構成値を編集します。
リポジトリ名 - このメニューから、アイデンティティ・ディレクトリ・サービス接続と関連付けるリポジトリを選択します。リポジトリを選択したら、次のフォームのフィールドを使用してそのプロパティを構成します。
ディレクトリ・タイプ - Microsoft Active Directory、Oracle Internet Directoryなど、リポジトリをホストするディレクトリ・サーバー・ソフトウェアのタイプを表示します。このフィールドは読取り専用です。
ホスト情報 - アイデンティティ・ディレクトリ・サービス・リポジトリが配置されているホスト・コンピュータに関する情報を表示します。ディレクトリ・サーバーがクラスタの一部である場合は、複数のホストを追加します。新しいホストを表に追加するには、「追加」をクリックします。「ホスト名」列に、IPアドレスまたはディレクトリ・サーバーが実行されているコンピュータ(または仮想コンピュータ)の名前を入力します。「ポート」列に、ディレクトリ・サーバーが使用するように構成されているポート番号を入力します。ホストがクラスタの一部である場合は、負荷分散列に、各ホストにダイレクトされる負荷の量をパーセントとして入力します。複数のホストの場合、量の合計が100%になる必要があります。ホストを削除するには、表でその行を選択し、「削除」をクリックします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。
可用性 - クラスタがフェイルオーバー操作用に構成されている場合はフェイルオーバーを選択し、クラスタが複数のホストに負荷を分散している場合はロード・バランスを選択します。既存のリポジトリを使用している場合、このフィールドは読取り専用です。
SSL - 接続がSSL用に構成されている場合は、「有効」を選択します。それ以外の場合は、オプション・ボックスをクリアにします。
バインドDN - ディレクトリ・サーバーから認証を受けるために使用するLDAP管理者の識別名(DN)を入力します。
バインド・パスワード - ディレクトリ・サーバーから認証を受けるために使用するバインドDNパスワードを入力します。
ベースDN - ユーザーおよびグループのデータが配置されているベース識別名(DN)を入力します。
エンティティ属性 - このタブのフィールドを使用して、企業ディレクトリ・サービスのスキーマをナビゲートするためにMobile and Socialで使用される属性を表示または編集します。「追加」をクリックして表に属性を追加するか、「削除」をクリックして属性を削除します。
名前 - 属性名。
物理属性 - 基盤となるリポジトリの対応する物理属性タイプの名前。
タイプ - 属性のデータ・タイプ。
説明 - 属性の簡単な説明。
機密 - 属性にパスワードなどの機密情報が含まれていることを示す場合に選択します。
読取り専用 - 変更されないように属性を保護する場合に選択します。
エンティティ/ユーザー・プロパティ - 「ユーザー」副項目のフィールドを使用して、Mobile and SocialがLDAPサーバー上のユーザー・エンティティと相互作用する方法を構成します。
ベースの作成 - ユーザーを定義するベースDN (LDAPディレクトリ・ツリーの最上位レベル)を指定します。
検索ベース - ユーザーの検索ベースDNを指定します。検索操作が処理されるときは、検索ベースDNにあるかそれより下のエントリのみが対象になります。
オブジェクト・クラスの作成 - 個人に関連付けられている属性が格納されているオブジェクト・クラスを指定します。
RDN属性 - 相対識別名属性を指定します。たとえば、cnです。
ID属性 - ユーザーを一意に識別する属性を指定します。uid属性やloginid属性などです。
フィルタ・オブジェクト・クラス - フィルタ条件にするオブジェクト・クラスを指定します。
属性構成 - ユーザー・プロファイル・サービス・プロバイダによる使用と検索を可能にするユーザーの属性を指定します。
使用中 - 属性が、ディレクトリ・サービスでユーザーに対して使用されている場合に指定します。
属性名 - 「エンティティ属性」タブで定義した属性の名前を指定します。
結果内 - 指定した属性を、検索結果で返す必要がある場合に選択します。
検索可能 - 指定した属性を検索操作に対して使用可能にする場合に選択します。
検索演算子 - 指定した属性の検索方法を制限するには、このメニューから検索演算子を選択します。
操作構成 - ユーザー・エンティティ・レベルで有効にする操作を「作成」、「更新」、「削除」、および「検索」から選択します。これらを無効にするには、オプション・ボックスの選択を解除します。
エンティティ/グループのプロパティ - 「グループ」副項目のフィールドを使用して、Mobile and SocialがLDAPサーバー上のグループ・エンティティと相互作用する方法を構成します。
ベースの作成 - ユーザーを定義するベースDN (LDAPディレクトリ・ツリーの最上位レベル)を指定します。
検索ベース - グループの検索ベースDNを指定します。検索操作が処理されるときは、検索ベースDNにあるかそれより下のエントリのみが対象になります。
オブジェクト・クラスの作成 - グループに関連付けられている属性が格納されているオブジェクト・クラスを指定します。
RDN属性 - 相対識別名属性を指定します。たとえば、cnです。
ID属性 - グループを一意に識別するLDAP属性を指定します。
フィルタ・オブジェクト・クラス - フィルタ条件にするオブジェクト・クラスを指定します。
属性構成 - ユーザー・プロファイル・サービス・プロバイダによる使用と検索を可能にするグループ属性を指定します。
使用中 - 属性が、ディレクトリ・サービスでユーザーに対して使用されている場合に指定します。
属性名 - 「エンティティ属性」タブで定義した属性の名前を指定します。
結果内 - 指定した属性を、検索結果で返す必要がある場合に選択します。
検索可能 - 指定した属性を検索操作に対して使用可能にする場合に選択します。
検索演算子 - 指定した属性の検索方法を制限するには、このメニューから検索演算子を選択します。
操作構成 - グループ・エンティティ・レベルで有効にする操作を「作成」、「更新」、「削除」、および「検索」から選択します。これらを無効にするには、オプション・ボックスの選択を解除します。
関係 - このタブのフィールドを使用して、このアイデンティティ・ディレクトリ・サービスの属性間の関係を構成します。
名前 - 関係の名前。
エンティティ(から) - 「ユーザー」を選択してユーザー属性から選択するか、「グループ」を選択して、属性(から)列のグループ属性から選択します。
属性(から) - マッピング元にする属性を選択します。
リレーション - 「開始」列で指定した属性と「終了」列で指定した属性間の関係を説明するメニューオプションを選択します。
エンティティ(に) - 「ユーザー」を選択してユーザー属性から選択するか、「グループ」を選択して、属性(に)列のグループ属性から選択します。
属性(に) - マッピング先にする属性を選択します。
再帰的 - 関係をディレクトリ・ツリーの下方向に拡張してネストされた子エンティティを含めるか、ディレクトリ・ツリーを上方向に拡張して親エンティティを含める場合に選択します。
関係構成 - アイデンティティ・ディレクトリ・サービスの対応する列にアクセスするために使用するURIセグメントを入力します。新しい関係を追加するには「追加」を、構成済の関係を削除するには「削除」を使用します。
アクセスURI - アイデンティティ・ディレクトリ・サービスの対応するデータ列にアクセスするために使用するURIセグメントを入力します。たとえば、memberOfがアクセスURIである場合は、
http://host:port/.../idX/memberOf
が、ID idXを持つエンティティの関連エンティティにアクセスするためのURIです。
アイデンティティ・ディレクトリ・サービスの関係 - 「アクセスURI」セグメントによってアクセスされるディレクトリ・サービス関係を選択します。アイデンティティ・ディレクトリ・サービスが、事前構成済UserProfileアイデンティティ・プロバイダではない場合、「アイデンティティ・ディレクトリ・サービス」構成セクションの「関係」タブで関係を構成できます。(UserProfileサービス・プロバイダに対してはアイデンティティ・ディレクトリ・サービス関係を構成できません。)
エンティティURI属性 - Mobile and Socialサーバーから送信されるURIレスポンスで使用されるJSON属性名を入力します。たとえば、指定されているエンティティURI属性がperson-uriである場合、URIレスポンスは次のようになります。
{ {"person-uri":uriY1, ...}, {"person-uri":uriY2, ...}, ... }
ここで、uriY1およびuriY2は、関連エンティティのそれぞれにアクセスするための直接URIです。
再帰型をリクエストするスコープ - 関係検索で、ネストされたレベルの属性を取得するには、スコープ属性値をスコープ問合せパラメータとともに使用します。再帰的に関連エンティティにアクセスするには、使用する値を入力します。Mobile and Socialのデフォルト構成では、toTopとallの2つのスコープ属性値が使用されます。「再帰型をリクエストするスコープ」の値が属性値allである場合、次のREST URIの例が使用されてリクエストが実行されます。
http://host:port/.../idX/reports?scope=all
この例では、URIによって、ID idXを持つエンティティに関連するエンティティが、それに続いて関連しているエンティティすべてとともに返されます。
フォーム入力アプリケーションのアイデンティティ・ディレクトリ・サービス・プロファイルを作成するには、「ユーザー・アイデンティティ・ストア」コンソール・ページの左側にある「フォーム入力アプリケーションIDSプロファイルの作成」ボタンをクリックします。(図5-3を参照。)
第5.3.2項「Identity Directory Serviceプロファイルの作成」および第5.3.3項「アイデンティティ・ディレクトリ・サービス・プロファイルの編集または削除」には、ほとんどのフォーム入力属性の定義が示されています。このタイプのプロファイルに固有の「エンティティ検索ベース」セクションの追加定義を次に示します。
ユーザー検索ベース: エンタープライズ・ユーザーが格納されるディレクトリ内のノードのフルDN (cn=Users,realm_DNなど)。
アプリケーション・テンプレート検索ベース: アプリケーション・テンプレートの検索が開始されるノードのフルDN。
上位検索ベース: 検索が開始されるノードのフルDN (cn=realm_DNなど)。
Mobile and Socialでは、UserIdentityStore1という事前構成済のIDSプロファイルが提供されます。このプロファイルにより、Mobile and Socialを使用するディレクトリ・オブジェクトに対して、参照タスクと更新タスクを実行できるようになります。
アイデンティティ・ディレクトリ・サービス・リポジトリを作成するには、次のようにします。
「起動パッド」で、「ユーザー・アイデンティティ・ストア」をクリックします。
「IDSリポジトリ」の下の「作成」をクリックします。
図5-5に示すように、「IDSリポジトリの作成」ページが表示されます。
新しいアイデンティティ・ディレクトリ・サービス・リポジトリに対して次の値を指定します。
名前: 一意の値を入力する必要があります。
ドロップダウンの選択肢から「ディレクトリ・タイプ」を選択します。
「追加」をクリックして、リポジトリの物理的な場所を構成します(ホスト名、ポート番号およびロードの重みのパーセンテージ)。
可用性 - 「フェイルオーバー」またはロード・バランスを選択
SSL - 有効化する場合は選択
バインドDN
バインド・パスワード
ベースDN
「接続のテスト」をクリックして、値が正しいことを確認します。
「作成」をクリックします。
プロファイルが、「IDSプロファイル」リストに表示されます。
有効なOracle Access Management管理者の資格証明を持つユーザーは、ユーザー・アイデンティティ・ストアの登録をデフォルト・ストアまたはシステム・ストアのいずれかとして指定できます。デフォルト・ストアは、セキュリティ・トークン・サービスおよびパッチ適用時の移行に必要です。管理者のロールと資格証明は、システム・ストアに存在している必要があります。ドロップダウン・メニューから適切なストアを定義できます。UserIdentityStore1は、埋込みのLDAPストアです。
|
注意: システム・ストアを変更すると、アイデンティティ管理ドメイン全体に影響を与えます。たとえば管理者ログインは、OAMAdminConsoleSchemeにより使用されるLDAP認証モジュールがシステム・ストアも使用する場合にのみ機能します。別のストアをリモート・ストアとして設定する場合、ロックアウトを避けるためにOAMAdminConsoleSchemeも変更してください。 |
「起動パッド」の「ユーザー・アイデンティティ・ストア」リンクから、デフォルトおよびシステム・アイデンティティ・ストア構成を変更できます。図5-6は、「ユーザー・アイデンティティ・ストア」ページのスクリーン・キャプチャです。
WebSphereインストールでサポートされているIDストアの構成方法は、『Oracle Fusion Middleware Oracle Identity and Access Managementサードパーティ・アプリケーション・サーバー・ガイド』に記載されています。ストア構成に関する追加情報は、次の各項を参照してください。
この項では次のトピックを記載しています:
管理者ログインは、認証スキーム(および割り当てられた認証モジュール)がIAMSuiteAgentによって使用されており、そのシステム・ストアも使用する場合にのみ機能します。
デフォルトでは、Oracle Access Managementの管理者ロールは、WebLogic管理者ロール(Administrators)と同じです。他のユーザー・アイデンティティ・ストア(たとえばOracle Internet Directory)を登録することもできますが、ただし、認証先の登録済ストアの少なくとも1人のユーザーを使用してユーザーweblogicを定義する必要があります。
企業によっては、Access Managerを担当するユーザーとSecurity Token Serviceを担当するユーザーに別の管理者グループが必要になることがあります。すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。アイデンティティ・ストア登録の編集時にストアをシステム・ストアとして指定すると、図5-7に示すように「アクセス・システム管理者」セクションがページ上に開きます。
ユーザー・アイデンティティ・ストア登録を追加または編集するときに、新しい管理者ロールを追加できます。図5-8は、使用するページとコントロールを示しています。
次の手順では、システム・ストアとして指定したユーザー・アイデンティティ・ストアに格納する必要があるOracle Access Management管理者ロールの定義または削除方法を説明します。まず、管理者が使用できるように目的のLDAPグループを定義してから、管理者グループがグループ検索ベースで使用可能なことを確認します。
前提条件
システム・ストアの管理者ロールを追加または削除する手順
システム・ストア登録の表示: 次の手順を実行します(またはシステム・ストアとして指定する、「データ・ソース」ノード内の異なるシステム・ストアを検索します)。
Oracle Access Managementコンソールの「起動パッド」で、「管理」をクリックします。
登録したシステム・ストアは、このページからは変更できません。
システム・ストアを検索して構成済の管理者を見つけます。
ユーザー・ロールの追加:
「アクセス・システム管理者」表の上にある「付与」(+)ボタンをクリックして、「ユーザーとグループの追加」ダイアログ・ボックスを表示します。
「タイプ」リストの「ユーザー」を選択し、「検索」ボタンをクリックします。
結果リスト内で目的のユーザーをクリックし、「選択済の追加」ボタンをクリックします。
必要に応じて繰り返し、目的の管理者ユーザー・ロールを追加します。
「適用」をクリックしてユーザー・ロールを送信します。
グループ・ロールの追加:
「アクセス・システム管理者」表の上にある「付与」(+)ボタンをクリックして、「ユーザーとグループの追加」ダイアログ・ボックスを表示します。
「タイプ」リストの「グループ」を選択し、「検索」ボタンをクリックします。
結果リスト内で目的のグループをクリックし、「選択済の追加」ボタンをクリックします。
必要に応じて繰り返し、目的の管理者グループ・ロールを追加します。
「適用」をクリックしてグループ・ロールを送信します。
管理者ロールの削除:
「アクセス・システム管理者」表で、削除するユーザーまたはグループを含む行をクリックします。
表の上にある「削除」(x)ボタンをクリックします。
確認するメッセージが表示されたら確認します。
「適用」をクリックして削除を送信します。
システム・ストアを使用する認証プラグインを修正します(新しいストアの場合)。
この手順は、「プラグイン・ベースのモジュールによるマルチステップ認証の編成」を参照してください。
新しいロールのテスト: ブラウザのウィンドウを閉じてから、再び開きます。
Oracle Access Managementコンソールからサインアウトしてブラウザ・ウィンドウを閉じます。
Oracle Access Managementコンソールを起動して、以前の管理者ロールを使用してログインを試み、これが失敗することを確認します。
新しい管理者ロールを使用してログインし、この試みが成功することを確認します。
ログイン失敗: 「管理者のロックアウト」を参照してください。
この項には次のトピックが含まれます:
Oracle Access Managementには、Access Managerのポリシー・データ、パスワード管理データおよびAccess Managerセッションを本番環境で保存するデータベースが必要です。
|
注意: 最大でも、デプロイメントに含まれるのは、1つのポリシー・ストア・データベース(パスワード管理の役割を果たす)と、1つのセッション・ストアです。デフォルトでは、単一のJDBCデータ・ストアが両方に使用されます。 |
デフォルトでは、次のデータはポリシー・ストア・データベースで維持されます。
認証モジュール、スキーム、アプリケーション・ドメインおよびポリシーを含むポリシー・データ。
構成済のユーザー・アイデンティティ・ストアごとのパスワード・ポリシー・タイプ、およびパスワードの要件、失効、通知を制御するポリシーを含んだパスワード管理データ。
分散されたメモリー内のストレージに対する永続的なバックアップとしてのセッション・データ。
|
注意: 本番環境での監査データ・ストレージの推奨モードは、スタンドアロンの監査データ専用RDBMSデータベースに監査レコードを書き込むことです。これは、個別に構成された監査ストアを使用して行います。ポリシー・ストアは監査データには使用されません。 |
Oracleには、本番環境のポリシー・ストアとして1つのデータベースが必要です。この単一のデータベースは、セッション・データを保存するためにも使用できます。データベースをセッション・ストアとして使用すると、スケーラビリティおよびフォールトトレランス性が増します(すべてのサーバーをダウンさせる電源イベントに対して)。
|
注意: データベースは最大2つまで、1つのポリシー・データベースと1つのセッション・データベースを使用できます。Access Managerは、実際のバックエンド・リポジトリには非依存であり、このポリシー・ストアの構成を直接的に管理することはありません。 |
ポリシー・データベースは、ベンダーの指示に従ってインストールする必要があります。ポリシー・データベースはOracle WebLogic Serverドメインで使用するように構成します。この構成には、Oracle Fusion Middleware構成ウィザードと、ポリシー・ストアのデータベース構成テンプレートを使用します。
WebLogic構成ウィザードを使用した初回のデプロイメント中に、次のデータベース詳細が要求されます。
データベース・ログインIDとパスワード
データベース・サービス名と場所
管理者は、RCUを使用するAccess Manager固有のスキーマでデータベースを拡張する必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。基本的なスキーマの作成は、RCUが起動されたときに発生します。RCUは、データベースがAccess Managerポリシー、パスワード管理およびセッション・データを受け入れるように準備します。
WebLogic構成ウィザードを使用すると、データベースへの接続を登録およびテストできます。
実際のAccess Managerポリシー要素は、Oracle Access Managementコンソールがデプロイされて初めてWebLogic AdminServerが起動されたときに作成されます。
|
関連項目: Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド |
Access ManagerにはoamDSというデータ・ソースが含まれており、これはAccess Managerスキーマで拡張されたデータベース・インスタンスに対して構成されます。あらかじめ定義された次のJava Naming and Directory Interface (JNDI)名が、データ・ソースを参照するためにOAMサーバーにより使用されます。
jdbc/oamds (used by both the policy layer and session layer to access database)
次の手順を使用して、WebLogic管理コンソールを使用して個別のセッション・データのデータベース・インスタンスを作成できます。Oracle Access Managementコンソールでは、この処理はサポートされていません。
|
注意: このまれなケースについては、手順2fの説明に従ってoam-config.xmlを慎重に編集することをお薦めします。 |
セッション・データ用に独立したデータベースを作成、使用する手順
セッション・データのデータベースをインストールおよび構成して、RCUをAccess Manager固有のスキーマとともに使用し、セッション・データ・ストアとしてデータベースを設定します。
セッション・データに新しいデータ・ソース・インスタンスを作成します。
WebLogic管理コンソールからは、「ドメイン構造」パネルでドメイン名、「サービス」ノードを展開します。
JDBC、データ・ソースを展開します。
JNDI名jdbc/oamsessionというデータ・ソースを作成します。
変更を保存します。
次の手順でのデータ損失を防ぐために、OAMサーバーとAdminServerを停止します。
oam-config.xmlで、DataSourceName属性の値を編集して、手順1で構成したものにします。例:
domain-home/config/fmwconfig/oam-config.xml
変更前:
<Setting Name="SmeDb" Type="htf:map">
<Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
com:2001/AM</Setting>
<Setting Name="Principal" Type="xsd:string">amuser</Setting>
<Setting Name="Password" Type="xsd:string">password</Setting>
<Setting Name="DataSourceName" Type="xsd:string">jdbc/oamds</Setting>
</Setting>
変更後:
<Setting Name="SmeDb" Type="htf:map">
<Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
com:2001/AM</Setting>
<Setting Name="Principal" Type="xsd:string">amuser</Setting>
<Setting Name="Password" Type="xsd:string">password</Setting>
<Setting Name="DataSourceName" Type="xsd:string">jdbc/oamsession</Setting>
</Setting>
AdminServerとOAMサーバーを再起動します。
この項では次のトピックを記載しています:
キーストアは、Access Managerのインストール時に作成および構成されます。パスワードおよびキー・エントリのパスワードはランダムに生成されます。
推奨のキーストア・フォーマットはJKS (Javaキーストア)です。Javaキーストアは水面下でAccess Managerに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成される暗号化セキュリティ・キーの格納に使用されます。
すべてのOAMエージェントおよびOSSOエージェントは、他のエージェントが読み取ることができない秘密鍵を持っています。
Oracle Coherenceベースのセッション・トラフィックを暗号化するキーがあります。
エージェントとアプリケーションの登録時に、SSO Cookie (Webgateおよびmod_ossoの場合)の暗号化および復号化に使用されるキーが生成されます。
管理者は、付録Cで説明されているように、Oracleが提供するimportcertツールをキーストア、キーおよび証明書に関連した様々な手順で使用します。
WLSTのresetKeystorePasswordメソッドを使用すると、.oamkeystoreパスワードおよび.oamkeystoreパスワードと同じパスワードが設定されたキー・エントリに新しい値を設定できます。『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
表5-4に、生成されるAccess Manager暗号化キーを示します。
表5-4 Access Managerキーと格納
| キーと格納 | 説明 |
|---|---|
|
Access Manager暗号化キー |
|
|
キーの格納 |
|
キーストアには、Oracle Access Managementコンソールからアクセスできません。キーストアと証明書は、付録C「通信の保護」で説明されているように管理できます。
|
関連項目: 「Identity Federationキーストアについて」
|
表5-5に、Access Managerに対して使用されるキーストアのサマリーを示します。
表5-5 Access Managerとセキュリティ・トークン・サービスのキーストア
| キーストア | 説明 |
|---|---|
|
システム・キーストア/パートナ・キーストア .oamkeystore |
OAM Serverインスタンスに関連付けられた鍵および証明書のコンテナ(署名および暗号化のためのOAM秘密鍵とセキュリティ・トークン・サービス秘密鍵)。 パートナ、クライアントおよびエージェントとの信頼性を確立するために使用されるキーおよび証明書のコンテナ。パートナ・キーおよび証明書は、機密情報が暗号化されて.oamkeystoreに格納されます。 JCEKSタイプのシステム・キーストア.oamkeystoreのみが存在することが可能です。 $ 証明書の別名とパスワードは、Oracle Access Managementコンソールを使用して構成できます。 関連項目: |
|
信頼キーストア amtrustkeystore |
信頼キーストアは、OAMサーバー・インスタンスと相互作用するエンティティに信頼性を確立するためにクライアントにより提供されるキーおよび証明書の検証に使用されます。 $ amtruststoreはインストール時に作成され、少なくとも1つの信頼できるアンカーを含める必要があります。 信頼キーストアは、JREのkeytoolアプリケーションを使用して管理されます。セキュリティ・トークン・サービスではカスタム信頼キーストアを使用できます。 関連項目: |
|
証明書失効リスト(CRL) amcrl.jar |
証明書失効情報リストは、ファイルシステム上のZIPアーカイブに格納されます。これらは、CRLベースの証明書失効確認の実行中に、OAMサーバーによって使用されます。 amcrl.jarには、DER形式のCRLファイルが含まれます。
OAM Serverでは、キーストアおよびCRL Zipファイルの通知リスナーが定義されます。これらのファイルを変更すると、セキュリティ・トークン・サービスでは、再起動しなくてもキーストア/crl-zipが実行時にリロードされます。 amcrl.jarは、インストールにより作成され、Oracle Access Managementコンソールを使用して変更できます。 関連項目: |
|
Oracle WSMエージェント・キーストア default-keystore.jks |
Oracle WSMエージェントは、様々な暗号化操作のためにこのキーストアを使用します。これらの操作では、Oracle WSMエージェントはOracle WSMタスク用に構成されたキーストアを使用します。 Oracle WSMエージェント・キーストアとAccess ManagerおよびSecurity Token Serviceのキーストアは常に異なるものにすることをお薦めします。そのようにしないと、キーはOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Access Manager/Security Token Serviceがアクセスされる可能性があります。 関連項目: 「Oracle Web Services Managerのキーストア(default-keystore.jks)について」 |
|
OPSSキーストア |
(Webサービス・リクエストの一部として受信される証明書トークンとは対照的に)クライアントがSKIなどの参照スキームを使用する特別な場合、リクエスタの証明書をOPSSキーストアに移入する必要があります。 これは、キーをOPSSキーストアに手動でプロビジョニングする必要がある、一般的ではないシナリオです。 関連項目:
|
|
.cohstore.jks |
これは、Coherenceノード間のSSL通信の暗号化に使用されるSSLキーと証明書の格納に使用されます。Coherence通信の保護については、Oracle Coherenceセキュリティ・ガイドを参照してください。 |
Identity FederationとAccess Managerは、デジタル署名と暗号化に使用するキー・ペアと証明書を格納します。Identity Federationは、次のことを実行する際にキーを使用します。
送信アサーションの署名
SAMLメッセージに含まれる着信XML暗号化データの復号化
次のキーストアは、暗号化証明書と署名証明書の格納に使用されます。
$DOMAIN_HOME/config/fmwconfig/.oamkeystore
Identity Federationは、CSFを使用してキーストア・パスワードと、サーバーの資格証明(HTTP Basic認証のユーザー名とパスワードなど)を安全に格納します。
この項では、インストール後に、Oracle Access Managerとともに使用する目的で、集中管理されたLDAPストアを有効にする方法について説明します。ここでは、Oracle Internet Directoryに重点を置いて説明します。ただし、選択したLDAPプロバイダによってタスクが異なることはありません。
Oracle Access Managerでは、アイデンティティ・ドメインとして各ユーザー移入とLDAPディレクトリ・ストアに対応しています。それぞれのアイデンティティ・ドメインは構成済のLDAPユーザー・アイデンティティ・ストアにマップされます。このストアはOracle Access Managerに登録されます。複数のLDAPストアは、異なるサポート対象LDAPプロバイダに依存するそれぞれとともに使用できます。
WebLogic Serverドメインの最初の構成時、組込みLDAPのみがOracle Access Managerのユーザー・アイデンティティ・ストアとして構成されます。組込みLDAP内では、weblogicがデフォルトの管理者としてあらかじめ設定された管理者グループが作成されます。
システム・ストアとして指定されたユーザー・アイデンティティ・ストアのみが、Oracle Access Managementコンソール、リモート登録、およびWLSTのカスタム管理コマンドを使用するためにサインインする管理者の認証に使用されます。
OAMに保護されたリソースにアクセスしようとするユーザーは、デフォルトのユーザー・アイデンティティ・ストアとして指定されたストアのみでなく、任意のストアに対して認証できます。
Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。トークン発行ポリシーにユーザーの制約を追加するとき、たとえば、ユーザーを選択するアイデンティティ・ストアはデフォルトのユーザー・アイデンティティ・ストアである必要があります。
ユーザー・アイデンティティ・ストアをAccess Managerに登録した後、管理者は1つ以上の認証モジュールでそのストアを参照できます。これらのモジュールは、Oracle Access Managerの認証スキームおよびポリシーの基盤となります。パートナを(Oracle Access Managementコンソールまたはリモート登録ツールを使用して)登録する場合、指定されたデフォルトの認証スキームを使用するポリシーを使用して、アプリケーション・ドメインを作成し、シードできます。ユーザーがOracle Access Managerによって保護されたリソースにアクセスすると、そのユーザーは、認証モジュールによって指定されたストアに対して認証されます。
詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』を参照してください。
