35 レルムの計画、デプロイおよび管理
ノート:
このガイドで言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g (10.1.4.3.0)以上のことです。
35.1 アイデンティティ管理レルムの理解
この項では、アイデンティティ管理レルムの計画の概要について説明します。
この概要の項目は次のとおりです。
35.1.1 アイデンティティ管理レルム計画の概要
この項では、DIT全体およびデプロイメント対象のユーザーとグループの配置を構成する場合のガイドラインを示しています。これらのガイドラインを実装すると、膨大な数のデプロイメント構成を行うことになるため、デプロイメントの目的をディレクトリ自体にメタデータとして取得する必要があります。Oracle Identity Managementインフラストラクチャに依存するOracleソフトウェアおよびサード・パーティのソフトウェアは、このメタデータによってデプロイメントの目的を認識し、カスタマイズされた環境で正常に機能できます
「Oracle Internet Directory編成の理解」を参照してください。
Oracle Internet Directoryでは、デプロイメントの目的は、アイデンティティ管理レルムに取得されます。このレルムは、前述の項で配置について説明したユーザーおよびグループに対して、アイデンティティ管理ポリシーを設定する場合にも役立ちます。
アイデンティティ管理レルムは、ディレクトリ内の適用範囲が明確な領域で、次の要素で構成されています。
-
適用範囲が明確なエンタープライズ・アイデンティティの集合(米国内のすべての従業員など)
-
これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合
-
アイデンティティ管理ポリシーを設定しやすくするグループの集合(アイデンティティの集約)
DIT全体の構造およびユーザーとグループの配置を決定した後、アイデンティティ管理レルムのルートとして機能するディレクトリ・エントリを識別する必要があります。このエントリによって、レルムに定義されたアイデンティティ管理ポリシーの範囲が決まります。デフォルトでは、アイデンティティ管理レルムのルート下のディレクトリ・サブツリー全体が、範囲となります。このエントリの下に、OracleContext
という特別なエントリが作成されます。次の項目が含まれます。
-
ユーザーおよびグループのネーミングおよび配置などのデプロイメント固有のDIT設計(前述の項を参照)
-
このレルムに関連付けられたアイデンティティ管理ポリシー
-
Oracleアプリケーション特有のレルム固有の追加情報
アイデンティティ管理レルムを計画する場合は、次のことを考慮します。
-
企業のセキュリティ要件に基づいて、アイデンティティ管理レルムのルートを選択する必要があります。通常、ほとんどの企業で必要なレルムは1つのみです。ただし、個別のアイデンティティ管理ポリシーを使用して複数のユーザー集団を管理するときは、複数のレルムが必要になる場合があります。
-
サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、選択したアイデンティティ管理レルムのルートを、サード・パーティのディレクトリのDIT設計と一致させます。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。
-
アイデンティティ管理レルムを構成し管理するには、Oracle Internet Directoryで提供される管理ツールを使用します。これには、Oracle Identity Management 10g (10.1.4.3.0)以上のOracle Internet Directoryセルフサービス・コンソールやコマンド行ツールなどがあります。
関連項目:
『Oracle Identity Managementリファレンス』のOracle Internet Directoryレルム・ツールに関する項の
oidrealm
コマンドのリファレンス。 -
Oracle Internet Directoryツールを使用してアイデンティティ管理レルムを構成した後、デプロイメントによって行われたカスタマイズを反映するために、ディレクトリのネーミングおよび格納ポリシーの更新を計画します。この更新は、Oracle Identity Managementインフラストラクチャを使用する他のOracleコンポーネントをインストールして使用する前に行う必要があります。
図35-1に、MyCompanyという会社のアイデンティティ管理レルムの例を示します。
図35-1 アイデンティティ管理レルムの例
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag119.gif)
図35-1の例では、デプロイメントでドメイン名ベースのDIT構造を使用しています。コンテナdc=us,dc=mycompany,dc=com
は、アイデンティティ管理レルムのルートです。その結果、デフォルトで、適用範囲がdc=us
エントリ下のディレクトリ・サブツリー全体に限定される新しいアイデンティティ管理レルムが作成されます。アイデンティティ管理レルムの名前はUS
です。
35.1.2 企業内デプロイメントにおけるアイデンティティ管理レルムの理解
次の各トピックでは、単一および複数のアイデンティティ管理レルムを使用するデプロイメントについて説明します。
35.1.2.1 企業における単一アイデンティティ管理レルムについて
この例では、企業にはユーザーの集団が1つあり、そのすべてのユーザーが同一のアイデンティティ管理ポリシーによって管理されます。これは、すべてのOracle製品のデフォルトの構成です。Oracle Internet Directoryに存在するデフォルトのアイデンティティ管理レルムは1つのみであり、企業内のすべてのOracleコンポーネントが、このレルムのユーザーに対応します。図35-2に、この使用方法を示します。
図35-2 企業での使用例: 単一アイデンティティ管理レルム
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag112.gif)
図35-2の例には、従業員のみを含む単一のデフォルトのアイデンティティ管理レルムがあります。このレルムでは、すべてのユーザーおよびグループが管理され、同じアプリケーションであるアプリケーションAおよびアプリケーションBへのアクセスを共有しています。
35.1.2.2 企業における複数アイデンティティ管理レルムについて
同一のアイデンティティ管理インフラストラクチャを使用して、内部ユーザーと外部の自己登録ユーザーの両方に対応することも可能です。内部ユーザーと外部ユーザーではアイデンティティ管理ポリシーが異なるため、内部ユーザー用と外部ユーザー用にレルムを1つずつデプロイできます。図35-3に、この使用方法を示します。
図35-3の例では、デフォルトのアイデンティティ管理レルムは内部ユーザー(従業員)用であり、これらの内部ユーザーにはアプリケーションA、BおよびCへのアクセス権があります。外部アイデンティティ管理レルムは外部ユーザー用であり、外部ユーザーには、アプリケーションCおよびDへのアクセス権があります。
35.1.3 ホスティングされたデプロイメントにおけるアイデンティティ管理レルムの概要
ホスティングされたデプロイメントでは、アプリケーション・サービス・プロバイダ(ASP)が、1社以上にアイデンティティ管理サービスを提供し、これらの企業にかわってアプリケーションのホスティングを行います。ホスティングされた各企業は、その企業のユーザーが管理される個別のアイデンティティ管理レルムに対応付けられます。アプリケーション・サービス・プロバイダに属するユーザーは、別のレルム(通常は、デフォルトのレルム)で管理されます。
図35-4に、ホスティングされたデプロイメント(2社をホスティング)を示します。
図35-4 ホスティングされたデプロイメントでの使用例
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag124.gif)
図35-4の例では、ASPユーザーはデフォルトのアイデンティティ管理レルムに存在します。ASPは、そのレルムのユーザー、グループおよび関連するポリシーを管理します。ASPユーザーは、ホスティングされた企業のためにアプリケーションA、B、Cを管理しています。ホスティングされた企業のMyCompanyユーザーは、MyCompanyというアイデンティティ管理レルムに存在します。これらのユーザーは、アプリケーションAおよびアプリケーションBを使用します。ホスティングされた企業のXY Corpユーザーは、XY Corpというアイデンティティ管理レルムに存在します。それらは、アプリケーションBおよびアプリケーションCを使用します。
35.1.4 アイデンティティ管理レルム・オブジェクト
この項では、アイデンティティ管理レルムのオブジェクトを示します。
表35-1に、アイデンティティ管理レルムのオブジェクトを示します。
表35-1 Oracle Identity Managementオブジェクト
オブジェクト | 説明 |
---|---|
ルートOracleコンテキスト |
このオブジェクトには、次のものが含まれます。
|
アイデンティティ管理レルム |
特別なオブジェクト・クラスが関連付けられた通常のディレクトリ・エントリ。 |
ID管理レルム固有のOracleコンテキスト |
このオブジェクトには、レルムごとに次のものが含まれます。
|
35.1.5 デフォルトのアイデンティティ管理レルムの概要
構成を簡単にするために、Oracle Internet Directoryのインストール時に、デフォルトのDITが作成され、デフォルトのアイデンティティ管理レルムが設定されます。
図35-5 デフォルトのアイデンティティ管理レルム
![デフォルトのアイデンティティ管理レルム デフォルトのアイデンティティ管理レルム](img/oidag133.gif)
図35-5に示されているとおり、デフォルトのアイデンティティ管理レルムはグローバルDITの一部です。ルートDSEのすぐ下のノードはdc=com
で、その下にdc=MyCompany
、次にdc=us
が続きます。これらの4つのノードは、全体的なDIT構造を表します。ノードdc=us
は、デフォルト・アイデンティティ管理レルムのルートです。ユーザーおよびグループの情報を含む2つのサブツリー(cn=Users
およびcn=Groups
)があります。説明上の理由から、cn=Users
ノードには、uid=user1
およびuid=user2
という2つのリーフが含まれています。同様に、cn=Groups
ノードには、cn=group1
およびcn=group2
が含まれています
オプションで、Oracle Internet Directoryをインストールするコンピュータのドメインに基づいて、DITを設定することもできます。たとえば、oidhost.us.mycompany.com
というコンピュータにインストールすると、デフォルトのアイデンティティ管理レルムのルートは、dc=us,dc=mycompany,dc=com
となります。
また、「Internet Directoryのネームスペースの指定」インストール画面で、デプロイメント要件を満たす別の識別名を、デフォルトのアイデンティティ管理レルムのルートとして指定することも可能です。たとえば、独自のアイデンティティ管理インストール環境をサード・パーティ・ディレクトリと統合する予定がある場合、サード・パーティ・ディレクトリのデフォルト・ネーミング・コンテキストの識別名と一致する識別名を指定することをお薦めします。サード・パーティ・ディレクトリからデフォルト・ネーミング・コンテキストを取得する方法の詳細は、『Oracle Directory Integration Platformの管理』の「接続済ディレクトリの統合の概念および考慮事項」を参照してください。
構成中に、Oracle Internet Directoryによって次のものが作成されます。
-
デフォルトのアイデンティティ管理レルムに関連付けられたOracleコンテキスト。Oracleコンテキストには、レルム固有のすべてのポリシーとメタデータが格納されます。前述の例の場合は、
cn=OracleContext,dc=us,dc=mycompany,dc=com
という識別名を持つOracleコンテキストが作成されます。このエントリとその下にあるノードによって、Oracleソフトウェアはレルム固有のポリシーと設定を検出できます。 -
デフォルトのアイデンティティ管理レルムでのディレクトリ構造およびネーミング・ポリシー。これによって、Oracleコンポーネントが様々なアイデンティティを検索できるようになります。デフォルト値は次のとおりです。
-
すべてのユーザーは、アイデンティティ管理レルムのベースの下にあるコンテナ
cn=users
に配置されます。この例では、cn=users,dc=us,dc=mycompany,dc=com
がこのコンテナです。 -
Oracle Identity Managementインフラストラクチャを使用してアイデンティティ管理レルム内に作成した新規ユーザーも、コンテナ
cn=users
の下に作成されます。 -
Oracle Identity Managementインフラストラクチャを使用してアイデンティティ管理レルム内に作成したすべての新規ユーザーは、オブジェクト・クラス
orclUserV2
およびinetOrgPerson
に属します。 -
すべてのグループは、アイデンティティ管理レルムのベースの下にあるコンテナ
cn=groups
に配置されます。この例では、cn=groups,dc=us,dc=mycompany,dc=com
がこのコンテナです。
-
-
アイデンティティ管理レルム管理者。このユーザーは、ユーザー・コンテナの下に配置されます。この例では、レルム管理者の完全修飾された識別名は
cn=orcladmin,cn=users,dc=us,dc=mycompany,dc=com
です。ノート:
レルム管理者のアカウントがロックされた場合は、Oracle Internet DirectoryのスーパーユーザーがOracle Directory Managerを使用してレルム管理者のアカウントのパスワードを変更することにより、ロックを解除できます。
-
認証サービスで適切な処理を実行できるようにするデフォルトの認証ポリシー。これには次のものがあります。
-
デフォルトのディレクトリ・パスワード・ポリシー(パスワードの長さ、ロックアウト、有効期限など)
-
ユーザーのプロビジョニングを行う際に自動生成される必要がある追加のパスワード・ベリファイア
-
-
アイデンティティ管理の権限。Oracle Internet Directoryによって、Oracle Internet Directoryセルフサービス・コンソールを介してこれらの権限を委任できるレルム管理者に付与されます。これらの権限の例は、次のとおりです。
-
共通のアイデンティティ管理構成権限(ユーザーの作成、ユーザー・プロファイルの変更、グループの作成など)
-
Oracle Identity Managementインフラストラクチャを使用して新しいOracleコンポーネントをインストールする権限。
-
Oracle Internet Directoryセルフサービス・コンソールを管理する権限
関連項目:
-
orclUserV2
の詳細は、『Oracle Identity Managementリファレンス』のorclUserV2
オブジェクト・クラスを参照してください -
Oracle Identity Managementのデフォルトのアクセス制御ポリシーの詳細は、「Oracle Identity Managementの権限の委任」を参照してください
-
-
35.2 デフォルトのアイデンティティ管理レルムのカスタマイズ
次の各トピックでは、いくつかのユース・ケースに基づいて、デフォルトのアイデンティティ管理レルムのカスタマイズ方法について説明します。
35.2.1 デフォルトのアイデンティティ管理レルムのカスタマイズ
レルムを作成した後、その様々な要素をカスタマイズできます。
表35-2に、カスタマイズできる要素、各種のカスタマイズで使用可能なツールおよび参照先を示します。
表35-2 デフォルトのアイデンティティ管理レルムのカスタマイズ
カスタマイズ可能な対象 | ツール | 情報 |
---|---|---|
ディレクトリ構造およびネーミング・ポリシー |
Oracle Internet Directoryセルフサービス・コンソール Oracle Directory Service Manager コマンド行ツール |
この項。 12cリリース2 (12.2.1.3.0)の『Oracle Fusion Middleware Oracle Identity Managerでのセルフ・サービス・タスクの実行』のOracle Internet Directoryセルフサービス・コンソールの使用に関する章。 |
認証ポリシー |
Oracle Directory Service Manager コマンド行ツール |
|
アイデンティティ管理の権限 |
Oracle Internet Directoryセルフサービス・コンソール Oracle Directory Service Manager コマンド行ツール |
Oracle Identity Managementの権限の委任 10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」 |
35.2.2 デフォルトのアイデンティティ管理レルムのカスタマイズのユース・ケースの理解
これが必要となる可能性がある典型的なシナリオは、Oracle Identity Managementインストールをサード・パーティ・ディレクトリと統合する場合です。
たとえば、デフォルトのアイデンティティ管理レルムがdc=mycompany,dc=com
であり、cn=users,dc=mycompany,dc=com
の下にユーザーが存在すると仮定します。
サード・パーティ・ディレクトリのネーミング・コンテキストが、デフォルト・レルム内のユーザーおよびグループの現在の検索ベースと一致しない場合は、既存のユーザーとサード・パーティのユーザーがどちらもOracle Single Sign-Onを使用してログインできるように、デフォルト・レルムのユーザーおよびグループの検索ベースを変更できます。既存のユーザーとサード・パーティのユーザーをともに含むことができて最も下位にあるユーザー検索ベースを選択します。この検索ベースを、最下位の共通ユーザー検索ベースと呼ぶことにします。
ノート:
このアプローチでは、Oracle Single Sign-Onのログインで選択されるユーザーのnickname
属性が、既存のユーザー検索ベースとサード・パーティ・ディレクトリのネーミング・コンテキスト全体で一意であると仮定しています。そうでない場合、nickname
属性の値が競合しているすべてのユーザーは、Oracle Single Sign-Onの認証に失敗します。
デプロイメント環境が次の1から5のユース・ケースのいずれかと一致する場合は、「既存のユーザーおよびグループの検索ベースの更新」で説明されている手順に従ってください。
ユース・ケース1
サード・パーティのネーミング・コンテキストは、デフォルト・レルムの下にありますが、レルムのユーザー検索ベース以外のコンテナ内に存在します。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=com
の下に存在し、サード・パーティのネーミング・コンテキストがcn=users,o=employees,dc=mycompany,dc=com
の下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=com
です。
ユース・ケース2
サード・パーティのネーミング・コンテキストは、デフォルト・レルムの外部にありますが、最下位の共通ユーザー検索ベースが存在します。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=com
の下に存在し、サード・パーティのネーミング・コンテキストがcn=users, dc=mycompanyecorp,dc=com
の下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=com
です。
ユース・ケース3
サード・パーティのネーミング・コンテキストは、デフォルト・レルムの識別名と同じです。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=com
の下に存在し、サード・パーティのネーミング・コンテキストがdc=mycompany,dc=com
のすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=com
です。
ユース・ケース4
サード・パーティのネーミング・コンテキストに、デフォルト・レルムの識別名の親が含まれます。
たとえば、識別名(DN
)がdc=us,dc=mycompany,dc=com
であるデフォルト・レルムがあり、既存のユーザーがcn=users,dc=us,dc=mycompany,dc=com
の下に存在し、サード・パーティのネーミング・コンテキストがdc=com
のすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=com
です。
ユース・ケース5
サード・パーティのネーミング・コンテキストは、既存のユーザー検索ベースの下に存在します。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=com
の下に存在し、サード・パーティのネーミング・コンテキストがl=emea,cn=users,dc=mycompany,dc=com
のすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、cn=users,dc=mycompany,dc=com
です。この使用例の場合、ユーザー検索ベースを変更する必要はありません。
ユース・ケース6
この場合、サード・パーティのネーミング・コンテキストはデフォルト・レルムの外部にあり、最下位の共通ユーザー検索ベースはルートDSEです。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=com
の下に存在し、サード・パーティのネーミング・コンテキストがcn=users,dc=mycompanycorp,dc=net
の下に存在する場合、最下位の共通ユーザー検索ベースは、ルートDSEです。
この場合、サード・パーティのネーミング・コンテキストを別の検索ベースとして追加する必要があります。ステップは次のとおりです。
35.2.3 既存のユーザーおよびグループの検索ベースの更新
この項では、既存のユーザー・グループ検索ベースを更新する手順について説明します。
サード・パーティ・ディレクトリとの同期を設定するには:
-
Oracle Internet Directoryデータベースをバックアップします。
-
サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。
-
次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。
-
ACLテンプレート・ファイル
$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbs
の変数%USERBASE%
と%REALMBASE%
をインスタンス化し、usracl.ldif
ファイルを作成します。変数%USERBASE%
は新規ユーザー・コンテナの識別名に、変数%REALMBASE%
はデフォルト・レルムの識別名に設定します。 -
ldapmodify
コマンドを使用してインスタンス化したLDIFファイルのusracl.ldif
をアップロードします。
-
-
次の手順に従って新規グループ・コンテナに適切なACLを適用します。
-
ACLテンプレート・ファイル
$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbs
の変数%GRPBASE%
と%REALMBASE%
をインスタンス化し、grpacl.ldif
ファイルを作成します。変数%USERBASE%
は新規ユーザー・コンテナの識別名に、変数%REALMBASE%
はデフォルト・レルムの識別名に設定します。 -
ldapmodify
コマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldif
をアップロードします。
-
-
既存のユーザーとサード・パーティのユーザーをともに含むことができる最下位の共通ユーザー検索ベースを決定します。
たとえば、既存のユーザーが
cn=users,dc=mycompany,dc=com
の下に存在し、サード・パーティのユーザーがl=emea,dc=mycompany,dc=com
の下に存在する場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=com
です。最下位の共通ユーザー検索ベースが、ルート・エントリになることもあります。たとえば、既存のユーザーが
cn=users,dc=mycompany,dc=com
の下に存在し、サード・パーティのユーザーがdc=mycompanycorp,dc=net
の下に存在する場合です。この場合は、「追加の検索ベースの設定」で説明されているデプロイメント例までスキップしてください。 -
グループも同期化する必要がある場合は、既存のグループとサード・パーティのグループをともに含むことができて最も下位にあるグループ検索ベースを決定します。この検索ベースを、最下位の共通グループ検索ベースと呼ぶことにします。
たとえば、既存のグループが
cn=groups,dc=mycompany,dc=com
の下に存在し、サード・パーティのグループがl=emea,dc=mycompany,dc=com
の下に存在する場合、最下位の共通グループ検索ベースは、dc=mycompany,dc=com
です。 -
レルムの管理者(通常は
orcladmin
)としてセルフサービス・コンソールにログインします。 -
「構成」タブに移動し、ユーザー検索ベースを決定した最下位の共通ユーザー検索ベースに設定します。グループも同期化する場合は、グループ検索ベースを決定した最下位の共通グループ検索ベースに設定します。
-
Oracle Single Sign-Onにこれらの変更を認識させるため、「Oracle Single Sign-Onのリフレッシュ」で説明されている手順を実行します。
-
orcladmin
としてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。 -
変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。「プロビジョニング・プロファイルの再構成」で説明されているステップに従ってください。
ノート:
ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する項を参照してください。
35.2.4 追加の検索ベースの設定
この項では、追加の検索ベースを設定する手順について説明します。
サード・パーティ・ディレクトリとの同期を設定するには:
-
Oracle Internet Directoryデータベースをバックアップします。
-
サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。
-
次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。
-
ACLテンプレート・ファイル
$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbs
の変数%USERBASE%
と%REALMBASE%
をインスタンス化し、usracl.ldif
ファイルを作成します。変数%USERBASE%
は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。 -
ldapmodify
コマンドを使用してインスタンス化したLDIFファイルのusracl.ldif
をアップロードします。
-
-
次の手順に従って新規グループ・コンテナに適切なACLを適用します。
-
ACLテンプレート・ファイル
$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbs
の変数%GRPBASE%
と%REALMBASE%
をインスタンス化し、grpacl.ldif
ファイルを作成します。変数%USERBASE%
は新規ユーザー・コンテナの識別名に、変数%REALMBASE%
はデフォルト・レルムの識別名に設定します。 -
ldapmodify
コマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldif
をアップロードします。
-
-
レルムの管理者としてセルフサービス・コンソールにログインします。
-
「構成」タブに移動します。
-
現在のレルムの
usersearchbase
にcn=users,dc=mycompanycorp,dc=net
を追加します。 -
現在のレルムの
groupsearchbase
にcn=groups,dc=mycompanycorp,dc=net
を追加します。
-
-
Oracle Single Sign-Onにこれらの変更を認識させるため、「Oracle Single Sign-Onのリフレッシュ」で説明されている手順を実行します。
-
orcladmin
としてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。 -
このアイデンティティ管理構成に基づいて中間層が構成されている場合、変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。「プロビジョニング・プロファイルの再構成」で説明されているステップに従ってください。
ノート:
ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する項を参照してください。
35.2.5 Oracle Single Sign-Onのリフレッシュ
この項では、Oracle Single Sign-onスクリプトをリフレッシュする方法を説明します。
Oracle Single Sign-Onに構成変更を認識させるため、$ORACLE_HOME/sso/admin/plsql/sso/
ディレクトリに移動して次のように入力し、Oracle Single Sign-Onのリフレッシュ・スクリプトを実行します。
sqlplus orasso@ssoreoid.sql
パスワードが要求されます。orasso
スキーマ・パスワードを取得するには、10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の付録「Single Sign-Onスキーマのパスワードの取得」を参照してください。
35.3 ホスティングされたデプロイメント用の追加アイデンティティ管理レルムについて
追加のアイデンティティ管理レルムは、Oracle Identity Management 10g (10.1.4.3.0)以上のセルフサービス・コンソールまたはoidrealm
を使用して作成できます。
ASPAdminsグループのメンバーのみが、新しいアイデンティティ管理レルムを作成できます。Oracle Directory Services Managerを使用して、デフォルトのアイデンティティ管理レルム固有のOracleコンテキストにおけるASPAdminsグループのuniquemember属性にユーザー識別名を追加し、このグループにユーザーを追加します。詳細は、「Oracle Directory Services Managerを使用した静的グループ・エントリの変更」を参照してください。
ノート:
複数のアイデンティティ管理レルムでは、動作しないアプリケーションもあります。
レルムを追加する場合は、追加したレルムが既存アプリケーションで認識されるように手動で設定する必要があります。詳細は、アプリケーション固有のマニュアルを参照してください。
Oracle Identity Managementインフラストラクチャでは、特別な管理手順を使用してシングル・サインオン・サーバーに追加のレルムを認識させる必要があります。Oracle Single Sign-Onで複数のレルムを有効にする方法は、10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の「複数レルムでのシングル・サインオン」を参照してください。
関連項目:
-
『Oracle Identity Managementリファレンス』の
oidrealm
コマンドのリファレンス。 -
アイデンティティ管理レルムの追加作成の詳細は、12cリリース2 (12.2.1.3.0)ライブラリの『Oracle Fusion Middleware Oracle Identity Managerでのセルフ・サービス・タスクの実行』の「Oracle Internet Directoryセルフサービス・コンソール」を参照してください。
35.4 DITビューの作成
11gリリース1 (11.1.1.9.0)以降では、異なるDITまたはソースDITのエントリを表示した仮想ビューまたはネームスペースであるDITビューを作成できます。次の項目がソースDITからDITビューのネームスペースに変換されます。
-
エントリ内の識別名とすべての識別名属性
-
DITビューで指定されている相対識別名マッピング
DITビューによって、テナント全体の共通エントリに対するクラウド環境の記憶域要件全体が削減されます。DITビューでは、LDAPMODDN以外のすべての操作が可能です。DITビューでは、エントリ内の任意の属性から相対識別名属性の値を導出できるため、ユーザー名がエントリ識別名に表示される場合に元のエントリを非表示にできます。
この項の内容は次のとおりです。
35.4.1 DITビューの指定
次のコマンドを使用してDITビューを指定できます。
DITビューを指定するには、次の構文を使用します。
objectclass: orclditview objectclass: extensibleobject orclRDNAttrMapping:targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN] orclDITBaseDN: realDN orclrdnmapping: targetRDN:sourceRDN orclreturnattr: orclmemberof orclreturnattr: attrName
35.4.2 DITビューの構文
この項では、orclditview
オブジェクト・クラスの項目について説明します。
表35-3に、DITビューを指定するために使用する項目を示します。
表35-3 DITビューの構文
項目 | 説明 |
---|---|
objectclass: orclditview |
Oracle Internet Directoryサーバーに、DITビュー・マッピングのエントリを処理するように指示します。 |
objectclass: extensibleobject |
エントリでは、オプションで任意の属性を保持できます。 |
orclRDNAttrMapping: targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN ] |
ターゲット属性に対するソース属性のマッピングと、別の属性の値を使用するオプションを指定します。
|
orclDITBaseDN: realDN |
元のソース・エントリの場所である
|
orclrdnmapping: targetRDN: sourceRDN |
|
orclreturnattr: attrName |
返却する複数値属性の名前を指定します。Oracle Internet Directoryサーバーは、これらの構成済属性のみを返します。 オプション。 |
|
このLDAPフィルタを使用してエントリをマスクします。 |
orclrdnfilter: LDAP Filter |
このLDAPフィルタを使用して、 |
|
|
|
属性または属性の特定の値を除外できます。 |
orclalternateDITDN: AlternateDN
|
ノート: Oracle Internet Directoryサーバーが |
35.4.3 DITビューの条件について
この項では、DITビューの条件について説明します。
DITビューを使用する場合、次の条件に留意する必要があります。
-
マップされるDITビューのエントリの相対識別名属性には、カンマ(,)、プラス記号(+)、等号(=)、セミコロン(;)、ハッシュ(#)、バックスラッシュ(\)、より小さい(<)、より大きい(>)などの特殊文字を含めることはできません。
-
マップされるDITビューのエントリの相対識別名属性は、
uniqueness
属性が有効化された単一値属性である必要があります。 -
DITビューから
orclmemberof
属性の別名(memberof
/ismemberof
)を取得する場合、DITビューの作成時に、次のように返却属性リストの別名を指定する必要があります。orclreturnattr: orclmemberof
35.4.4 DITビューの例
次の例では、実際のエントリがDITビュー・エントリに変換されます。
実際のエントリ:
uid=user.1,ou=people,dc=us,dc=example,dc=com
DITビュー・エントリ:
displayname=user.1,ou=people,dc=uk,dc=example,dc=com
次に例を示します。
dn: ou=people,dc=uk,dc=example,dc=com objectclass: top objectclass: orclditview objectclass: extensibleobject orclrdnattrmapping: displayname:uid:mail orclditbasedn: ou=people,dc=us,dc=example,dc=com
次の例では、実際のエントリがDITマップ・エントリに変換されます(user.1@example.com
はmail
属性の値です)。
実際のエントリ:
uid=user.1,ou=people,dc=us,dc=example,dc=com
DITビュー・エントリ:
displayname=user.1@example.com,ou=people,dc=ind,dc=example,dc=com
次に例を示します。
dn: ou=people,dc=ind,dc=example,dc=com objectclass: top objectclass: orclditview objectclass: extensibleobject orclrdnattrmapping: displayname:uid:mail orclditbasedn: ou=People,dc=us,dc=example,dc=com ou: people
次の例では、実際のエントリがDITマップ・エントリに変換されます(user.1@example.com
はmail属性の値です)。
実際のエントリ:
uid=user.1,ou=people,dc=us,dc=example,dc=com
DITビュー・エントリ:
displayname=user.1@example.com,cn=users,cn=common,dc=example,dc=com
次に例を示します。
dn: cn=common,dc=example,dc=com objectclass: top objectclass: orclditview objectclass: extensibleobject orclrdnattrmapping: displayname:uid:mail orclditbasedn: dc=us,dc=example,dc=com orclrdnmapping: cn=users:ou=people orclrdnmapping: cn=groupview:cn=groups cn: common
次の例では、属性構成が返されます。この構成は、エントリがこのツリーで検索されると、uid
、mail
、cn
およびsn
属性のみが返されることを示しています。他の属性を持つエントリを追加または更新する場合、この制限は適用されないため、他の属性を持つエントリを追加できることに注意してください。
dn: cn=common,dc=example,dc=com objectclass: top objectclass: orclditview objectclass: extensibleobject orclrdnattrmapping: displayname:uid:mail orclditbasedn: dc=us,dc=example,dc=com orclrdnmapping: cn=users:ou=people orclrdnmapping: cn=groupview:cn=groups orclreturnattr: cn orclreturnattr: uid orclreturnattr: mail orclreturnattr: sn cn: common
次の例で、属性マッピングについて説明します。構文は次のとおりです。
orclattrmapping=targetAttr:SourceAttr:overWrite
overWrite
が1
に設定されている場合、targetAttr
の既存の値は削除されます。overWrite
が0
に設定されている場合、targetAttr
の既存の値にsourceAttr
の値が追加されます。
dn: cn=ditview,dc=oracle,dc=com changetype: modify replace: orclattrmapping orclattrmapping: cn:mail:0 orclattrmapping: sn:givenname:1
次の例で、属性の値を除外する方法について説明します。構文は次のとおりです。
orclattrexclude: attribute: optionalValue
dn: cn=ditview,dc=oracle,dc=com changetype: modify orclattrexclude: objectclass:orgperson orclattrexclude: authpassword orclattrexclude: userpassword
次の例で、代替ベース識別名について説明します。
dn: cn=filteredusers,dc=oracle objectclass: top objectclass: orclditview objectclass: extensibleobject orclditbasedn: ou=people,dc=us,dc=oracle,dc=com orclalternateditdn: ou=contractors, dc=us,dc=oracle,dc=com orclmaskfilter: (employeetype=regular) cn: filteredusers