| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2) B69533-02 |
|
 前へ |
 次へ |
この章では、Oracle Access Managementコンソールでデータソースを登録および管理する手順について説明します。この章の情報は、Oracle Access Managementコンソールから使用可能なすべてのサービスに共通します。
この章の内容は次のとおりです。
この項では、この章のタスクの要件を明らかにします。この章のタスクを開始する前に、次のトピックを確認してください。
|
注意: デフォルトのLDAPグループ |
「データ・ソース」という用語はJava Database Connectivity(JDBC)のもので、Access Managerにおいてユーザー・アイデンティティ・ストアのコレクションまたはポリシーのデータベースを指すときに使用します。
Access Managerは、通常、エンタープライズにインストールされるデータソースのタイプをいくつかサポートしています。表4-1に示すように、各データソースは様々な情報タイプのストレージ・コンテナです。
表4-1 Oracle Access Managementのデータソース
| データソース | 説明 |
|---|---|
|
ユーザー・アイデンティティ・ストア |
一元化されたLDAPストレージで、ユーザー指向の集計データが系統だって維持管理されます。 Access Managerにはアイデンティティ・サービスは含まれず、ネイティブのユーザーやグループ、ロール・ストアはありません。 デフォルトでは、Access Managerは、WebLogic Serverドメインの埋込みLDAPをユーザー・アイデンティティ・ストアとして使用します。ただし、数多くの他の外部LDAPリポジトリをユーザー・アイデンティティ・ストアとして登録することも可能です。この場合、管理者ロールおよびユーザーを含むシステム・ストアとして1つのストアを指定する必要があります。 |
|
データベース |
コンテンツのアクセスや管理、更新が簡単となるように、整理されて格納された情報のコレクション。 Access Managerのポリシー・データには、パスワード管理データなどがあり、Access Manager固有のスキーマで拡張されたデータベースに格納してAccess Managerに登録する必要があります。 |
|
Javaキーストア |
Oracle Access Managementに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成されるセキュリティ・キーの格納に使用されます。すべてのOAMエージェントおよびOSSOエージェントは、他のエージェントが読み取ることができない秘密鍵を持っています。また、Oracle Coherenceベースのセッション管理トラフィックを暗号化するキーもあります。ただし、キーストアは不可視であり、管理や変更はできません。 キーのパスワードは資格証明ストアに格納されます。 |
データソースは、Access Managerにインストールして登録する必要があります。こうすることで、ユーザーが保護されたリソースにアクセスしようとしたときに認証を可能にします(また、認証時に許可を受けたユーザーのみがリソースにアクセスできるようにします)。
初回のデプロイメント・プロセス中(『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照)に、埋込みLDAPストアがユーザー・アイデンティティ・ストアとして使用されます。Access Managerの構成データは、XMLファイルoam-config.xmlに格納されます。
|
注意: 変更にはOracle Access ManagementコンソールまたはWebLogic Scripting Tool (WLST)コマンドのみを使用することをお薦めします。oam-config.xmlは編集しないでください。 |
表4-2に、Oracle Access Managementに使用できるサービスと、そのサービスのデータソースに関する情報の入手先を示します。
表4-2 Oracle Access Managementのサービスのデータソース
| サービス | 説明 |
|---|---|
|
Access Manager |
Access Managerは、この章の次の項で説明するデータソースを使用する、シングル・サインオンに認証を提供します。 |
|
アイデンティティ・フェデレーション |
Identity Federationは、複数のアイデンティティ・ストアをサポートし、アイデンティティ・パートナ単位で割り当てることができます。アイデンティティ・ストアは個別にOracle Access Managementに登録する必要があります。アイデンティティ・ストアがアイデンティティ・パートナで定義されていない場合は、指定されたデフォルト・ストアが使用されます。 |
|
セキュリティ・トークン・サービス |
指定されたデフォルト・ストアのみを使用します。次のトピックを参照してください。 |
|
Mobile and Social |
Mobile and Socialは、ユーザー認証やユーザー・プロファイル・サービス用のディレクトリ・サーバーを参照できるように、独自のアイデンティティ・ディレクトリ・サービス構成を提供しています。 Access Managerやその他のサービスが依存するグローバル(共通)データ・ソースへの依存性は存在しません。 関連項目:
|
ユーザー・アイデンティティ・ストアは一元化された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パートナで定義されていない場合は、デフォルト・ストアが使用されます。詳細は、「フェデレーション用のアイデンティティ・プロバイダ・パートナの管理」を参照してください。
セキュリティ・トークン・サービス: ユーザーを参照するユーザー名トークンを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ヘッダーを認証されているユーザーのすべてのリクエストに設定し、必要に応じて使用するアプリケーションがユーザーの曖昧性を解消できるようにします。
セッション
セッション管理検索は、ユーザー・アイデンティティ・ストアについて管理者に通知し、これは検索結果表にリストされます。
監査およびロギング
ユーザーが認証されているユーザー・アイデンティティ・ストアは、監査およびロギング中に考慮されます。
|
関連項目:
|
Oracle Access Managementには、Access Managerのポリシー・データ、パスワード管理データおよびAccess Managerセッションを本番環境で保存するデータベースが必要です。
|
注意: 最大でも、デプロイメントに含まれるのは、1つのポリシー・ストア・データベース(パスワード管理の役割を果たす)と、1つのセッション・ストアです。デフォルトでは、単一のJDBCデータ・ストアが両方に使用されます。 |
デフォルトでは、次のデータはポリシー・ストア・データベースで維持されます。
認証モジュール、スキーム、アプリケーション・ドメインおよびポリシーを含むポリシー・データ。
構成済のユーザー・アイデンティティ・ストアごとのパスワード・ポリシー・タイプ、およびパスワードの要件、失効、通知を制御するポリシーを含んだパスワード管理データ。
分散されたメモリー内のストレージに対する永続的なバックアップとしてのセッション・データ。
|
注意: 本番環境での監査データ・ストレージの推奨モードは、スタンドアロンの監査データ専用RDBMSデータベースに監査レコードを書き込むことです。これは、個別に構成された監査ストアを使用して行います。ポリシー・ストアは監査データには使用されません。 |
Access Managerには、Access Manager関連のシステム構成データをすべて含むXMLファイル(oam-config.xml)が用意されています。各OAMサーバーには、最新の構成XMLファイルのローカル・コピーが1つあります。
サーバーとエージェントの登録を含むAccess Managerデプロイメント構成に加えられたすべての変更は、oam-config.xmlファイルに格納されて、自動的に各OAMサーバーに伝播されます。
高可用性環境でフェイルオーバーが構成されているかどうかに関係なく、すべてのOAMサーバーには常に最新のoam-config.xmlファイルがあります。
|
注意: oam-config.xmlは編集しないことをお薦めします。 |
oam-config.xmlファイルは編集しないことをお薦めします。このファイルを変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。ただし、oam-config.xmlの編集が必要な場合には、次のガイドラインに従ってください。
$DOMAIN_HOME/config/fmwconfig/にあるoam-config.xmlをバックアップし、使用する場合にはコピーを別の場所に保存します。
AdminServerを実行されているノードで、他のAdminServerユーザーによって発生する可能性がある競合ができるだけ少なくなるように変更を加えます。
OAMサーバーが実行されている場合は、ファイルの上部にある構成のバージョン番号に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>
推奨のキーストア・フォーマットはJKS(Javaキーストア)です。Javaキーストアは水面下でAccess Managerに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成される暗号化セキュリティ・キーの格納に使用されます。次に例を示します。
すべてのOAMエージェントおよびOSSOエージェントは、他のエージェントが読み取ることができない秘密鍵を持っています。
Oracle Coherenceベースのセッション・トラフィックを暗号化するキーがあります。
エージェントとアプリケーションの登録時に、SSO Cookie(Webgateおよびmod_ossoの場合)の暗号化および復号化に使用されるキーが生成されます。
表4-3は、生成された暗号化キーの比較と、それぞれの格納場所を簡単に説明しています。
表4-3 11.1.2 キーと格納
| キーと格納 | 説明 |
|---|---|
|
Access Manager暗号化キー |
|
|
Access Managerキー・ストレージ |
|
|
注意: キーストアはコンソールからは使用できず、表示や管理、変更はできません。 |
Security Token Serviceのいくつかのタイプのキーストアを簡単に要約したものを次に示します。
OAMサーバー・インスタンスに関連付けられたキーおよび証明書のシステム・キーストア
OAMサーバー・インスタンスと相互作用するエンティティに信頼性を確立するために使用されるキーおよび証明書の信頼キーストア
パートナ、クライアントおよびエージェントとの信頼性を確立するために使用されるキーおよび証明書のパートナ・キーストア。パートナ・キーおよび証明書は、機密情報が暗号化されて.oamkeystoreに格納されます。
証明書失効リスト(CRL)は、CRLベースの証明書失効確認の実行中に、OAMサーバー・インスタンスによって使用されます。
次のファイルは、JMXフレームワークによってドメイン内のすべてのOAMサーバー間で配布されます。
システム・キーストアとパートナ・キーストア: .oamkeystore
信頼キーストア: amtruststore
CRL: amcrl.jar
Security Token ServiceでOracle WSMエージェント機能を使用してWSポリシーを公開し、インバウンドおよびアウトバウンドWSメッセージのメッセージを保護できます。
Oracle WSMでは、システムおよびパートナ・キーおよび証明書用に、JKSタイプの別のキーストアが必要です。
デフォルト名はjps-config.xmlで次のように指定されています。
default-keystore.jks
|
注意: Oracle WSMエージェント・キーストアとAccess ManagerおよびSecurity Token Serviceのキーストアは常に異なるものにすることをお薦めします。そのようにしないと、キーはOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Access Manager/Security Token Serviceがアクセスされる可能性があります。 |
この項では、Oracle Access Managementコンソールを使用してユーザー・アイデンティティ・ストアの登録を管理する上で必要な手順を説明します。
このトピックでは、「システム構成」タブの下の様々なユーザー・アイデンティティ・ストアの設定について説明します。
図4-1に、「ユーザー・アイデンティティ・ストアの作成」ページを示します。このページには、自分の環境に合せて編集できるストア設定とデフォルト設定の入力フィールドがあります。「ストア・タイプ」ドロップダウン・リストには、サポートされる選択項目が表示されます。
ページ上のアスタリスク(*)は必須の設定です。表4-4に、タイプ別の各要素を示します。
表4-4 ユーザー・アイデンティティ・ストアの要素
| 要素 | 説明 |
|---|---|
|
ストア名 |
この登録の一意の名称。名称は最大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 |
|
参照ポリシー |
以下の値のいずれかです:
|
図4-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コンソールの「システム構成」タブで「共通構成」セクションから「データソース」ノードを開きます。
「ユーザー・アイデンティティ・ストア」をクリックし、ツール・バーの「作成」コマンド・ボタンをクリックします。
デプロイメントに適した値(表4-4)をフォームに入力し、「適用」をクリックして登録を送信します。
接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。
登録ページを閉じます。
管理者の追加: 「管理者ロールの管理」を参照してください。
ナビゲーション・ツリーで、登録ページを開くストア名をダブルクリックします。
「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。
「システム管理者ロールの追加」ダイアログ・ボックス(...)に入力します。
「適用」をクリックします。
デフォルト・ストアの設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。
「適用」をクリックして登録を送信してから、ページを閉じます。
次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。
有効なOracle Access Management管理者の資格証明を持つユーザーは、ユーザー・アイデンティティ・ストアの登録を表示または変更できます。
前提条件
登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。
ユーザー・アイデンティティ・ストアの閲覧または変更の手順
Oracle Access Managementコンソールの「システム構成」タブ、「共通構成」セクション、「データソース」ノード、「ユーザー・アイデンティティ・ストア」ノードの順に開きます。
目的の「ユーザー・アイデンティティ・ストア」登録ページをクリックして開きます。
必要に応じて値を変更します(表4-4を参照)。
「適用」をクリックして、登録を更新します(または変更を適用しないでページを閉じます)。
接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。
システム・ストアまたはデフォルト・ストアとして設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。
管理者ロールの管理: 「管理者ロールの管理」を参照してください。
次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。
完了したらページを閉じます。
有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、Oracle Access Managementコンソールによりユーザー・アイデンティティ・ストアの登録を削除できます。
|
注意: デフォルト・ストアまたはシステム・ストアの登録は削除できません。 |
セカンダリ・ユーザー・アイデンティティ・ストア登録の削除の手順
削除するストアを参照しているLDAP認証モジュールを編集します(有効なアイデンティティ・ストアがモジュール内で参照されているか確認するため)。
Oracle Access Managementコンソールの「システム構成」タブ、「共通構成」セクション、「データソース」ノード、「ユーザー・アイデンティティ・ストア」ノードの順に開きます。
目的の「ユーザー・アイデンティティ・ストア」登録ページをクリックして開き、削除するストアであることを確認し（さらにデフォルトでないことを確認してから）、ページを閉じます。
希望するインスタンス名をクリックしてから、ツール・バーで「削除」ボタンをクリックします。
「確認」ウィンドウで「削除」ボタンをクリックします(または「取消」をクリックしてウィンドウを閉じ、インスタンスを保持します)。
定義がナビゲーション・ツリーにないことを確認します。
この項の内容は次のとおりです。
有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、ユーザー・アイデンティティ・ストアの登録をデフォルト・ストアまたはシステム・ストアのいずれかとして指定できます。
|
注意: 管理者ログインは、 |
図4-3は、新しいユーザー・アイデンティティ・ストア登録を追加した直後に表示されるデフォルト・ストアおよびシステム・ストアのオプションを示します。
図4-4に、デフォルト・ストアを表示したときの登録ページを示します。
システム・ストアの指定を適用するとすぐに、アクセス・システム管理者ロールを追加するように要求されます(「管理者ロールの管理」を参照してください)。また、OAMAdminConsoleSchemeによって使用されるLDAPモジュールがシステム・ストアを参照するようにする必要もあります。
図4-5に示されているように、「共通設定」ページから「デフォルトおよびシステム・アイデンティティ・ストア」にアクセスすることもできます。
Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用してデフォルト・ストアおよびシステム・ストアの指定を定義または変更できます。
デフォルト・ストアおよびシステム・ストアを定義する手順
Oracle Access Managementコンソールから、次を開きます。
システム・ストアの設定: このストアに管理者ロールおよび証明書が存在する必要があります。
システム・ストアとして指定するストア名をクリックし、登録ページを開きます。
「システム・ストアとして設定」の横にあるボックスを選択します(ドメイン全体の認証および認可操作用)。
「適用」をクリックして指定を送信します。
管理者の追加: 「管理者ロールの管理」を参照してください。
認証モジュール: OAMAdminConsoleScheme (認証スキーム)によって使用されるLDAP認証モジュールがシステム・ストアを使用するように設定します。
このストアを使用するように、次を参照して、1つ以上の認証プラグインを構成します。
デフォルト・ストアの設定: このストアは、パッチ適用時のセキュリティ・トークン・サービスおよび移行に必要です。
デフォルト・ストアとして指定するストア名をクリックし、登録ページを開きます。
「デフォルト・ストアとして設定」の横にあるボックスを選択し、このLDAPストアを設定します(移行用)。
認証モジュール: OAMAdminConsoleSchemeを見つけて、LDAPモジュールがこのストアを参照していないことを確認します。「ネイティブ認証モジュールの管理」を参照してください。
認可ポリシー条件: 認可ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。認証ポリシー条件の定義を参照してください。
トークン発行ポリシー条件: トークン発行ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。「トークン発行ポリシー、条件およびルールの管理」を参照してください。
登録ページを閉じます。
ここでは、次の内容について説明します。
管理者ログインは、認証スキーム(および割り当てられた認証モジュール)がIAMSuiteAgentによって使用されており、そのシステム・ストアも使用する場合にのみ機能します。
デフォルトでは、Oracle Access Managementの管理者ロールは、WebLogic管理者ロール(Administrators)と同じです。他のユーザー・アイデンティティ・ストア(たとえばOracle Internet Directory)を登録することもできますが、ただし、認証先の登録済ストアの少なくとも1人のユーザーを使用してユーザーweblogicを定義する必要があります。
企業によっては、Access Managerを担当するユーザーとSecurity Token Serviceを担当するユーザーに別の管理者グループが必要になることがあります。すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。アイデンティティ・ストア登録の編集時にストアをシステム・ストアとして指定すると、図4-6に示すように「アクセス・システム管理者」セクションがページ上に開きます。
|
注意: すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。 |
ユーザー・アイデンティティ・ストア登録を追加または編集するときに、新しい管理者ロールを追加できます。図4-7は、使用するページとコントロールを示しています。
次の手順では、システム・ストアとして指定したユーザー・アイデンティティ・ストアに格納する必要があるOracle Access Management管理者ロールの定義または削除方法を説明します。
前提条件
システム・ストアの管理者ロールを追加または削除する手順
指定したシステムLDAPストアで、次を実行します。
管理者に使用する目的のLDAPグループを定義します。
管理者グループが、グループ検索ベースで使用可能なことを確認します。
システム・ストア登録の表示: 次の手順を実行します(またはシステム・ストアとして指定する、「データソース」ノード内の異なるシステム・ストアを検索します)。
Oracle Access Managementコンソールの「ようこそ」ページから、「構成」パネルの「共通設定」をクリックします。
「デフォルトおよびシステム・アイデンティティ・ストア」セクションを必要に応じてスクロールおよび展開します。
システム・ストアの名前をクリックし、構成ページを表示します。
ユーザー・ロールの追加:
「アクセス・システム管理者」表の上にある「追加」(+)ボタンをクリックして、「システム管理者ロールの追加」ダイアログ・ボックスを表示します。
「タイプ」リストの「ユーザー」を選択し、「検索」ボタンをクリックします。
結果リスト内で目的のユーザーをクリックし、「選択済の追加」ボタンをクリックします。
必要に応じて繰り返し、目的の管理者ユーザー・ロールを追加します。
「適用」をクリックしてユーザー・ロールを送信します。
グループ・ロールの追加:
「アクセス・システム管理者」表の上にある「追加」(+)ボタンをクリックして、「システム管理者ロールの追加」ダイアログ・ボックスを表示します。
「タイプ」リストの「グループ」を選択し、「検索」ボタンをクリックします。
結果リスト内で目的のグループをクリックし、「選択済の追加」ボタンをクリックします。
必要に応じて繰り返し、目的の管理者グループ・ロールを追加します。
「適用」をクリックしてグループ・ロールを送信します。
管理者ロールの削除:
「アクセス・システム管理者」表で、削除するユーザーまたはグループを含む行をクリックします。
表の上にある「削除」(x)ボタンをクリックします。
確認するメッセージが表示されたら確認します。
「適用」をクリックして削除を送信します。
次を参照して、システム・ストアを使用する認証プラグインを修正します(新しいストアの場合)。
新しいロールのテスト: ブラウザのウィンドウを閉じてから、再び開きます。
Oracle Access Managementコンソールからサインアウトしてブラウザ・ウィンドウを閉じます。
Oracle Access Managementコンソールを起動して、以前の管理者ロールを使用してログインを試み、これが失敗することを確認します。
新しい管理者ロールを使用してログインし、この試みが成功することを確認します。
ログイン失敗: 「管理者のロックアウト」を参照してください。
この項の内容は次のとおりです。
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サーバーを再起動します。
