1. Oracle Access Management管理者ガイド
  2. 共通構成およびシステム構成の管理
  3. データ・ソースの管理

5 データ・ソースの管理

データ・ソースという用語はJava Database Connectivity (JDBC)のもので、Oracle Access Managementにおいてユーザー・アイデンティティ・ストアのコレクションまたはポリシーのデータベースを指すときに使用します。これらのデータ・ソースにアクセスするには、Oracle Access Managementコンソールを使用して登録する必要があります。

次の各トピックでは、Oracle Access Managementコンソールを使用してデータ・ソースを登録および管理するタスクについて説明します。この情報は、Oracle Access Managementコンソールから使用可能なすべてのサービスに共通します。

5.1 Oracle Access Managementのデータ・ソース

Oracle Access Managementは、通常、エンタープライズにインストールされるデータ・ソースのタイプをいくつかサポートしています。

表5-1に、それぞれが様々なタイプのストレージ・コンテナであるデータ・ソースを示します。

表5-1 Oracle Access Managementのデータ・ソース

データ・ソース 説明

データベース

コンテンツのアクセスや管理、更新が簡単となるように、整理されて格納された情報のコレクション。

  • Access Managerのポリシー・データには、パスワード管理データなどがあり、Access Manager固有のスキーマで拡張されたデータベースに格納してAccess Managerに登録する必要があります。

    「ポリシーおよびセッション・データベースの管理」を参照してください。

  • セッション・ストア: デフォルトでは、Access Managerのセッション・データはポリシー・ストアに移行されたメモリー内のキャッシュに格納されます。本番環境では、ポリシー・データ用と、その他のセッション・データ用に独立したデータベースを用意できます。

    セッションおよびセッション・データの詳細は、「Access Managerセッションの維持」を参照してください。

  • 監査ストア: 監査データは、ファイルまたは個別のデータベース(ポリシー・ストアのデータベース以外)に格納できます。

    管理イベントおよびランタイム・イベントの監査の詳細は、「管理イベントおよびランタイム・イベントの監査」を参照してください。

ユーザー・アイデンティティ・ストア

一元化されたLDAPストレージで、ユーザー指向の集計データが系統だって維持管理されます。(Access Managerにはアイデンティティ・サービスは含まれず、ネイティブのユーザーやグループ、ロール・ストアはありません。)アイデンティティ・ストアは、Access Managerにインストールして登録する必要があります。こうすることで、ユーザーが保護されたリソースにアクセスしようとしたときに認証を可能にします(また、認証時に許可を受けたユーザーのみがリソースにアクセスできるようにします)。初回デプロイメント・プロセス時に、『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 Identity and Access Managementのインストールおよび構成』で説明されているように、Oracle Access Management構成データはXMLファイルoam-config.xmlに格納されます。

「OAM構成の更新」を参照してください。

キーストア

Oracle Access Managementサービスには、「Oracle Access Managementキーストアの概要」で説明しているとおり、複数のキーストアが関連付けられています。

  • 組込みJavaキーストア: OAMサーバーとWebgate間の簡易または証明書ベースの通信のための証明書として使用されます。構成ウィザードを実行した後に、初回のAdminServer起動でキーストアのブートストラップが発生します。

    関連項目: 「Access Managerセキュリティ・キーおよび組込みJavaキーストア」

  • Security Token Serviceキーストア: Access ManagerおよびSecurity Token Serviceのキーストアは常に異なるものにすることをお薦めします。詳細は、「Access Managerキーストア」を参照してください。

  • Identity Federationキーストア: キーストア設定により、キーストア内のキーに対して別名(略称)を作成できます。

    関連項目: 「Identity Federationキーストア」

表5-2は、Oracle Access Managementサービスと、それぞれに使用されるデータ・ソースの情報へのリンクを示しています。

表5-2 Oracle Access Managementのサービスのデータ・ソース

サービス 説明

Access Manager

Access Managerでは、複数のアイデンティティ・ストアをサポートし、データ・ソースを使用したSSO認証を提供します。

Identity Federation

Identity Federationは、アイデンティティ・パートナ単位で割り当てることができる、複数のアイデンティティ・ストアをサポートします。各アイデンティティ・ストアはAccess Managerに登録されている必要があります。アイデンティティ・ストアがアイデンティティ・パートナで定義されていない場合は、指定されたデフォルト・ストアが使用されます。

関連項目:

次の各項では、さらに詳細を説明します。

5.1.1 OAM構成の更新

OAM 12c (12.2.1.3.0)リリースでは、OAM構成はOAM DBストア(OAM SCHEMA)にのみ存在します。

そのため、$DOMAIN_HOMEのoam-config.xmlを編集しても、何の効果もありません。構成を変更するには、次の手順に従います。
  1. <working directory>を作成し、そのディレクトリに移動します:
    mkdir <working directory>
    cd <working directory>
  2. ディレクトリ内に、次を含むdbschema.propertiesファイルを作成します:
    oam.entityStore.ConnectString=jdbc:oracle:thin:@<DB_HOST>:<DB_PORT>/<DB_SERVICE_NAME>
oam.entityStore.schemaUser=<PREFIX>_OAM
oam.entityStore.schemaPassword= <password>
oam.importExportDirPath=<path to which configuration is exported or imported>
oam.frontending=params=host;port;protocol

    たとえば:

    oam.entityStore.ConnectString=jdbc:oracle:thin:@dbhost.example.com:1521/pdb1.example.com
oam.entityStore.schemaUser=DEV_OAM
oam.entityStore.schemaPassword= <password>
oam.importExportDirPath=<work directory>
oam.frontending=params=host;port;protocol
  3. config-utility.jarを使用してdbstoreから構成をエクスポートします:
    java -cp $ORACLE_HOME/oam/server/tools/config-utility/config-utility.jar:$ORACLE_HOME/oracle_common/modules/oracle.jdbc/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME export dbschema.properties

    これにより、oam-config.xmlが<working directory>にエクスポートされます

  4. 必要に応じて、<working directory>/oam-config.xmlを変更します。
  5. config-utility.jarを使用してdbstoreに構成をインポートします:
    java -cp $ORACLE_HOME/oam/server/tools/config-utility/config-utility.jar:$ORACLE_HOME/oracle_common/modules/oracle.jdbc/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME import dbschema.properties

5.1.2 デフォルトのLDAPグループについて

デフォルトのLDAPグループAdministratorsは、Oracle Fusion Middlewareの構成ウィザードを使用した初回デプロイメント時に設定されます。

詳細は、「Oracle Access Management管理者について」を参照してください。

5.2 ユーザー・アイデンティティ・ストアの登録および管理

ユーザー・アイデンティティ・ストアは一元化されたLDAPストアで、管理者およびユーザー指向の集計データが系統だって保持管理されます。

Oracle Access Managementでは複数のLDAPベンダーがサポートされており、Oracle Access Managementとそのサービスによる使用のために複数のLDAPストアを登録できます。Oracle Access Managementでは、アイデンティティ・ドメインとして各ユーザー移入とLDAPディレクトリ・ストアに対応しています。それぞれのアイデンティティ・ドメインは構成済のLDAPユーザー・アイデンティティ・ストアにマップされます。このストアはOracle Access Managementによって登録する必要があります。この項では、Oracle Access Managementコンソールを使用してユーザー・アイデンティティ・ストアを登録および管理するのに必要な情報について説明します。

ノート:

アイデンティティ・データ・ストアへのアクセスには、従来のOAM IDストア機能ではなく、アイデンティティ・ディレクトリ・サービス・プロファイルを使用することをお薦めします。OAM IDストア機能は今後のリリースで非推奨になります。アイデンティティ・ディレクトリ・サービスの詳細は、「アイデンティティ・ディレクトリ・サービスのユーザー・アイデンティティ・ストアの管理」を参照してください。

5.2.1 ユーザー・アイデンティティ・ストアの理解

Oracle Fusion Middleware構成ウィザードを使用したWebLogic Serverドメインの最初の構成時、組込みLDAPのみがユーザー・アイデンティティ・ストアとして構成されます。組込みLDAP内では、weblogicがデフォルトの管理者としてあらかじめ設定された管理者グループが作成されます。

ノート:

組込みLDAPは、ユーザーが10,000人未満のときにパフォーマンスが最も良くなります。ユーザーがこれより多い場合は、別のエンタープライズLDAPサーバーを考慮してください。高可用性構成では、ユーザー・アイデンティティ・ストアとして外部LDAPディレクトリを使用することをお薦めします。Oracle WebLogic Serverのセキュリティの管理を参照してください

ユーザーはAccess Managerで保護されたリソースにアクセスしようとする場合、指定されたデフォルトのストアに限らず任意のストアに対して認証できます。ただし、いくつかの考慮事項があります。

  • システム・ストア: 1つのユーザー・アイデンティティ・ストアのみをシステム・ストアとして指定できます(さらに必ず指定する必要があります)。これは、Oracle Access Managementコンソール、リモート登録ツールおよびWLSTのカスタム管理コマンドを使用するためにサインインする管理者の認証に使用されます。したがって、Oracle Access Managementコンソールまたはリモート登録ユーティリティを使用する管理者は、システム・ストアに資格証明を格納しておく必要があります。リモート・ユーザー・ストアをシステム・ストアとして定義すると、OAMAdminConsoleSchemeを変更して、同じリモート・ユーザー・ストア(システム・ストア)を参照するLDAP認証モジュールを使用する必要があります。詳細は、「ユーザー・アイデンティティのシステム・ストアの使用について」を参照してください。

  • デフォルト・ストア: 名前が示すとおり、デフォルト・ストアとして指定されたLDAPストアは、モジュールまたはプラグインに別のストアの使用を構成しないかぎり、LDAP認証モジュールでの使用に対して自動的に選択されます。

ノート:

Access Managerに保護されたリソースにアクセスするユーザーは、認証スキームで登録および定義された任意のユーザー・アイデンティティ・ストアに対して認証できますが、セキュリティ・トークン・サービスはデフォルトのユーザー・アイデンティティ・ストアのみを使用します。たとえば、トークン発行ポリシーにユーザー条件を追加するとき、ユーザーを選択するアイデンティティ・ストアはデフォルト・ストアである必要があります。

Oracle Access Managementコンソールでは、ユーザー・アイデンティティ・ストアの登録は、「構成」起動パッド下にまとめられています。管理者は、Oracle Access Managementコンソールまたは『WebLogic Server WLSTコマンド・リファレンス』に記載されているカスタマイズ・コマンドを使用して、ユーザー・アイデンティティ・ストアの登録と、登録の表示、変更および削除が可能です。

5.2.2 ユーザー・アイデンティティのシステム・ストアの使用について

有効なOracle Access Managementシステム管理者の資格証明を持つユーザーは、登録済のユーザー・アイデンティティ・ストアをデフォルト・ストアまたはシステム・ストアのいずれかとして指定できます。

「アイデンティティ・ディレクトリ・サービスのユーザー・アイデンティティ・ストアの管理」に説明されているように、Oracle Access Managementコンソールでデフォルト・アイデンティティ・ストアおよびシステム・アイデンティティ・ストアの構成を選択できます。

UserIdentityStore1は、埋込みのAccess Manager LDAPストアです。インストール後、Oracle Access ManagementコンソールおよびOAM Policy ManagerがIAM Suiteエージェントによって保護されます。IAM Suiteアプリケーション・ドメインは、OAMAdminConsoleScheme認証スキームを使用するOAM管理コンソール認証ポリシーでシードされています。また、OAMAdminConsoleSchemeはLDAP認証モジュールを使用し、システム・ストアとLDAP認証モジュールは両方ともWebLogic埋込みアイデンティティ・ストア(UserIdentityStore1)を使用します。Access Managerの管理者ロールが、システム・ストアに属するエンタープライズ・グループおよびユーザーにマップされます。

5.2.2.1 ユーザー・アイデンティティのシステム・ストアの使用

システム・ストアを変更すると、アイデンティティ管理(IAM Suite)ドメイン全体に影響を与えます。システム・ストアをリモート・アイデンティティ・ストアに変更する場合は、WebLogicでこのリモート・ストアの認証プロバイダを作成する必要があります。

このリモート・ストア・プロバイダが、WebLogicコンソールのプロバイダ・リスト内に表示されます。次の点にも留意してください:

  • 新しいリモート・ストア・プロバイダより前のすべてのプロバイダの制御フラグがSUFFICIENTまたはOPTIONALに設定されていることを確認します。

  • ADMIN (WebLogicグローバル・ロール)を、このリモート・ストアからのエンタープライズ・グループまたはユーザーに割り当てます。これを行うには、IDM構成ツールを使用してリモート・ストアを準備するステップを実行し、WebLogicドキュメントを参照します。

  • Oracle Unified Directoryをシステム・ストアとして使用する場合は、WebLogicでIPlanetAuthenticatorを作成します。

    システム・ストアをリモート・ストアに変更する前に、前述の構成を実行してテストする必要があります。また、リモート・ストアを使用するようにLDAP認証モジュール構成を変更する必要もあります。リモート・ストアは、OAMアイデンティティ・ストアまたはIDSプロファイルを使用して構成できます。

    ノート:

    管理者ログインは、(OAMAdminConsoleSchemeによって使用される) LDAP認証モジュールもそのシステム・ストアを使用する場合のみ機能します。別のストアをリモート・ストアとして設定する場合、ロックアウトを回避するために必ずOAMAdminConsoleSchemeを変更してください。

    Webゲートを使用して(AdminServerの) Oracle Access Managementコンソールおよび(OAMサーバーの) Policy Managerコンソールを保護する場合、前述の手順に加えて、WebLogicでOAMアイデンティティ・アサータを作成し、WLSTコマンドを使用してJPSでOAMをSSOプロバイダとして有効にします。詳細は、「Oracle ADFアプリケーションとAccess Manager SSOの統合」を参照してください。また、OAMポリシー・マネージャ・コンソールのホスト名およびポートをホワイトリストに登録し、Webゲート保護を完全に有効にする必要もあります。

    管理者ロールに関する情報は、「管理者ロールの管理」を参照してください。

5.2.3 複数のアイデンティティ・ストアの使用について

管理者はOracle Access Managementに複数のユーザー・アイデンティティ・ストアをインストールおよび登録できます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。

複数のアイデンティティ・ストアが登録されている場合、管理者は次を定義する必要があります。

  • システム・ストア: 管理者はシステム・ストアに対してのみログインできます。

  • デフォルト・ストア: パッチ適用時と、Identity Federationおよびセキュリティ・トークン・サービスの使用時に起動する。

    • パッチ適用: パッチの適用前に、デフォルト・ストアとしてUserIdentityStore1を指定し、UserIdentityStore1 (Weblogic Serverの組込みLDAP)を使用するようにLDAP認証モジュールを更新します。

    • Identity Federation: IdPパートナ単位で複数のアイデンティティ・ストアをサポートします。指定したアイデンティティ・ストアは、別のストアと同じように登録する必要があります。アイデンティティ・ストアがIdPパートナで定義されていない場合は、デフォルト・ストアが使用されます。詳細は、「サービス・プロバイダとしてのIdentity Federationの管理」を参照してください。

  • 各LDAP認証モジュールまたはプラグイン(およびフォームまたは基本認証スキーム)とともに使用する特定のストア

外部LDAPリポジトリは、ユーザー、ロールおよびグループ・メンバーシップ情報を提供できます。たとえば、ユーザーのグループは、ログイン時に計算され、セッションの存続期間内に格納されます。情報は次のように使用されます。

  • 認証中にポリシーを評価する場合

  • ポリシー内の認可条件に対するアイデンティティを評価する場合

  • 認可ポリシーでの条件のアイデンティティを検索するために、LDAPを使用する場合

ノート:

ユーザーのグループ・メンバーシップ情報を消去し、後日Oracle Access Managementで再計算する方法はありません。

OAMでのユーザー・アイデンティティ・ストアの登録は、OAMサーバーとの接続性を提供するために必要です。アイデンティティ・ストアを登録した後、管理者はそれを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。

Oracle Access Managementでは、各ユーザー移入とディレクトリのそれぞれをアイデンティティ・ドメインとして対応可能です。各アイデンティティ・ドメインは、単に構成済アイデンティティ・ストア名にマップします。

複数のアイデンティティ・レルムをサポートするには、ユーザーまたはグループのレルム間表現、またはアイデンティティ・ストア内に存在するエンティティが必要です。この表現は、正規識別子と呼ばれますが、Oracle Access Managementの様々なランタイムおよび管理コンポーネントに対する一意の識別子として機能します。

  • 外部表現: アイデンティティ・ドメイン情報とともに単純なユーザー名を修飾します。

    たとえば、Oracle Access Managementコンソールでユーザー名を示す表には、それぞれのユーザーのアイデンティティ・ドメインを表示する列が含まれます。アイデンティティ・ドメインはアイデンティティ・ストア名にマップします。ユーザー情報を表示するすべての機能コンポーネント(コンソール、ポリシー、レスポンス、ロギング、セッション管理、監査など)は、アイデンティティ・ドメイン情報の場合と同様に修飾を開始します。

  • 内部表現: 曖昧性解消をサポートするために、OAMは完全修飾名を格納および使用します(またはコンポジット・キーを形成するために両方のフィールドをそのまま使用します)。

    たとえば、セッション管理エンジンはコンポジットを格納する必要をなくすためにこのようにしています。どちらの場合も、完全修飾名は表示されません。

5.2.3.1 アイデンティティ・ストアを使用するOracle Access Managementのコンポーネント

Oracle Access Managementのランタイム・コンポーネントおよび管理コンポーネントではアイデンティティ・ストアを使用します。

表5-3に、Oracle Access Managementの様々なランタイム・コンポーネントおよび管理コンポーネントを示します。

表5-3 アイデンティティ・ストアを使用するコンポーネント

コンポーネント 説明

認可ポリシー管理

認可ポリシー管理は、ユーザーまたはグループへの権限付与のオーサリングを許可します。管理者は、特定のユーザーまたはグループを選択し、アクセス権を付与または拒否して、特定のアイデンティティ・ストア内を検索できます。検索結果は、Access Manager認可ポリシーのアイデンティティ条件タイプのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。

実行時

認証および認可は、ポリシー・ランタイム・コンポーネントに基づきます。OAMIdentityは、認証されたユーザーおよびそのユーザーがメンバーとなっているグループ(存在する場合)のランタイム表現です。ポリシー評価中、OAMIdentity内の情報は、認可ポリシーのアイデンティティ制約の一部として格納されているものと照合されます。ドメインは、トークン内の名前修飾子としてアサートされます。

OAMプロキシの場合、既存のOAM_REMOTE_USERヘッダーに加えて、2番目のOAM_IDENTITY_DOMAINヘッダーを認証されているユーザーのすべてのリクエストに設定し、必要に応じて使用するアプリケーションがユーザーの曖昧性を解消できるようにします。

セッション

セッション管理検索は、ユーザー・アイデンティティ・ストアについて管理者に通知し、これは検索結果表にリストされます。

監査およびロギング

ユーザーが認証されているユーザー・アイデンティティ・ストアは、監査およびロギング中に考慮されます。

関連項目:

5.2.4 ユーザー・アイデンティティ・ストア設定

「システム構成」タブからユーザー・アイデンティティ・ストアを作成できます。

図5-1に、「ユーザー・アイデンティティ・ストアの作成」ページを示します。このページには、自分の環境に合せて編集できるストア設定とデフォルト設定の詳細の入力フィールドがあります。「ストア・タイプ」ドロップダウン・リストには、サポートされる選択項目が表示されます。

図5-1 ユーザー・アイデンティティ・ストア登録の作成

図5-1の説明が続きます
「図5-1 ユーザー・アイデンティティ・ストア登録の作成」の説明

ページ上のアスタリスク(*)は必須の設定です。表5-4は、タイプ別の各要素を示します。

表5-4 ユーザー・アイデンティティ・ストアの要素

セクション 要素 説明

一般

ストア名

この登録の一意の名称。名称は最大30文字までを使用できます。

ストア・タイプ

サポートされているすべてのLDAPプロバイダのリスト。ここから選択できます。「複数のアイデンティティ・ストアの使用について」で説明されているとおり、複数のアイデンティティ・ストアを使用できます。

LDAPプロバイダのリスト

関連項目: 表24-6。

説明

オプション。

SSLの有効化

このボックスをクリックして選択すると、ディレクトリ・サーバーとOAMサーバーの間でSSLが有効であることを示します。

keytoolコマンド行インタフェースを使用して、適切なCAルート証明書およびサーバー証明書を($JAVA_HOME/lib/security/cacertsにある)デフォルトのJDKキーストアにインポートする必要もあります。

ノート: CAルート証明書は任意のキーストアに追加できます(次のJavaプロパティに対してそのキーストアに関する適切な値が設定されている場合)。このためには、適切な値および-Dオプションを使用してOAM管理サーバーおよび管理対象サーバーのインスタンスを起動します。

  • javax.net.ssl.trustStore=trust.jks

  • javax.net.ssl.trustStorePassword=<trustPass>

  • javax.net.ssl.keyStore=keystore.p12

  • javax.net.ssl.keyStoreType=pkcs12

  • javax.net.ssl.keyStorePassword=<keyStorePass>

プリフェッチされた属性

カンマ区切りのユーザー属性のリスト(たとえば、email, phone, mobile)。OAMサーバーは、アイデンティティ・ストアに対してユーザーを認証する間に、ユーザー属性のリストをメモリーにキャッシュします。キャッシュされた値は、認証レスポンス・ヘッダー、認可ポリシー・レスポンス・ヘッダーおよび認可ポリシー条件の計算に使用されます。プリフェッチされた属性では、ユーザー・アイデンティティ・ストアへのラウンド・トリップを回避することで、パフォーマンスを大幅に改善します。OAM管理者は、認証および認可ポリシー・レスポンス・ヘッダーと認可条件で使用されるすべてのユーザー属性が、ユーザー・アイデンティティ・ストア・プロファイルでプリフェッチされた属性として定義されていることを確認する必要があります。

ユーザーのネイティブIDストア

これによって、LDAP認証モジュール内にネイティブにロック/無効化されている/pw_must_changeコードの認証コードを取得できます。

場所と資格証明

Location

パート番号を含むLDAPホストのURL。Oracle Access Managementは、フェイルオーバー機能で複数のLDAP URLをサポートします。IDアサーション・プロバイダは、LDAP URLが表示される順序に基づいて次のLDAP URLにフェイルオーバーします。

1つの(または複数の)LDAP URLをホスト:ポートの形式で入力します。複数のURLは、空白または改行で区切る必要があります。このURL値には、ldap://またはldaps://(SSL_NO_AUTHをサポート)を指定する必要はありません。 

localhost:myhost:7001

ノート: サポートされるURLの文字数は、ブラウザのバージョンに基づきます。Oracle Access Managementおよびブラウザが処理できる長さを超えたURLを、アプリケーションで使用しないようにしてください。

バインドDN

接続プールのユーザーDNで、これを介して他のすべてのBINDが発生します。ユーザーおよびグループ・ベースのDNには、適切な読取りおよび検索の権限を持つ管理者以外のユーザーをお薦めします。

たとえば: 

uid=amldapuser,ou=people,o=org

パスワード

プリンシパルのパスワードで、セキュリティのために暗号化されます。
ユーザーおよびグループ

ログインID属性

ログインID (ユーザー名)を識別する属性。

たとえば: 

uid

ユーザー・パスワード属性

ユーザーのパスワードが格納されるユーザー・アイデンティティ・ストア(LDAPディレクトリ)内の属性。これは、柔軟性を高めるために構成可能になっています。

ユーザー検索ベース

ディレクトリ情報ツリー(DIT)のノード。この下にユーザー・データが格納され、すべてのユーザー・データ検索の最も高いベースとなります。

たとえば: 

ou=people,ou=myrealm,dc=base_domain

ユーザー・フィルタ・オブジェクト・クラス

ユーザー・オブジェクト・クラス名のカンマ区切りリストで、ユーザーの検索結果に含めるオブジェクト・クラス。たとえば、user,personなどです。

グループ名属性

グループ名を識別する属性。

デフォルト: cn

グループ検索ベース

現在はuniquemember属性を持つ静的グループのみがサポートされています。

ディレクトリ情報ツリー(DIT)のノード。この下にグループ・データが格納され、すべてのグループ・データ検索の最も高いベースとなります。

たとえば: 

ou=groups,ou=myrealm,dc=base_domain

グループ・フィルタ・クラス

グループ・オブジェクト・クラスのカンマ区切りリストで、グループの検索結果に含めるオブジェクト・クラス。たとえば: groups、groupOfNamesなど。

グループ・メンバーシップ・キャッシュの有効化

グループ・キャッシュのブーリアン値: trueまたはfalse

デフォルト: true

グループ・キャッシュ・サイズ

グループ・キャッシュ・サイズの整数

デフォルト: 10000

グループ・キャッシュ存続時間(秒)

グループ・キャッシュ要素、存続時間の整数(秒)。

デフォルト: 0

接続の詳細

最小プール・サイズ

接続プールに設定される最小サイズ。

デフォルト: 10

最大プール・サイズ

接続プールに設定される最大サイズ。

デフォルト: 50

待機タイムアウト

完全に利用されているプールで、接続リクエストがタイムアウトするまでの時間(秒)。

デフォルト: 120

非アクティブ・タイムアウト

完全に利用されているプールのイベントで、接続リクエストがタイムアウトするまで非アクティブになることができる時間(秒)。

参照ポリシー

次の値のいずれかです:

  • follow: LDAP検索時に参照に従います(デフォルト)

  • ignore: LDAP検索時に参照エントリを無視します

  • throw: 参照の例外によって発生します。コンポーネントのユーザーによって検出可能です。

パスワード管理の有効化

下にリストされた属性値に対するパスワード・ポリシー強制を有効化します。パスワード・ポリシー内の対応するオプションも同様に構成する必要があります。

Oblixユーザー・スキーマの使用

標準のOracleスキーマのかわりにOBLIXスキーマを使用できるようにします。

グローバル共通ID属性

ユーザーID属性の名前を指定します。この属性は、ユーザーIDがパスワードの一部になっていないことを確認するために、パスワード・ポリシーの一部として使用されます。

名属性

名属性の名前を指定します。この属性は、ユーザーの名前がパスワードの一部になっていないことを確認するために、パスワード・ポリシーの一部として使用されます。

姓属性

姓属性の名前を指定します。この属性は、ユーザーの姓がパスワードの一部になっていないことを確認するために、パスワード・ポリシーの一部として使用されます。

結果タイム・リミット(秒)

結果タイム・リミットはサポートされません。かわりに、次の説明に従ってOperationTimeoutを使用してください。

OperationTimeoutでは、LDAPリクエストがLDAPリモート・ホストによって承認されるのをIDSが待機する時間(ミリ秒単位)を指定します。

デフォルト値は120000ミリ秒です

IDSベース・プロファイルでは、modifyLDAPAdapter WLSTコマンドを使用してタイムアウト値を設定します。たとえば: 

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='OperationTimeout', value=120000, contextName='ids')

元のIDストア・プロファイルでは、oam-config.xmlを編集してIDストア・スニペット内の値を設定します。たとえば、 

<Setting Name="CONN_TIMEOUT" Type="xsd:string">120000</Setting>

「OAM構成の更新」を参照してください

再試行回数

現行ではサポートされていません。

電子メール・アドレス属性

現行ではサポートされていません。

チャレンジ質問属性

現行ではサポートされていません。

チャレンジ回答属性

現行ではサポートされていません。

図5-2に、デフォルトとシステム・ストアの指定内容を示します。「アクセス・システム管理者」セクションを参照してください。定義済のシステム・ストアおよびストア自体内のみで、管理者ロールを追加または削除できます。

図5-2 システム・ストア登録

図5-2の説明が続きます
「図5-2 システム・ストア登録」の説明

関連項目:

ユーザーの分類の詳細は、「リソースの保護およびSSOの有効化ポリシーの管理」を参照してください。

5.2.5 新しいユーザー・アイデンティティ・ストアの登録

有効なOracle Access Management管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して新しいユーザー・アイデンティティ・ストアを登録できます。

アイデンティティ・ストアを登録した後、それを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。また、認可ポリシーのアイデンティティ条件内にある特定のアイデンティティ・ストアを参照することもできます。始める前に:

次の手順に従い、新しいユーザー・アイデンティティ・ストアの定義を登録します。

  1. Oracle Access Managementコンソールの上部にある「構成」をクリックします。

  2. 「構成」コンソールで、「ユーザー・アイデンティティ・ストア」をクリックします。

  3. 「OAM IDストア」セクションで、「作成」をクリックします。

  4. デプロイメントに適した値をフォームに入力し(表5-4)、「適用」をクリックして登録を送信します。

  5. 接続テスト: 「接続テスト」をクリックして接続性を確認し、確認ウィンドウを閉じます。

  6. 登録ページを閉じます。

  7. 管理者の追加: 「管理者ロールの管理」を参照してください。

    1. ナビゲーション・ツリーで、登録ページを開くストア名をダブルクリックします。

    2. 「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。

    3. 「システム管理者ロールの追加」ダイアログ・ボックス(...)に入力します。

    4. 「適用」をクリックします。

  8. デフォルト・ストアの設定: 「ユーザー・アイデンティティのシステム・ストアの使用について」を参照してください。

  9. 「適用」をクリックして登録を送信してから、ページを閉じます。

  10. 次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。

5.2.6 ユーザー・アイデンティティ・ストア登録の表示または編集

有効なOracle Access Management管理者の資格証明を持つユーザーは、ユーザー・アイデンティティ・ストアの登録を表示または変更できます。登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。

ユーザー・アイデンティティ・ストアを表示または変更するには:

  1. Oracle Access Managementコンソールの上部にある「構成」をクリックします。
  2. 「構成」コンソールで、「ユーザー・アイデンティティ・ストア」をクリックします。
  3. 「OAM IDストア」リストで、ターゲット・アイデンティティ・ストアを選択し、「編集」をクリックします。
  4. 必要に応じて値を変更します(表5-4を参照)。
  5. 「適用」をクリックして、登録を更新します(または変更を適用しないでタブを閉じます)。
  6. 接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、確認ウィンドウを閉じます。
  7. システム・ストアまたはデフォルト・ストアとして設定: 「ユーザー・アイデンティティのシステム・ストアの使用について」を参照してください。
  8. 管理者ロールの管理: 「管理者ロールの管理」を参照してください。
  9. 次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。
  10. 終了する際はページを閉じます。

5.2.7 ユーザー・アイデンティティ・ストア登録の削除

有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、Oracle Access Managementコンソールによりユーザー・アイデンティティ・ストアの登録を削除できます。デフォルト・ストアまたはシステム・ストアの登録は削除できません。

ユーザー・アイデンティティ・ストア登録を削除するには、次のようにします。

  1. 削除するストアを参照しているLDAP認証モジュールを編集します(有効なアイデンティティ・ストアがモジュール内で参照されているか確認するため)。
  2. Oracle Access Managementコンソールの上部にある「構成」をクリックします。
  3. 「構成」コンソールで、「ユーザー・アイデンティティ・ストア」をクリックします。
  4. 「OAM IDストア」リストで、ターゲット・アイデンティティ・ストアを選択し、「削除」をクリックします。
  5. 表示される確認ダイアログで、「削除」をクリックして削除を確認します(または「取消」をクリックしてウィンドウを閉じ、インスタンスを保持します)。
  6. 定義がナビゲーション・ツリーにないことを確認します。

5.3 アイデンティティ・ディレクトリ・サービスのユーザー・アイデンティティ・ストアの管理

アイデンティティ・ディレクトリ・サービス(IDS)は、Access Managerが複数のアイデンティティ・データ・ストアにアクセスするために使用する柔軟で構成可能なサービスです。IDSの目的は、Access Manager自体とともにデプロイされていないアイデンティティ・ストアのユーザーまたはグループを管理できるようにすることです。

次の各項で、詳細を説明します。

5.3.1 アイデンティティ・ディレクトリ・サービス

アイデンティティ・ディレクトリ・サービスでは、冗長な構成を排除し、アイデンティティ管理操作を簡素化する、アイデンティティ・ストア・アクセスのための一貫性のある合理化されたテクノロジを提供します。

IDSには次のような利点があります。

  1. ディレクトリにより管理されるネイティブのユーザー/パスワードの状態との統合など、様々なユーザー・ディレクトリ・タイプのサポート。

  2. Oracle Identity Managementコンポーネント間で一貫した管理ユーザー・インタフェースおよび様々なアイデンティティ・ストアを使用するためのパラダイム。

  3. 組込みのフェイルオーバーおよびロード・バランシング機能。

  4. 論理属性から物理属性へのマッピングとエンティティ関係。

次に、サポートされているディレクトリ・サーバーのリストを示します。

  • 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は、アイデンティティ・ディレクトリ・サービス・コンソールのページのスクリーン・キャプチャです。

図5-3 アイデンティティ・ディレクトリ・サービス・コンソールのページ

図5-3の説明が続きます
「図5-3 アイデンティティ・ディレクトリ・サービス・コンソールのページ」の説明

ノート:

このページには、従来のOAM IDストアの構成パネルが含まれていることに注意してください。アイデンティティ・データ・ストアへのアクセスには、従来のOAM IDストア機能ではなく、アイデンティティ・ディレクトリ・サービス・プロファイルを使用することをお薦めします。OAM IDストア機能は今後のリリースで非推奨になります。

アイデンティティ・ディレクトリ・サービス・ストアの構成には、IDSプロファイルおよびIDSリポジトリのパラメータの構成が含まれます。IDSプロファイルでは、特定のタイプのアイデンティティ・ストアの全範囲の特性を指定します。これはリポジトリの論理構成で、次のデータが含まれます。

  • エンティティ定義

  • エンティティ関係定義

  • デフォルトの操作構成(テナントの検索/作成ベース、テナント・フィルタ、タイムアウトおよびキャッシュ構成を含む)

IDSリポジトリ構成は、実際のストアの場所を定義します。IDSリポジトリは、次のデータを含む物理構成です。

  • 接続の詳細(ホスト・マシン、ポート番号および資格証明を含む) 接続プールの詳細 高可用性/フェイルオーバー構成 エンティティ属性マッピング

5.3.2 Identity Directory Serviceプロファイルの作成

「構成」コンソールからアイデンティティ・ディレクトリ・サービス・プロファイルを作成できます。

作成するには、次のようにします。

  1. Oracle Access Managementコンソールの上部にある「構成」をクリックします。

  2. 「構成」コンソールで、「ユーザー・アイデンティティ・ストア」をクリックします。

  3. 「IDSプロファイル」セクションで、「作成」をクリックします。

    図5-4に示すように、「IDSプロファイルの作成」ページが表示されます。

    図5-4 「IDSプロファイルの作成」ページ

    図5-4の説明が続きます
    「図5-4 「IDSプロファイルの作成」ページ」の説明

  4. 新しいIdentity Directory Serviceプロファイルの次の値を指定します。

    • 名前 - このユーザー・プロファイル・サービス・プロバイダに一意の名前を入力します。

    • 説明 - (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

  5. 「新規作成」または「既存のものを使用」を選択して、リポジトリのプロパティを構成します。

    「新規作成」では、アイデンティティ・ディレクトリ・サービス接続の新しいリポジトリ・オブジェクト(つまり、LDAPディレクトリ・サーバーの参照)を定義します。「リポジトリ」セクションで値を定義した後に、「接続テスト」をクリックして、定義した値に間違いがないことを確認します。このオプションは、新しいアイデンティティ・ディレクトリ・サービス接続を定義している場合にのみ使用可能です。「既存のものを使用」を使用すると、以前に定義したリポジトリ・オブジェクトをドロップダウン・メニューから選択できるようになります。

    • (リポジトリの)「名前」 - 新しい一意の名前を入力するか(作成する場合)、メニューから既存のものを選択します。新しい名前を入力した後には、アイデンティティ・ディレクトリ・サービス接続のプロパティを構成します。

    • ディレクトリ・タイプ - Microsoft Active DirectoryやOracle Internet Directoryなど、リポジトリをホストするディレクトリ・サーバー・ソフトウェアのタイプを選択します。ディレクトリがリストされない場合は、このフィールドを空白のままにします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

    • ホスト情報 - アイデンティティ・ディレクトリ・サービス・リポジトリが配置されているホスト・コンピュータに関する情報を格納します。ディレクトリ・サーバーがクラスタの一部である場合は、複数のホストを追加します。新しいホストを表に追加するには、「追加」をクリックします。「ホスト名」列に、IPアドレスまたはディレクトリ・サーバーが実行されているコンピュータ(または仮想コンピュータ)の名前を入力します。「ポート」列に、ディレクトリ・サーバーが使用するように構成されているポート番号を入力します。ホストがクラスタの一部である場合は、負荷分散列に、各ホストにダイレクトされる負荷の量をパーセントとして入力します。複数のホストの場合、量の合計が100%になる必要があります。ホストを削除するには、表でその行を選択し、「削除」をクリックします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

    • 可用性 - クラスタがフェイルオーバー操作用に構成されている場合はフェイルオーバーを選択し、クラスタが複数のホストに負荷を分散している場合はロード・バランスを選択します。既存のリポジトリを使用している場合、このフィールドは読取り専用です。

    • SSL - 接続がSSL用に構成されている場合は、「有効」を選択します。(SSL構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。)

      ノート:

      TLS接続の設定に必要なSSL証明書を追加するには、次の手順を実行します。

      1. 次のコマンドを実行して、LibOVDキーストアを作成します。

        MW_HOME/oracle_common/bin/libovdconfig.sh -host WLS_ADMIN_HOST 
 -port WLS_ADMIN_PORT -userName weblogic 
 -domainPath WLS_DOMAIN_PATH -createKeystore 
 -contextName ids

        要求されたら、AdminServerパスワードおよびLibOVDキーストアに使用するパスワードを入力します。

      2. OIDサーバー証明書をLibOVDキーストアにインポートします。

        keytool -importcert 
 -keystore DOMAIN_HOME/config/fmwconfig/ovd/
ids/keystores/adapters.jks 
 -storepass KEYSTORE_PASSWORD -alias ALIAS_NAME 
 -file FULL_PATH_TO_CERTFILE -noprompt

    • バインドDN - ディレクトリ・サーバーから認証を受けるために使用するLDAP管理者の識別名(DN)を入力します。

    • バインド・パスワード - ディレクトリ・サーバーから認証を受けるために使用するバインドDNパスワードを入力します。

    • ベースDN - ユーザーおよびグループのデータが配置されているベース識別名(DN)を入力します。

    • パスワード管理 - 「パスワード管理の有効化」を選択すると、表5-4に示した属性値に対するパスワード・ポリシー強制が有効になります。パスワード・ポリシー内の対応するオプションも同様に構成する必要があります。

  6. ユーザー・プロパティを設定して、LDAPユーザー・オブジェクトを構成します。

    ノート:

    既存のアイデンティティ・ディレクトリ・サービス接続を使用している場合、これらのフィールドは読取り専用です。

    • オブジェクト・クラス - ディレクトリ・サーバーで定義されている組織内の人々を表すカスタム・オブジェクト・クラスを追加するには、「追加」をクリックします。

    • RDN属性 - ディレクトリ・サーバー上のユーザー・オブジェクトに対して指定されている相対識別名属性(cnなど)を入力します。

    • ベースDN- ディレクトリ・サーバー上のユーザー・オブジェクトのベースDNを(LDAP形式で)入力します。

    • ログインID属性 - ユーザーを指定するログインIDの抽出元になるLDAP属性を入力します。

    • グローバル共通ID属性 - グローバルな共通のユーザーID属性を入力します。

  7. グループ・プロパティを設定して、LDAPグループ・オブジェクトを構成します。

    • オブジェクト・クラス - ディレクトリ・サーバーで定義されている組織内の人々のグループを表すカスタム・オブジェクト・クラスを追加するには、「追加」をクリックします。

    • RDN属性 - ディレクトリ・サーバー上のグループ・オブジェクトに対して指定されている相対識別名属性(cnなど)を入力します。

    • ベースDN- ディレクトリ・サーバー上のグループ・オブジェクトのベースDNを(LDAP形式で)入力します。

    • ID属性 - グループ・オブジェクトに対して指定されているIDの抽出元になるLDAP属性を入力します。

  8. 「作成」をクリックします。

    プロファイルが、「IDSプロファイル」リストに表示されます。

5.3.3 アイデンティティ・ディレクトリ・サービス・プロファイルの編集または削除

IDSプロファイルを編集または削除するには、表で名前を選択してから、ツール・バーにある「編集」または「削除」をクリックします。

プロファイルを編集することにより、アイデンティティ・ディレクトリ・サービス接続の追加構成プロパティが可能になります。

  • 名前 - ドロップダウン・メニューから、ユーザー・プロファイル・サービス・プロバイダと関連付けるアイデンティティ・ディレクトリ・サービス接続を選択します。

    • デフォルトのアイデンティティ・ディレクトリ・サービスのいずれか(userroleまたはidxuserroleのいずれか)を選択すると、構成値の表示や編集はできなくなります。

    • 管理者が作成したアイデンティティ・ディレクトリ・サービス接続を選択すると、構成値を必要に応じて表示および編集できるようになります。

  • 一般およびリポジトリ - このタブのフィールドを使用して、ディレクトリ・サービスおよびリポジトリの構成値を編集します。

    • リポジトリ名 - このメニューから、アイデンティティ・ディレクトリ・サービス接続と関連付けるリポジトリを選択します。リポジトリを選択したら、次のフォームのフィールドを使用してそのプロパティを構成します。

    • ディレクトリ・タイプ - Microsoft Active Directory、Oracle Internet Directoryなど、リポジトリをホストするディレクトリ・サーバー・ソフトウェアのタイプを表示します。このフィールドは読取り専用です。

    • ホスト情報 - アイデンティティ・ディレクトリ・サービス・リポジトリが配置されているホスト・コンピュータに関する情報を表示します。ディレクトリ・サーバーがクラスタの一部である場合は、複数のホストを追加します。新しいホストを表に追加するには、「追加」をクリックします。「ホスト名」列に、IPアドレスまたはディレクトリ・サーバーが実行されているコンピュータ(または仮想コンピュータ)の名前を入力します。「ポート」列に、ディレクトリ・サーバーが使用するように構成されているポート番号を入力します。ホストがクラスタの一部である場合は、負荷分散列に、各ホストにダイレクトされる負荷の量をパーセントとして入力します。複数のホストの場合、量の合計が100%になる必要があります。ホストを削除するには、表でその行を選択し、「削除」をクリックします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

    • 可用性 - クラスタがフェイルオーバー操作用に構成されている場合はフェイルオーバーを選択し、クラスタが複数のホストに負荷を分散している場合はロード・バランスを選択します。既存のリポジトリを使用している場合、このフィールドは読取り専用です。

    • SSL - 接続がSSL用に構成されている場合は、「有効」を選択します。それ以外の場合は、オプション・ボックスをクリアにします。TLS接続に必要なSSL証明書を追加する方法の詳細は、「Identity Directory Serviceプロファイルの作成」の「SSL」を参照してください。

    • バインドDN - ディレクトリ・サーバーから認証を受けるために使用するLDAP管理者の識別名(DN)を入力します。

    • バインド・パスワード - ディレクトリ・サーバーから認証を受けるために使用するバインドDNパスワードを入力します。

    • ベースDN - ユーザーおよびグループのデータが配置されているベース識別名(DN)を入力します。

    • パスワード管理 - 「パスワード管理の有効化」を選択すると、表5-4に示した属性値に対するパスワード・ポリシー強制が有効になります。パスワード・ポリシー内の対応するオプションも同様に構成する必要があります。

  • エンティティ属性 - このタブのフィールドを使用して、属性を表示または編集します。「追加」をクリックして表に属性を追加するか、「削除」をクリックして属性を削除します。

    • 名前 - 属性名。

    • 物理属性 - 基盤となるリポジトリの対応する物理属性タイプの名前。

    • タイプ - 属性のデータ・タイプ。

    • 説明 - 属性の簡単な説明。

    • 機密 - 属性にパスワードなどの機密情報が含まれていることを示す場合に選択します。

    • 読取り専用 - 変更されないように属性を保護する場合に選択します。

  • エンティティ/ユーザー・プロパティ - この「ユーザー」サブヘッダーのフィールドを使用して、LDAPサーバーのユーザー・エンティティとの対話処理を構成します。

    • ベースの作成 - ユーザーを定義するベースDN (LDAPディレクトリ・ツリーの最上位レベル)を指定します。

    • 検索ベース - ユーザーの検索ベースDNを指定します。検索操作が処理されるときは、検索ベースDNにあるかそれより下のエントリのみが対象になります。

    • オブジェクト・クラスの作成 - 個人に関連付けられている属性が格納されているオブジェクト・クラスを指定します。

    • RDN属性 - 相対識別名属性を指定します。たとえば、cnです。

    • ID属性 - ユーザーを一意に識別する属性を指定します。uid属性やloginid属性などです。

    • フィルタ・オブジェクト・クラス - フィルタ条件にするオブジェクト・クラスを指定します。

    • 属性構成 - ユーザー・プロファイル・サービス・プロバイダによる使用と検索を可能にするユーザーの属性を指定します。

      • 使用中 - 属性が、ディレクトリ・サービスでユーザーに対して使用されている場合に指定します。

      • 属性名 - 「エンティティ属性」タブで定義した属性の名前を指定します。

      • 結果内 - 指定した属性を、検索結果で返す必要がある場合に選択します。

      • 検索可能 - 指定した属性を検索操作に対して使用可能にする場合に選択します。

      • 検索演算子 - 指定した属性の検索方法を制限するには、このメニューから検索演算子を選択します。

    • 操作構成 - ユーザー・エンティティ・レベルで有効にする操作を「作成」、「更新」、「削除」、および「検索」から選択します。これらを無効にするには、オプション・ボックスをクリアします。

  • エンティティ/グループ・プロパティ - この「グループ」サブヘッダーのフィールドを使用して、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属性 - URIレスポンスで使用されるJSON属性名を入力します。たとえば、指定されているエンティティURI属性がperson-uriである場合、URIレスポンスは次のようになります。 

      { {"person-uri":uriY1, ...}, {"person-uri":uriY2, ...}, ... }

      ここで、 uriY1およびuriY2は、関連エンティティのそれぞれにアクセスするための直接URIです。

    • 再帰型をリクエストするスコープ - 関係検索で、ネストされたレベルの属性を取得するには、スコープ属性値をスコープ問合せパラメータとともに使用します。再帰的に関連エンティティにアクセスするには、使用する値を入力します。

      「再帰型をリクエストするスコープ」の値が属性値allである場合、次のREST URIの例が使用されてリクエストが実行されます。 

      http://host:port/.../idX/reports?scope=all

      この例では、URIによって、ID idXを持つエンティティに関連するエンティティが、それに続いて関連しているエンティティすべてとともに返されます。

5.3.4 フォーム入力アプリケーションのアイデンティティ・ディレクトリ・サービス・プロファイルの作成

フォーム入力アプリケーションのアイデンティティ・ディレクトリ・サービス・プロファイルを作成するには、「ユーザー・アイデンティティ・ストア」コンソール・ページの左側にある「フォーム入力アプリケーションIDSプロファイルの作成」ボタンをクリックします。

(図5-3を参照してください。)

「Identity Directory Serviceプロファイルの作成」および「アイデンティティ・ディレクトリ・サービス・プロファイルの編集または削除」には、ほとんどのフォーム入力属性の定義が示されています。このタイプのプロファイルに固有の「エンティティ検索ベース」セクションの追加定義を次に示します。

  • ユーザー検索ベース - エンタープライズ・ユーザーが格納されるディレクトリ内のノードのフルDN (cn=Users,realm_DNなど)。

  • アプリケーション・テンプレート検索ベース - アプリケーション・テンプレートの検索が開始されるノードのフルDN。

  • 上位検索ベース - 検索が開始されるノードのフルDN (cn=realm_DNなど)。

5.3.5 事前構成されたアイデンティティ・ディレクトリ・サービス・プロファイルの理解

Mobile and Socialでは、UserIdentityStore1という事前構成済のIDSプロファイルが提供されます。事前構成されたアイデンティティ・ディレクトリ・サービス・プロファイルにより、Mobile and Socialを使用するディレクトリ・オブジェクトに対して、参照タスクと更新タスクを実行できるようになります。

5.3.6 アイデンティティ・ディレクトリ・サービス・リポジトリの作成

「構成」コンソールからアイデンティティ・ディレクトリ・サービス・リポジトリを作成できます。

アイデンティティ・ディレクトリ・サービス・リポジトリを作成するには、次を参照してください。

  1. Oracle Access Managementコンソールの上部にある「構成」をクリックします。
  2. 「構成」コンソールで、「ユーザー・アイデンティティ・ストア」をクリックします。
  3. 「IDSリポジトリ」の下の「作成」をクリックします。

    図5-5に示すように、「IDSリポジトリの作成」ページが表示されます。

    図5-5 「IDSリポジトリの作成」ページ

    図5-5の説明が続きます
    「図5-5 「IDSリポジトリの作成」ページ」の説明
  4. 新しいアイデンティティ・ディレクトリ・サービス・リポジトリに対して次の値を指定します。

    1. 名前: 一意の値を入力する必要があります。

    2. ドロップダウンの選択肢から「ディレクトリ・タイプ」を選択します。

  5. 「追加」をクリックして、リポジトリの物理的な場所を構成します(ホスト名、ポート番号およびロードの重みのパーセンテージ)。
  6. リポジトリのプロパティを次のように構成します。

    1. (リポジトリの)「名前」 - 新しい一意の名前を入力するか(作成する場合)、メニューから既存のものを選択します。新しい名前を入力した後には、アイデンティティ・ディレクトリ・サービス接続のプロパティを構成します。

    2. ディレクトリ・タイプ - Microsoft Active DirectoryやOracle Internet Directoryなど、リポジトリをホストするディレクトリ・サーバー・ソフトウェアのタイプを選択します。ディレクトリがリストされない場合は、このフィールドを空白のままにします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

    3. ホスト情報 - アイデンティティ・ディレクトリ・サービス・リポジトリが配置されているホスト・コンピュータに関する情報を格納します。ディレクトリ・サーバーがクラスタの一部である場合は、複数のホストを追加します。新しいホストを表に追加するには、「追加」をクリックします。「ホスト名」列に、IPアドレスまたはディレクトリ・サーバーが実行されているコンピュータ(または仮想コンピュータ)の名前を入力します。「ポート」列に、ディレクトリ・サーバーが使用するように構成されているポート番号を入力します。ホストがクラスタの一部である場合は、負荷分散列に、各ホストにダイレクトされる負荷の量をパーセントとして入力します。複数のホストの場合、量の合計が100%になる必要があります。ホストを削除するには、表でその行を選択し、「削除」をクリックします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

    4. 可用性 - クラスタがフェイルオーバー操作用に構成されている場合はフェイルオーバーを選択し、クラスタが複数のホストに負荷を分散している場合はロード・バランスを選択します。既存のリポジトリを使用している場合、このフィールドは読取り専用です。

    5. SSL - 接続がSSL用に構成されている場合は、「有効」を選択します。TLS接続に必要なSSL証明書を追加する方法の詳細は、「Identity Directory Serviceプロファイルの作成」の「SSL」を参照してください。(SSL構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。)

    6. バインドDN - ディレクトリ・サーバーから認証を受けるために使用するLDAP管理者の識別名(DN)を入力します。

    7. バインド・パスワード - ディレクトリ・サーバーから認証を受けるために使用するバインドDNパスワードを入力します。

    8. ベースDN - ユーザーおよびグループのデータが配置されているベース識別名(DN)を入力します。

    9. パスワード管理 - 「パスワード管理の有効化」を選択すると、表5-4に示した属性値に対するパスワード・ポリシー強制が有効になります。パスワード・ポリシー内の対応するオプションも同様に構成する必要があります。

  7. 「接続テスト」をクリックして、値が正しいことを確認します。
  8. 「作成」をクリックします。

    リポジトリが「IDSリポジトリ」表に表示されます。

5.4 管理者ロールの管理

デフォルトでは、Oracle Access Managementの管理者ロールはWebLogicの管理者ロール(Administrators)と同じです。

他のユーザー・アイデンティティ・ストア(たとえばOracle Internet Directory)を登録することもできますが、ただし、認証先の登録済ストアの少なくとも1人のユーザーを使用してユーザーweblogicを定義する必要があります。管理者ログインは、認証スキーム(および割り当てられた認証モジュール)がそのシステム・ストアも使用する場合にのみ機能します。この項では次のトピックを記載しています:

5.4.1 管理者ロールの理解

企業によっては、Access Managerを担当するユーザーとSecurity Token Serviceを担当するユーザーに別の管理者グループが必要になることがあります。すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。

アイデンティティ・ストア登録の編集時にストアをシステム・ストアとして指定すると、「アクセス・システム管理者」セクションが表示されます。ユーザー・アイデンティティ・ストア登録を追加または編集するときに、新しい管理者ロールを追加できます。図5-6は、使用するページとコントロールを示しています。

図5-6 システム管理者ロールの追加

図5-6の説明が続きます
「図5-6 システム管理者ロールの追加」の説明

5.4.2 管理者ロールの定義および削除

システム・ストアとして指定したユーザー・アイデンティティ・ストアに格納する必要があるOracle Access Management管理者ロールを定義または削除できます。

まず、管理者が使用できるように目的のLDAPグループを定義してから、管理者グループがグループ検索ベースで使用可能なことを確認します。(「ユーザー・アイデンティティのシステム・ストアの使用について」を参照してください。)システム・ストアに管理者ロールを追加またはシステム・ストアから削除するには、次の手順に従います。

  1. システム・ストア登録の表示: 次のステップを実行します(またはシステム・ストアとして指定する、「データ・ソース」ノード内の異なるシステム・ストアを検索します)。

    1. Oracle Access Managementコンソールの上部にある「構成」をクリックします。

    2. 「構成」コンソールで、「管理」をクリックします。

      登録したシステム・ストアは、このページからは変更できません。

    3. システム・ストアを検索して構成済の管理者を見つけます。

  2. ユーザー・ロールの追加:

    1. 「アクセス・システム管理者」表の上にある「付与」(+)ボタンをクリックして、「ユーザーとグループの追加」ダイアログ・ボックスを表示します。

    2. 「タイプ」リストで「ユーザー」を選択し、「検索」をクリックします。

    3. 結果リスト内で目的のユーザーをクリックし、「選択済の追加」をクリックします。

    4. 必要に応じて繰り返し、目的の管理者ユーザー・ロールを追加します。

    5. 「適用」をクリックしてユーザー・ロールを送信します。

  3. グループ・ロールの追加:

    1. 「アクセス・システム管理者」表の上にある「付与」(+)ボタンをクリックして、「ユーザーとグループの追加」ダイアログ・ボックスを表示します。

    2. 「タイプ」リストの「グループ」を選択し、「検索」ボタンをクリックします。

    3. 結果リスト内で目的のグループをクリックし、「選択済の追加」ボタンをクリックします。

    4. 必要に応じて繰り返し、目的の管理者グループ・ロールを追加します。

    5. 「適用」をクリックしてグループ・ロールを送信します。

  4. 管理者ロールの削除:

    1. 「アクセス・システム管理者」表で、削除するユーザーまたはグループを含む行をクリックします。

    2. 表の上にある「削除」(x)ボタンをクリックします。

    3. 確認するメッセージが表示されたら確認します。

    4. 「適用」をクリックして削除を送信します。

  5. システム・ストアを使用する認証プラグインを修正します(新しいストアの場合)。

    この手順の詳細は、「プラグイン・ベースのモジュールによるマルチステップ認証の編成」を参照してください。

  6. 新しいロールのテスト: ブラウザのウィンドウを閉じてから、再び開きます。

    1. Oracle Access Managementコンソールからサインアウトしてブラウザ・ウィンドウを閉じます。

    2. Oracle Access Managementコンソールを起動して、以前の管理者ロールを使用してログインを試み、これが失敗することを確認します。

    3. 新しい管理者ロールを使用してログインし、この試みが成功することを確認します。

      ログイン失敗: 「管理者のロックアウト」を参照してください。

5.5 ポリシーおよびセッション・データベースの管理

Oracle Access Managementには、Access Managerのポリシー・データ、パスワード管理データおよびAccess Managerセッションを本番環境で保存するデータベースが必要です。最大でも、デプロイメントに含まれるのは、1つのポリシー・ストア・データベース(パスワード管理の役割を果たす)と、1つのセッション・ストアです。デフォルトでは、単一のJDBCデータ・ストアが両方に使用されます。

この項には次のトピックが含まれます:

5.5.1 ポリシー、パスワード管理およびセッションのデータベース・ストアについて

本番環境では、OracleデータベースにAccess Managerのポリシー・データ、パスワード管理データおよびセッションが格納されます。

デフォルトでは、ポリシー・ストア・データベースに次のデータが格納されます。

  • 認証モジュール、スキーム、アプリケーション・ドメインおよびポリシーを含むポリシー・データ。

  • 構成済のユーザー・アイデンティティ・ストアごとのパスワード・ポリシー・タイプ、およびパスワードの要件、失効、通知を制御するポリシーを含んだパスワード管理データ。

  • 分散されたメモリー内のストレージに対する永続的なバックアップとしてのセッション・データ。

ノート:

本番環境での監査データ・ストレージの推奨モードは、スタンドアロンの監査データ専用RDBMSデータベースに監査レコードを書き込むことです。これは、個別に構成された監査ストアを使用して行います。ポリシー・ストアは監査データには使用されません。

関連項目:

「ポリシーおよびセッション・データベースの管理」

5.5.2 データベースのデプロイメントについて

Oracleには、本番環境のポリシー・ストアとして1つのデータベースが必要です。この単一のデータベースは、セッション・データを保存するためにも使用できます。

データベースをセッション・ストアとして使用すると、スケーラビリティおよびフォールトトレランス性が増します(すべてのサーバーをダウンさせる電源イベントに対して)。

ノート:

データベースは最大2つまで、1つのポリシー・データベースと1つのセッション・データベースを使用できます。Access Managerは、実際のバックエンド・リポジトリには非依存であり、このポリシー・ストアの構成を直接的に管理することはありません。

ポリシー・データベースは、ベンダーの指示に従ってインストールする必要があります。ポリシー・データベースはOracle WebLogic Serverドメインで使用するように構成します。この構成には、Oracle Fusion Middleware構成ウィザードと、ポリシー・ストアのデータベース構成テンプレートを使用します。

WebLogic構成ウィザードを使用した初回のデプロイメント中に、次のデータベース詳細が要求されます。

  • データベース・ログインIDとパスワード

  • データベース・サービス名と場所

管理者は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のリポジトリ作成ユーティリティ画面の操作でスキーマを作成する項の説明に従って、RCUを使用するAccess Manager固有のスキーマでデータベースを拡張する必要があります(を参照してください)。基本的なスキーマの作成は、RCUが起動されたときに発生します。RCUは、データベースがAccess Managerポリシー、パスワード管理およびセッション・データを受け入れるように準備します。

WebLogic構成ウィザードを使用すると、データベースへの接続を登録およびテストできます。

実際のAccess Managerポリシー要素は、Oracle Access Managementコンソールがデプロイされて初めてWebLogic AdminServerが起動されたときに作成されます。

関連項目:

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOAM Suiteドメインの構成に関する項。

5.5.3 Access Managerセッションの個別データベースの構成

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を慎重に編集することをお薦めします。

  1. セッション・データのデータベースをインストールおよび構成して、RCUをAccess Manager固有のスキーマとともに使用し、セッション・データ・ストアとしてデータベースを設定します。

  2. セッション・データに新しいデータ・ソース・インスタンスを作成します。

    1. WebLogic管理コンソールからは、「ドメイン構造」パネルでドメイン名、「サービス」ノードを展開します。

    2. JDBC、データ・ソースを展開します。

    3. JNDI名jdbc/oamsessionというデータ・ソースを作成します。

    4. 変更を保存します。

    5. 次のステップでのデータ損失を防ぐために、OAMサーバーとAdminServerを停止します。

    6. oam-config.xmlで、DataSourceName属性の値を編集して、ステップ1で構成したものにします。たとえば:

      送信元 

      <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>

      「OAM構成の更新」を参照してください

  3. AdminServerとOAMサーバーを再起動します。

5.6 Oracle Access Managementキーストアの概要

認可時にOAMサーバーとWebgate間の簡易または証明書ベースの通信のための証明書として使用するために、Javaキーストアが設定されます。構成ウィザードを実行した後に、初回のAdminServer起動でキーストアのブートストラップも発生します。

この項では次のトピックを記載しています:

5.6.1 Access Managerセキュリティ・キーおよび組込みJavaキーストア

キーストアは、Access Managerのインストール時に作成および構成されます。パスワードおよびキー・エントリのパスワードはランダムに生成されます。

推奨のキーストア・フォーマットはJKS (Javaキーストア)です。Javaキーストアは水面下でAccess Managerに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成される暗号化セキュリティ・キーの格納に使用されます。

  • それぞれのOAMエージェントは、他のエージェントが読むことのできない秘密キーを持っています。

  • エージェントとアプリケーションの登録時に、SSO Cookie (Webgateの場合)の暗号化および復号化に使用されるキーが生成されます。

管理者は、「通信の保護」で説明されているように、Oracleが提供するimportcertツールをキーストア、キーおよび証明書に関連する様々な手順で使用します。

表5-5に、生成されるAccess Manager暗号化キーを示します。

表5-5 Access Managerキーと格納

キーと格納 説明

Access Manager暗号化キー

  • OAM WebゲートとOAMサーバー間で共有されるエージェントの秘密キーごとに1つ

  • 1つのOAMサーバー・キー

キー・ストレージ

  • エージェント側: エージェントごとのキーは、ローカルでウォレット・ファイルのOracleシークレット・ストアに格納されます。クライアント・キーストア/scratch/clientTrustStore.jksおよび/scratch/clientKey.jksを使用できます。

  • OAMサーバー側: .oamkeystoreはエージェントごとのキーとサーバー・キーを含み、サーバー側の資格証明ストアに格納されます。

キーストアには、Oracle Access Managementコンソールからアクセスできません。キーストアと証明書は、「通信の保護」で説明されているように管理できます。

関連項目:

「Identity Federationキーストア」

5.6.2 Access Managerキーストア

Access ManagerおよびSecurity Token Serviceのキーストアは、Access Mangerのインストール時に作成および構成されます。

表5-6に、Access Managerに対して使用されるキーストアの概要を示します。

表5-6 Access Managerとセキュリティ・トークン・サービスのキーストア

キーストア 説明

システム・キーストア/パートナ・キーストア

.oamkeystore

OAMサーバー・インスタンスに関連付けられたキーおよび証明書のコンテナ(署名および暗号化のためのOAM秘密キー)。

パートナ、クライアントおよびエージェントとの信頼性を確立するために使用されるキーおよび証明書のコンテナ。パートナ・キーおよび証明書は、機密情報が暗号化されて.oamkeystoreに格納されます。

JCEKSタイプのシステム・キーストア.oamkeystoreのみが存在することが可能です。

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

証明書の別名とパスワードは、Oracle Access Managementコンソールを使用して構成できます。

信頼キーストア

amtrustkeystore

信頼キーストアは、OAMサーバー・インスタンスと相互作用するエンティティに信頼性を確立するためにクライアントにより提供されるキーおよび証明書の検証に使用されます。

$DOMAIN_HOME/config/fmwconfig/amtruststore

amtruststoreはインストール時に作成され、少なくとも1つの信頼できるアンカーを含める必要があります。

信頼キーストアは、JREのkeytoolアプリケーションを使用して管理されます。セキュリティ・トークン・サービスではカスタム信頼キーストアを使用できます。

証明書失効リスト(CRL)

amcrl.jar

証明書失効情報リストは、ファイルシステム上のZIPアーカイブに格納されます。これらは、CRLベースの証明書失効確認の実行中に、OAMサーバーによって使用されます。

amcrl.jarには、DER形式のCRLファイルが含まれます。

$DOMAIN_HOME/config/fmwconfig/amcrl.jar

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がアクセスされる可能性があります。

OPSSキーストア

(Webサービス・リクエストの一部として受信される証明書トークンとは対照的に)クライアントがSKIなどの参照スキームを使用する特別な場合、リクエスタの証明書をOPSSキーストアに移入する必要があります。

これは、キーをOPSSキーストアに手動でプロビジョニングする必要がある、一般的ではないシナリオです。

関連項目:

5.6.3 Identity Federationキーストア

Identity FederationとAccess Managerは、デジタル署名と暗号化に使用するキー・ペアと証明書を格納します。

Identity Federationは、次のことを実行する際にキーを使用します。

  • 送信アサーションの署名

  • SAMLメッセージに含まれる着信XML暗号化データの復号化

次のキーストアは、暗号化証明書と署名証明書の格納に使用されます。

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

Identity Federationは、CSFを使用してキーストア・パスワードと、サーバーの資格証明(HTTP Basic認証のユーザー名とパスワードなど)を安全に格納します。

関連項目:

5.7 サポートされるLDAPディレクトリとOracle Access Managerとの統合

Oracle Access Managerのインストール後タスクで使用するために、集中管理されたLDAPストアを有効にできます。

ここではOracle Internet Directoryを取り挙げて説明しますが、どのLDAPディレクトリを選択してもタスクは同じです。

Oracle Access Managerでは、アイデンティティ・ドメインとして各ユーザー移入とLDAPディレクトリ・ストアに対応しています。それぞれのアイデンティティ・ドメインは、Oracle Access Managerに登録されている構成済のLDAPユーザー・アイデンティティ・ストアにマップされます。複数の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 Identity Management Suite統合ガイド』のIdM Suiteコンポーネント統合の概要を述べた項を参照してください。