| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
前 |
次 |
この章では、Oracle Access Managementコンソールでデータ・ソースを登録および管理する手順について説明します。この章には次のトピックが含まれます。
|
注意: 特に明記しないかぎり、この章の情報は、Oracle Access Managerを単体で使用している場合もOracle Security Token Serviceとともに使用している場合も同じです。 |
次のトピックに記載されているように、Oracle Access Manager with Oracle Security Token Serviceでは様々なタイプのデータを管理する必要があります。
ユーザー・アイデンティティ・ストアは一元化されたLDAPストアで、管理者およびユーザー指向の集計データが系統だって維持管理されます。
システム・ストアとして指定されたユーザー・アイデンティティ・ストアのみが、Oracle Access Managerコンソール、リモート登録、およびWLSTのカスタム管理コマンドを使用するためにサインインする管理者の認証に使用されます。
OAMに保護されたリソースにアクセスしようとするユーザーは、デフォルトのユーザー・アイデンティティ・ストアとしてマークされたストアのみでなく、任意のストアに対して認証できます。
Oracle Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。トークン発行ポリシーにユーザーの制約を追加するとき、たとえば、ユーザーを選択するアイデンティティ・ストアはデフォルトのユーザー・アイデンティティ・ストアである必要があります。
|
注意: Oracle Access Managerコンソールを使用する管理者は、システム・ストアに存在する必要があります。OAMに保護されたリソースにアクセスしようとするユーザーは、指定されたデフォルトのストアのみでなく、任意のストアに対して認証できます。Oracle Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。 |
リモート・ユーザー・ストアをシステム・ストアとして定義すると、OAMAdminConsoleSchemeを変更して、同じリモート・ユーザー・ストア(システム・ストア)を参照するLDAP認証モジュールを使用する必要があります。
Oracle Access Managerコンソールでは、ユーザー・アイデンティティ・ストアの登録は、「データソース」ノード(「システム構成」タブの「共通構成」セクション)の下にまとめられています。管理者は、Oracle Access ManagerコンソールまたはOAM 11gのカスタムWLSTコマンドを使用して、ユーザー・アイデンティティ・ストア登録の登録、表示、変更および削除が可能です。
Oracle Fusion Middleware構成ウィザードを使用した初回のWebLogic Serverドメイン構成時に、埋込みLDAPが唯一のユーザー・アイデンティティ・ストアとして構成されます。
|
注意: 埋込みLDAPは、ユーザーが10,000人未満のときにパフォーマンスが最も良くなります。ユーザーがこれより多い場合は、別のエンタープライズLDAPサーバーを考慮してください。 |
埋込みLDAP内では、"weblogic"がデフォルトの管理者としてあらかじめ設定された管理者グループが作成されます。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』 部品番号 |
管理者は、Oracle Access Manager with Oracle Security Token Serviceのユーザー・アイデンティティ・ストアを複数インストールできます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。ただし、管理者ログインはシステム・アイデンティティ・ストアに対してのみ発生します。複数のアイデンティティ・ストアが登録されている場合、管理者は次を定義する必要があります。
管理ログインのシステム・ストア
移行中およびOracle Security Token Serviceの使用中に関与するデフォルトのユーザー・ストア
外部LDAPリポジトリは、次の場合に使用するユーザー、ロールおよびグループ・メンバーシップ情報を提供できます。
認証中にポリシーを評価する場合
ポリシー内の認可制約に対するアイデンティティを評価する場合
認可ポリシーごとの制約のアイデンティティを検索するために、LDAPを使用する場合
Oracle Access Managerでのユーザー・アイデンティティ・ストアの登録は、OAMサーバーとの接続を提供するために必要です。アイデンティティ・ストアを登録した後、管理者はそれを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。
Oracle Access Managerは、各ユーザー移入およびアイデンティティ・ドメインとしてディレクトリに対処します。各アイデンティティ・ドメインは、単に構成済アイデンティティ・ストア名にマップします。
元のOracle Access Manager 11gリリースでは、ユーザーは単純なユーザー名/IDフィールドを使用して内部および外部の両方で識別されました。複数のアイデンティティ・レルムをサポートするには、ユーザーまたはグループのレルム間表現、またはアイデンティティ・ストア内に存在するエンティティが必要です。この表現は、正規識別子と呼ばれますが、Oracle Access Managerの様々なランタイムおよび管理コンポーネントに対する一意の識別子として機能します。
外部表現: アイデンティティ・ドメイン情報とともに単純なユーザー名を修飾します。
たとえば、Oracle Access Managerコンソールでユーザー名をリストする表には、それぞれのユーザーのアイデンティティ・ドメインを表示する列が含まれます。アイデンティティ・ドメインはアイデンティティ・ストア名にマップします。ユーザー情報を表示するすべての機能コンポーネント(コンソール、ポリシー、レスポンス、ロギング、セッション管理、監査など)は、アイデンティティ・ドメイン情報の場合と同様に修飾を開始します。
内部表現: 曖昧性解消をサポートするために、OAMは完全修飾名を格納および使用します(またはコンポジット・キーを形成するために両方のフィールドをそのまま使用します)。
たとえば、セッション管理エンジンはコンポジットを格納する必要をなくすためにこのようにしています。どちらの場合も、完全修飾名は表示されません。
認可ポリシー管理
認可ポリシー管理は、ユーザーまたはグループへの権限付与のオーサリングを許可します。管理者は、特定のユーザーまたはグループを選択し、アクセス権を付与または拒否して、特定のアイデンティティ・ストア内を検索できます。検索結果は、Oracle Access Manager認可ポリシーのアイデンティティ制約コンポーネントのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。
ランタイム
認証および認可は、ポリシー・ランタイム・コンポーネントに基づきます。OAMIdentityは、認証されたユーザーおよびそのユーザーがメンバーとなっているグループ(存在する場合)のランタイム表現です。ポリシー評価中、OAMIdentity内の情報は、認可ポリシーのアイデンティティ制約の一部として格納されているものと照合されます。ドメインは、トークン内の名前修飾子としてアサートされます。
OAMプロキシの場合、既存のOAM_REMOTE_USERヘッダーに加えて、2番目のOAM_IDENTITY_DOMAINヘッダーを認証されているユーザーのすべてのリクエストに設定し、必要に応じて使用するアプリケーションがユーザーの曖昧性を解消できるようにします。
セッション
セッション管理検索は、ユーザー・アイデンティティ・ストアについて管理者に通知し、これは検索結果表にリストされます。
監査およびロギング
ユーザーが認証されているユーザー・アイデンティティ・ストアは、監査およびロギング中に考慮されます。
OAM 11gでは、OAMポリシー・データおよび(オプションで)OAMユーザー・セッション・データを格納するためにデータベースを必要とします。
ポリシー・データベースは、ベンダーの指示に従ってインストールし、RCUを使用してOAM固有のスキーマで拡張する必要があります(『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください)。Oracle Access Managerをデータベース・ポリシー・ストアの構成テンプレートとともに実行すると、OAM 11gポリシーとセッション・データを格納するデータベースが自動的に準備されます。
データベースは、Oracle WebLogic Serverドメインでの初回の構成時に、Oracle Fusion Middleware構成ウィザードを使用してOracle Access Manager 11gに対して指定されます。
|
注意: OAM 11gデプロイメントは、最大で1つのポリシーと1つのセッション・ストアを持つことができます。デフォルトでは、単一のJDBCデータ・ストアが両方に使用されます。 |
次のデータが管理されます。
認証モジュール、スキーム、アプリケーション・ドメイン、認証および認可ポリシーを含むポリシー・データ。
分散されたメモリー内のストレージに対する永続的なバックアップとしてのセッション・データ
管理者はOAM固有のスキーマでデータベースを拡張する必要があります。
|
注意: 本番環境での監査データ・ストレージの推奨モードは、スタンドアロンの監査データ専用RDBMSデータベースに監査レコードを書き込むことです。これは、個別に構成された監査ストアを使用して行います。ポリシー・ストアは監査データには使用されません。 |
Oracle Access Managerには、OAM関連のシステム構成データをすべて含むXMLファイル(oam-config.xml)が用意されています。各OAMサーバーには、最新の構成XMLファイルのローカル・コピーが1つあります。
サーバーとエージェントの登録を含むOracle Access Managerデプロイメント構成に加えられたすべての変更は、oam-config.xmlファイルに格納されて、自動的に各OAMサーバーに伝播されます。
|
注意: oam-config.xmlファイルは編集しないでください。変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。 |
高可用性環境でフェイルオーバーが構成されているかどうかに関係なく、すべてのOAMサーバーには常に最新のoam-config.xmlファイルがあります。
推奨のキーストア・フォーマットはJKS(Javaキーストア)です。Javaキーストアは水面下でOracle Access Manager 11gに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成される暗号化セキュリティ・キーの格納に使用されます。次に例を示します。
それぞれのOracle Access ManagerおよびOSSOエージェントは、他のエージェントが読むことのできない秘密鍵を持っています。
Oracle Coherenceベースのセッション管理トラフィックを暗号化するキーがあります。
エージェントとパートナ(アプリケーション)の登録時に、SSO Cookie(Webgateおよびmod_osso cookieの場合はObSSOCookie)の暗号化および復号化に使用されるキーが生成されます。
表5-1は、Oracle Access Manager 11g、10gおよびOSSO 10gによって生成された暗号化キーの比較と、それぞれの格納場所を簡単に説明しています。
表5-1 Oracle Access Manager 11g、10gおよびOSSOのキーの比較
| OAM 11g | OAM 10g | OSSO 10g | |
|---|---|---|---|
|
暗号化キー |
|
すべてのOAM Webgateに対してグローバルで共有される秘密鍵が1つ |
|
|
キー・ストレージ |
|
ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可) |
|
|
注意: キーストアはコンソールからは使用できず、表示や管理、変更はできません。 |
Oracle Access Manager with Oracle Security Token Serviceのいくつかのタイプのキーストアを簡単に要約したものを次に示します。
OAMサーバー・インスタンスに関連付けられたキーおよび証明書のシステム・キーストア
OAMサーバー・インスタンスと相互作用するエンティティに信頼性を確立するために使用されるキーおよび証明書の信頼キーストア
パートナ、クライアントおよびエージェントとの信頼性を確立するために使用されるキーおよび証明書のパートナ・キーストア。パートナ・キーおよび証明書は、機密情報が暗号化されて.oamkeystoreに格納されます。
証明書失効リスト(CRL)は、CRLベースの証明書失効確認の実行中に、Oracle Access Manager/Oracle Security Token Serviceサーバー・インスタンスによって使用されます。
次のファイルは、JMXフレームワークによってドメイン内のすべての管理対象サーバー間で配布されます。
システム・キーストア: .oamkeystore
信頼キーストア: amtruststore
パートナ・キーストア: .oamkeystore
CRL: amcrl.jar
Oracle WSMエージェント・キーストア: Oracle WSMエージェントの機能は、WSポリシーの公開と、インバウンドおよびアウトバウンドWSメッセージにおけるメッセージ保護の施行のためにOracle Security Token Serviceで使用できます。Oracle WSMでは、システムおよびパートナ・キーおよび証明書用に、JKSタイプの別のキーストアが必要です。デフォルト名はdefault-keystore.jksであり、jps-config.xmlで指定されます。
|
注意: Oracle WSMエージェント・キーストアとOAM/OSTSキーストアを常に別にしておくことをお薦めします。そのようにしないと、キーはOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Oracle Access Managerキーがアクセスされる可能性があります。 |
この項では、OAM 11g管理コンソールを使用してユーザー・アイデンティティ・ストアの登録を管理する上で必要な手順を説明します。
このトピックでは、「システム構成」タブの下の様々なユーザー・アイデンティティ・ストアの設定について説明します。
図5-1に、完了した登録のページを示します。「ユーザー・アイデンティティ・ストアの作成」ページも同様ですが、デフォルトの「接続の詳細」値以外は空です。「ストア・タイプ」ドロップダウン・リストには、サポートされる選択項目が表示されます。
ページ上のアスタリスク(*)は必須の設定です。表5-2は、タイプ別の各要素を示します。
表5-2 ユーザー・アイデンティティ・ストアの要素
| 要素 | 説明 |
|---|---|
|
ストア名 |
この登録の一意の名称。名称は最大30文字までを使用できます。 |
|
ストア・タイプ |
サポートされているすべてのLDAPプロバイダのリスト。ここから選択できます。  |
|
説明 |
オプション。 |
|
SSLの有効化 |
このボックスをクリックして選択すると、ディレクトリ・サーバーとOAMサーバーの間でSSLが有効であることを示します。 |
|
場所と資格証明 |
|
|
ロケーション |
パート番号を含むLDAPホストのURL。Oracle Access Manager 11gは、フェイルオーバー機能で複数のLDAP URLをサポートします。アイデンティティ・アサーション・プロバイダは、LDAP URLが表示される順序に基づいて次のLDAP URLにフェイルオーバーします。 「ロケーション」フィールドにURL値を指定している場合、ldap://またはldaps://(SSL_NO_AUTHをサポート)を指定する必要はありません。たとえば、次のように入力します。 localhost:7001 注意: サポートされるURLの文字数は、ブラウザのバージョンに基づきます。Oracle Access Managerおよびブラウザが処理できる長さを超えたURLを、アプリケーションで使用しないようにしてください。 |
|
バインドDN |
接続プールのユーザーDNで、これを介して他のすべてのBINDが発生します。ユーザーおよびグループ・ベースのDNには、適切な読み取りおよび検索の権限を持つ管理者以外のユーザーをお薦めします。 例: uid=amldapuser,ou=people,o=org |
|
パスワード |
プリンシパルのパスワードで、セキュリティのために暗号化されます。 |
|
ユーザーとグループ |
|
|
ユーザー名属性 |
ユーザー名を識別する属性。 例: uid |
|
ユーザー検索ベース |
ディレクトリ情報ツリー(DIT)のノード。この下にユーザー・データが格納され、すべてのユーザー・データ検索の最も高いベースとなります。 例: ou=people,ou=myrealm,dc=base_domain |
|
ユーザー・フィルタのオブジェクト・クラス |
ユーザー・オブジェクト・クラス名のカンマ区切りリストで、ユーザーの検索結果に含めるオブジェクト・クラス。例: userやperson |
|
グループ名属性 |
グループ名を識別する属性。 デフォルト: 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に、システム・ストアの完了した登録ページを表示されるとおりに示します。「アクセス・システム管理者」ロールがリストされています。定義済のシステム・ストアおよびストア自体内のみで、管理者ロールを追加または削除できます。
有効な管理者の資格証明を持つユーザーは、この手順を利用して、管理者コンソールにより新しいユーザー・アイデンティティ・ストアを登録できます。
アイデンティティ・ストアを登録した後、それを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。アクセス・ポリシーの認可制約でも参照できます。
前提条件
登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。
新しいユーザー・アイデンティティ・ストアの定義を登録する手順
「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。
「ユーザー・アイデンティティ・ストア」をクリックし、ツール・バーの「作成」コマンド・ボタンをクリックします。
デプロイメントに適した値をフォームに入力し(表5-2)、「適用」をクリックして登録を送信します。
接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。
登録ページを閉じて、次の作業を実行します。
管理者の追加: 「管理者ロールの管理」を参照してください。
ナビゲーション・ツリーで、登録ページを開くストア名をダブルクリックします。
「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。
「システム管理者ロールの追加」ダイアログ・ボックス(...)に入力します。
「適用」をクリックします。
デフォルト・ストアの設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。
「適用」をクリックして登録を送信してから、ページを閉じます。
このストアを使用するには、1つまたは複数の認証モジュールを構成します。詳細は「認証モジュール」にあります。
有効な管理者の資格証明を持つユーザーは、ユーザー・アイデンティティ・ストアの登録を表示または変更できます。
前提条件
登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。
ユーザー・アイデンティティ・ストアの閲覧または変更の手順
「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。
「ユーザー・アイデンティティ・ストア」ノードを展開します。
希望するユーザー・アイデンティティ・ストアの登録名をダブルクリックします。
必要に応じて値を変更します(表5-2を参照)。
「適用」をクリックして、登録を更新します(または変更を適用しないでページを閉じます)。
接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。
デフォルト・ストアとして設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。
管理者ロールの管理: 「管理者ロールの管理」を参照してください。
完了したらページを閉じます。
有効な管理者の資格証明を持つユーザーは、この手順を利用して、管理者コンソールによりユーザー・アイデンティティ・ストアの登録を削除できます。
|
注意: デフォルト・ユーザー・アイデンティティ・ストアまたはシステム・ストアの登録は削除できません。 |
セカンダリ・ユーザー・アイデンティティ・ストア登録の削除の手順
削除するストアを参照しているLDAP認証モジュールを編集します(有効なアイデンティティ・ストアがモジュール内で参照されているか確認するため)。
「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。
「ユーザー・アイデンティティ・ストア」ノードを展開します。
オプション: 目的のインスタンス名をダブルクリックして、削除する対象である(およびデフォルトでない)ことを確認してから、ページを閉じます。
希望するインスタンス名をクリックしてから、ツール・バーで「削除」ボタンをクリックします。
「確認」ウィンドウで「削除」ボタンをクリックします(または「取消」をクリックしてウィンドウを閉じ、インスタンスを保持します)。
定義がナビゲーション・ツリーにないことを確認します。
この項には、次の項目が含まれます。
アイデンティティ・ストア登録の後、新規ストアをデフォルト・ストアまたはシステム・ストア(あるいはその両方)として指定できます。
デフォルト・ストア: Oracle Security Token Serviceによって使用され、パッチ適用時には移行目的で使用されます。
システム・ストア: アイデンティティ管理ドメイン全体のアクセス・システム管理者ロールのグループ/ユーザーが含まれ、これに対してOAMAdminConsoleSchemeポイントによってLDAP認証モジュールが使用されます。
|
注意: 管理者ログインは、OAMAdminConsoleSchemeによって使用されるLDAP認証モジュールもそのシステム・ストアを使用する場合のみ機能します。システム・ストアを変更すると、アイデンティティ管理ドメイン全体に影響を与えます。別のストアをリモート・ストアとして設定する場合、ロックアウトを避けるためにOAMAdminConsoleSchemeも変更してください。 |
図5-4は、新しいユーザー・アイデンティティ・ストア登録を追加した直後に表示されるデフォルト・ストアおよびシステム・ストアのオプションを示します。
図5-4は、デフォルト・ストアを表示したときの登録ページを示します。
システム・ストアの指定を適用するとすぐに、アクセス・システム管理者ロールを追加するように要求されます(「管理者ロールの管理」を参照してください)。また、OAMAdminConsoleSchemeによって使用されるLDAPモジュールがシステム・ストアを参照するようにする必要もあります。
図5-5に示されているように、「共通設定」ページから「デフォルトおよびシステム・アイデンティティ・ストア」にアクセスすることもできます。
管理者の資格証明を持つユーザーは、次の手順を使用してデフォルト・ストアおよびシステム・ストアの指定を定義または変更できます。
デフォルト・ストアおよびシステム・ストアを定義する手順
Oracle Access Managerコンソールから、次を開きます。
システム・ストアの設定: このストアに管理者ロールおよび証明書が存在する必要があります。
システム・ストアにするストア名をダブルクリックし、登録ページを開きます。
「システム・ストアとして設定」の横にあるボックスを選択します(ドメイン全体の認証および認可操作用)。
「適用」をクリックして指定を送信します。
管理者の追加: 「管理者ロールの管理」を参照してください。
認証モジュール: OAMAdminConsoleScheme (認証スキーム)によって使用されるLDAP認証モジュールがシステム・ストアを使用するように設定します。「認証モジュールの管理」を参照してください。
デフォルト・ストアの設定: このストアは、パッチ適用時の移行目的にのみ使用します。
デフォルト・ストアにするストア名をダブルクリックし、登録ページを開きます。
「デフォルト・ストアとして設定」の横にあるボックスを選択し、このLDAPストアを設定します(移行用)。
認証モジュール: OAMAdminConsoleSchemeのLDAPモジュールがこのストアを参照しないことを確認します。「認証モジュールの管理」を参照してください。
登録ページを閉じて、次の作業を実行します。
ここでは、次の内容について説明します。
管理者ログインは、認証スキーム(および割り当てられた認証モジュール)がIAMSuiteAgentによって使用されており、そのシステム・ストアも使用する場合にのみ機能します。
デフォルトでは、Oracle Access Manager with Oracle Security Token Serviceの管理者ロールは、WebLogic管理者ロール(Administrators)と同じです。ただし、企業によっては、Oracle Access Managerを担当するユーザーとOracle Security Token Serviceを担当するユーザーに別の管理者グループが必要になることがあります。
すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。アイデンティティ・ストア登録の編集時にストアをシステム・ストアとして指定すると、図5-6に示すように「アクセス・システム管理者」セクションがページ上に開きます。
ユーザー・アイデンティティ・ストア登録を追加または編集するときに、新しい管理者ロールを追加できます。図5-7 システム管理者ロールの追加に、使用するページおよびコントロールを示します。
次の手順では、システム・ストアとして指定したユーザー・アイデンティティ・ストアに格納する必要がある管理者ロールの定義または削除方法を説明します。
前提条件
システム・ストアの管理者ロールを追加または削除する手順
OAMの指定されたシステムLDAPストアで次のようにします。
管理者に使用する目的のLDAPグループを定義します。
管理者グループが、グループ検索ベースで使用可能なことを確認します。
システム・ストア登録の検索: 次の手順を実行します(またはシステム・ストアとして指定する、「データソース」ノード内の異なるシステム・ストアを検索します)。
Oracle Access Managerコンソールの「ようこそ」ページから、「構成」パネルの「共通設定」をクリックします。
「デフォルトおよびシステム・アイデンティティ・ストア」セクションを必要に応じてスクロールおよび展開します。
システム・ストアの名前をクリックし、構成ページを表示します。
ユーザー・ロールの追加:
「アクセス・システム管理者」表の上にある「追加」(+)ボタンをクリックして、「システム管理者ロールの追加」ダイアログ・ボックスを表示します。
「タイプ」リストの「ユーザー」を選択し、「検索」ボタンをクリックします。
結果リスト内で目的のユーザーをクリックし、「選択済の追加」ボタンをクリックします。
必要に応じて繰り返し、目的の管理者ユーザー・ロールを追加します。
「適用」をクリックしてユーザー・ロールを送信します。
グループ・ロールの追加:
「アクセス・システム管理者」表の上にある「追加」(+)ボタンをクリックして、「システム管理者ロールの追加」ダイアログ・ボックスを表示します。
「タイプ」リストの「グループ」を選択し、「検索」ボタンをクリックします。
結果リスト内で目的のグループをクリックし、「選択済の追加」ボタンをクリックします。
必要に応じて繰り返し、目的の管理者グループ・ロールを追加します。
「適用」をクリックしてグループ・ロールを送信します。
管理者ロールの削除:
「アクセス・システム管理者」表で、削除するユーザーまたはグループを含む行をクリックします。
表の上にある「削除」(x)ボタンをクリックします。
確認するメッセージが表示されたら確認します。
「適用」をクリックして削除を送信します。
「認証モジュールの管理」の説明に従って、システム・ストアを使用する認証モジュールを修正します(新しいストアである場合)。
新しいロールのテスト: ブラウザのウィンドウを閉じてから、再び開きます。
Oracle Access Managerコンソールからサインアウトしてブラウザ・ウィンドウを閉じます。
Oracle Access Managerコンソールを起動して、以前の管理者ロールを使用してログインを試み、これが失敗することを確認します。
新しい管理者ロールを使用してログインし、この試みが成功することを確認します。
この項には次のトピックが含まれます。
Oracleではポリシー・ストアとして単一のデータベースが必要ですが、これはセッション・データの格納にも使用できます。データベースをセッション・ストアとして使用すると、スケーラビリティおよびフォールトトレランス性が増します(すべてのサーバーをダウンさせる電源イベントに対して)。1つのポリシー・データベースと1つのセッション・データベースまで持つことができます。
WebLogic構成ウィザードを使用した初回のデプロイメント中に、次のデータベース詳細が要求されます。
データベース・ログインIDとパスワード
データベース・サービス名と場所
WebLogic構成ウィザードを使用すると、データベースへの接続をテストできます。また、データベースはOAMに登録されます。
基本的なスキーマの作成は、RCUが起動されたときに発生します。RCUは、OAM 11gのデータを受け入れるためにデータベースを準備します。Oracle Access Managerをデータベース・ポリシー・ストアの構成テンプレートとともに実行すると、OAM 11gポリシーとセッション・データを格納するデータベースが自動的に準備されます。実際のOAMポリシー要素は、Oracle Access Managerコンソールがデプロイされて初めてWebLogic AdminServerが起動されたときに作成されます。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』 |
|
注意: OAMと使用するポリシー・ストアとして、1つのデータベースのみを登録できます。OAMには、ドメイン・ホームに読取り専用のoam-policy.xmlファイルが含まれています。このファイルは直接編集しないでください。変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。 |
Oracle Access Manager 11gには"oamDS"というデータ・ソースが含まれており、これはOAMスキーマで拡張されたデータベース・インスタンスに対して構成されます。あらかじめ定義された次のJava Naming and Directory Interface(JNDI)名が、データ・ソースを参照するためにOAMサーバーにより使用されます。
jdbc/oamds (used by both the policy layer and session layer to access database)
次の手順を使用して、WebLogic管理コンソールを使用して個別のセッション・データのデータベース・インスタンスを作成できます。Oracle Access Managerコンソールでは、この処理はサポートされていません。
|
注意: このまれなケースについては、手順2fの説明に従ってoam-config.xmlを慎重に編集することをお薦めします。 |
セッション・データ用に独立したデータベースを作成、使用する手順
セッション・データのデータベースをインストールおよび構成して、RCUをOAM固有のスキーマとともに使用し、セッション・データ・ストアとしてデータベースを設定します。
セッション・データに新しいデータ・ソース・インスタンスを作成します。
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サーバーを再起動します。
