10g（10.1.4.0.1）
B31468-01
 目次 |
 索引 |
| Oracle Access Manager IDおよび共通管理ガイド 10g（10.1.4.0.1） B31468-01 |
|
User Manager、Group ManagerおよびOrganization Managerは、エンド・ユーザーが自分、他人、グループ、インベントリ、および管理者が使用を許可したその他の項目に関する情報を参照および変更できるIDシステム・アプリケーションです。
第3章「IDシステムでのスキーマ・データの使用」の章では、ディレクトリやオブジェクト・テンプレート・ファイルのオブジェクトおよび属性をIDシステムに認識させる方法と、アプリケーション・ページでの属性の表示形式を構成する方法について説明しました。この章では、属性を特定のアプリケーション・ページに配置する方法と、ユーザーにそれらの属性の参照および変更を許可する方法について説明します。また、各アプリケーションの使用方法についても説明します。
User Manager、Group ManagerおよびOrganization Managerアプリケーションを構成するには、マスターID管理者または委任ID管理者である必要があります。「管理の委任」を参照してください。
この章の内容は次のとおりです。
User Manager、Group ManagerおよびOrganization Managerは、IDシステムの主要アプリケーションです。
管理者は、これらのアプリケーションで誰にどの属性および値を表示するかを制御します。また、ユーザーが検索を実行した際にディレクトリ・ツリーのどの部分へのアクセスを許可するかも制御します。管理者は、フィルタを追加して、ユーザー検索の結果がフィルタに指定した基準に準拠するよう設定できます。
IDシステムを初めてインストールして設定し、そのオブジェクトと属性を構成した段階では、IDシステム・アプリケーション・ページは空です。次の手順に従って、IDシステム・アプリケーションで情報を使用できるようにします。
IDシステム・アプリケーションには、それぞれ1つ以上のタブが含まれます。これらのタブは、次のように構成します。
User Managerのタブは、Person構造化オブジェクト・クラスに関連付けられます。Group Managerのタブは、Group構造化オブジェクト・クラスに関連付けられます。Organization Managerでは、複数のタブを保持することが可能であり、各タブはそれぞれ異なるオブジェクト・クラスに関連付けられます。すべてのタブには、補助LDAPオブジェクト・クラスおよびテンプレート・オブジェクト・クラスを関連付けることができます。
User Manager、Group ManagerおよびOrganization Managerページに表示されるタブの特性を参照および変更できます。
「User Manager構成」、「Group Manager構成」または「Organization Manager構成」ページが表示されます。
アプリケーションのタブの名前が含まれる「タブの構成」ページが表示されます。Organization Managerでは、2つ以上のタブが表示される場合があります。
User ManagerおよびGroup Managerのタブは1つのみであるため、ただ1つのリンクが表示されます。Organization Managerでは、2つ以上のタブが表示される場合があります。
「タブの表示」ページが表示されます。
表4-1に、このページに含まれる情報を示します。
| フィールド | 説明 |
|---|---|
|
タブID |
タブの一意の識別子。 |
|
タブ名 |
このフィールドはローカライズできます。 |
|
タブ・イメージ |
タブのGIFイメージ。GIFは、WebPass_install_dir/identity/oblix/lang/langTag/style0に格納されている必要があります。ここで、WebPass_install_dirはWebPassがインストールされているディレクトリであり、langTagは使用中の特定の言語が含まれるフォルダです。 GIFファイルの名前のみを入力し、フルパスは入力しないでください。 |
|
押した状態のタブ・イメージ |
ユーザーがタブ・イメージをクリックしたときに表示されるGIFイメージ。 |
|
マウスを置いたときに表示されるメッセージ |
このフィールドはローカライズできます。 |
|
クラス・タイプ |
このタブの構造化クラスに関連付けられているタイプ。詳細は、「オブジェクト・クラス・タイプ」を参照してください。 |
|
オブジェクト・クラス |
このタブで使用されている構造化オブジェクト・クラス、補助オブジェクト・クラスおよびテンプレート・オブジェクト・クラス。テンプレート・オブジェクト・クラスは、miis.personなどの完全修飾形式で表示されます。この形式は、クラスの定義されている.tplファイルから読み取られます。第6章「外部アプリケーションへの非LDAPデータの送信」を参照してください。 構造化オブジェクト・クラスは、IDシステム・コンソールでは変更できません。補助オブジェクト・クラスは、構造化オブジェクト・クラスに関連付けることができます。「User ManagerまたはOrganization Managerタブへの補助オブジェクト・クラスおよびテンプレート・オブジェクト・クラスの追加」を参照してください。 一部のオブジェクト・クラスはこのページの編集不可能なリストに表示され、他のオブジェクト・クラスはこのページのテキスト・ボックスに表示されます。テキスト・ボックスのオブジェクト・クラスは、まだタブに追加されていません。 |
|
タブ・フィルタ |
ディレクトリを問い合せるためのLDAPフィルタ。このフィルタにより、限定されたオブジェクトが戻されます。記述可能なLDAPフィルタ・タイプの例は、「静的LDAP検索フィルタ」および「動的LDAP検索フィルタの例」を参照してください。 タブ・フィルタでは、フィルタ置換がサポートされません。タブ・フィルタの効果があるのは、タブにおいて検索、プロファイルの表示と変更、およびレポートの作成を行う場合です。フィルタは、検索時に指定された基準とAND関係で組み合されて使用されます。また、レポートの作成時に使用されます。つまり、フィルタと検索の両方の基準が適用されます。表示操作と変更操作では、このフィルタの使用によりターゲット・オブジェクトが限定されます。 |
|
タブ検索ベース |
ディレクトリ・ツリー（DIT）でのユーザー検索の開始ポイント。詳細は、「検索ベースの概要」を参照してください。 |
変更がIDシステム・アプリケーションに反映されない場合は、IDシステム・コンソールで「システム構成」→「サーバー設定の表示」に移動し、「メモリー・キャッシュを消去」をクリックしてフラッシュ操作を実行し、キャッシュをリロードします。
複数の言語パックをインストールしている場合、それらの言語で表示するようタブ名をローカライズできます。ローカライズされたタブ名は、管理コンソールで作成、表示および変更します。
複数の言語を管理する方法の詳細は、「Oracle Access Managerでの複数の言語の構成」を参照してください。
「User Manager構成」、「Group Manager構成」または「Organization Manager構成」ページが表示されます。
アプリケーションの1つ以上のタブ名が含まれる「タブ」ページが表示されます。
「タブの表示」ページが表示されます。このページには、ID、名前、クラス・タイプ、オブジェクト・クラスなどのタブの詳細が表示されます。
このボタンがページに表示されない場合は、インストールされている言語が1つのみのため、表示名をローカライズすることはできません。インストールされている単一言語の表示名を変更するには、「変更」をクリックします。
「タブ・ラベル表示名のサマリー」ページが表示されます。次の言語固有のフィールドに対して構成された表示名があれば、その名前がこのページに表示されます。
特定の言語でまだ構成されていない表示名は、「未構成」としてマークされます。
タブ・ラベル表示名の構成ページが表示されます。このページには、タブ表示名のフィールドと、すべてのインストール済言語のリンクが含まれます。
Organization Managerには、2つ以上のタブを含めることができます。
「タブの構成」ページが表示されます。
「タブの作成」ページが表示されます。
User Manager、Group ManagerおよびOrganization Managerのアプリケーション・ページの上部には、検索フィールドがあります。検索フィールドの例は、「Group Managerタブへの補助オブジェクト・クラスおよびテンプレート・オブジェクト・クラスの追加」を参照してください。検索機能リストに表示する属性を指定できます。検索属性は、LDAPディレクトリからのみ取得できます。テンプレート属性は、検索属性として使用できません。
「検索属性の表示」ページが表示されます。
検索結果に表示する属性を選択できます。複数の言語をインストールして構成している場合は、検索結果属性をローカライズできます。これにより、複数の言語で検索結果を表示できます。
「検索結果属性の表示」ページが表示されます。
このページには、ユーザーによる検索の結果が戻されるときに表示される属性が含まれます。複数の言語でIDシステムを構成している場合、それらの言語がこのページに表示されます。
「検索結果属性の変更」ページが表示されます。
最初の属性は、常に「クラス属性」です。
このページでクラス属性の名前を変更することはできません。クラス属性は太字で表示され、このページでは編集できません。クラス属性を変更する方法の詳細は、「クラス属性の選択」を参照してください。
属性の表示名は、属性リストの右側の編集可能なフィールドに表示されます。この名前は、IDシステムのユーザー・アプリケーションに表示されます。詳細は、「オブジェクト・クラス属性の概要」を参照してください。
「タブの表示」ページが表示されます。
「検索結果属性の表示名のサマリー」ページが表示されます。このページには、すべてのロケールの既存の表示名がリストされます。特定の言語でまだ構成されていない表示名は、「未構成」としてマークされます。
「検索結果属性の表示名の構成」ページが表示されます。
補助オブジェクト・クラスは、構造化オブジェクト・クラスに追加するミックスイン・クラスとして使用できます。たとえば、個人用の補助クラスが存在し、そこに個人のバッジ番号の属性が含まれる場合、その補助クラスを構造化オブジェクト・クラスに関連付けることが可能です。User Manager、Group ManagerおよびOrganization Managerアプリケーションを構成する場合に、自由に使用できるオブジェクト・クラスが増加すれば、アプリケーション・ユーザーのために構成できる情報も増加します。
第5章「ID機能とワークフローの連携」の手順に従ってワークフローを作成している場合、補助オブジェクト・クラスをタブに関連付ける際には次のことに留意してください。
テンプレート・オブジェクトもタブに関連付けることができます。テンプレート・オブジェクトを使用するワークフローを構成する予定の場合、この作業は必須です。
詳細は、「オブジェクト・クラスの追加」を参照してください。
「タブ」ページが表示されます。
「タブの表示」ページが表示されます。
「タブの変更」ページが表示されます。
変更を保存すると、選択した1つ以上のオブジェクト・クラスが、選択ボックスの左側のリストに追加されます。
補助オブジェクト・クラスをGroup Managerに関連付ける場合、グループ・タイプを使用します。Oracle Access Managerでは、oblixAdvancedGroup補助オブジェクト・クラスを提供しており、グループへのメンバーのサブスクライブや、動的グループの作成と拡張を行うための属性を構成できます。
次のページは、「Group Manager」タブをクリックし、次に「グループ」サブタブをクリックすると表示されます。「グループ」は、複数のグループ・タイプ・パネルで構成されます。
グループ・タイプ・パネルを作成すると、関連付けられたオブジェクト・クラスの属性をGroup Managerユーザー・アプリケーションで使用できます。
詳細は、「オブジェクト・クラスの追加」を参照してください。
オブジェクト・クラスが追加されます。この新規オブジェクト・クラスを参照するには、「Group Manager構成」の左側のナビゲーション・ペインにある「タブ」リンクをクリックします。
「Group Managerオプション」機能を使用すると、Group Managerアプリケーションの「グループ」および「メンバー・プロファイルの表示」ページに表示する項目を選択できます。この機能により、コストのかかる操作を無効化できます。この機能は、IDシステムのパフォーマンスを向上する必要がある場合に役立ちます。
「Group Managerオプション」ページが表示されます。
表4-2に、各オプションを示します。
Organization Managerに複数のタブが含まれる場合、タブを削除できます。
「タブの表示」ページが表示されます。Organization Managerに複数のタブが定義されている場合、このページに「削除」ボタンが表示されます。
削除の確認を求められます。
Organization Managerに複数のタブがリストされている場合、タブの表示順序を変更できます。
Tab 1、Tab 2のようにリストされた「タブの順序付け」ページが表示されます。各タブ番号の横に、既存のタブの名前を含むリストがあります。
Tab 1: Site
Tab 2: Location
プロファイル・ページは、IDシステム・アプリケーションのオブジェクトに関する情報が表示されるWebページです。たとえば、User Managerでユーザーに関する情報を検索すると、そのユーザーのプロファイル・ページが表示されます。プロファイル・ページには、ユーザーの次のようなデータが含まれます。
プロファイル・ページの情報は、IDシステムの通信先であるLDAPディレクトリのオブジェクトおよび属性に基づきます。または、オブジェクト・テンプレート・ファイルの情報に基づく場合もあります。
プロファイル・ページは、一連のパネルで編成できます。たとえば、個人のプロファイル・ページには、個人、ロケーションおよびプロジェクト情報に関する複数のパネルを含めることが可能です。プロビジョニング目的でオブジェクト・テンプレート・ファイルを構成している場合、テンプレート・ファイルの各属性を1つの特定のパネルに配置できます。
ユーザーは、次のいずれかの方法でプロファイル・ページを表示できます。
パネルでLDAP属性を構成すると、その属性のラベルと値は、パネルを使用するプロファイル・ページに表示されます。一方で、テンプレート属性は、プロファイル・ページには実際に表示されません。テンプレート属性は、その属性を使用するワークフローを定義している場合にかぎり、「プロファイルの変更」ページにのみ表示されます。
詳細は、第6章「外部アプリケーションへの非LDAPデータの送信」を参照してください。
ヘッダー・パネルは、User ManagerまたはOrganization Managerのプロファイルの上部に表示されます。ヘッダーには、タブの構造化オブジェクト・クラスから取得された「フルネーム」、「役職」および「写真」セマンティク型の属性が表示されます。ヘッダーは、ユーザーIDプロファイル・ページで表示しないよう無効化できます。
ユーザーのヘッダー・パネルの例は、次のとおりです。
「タブの構成」ページが表示されます。Organization Managerでは、複数のタブが表示される場合があります。
プロファイル・ヘッダーに表示される属性が、「ヘッダー・パネルの構成」ページに表示されます。たとえば、「マップ・イメージ」、「ロケーション名」、「ロケーション・タイトル」などです。
IDシステム・コンソールで構成したパネルは、User Manager、Group ManagerおよびOrganization Managerページで一連の属性としてユーザーに表示されます。
次の表に、ユーザー・プロファイル・パネルのいくつかの例を示します。
| パネル | 属性 |
|---|---|
|
通信 |
携帯電話番号 |
|
ロケーション |
建物番号 |
|
個人 |
マネージャ |
パネルを構成する前に、パネルに配置する属性のオブジェクト・クラスが適切なオブジェクト・クラス・タイプで構成されていることを確認してください。「オブジェクト・クラス・タイプ」を参照してください。
そのオブジェクトのプロファイル・ページが表示されます。
プロファイルがページ・ビューでアプリケーションに表示されている場合は、「パネルの表示」ボタンをクリックします。
パネルは、システム設定時に構成した属性と、第3章「IDシステムでのスキーマ・データの使用」に記載されたタスクの実行により構成した属性を使用して作成できます。1つのパネルで属性を1回のみ使用することや、複数のパネルで同じ属性を常時使用することが可能です。
以前のリリースでは、チャレンジ・フレーズ属性とレスポンス属性を「ユーザー・プロファイル」ページの異なるパネルに配置できました。ただし、リリース10g（10.1.4.0.1）では、チャレンジ・フレーズ属性とレスポンス属性を同じパネルに配置する必要があります。リリース10g（10.1.4.0.1）の場合、チャレンジ・フレーズとレスポンスは、パネルで交互に構成されていない場合でも、交互に表示されます。
パネルにチャレンジ属性のみが含まれる場合、チャレンジ属性は「ユーザー・プロファイル」ページにレスポンスなしで表示されます。パネルにレスポンスのみが含まれる場合（チャレンジ属性がない場合）、レスポンスは「ユーザー・プロファイル」ページに表示されません。
複数の言語でIDシステムを構成している場合、各言語のパネル・フィールドを表示または変更できます。次のパネル・フィールドの表示名をローカライズできます。
「タブの表示」ページが表示されます。
「パネルの構成」ページが表示されます。現在定義されているパネルが表示されます。
「作成」を選択すると、「パネルの作成」ページが表示されます。
「パネルの変更」ページは、「パネルの作成」ページとほぼ同じです。どちらのページでも、次のフィールドを使用できます。
| ラベル | 説明 | ラベル |
|---|---|---|
|
パネル・ラベル |
この名前はローカライズできます。 |
パネル・ラベル |
|
説明 |
このテキストはローカライズできます。 |
説明 |
|
属性 |
リストから選択された属性。追加の属性フィールドが必要な場合は、ページの右側の「追加」をクリックします。テンプレート属性を選択した場合、属性ラベルはこのパネルに表示されません。テンプレート属性は、ワークフローのコンテキストでのみ表示されます。 これらの属性はローカライズできます。 |
属性 |
|
タイトル・イメージ |
ユーザー・プロファイルは、タブで分けられたページとして、または単一のページとして表示できます。タイトル・イメージは、プロファイルを単一のページとして表示したときにパネル・タイトルに使用されるGIFイメージです。GIFは、WebPass_install_dir/identity/oblix/lang/langTag/style0に格納されている必要があります（ここで、WebPass_install_dirはWebPassがインストールされているディレクトリであり、langTagは使用中の特定の言語が含まれるフォルダです）。パスなしでGIFファイルの名前のみを入力します。タイトル・イメージは、「IDシステム・アプリケーションのスタイルの構成」の手順に従って変更できます。 |
タイトル・イメージ |
|
「タブ・イメージ」と「タブ・イメージ(下)」 |
ユーザー・プロファイルは、タブで分けられたページとして、または単一のページとして表示できます。タブ・イメージは、タブで分けられたページとしてプロファイルを表示したときに使用されるGIFイメージです。タブ・イメージは、通常、パネル・ラベルと一致します。タブ・イメージを定義するまでは、パネル・ラベルがユーザー・プロファイル・ページにリンクとして表示されます。リンクまたはタブ・イメージをクリックすると、パネルが表示されます。「タブ・イメージ(下)」のイメージは、ユーザー・プロファイル・ページの下部に表示されます。 |
「タブ・イメージ」と「タブ・イメージ(下)」 |
|
押した状態のタブ・イメージ |
ユーザーがユーザー・プロファイルのパネル・タブをクリックしたときに使用されるイメージ。 |
押した状態のタブ・イメージ |
「パネル情報完了」の横のボックスを選択すると、パネル定義が保存されます。ただし、ユーザーがパネルの内容を参照できるかどうかは、読取り権限によって制御されます。これらのオプションの詳細は、「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
注意
「タブの表示」ページが表示されます。
「プロファイル」ページが表示されます。
適切な「パネルの構成」ページが表示されます。このページには、構成済の各パネルのリンクが表示されます。
既存のタブがページに表示されます。
「翻訳」ボタンが表示されない場合は、インストールされている言語が1つのみのため、パネルをローカライズすることはできません。インストールされている単一言語のパネル要素の表示名を編集するには、「変更」をクリックします。
「翻訳」をクリックすると、「パネル表示名のサマリー」ページが表示されます。このページには、次のフィールドに対して構成されているすべての言語固有の表示名が表示されます。
まだ構成されていない表示名は、「未構成」としてマークされます。
パネル表示名の構成ページが表示されます。このページには、パネル表示名のフィールドと、すべてのインストール済言語のリンクが含まれます。
パネルは、特定の順序でプロファイル・ページに表示されます。Group Managerでのパネルの表示順序は、変更できます。
「パネルの順序付け」ページが表示されます。
グループ・タイプ・パネルにより、「グループ」タブの属性を編成できます。たとえば、構造化オブジェクト・クラスとしてgroupOfUniqueNamesを、補助クラスとしてoblixAdvancedGroupを構成している場合、グループ・タイプ・パネルを作成することで、これらのクラスから「グループ」タブの属性を編成できます。
グループ・タイプ・パネルは、LDAP属性用に確保されています。テンプレート属性は、グループ・タイプ・パネルで構成できません。
IDシステムでグループ・タイプとして識別される各オブジェクト・クラス（「オブジェクト・クラス・タイプ」を参照）は、グループ・タイプ・パネルに関連付けることができます。
「パネルの構成」ページに構成済のグループ・タイプ・パネルのリストが表示されます。
選択したパネルの設定を含む「パネルの表示」ページが表示されます。
Groupオブジェクト・クラスの属性を編成するには、グループ・タイプ・パネルを構成する必要があります。Group構造化オブジェクト・クラスに対して、少なくとも1つのパネルを作成する必要があります。これにより、Group構造化オブジェクト・クラスの属性のみを含むグループを「グループ」プロファイル・ページで参照できます。
複数の言語をインストールして構成している場合は、次のパネル・フィールドの表示名をローカライズできます。
「グループ・タイプ」ページにグループ・タイプのリストが表示されます。
Group構造化オブジェクト・クラスを拡張する補助オブジェクト・クラスか、スキーマでGroup構造化オブジェクト・クラスに関連付けられている補助オブジェクト・クラスのみを選択します。このページで選択できるのは、構成済の補助クラスのみです。詳細は、「オブジェクト・クラスの追加」を参照してください。
注意
「タブ情報完了」を選択すると、パネル定義が保存されますが、ユーザーがパネルの内容を参照できるかどうかは読取り権限によって制御されます。「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
注意
「パネルの表示」ページが表示されます。
このボタンは、2つ以上の言語がインストールされている場合にのみ表示されます。1つの言語のみをインストールしている場合にパネル要素の表示名を構成するには、「変更」をクリックします。
「パネル表示名のサマリー」ページが表示されます。このページには、次のフィールドに対して構成されているすべての表示名がリストされます。
特定の言語でまだ構成されていない表示名は、「未構成」としてマークされます。
パネル表示名の構成ページが表示されます。
「共通構成」ページで構成した属性は、そのオブジェクト・クラスを利用する各アプリケーションで使用されます。たとえば、共通構成を通じてcn属性の表示名を「フルネーム」に設定できます。この名前は、ユーザー・プロファイル・ページに表示されます。その後、「User Manager構成」画面でcn属性を「氏名」と表示するよう構成すると、ユーザー・プロファイル・ページにはデフォルトで「氏名」と表示されます。詳細は、第3章「IDシステムでのスキーマ・データの使用」を参照してください。
パネルに表示される属性の表示名をローカライズすることも可能です。これにより、ユーザーにとって固有の言語で属性を表示できます。複数の言語を管理する方法の詳細は、「Oracle Access Managerでの複数の言語の構成」を参照してください。
ただし、次に説明するとおり、オブジェクト・クラス・レベルで属性に構成されている情報は上書きできます。
各IDシステム・アプリケーション（User Manager、Group ManagerおよびOrganization Manager）には、「タブ」機能を備えたアプリケーション固有の構成タブがあります。アプリケーション固有の「タブ」機能を使用すると、そのアプリケーション固有の構成タブの属性のみを対象に、オブジェクト・クラス・レベルの構成とは異なる表示名または表示タイプを使用できます。たとえば、「User Manager構成」タブの「説明」属性に異なる表示名を指定できます。
複数の言語をインストールしている環境で適切なローカライズを行うには、タブ・レベルで属性を再構成するときに、インストール済のすべての言語でその属性の表示名を指定する必要があります。例として、2つの言語をインストールしている場合を検討します。たとえば、「User Manager構成」タブの「説明」属性を2つの言語に翻訳するには、同じタブ・レベルで各インストール済言語の属性の表示名を指定する必要があります。「翻訳」ボタンは、2つ以上の言語がインストールされている場合にのみ表示されます。
次の手順では、タブ・レベルで属性を再構成し、オブジェクト・クラス・レベルで属性に構成されている情報を上書きする方法について説明します。
「タブ」ページが表示されます。Organization Managerでは、複数のタブが表示される場合があります。
「タブの表示」ページが表示されます。
「属性の変更」ページが表示されます。
属性の変更方法の詳細は、「属性の構成」を参照してください。次の手順を使用すると、属性の表示名をローカライズできます。
「タブの構成」ページが表示されます。Organization Managerでは、複数のタブが表示される場合があります。
「タブの表示」ページが表示されます。
「属性表示名のサマリー」ページが表示されます。このページには、構成済の属性の表示名がすべての言語でリストされます。まだ構成されていない表示名は、「未構成」としてマークされます。
「検索結果属性の表示名の構成」ページが表示されます。このページには、属性の表示名フィールドと、インストール済言語のリンクがリストされます。
オブジェクトや属性を構成し、アプリケーション・タブのパネルに属性を編成する操作は、ブロックを組み立てることに似ています。基礎となるブロックを配置したら、次にそれらの操作を誰に許可するかを決定できます。
IDシステムを設定して、アプリケーション・パネルに構成したLDAP属性の検索と表示をユーザーに許可する必要があります。これを行うには、次の操作を実行します。
次の項では、表示権限と変更権限を構成する手段として、検索ベースを設定する方法について説明します。検索ベースは、LDAPディレクトリ・ツリーの検索に関連します。テンプレート属性は、検索ベースの設定とは無関係です。ユーザーにテンプレート属性の値の入力を許可するには、それらのユーザーがテンプレート属性の使用されるワークフローの参加者である必要があります。詳細は、第5章「ID機能とワークフローの連携」を参照してください。
注意
検索ベースは、ディレクトリ・ツリーのブランチです（または、ツリーの最上位ノードとなることもあります）。インストール時に、デフォルトの検索ベースを選択します。デフォルトの検索ベースは、その下にすべてのユーザー・データが格納されるディレクトリ・ツリー内のノードであり、すべてのユーザー・データを検索できる最上位の基準です。検索ベースにより、検索時にユーザーが使用できるディレクトリ・ツリーの特定部分が決定されます。ユーザーにエントリの参照を許可するには、IDシステムに構成された各構造化オブジェクト・クラスに対して検索ベースを設定する必要があります。構造化オブジェクト・クラスごとに複数の検索ベースを設定できます。
検索ベースを設定する場合、誰に何を（ディレクトリ・ツリーの特定レベルのオブジェクト・クラス）検索可能にするかを決定します。このとき、オプションで検索フィルタを使用します。
検索ベースを設定する前に、次のことを決定する必要があります。
たとえば、ある検索ベースを従業員用として構成し、別の検索ベースを顧客用として構成できます。これにより、顧客側から従業員情報が参照されないことが保証されます。
別の例としては、2つの競合する部品納入サプライヤが存在する場合に、各サプライヤのユーザーが自社に関する部分のみをDITで参照できるように検索ベースを設定できます。
検索ベースを設定する場合、ログイン・ユーザーが参照できる検索ベースのブランチを指定するためのフィルタを定義できます。ディレクトリ・ツリーが特にフラットな形状の場合、ノードを選択しても検索ベースをあまり限定できないため、フィルタ機能は検索の絞込みに役立ちます。フィルタは、ディレクトリ・ツリーに大量のブランチがある場合にも役立ちます。たとえば、10,000の販売代理店がある場合、販売店内で検索を絞り込むことが可能です。
ただし、フィルタにより大量のエントリが生成される場合、パフォーマンスが影響を受ける可能性があります。検索ベース・フィルタを使用するかわりに、クラス属性に対する読取り権限を設定できます（「クラス属性の選択」を参照してください）。クラス属性は、属性アクセスと、プロファイル・ページへの検索結果のリンクに使用されます。
たとえば、検索ベースからリソース・フィルタを削除して、「すべてのユーザー」のロールにPersonオブジェクト・クラスへのアクセスを許可するとします。検索ベースを設定するかわりに、クラス属性にアクセスできるユーザーを指定するルールを使用して、そのクラス属性に対する読取り権限を定義します。これにより、IDシステムで実行されるディレクトリ検索の数を削減できます。詳細は、「LDAP属性権限の設定と変更」を参照してください。
ディレクトリ・ツリーの検索対象レベルを変更する場合、または検索属性を変更する場合、検索ベースを直接変更することはできません。直接変更すると、IDシステムでは、変更された検索ベースが新しく定義された検索ベースとして扱われます。検索ベースを変更する唯一の方法は、検索ベースを一度削除して新しく作成することです。
ディレクトリの検索は、システム・パフォーマンスにおける重要な要因です。索引付けのガイドラインは、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
Oracle Internet Directoryでは、索引付けされていない属性が検索で使用されると、エラーが戻されます。たとえば、索引付けされていない「一致する属性」を使用して導出属性を定義し、その属性をOracle Access Managerのプロファイル・ページに追加するとします。ページが表示されると、Oracle Internet Directoryによってエラーが戻され、導出属性の値はプロファイル・ページに表示されません。Oracle Access Managerのログ・ファイルには、「操作はサポートされていません。」というエラー・メッセージが記録されます。
検索フィルタで追加属性を使用するには、それらの属性をカタログ・エントリに追加する必要があります。索引付けできるのは、次の条件に対応する属性のみです。
新規属性（つまり、ディレクトリ内にデータが存在しない属性）を索引付けするには、ldapmodifyツールを使用します。ディレクトリ内にすでにデータが存在する属性を索引付けするには、カタログ管理ツールを使用します。属性から索引を削除する場合、ldapmodifyも使用できますが、カタログ管理ツールを使用することをお薦めします。
スキーマに新規属性を定義したら、ldapmodifyを使用してその属性をカタログ・エントリに追加できます。
ディレクトリ・データが存在しない属性を追加するには、ldapmodifyを使用してLDIFファイルをインポートします。たとえば、スキーマに定義されている新規属性fooを追加するには、ldapmodifyを使用して次のLDIFファイルをOracle Internet Directoryにインポートします。
dn: cn=catalogs changetype: modify add: orclindexedattribute orclindexedattribute: foo
この方法は、ディレクトリにデータが存在する属性の索引付けには使用しないでください。ディレクトリにデータが存在する属性を索引付けするには、カタログ管理ツールを使用します。
次の手順では、検索ベースを設定する方法について説明します。
「構成」ページが表示されます。
一部のブラウザでは、アプリケーションの証明書を信頼するかどうかを尋ねるプロンプトが表示されることがあります。その場合は、「常に信頼」オプションを選択してください。
「検索ベースの設定」ページが表示されます。
選択するオブジェクト・クラスにより、検索対象が定義されます。たとえば、製品の検索ベースを設定する場合、製品オブジェクト・クラスを選択します。
検索ベース・ドメイン・ボックスには、検索の最上位ノードが示されます。検索ベース・ドメイン・ボックスのすぐ下のフィールドで、情報を入力または編集します。
たとえば、製造部門の製品を対象に検索ベースを定義する場合、検索ベースの製造（Manufacturing）ブランチを選択します。
ディレクトリ・ツリーの最上位レベルを選択すると、ドメイン全体が検索に使用されます。検索ベースを再定義するには、ツリー内でより下位のノードを選択するか、フィルタを入力します。たとえば、検索を北米に限定するには、最上位ノードを選択し、フィルタとしてregion=North Americaと入力します。この例では、ディレクトリ・ツリーに北米（North America）というブランチがあると仮定します。フィルタの記述方法の詳細は、「ルールとフィルタの使用方法」を参照してください。
「フィルタ」ボックスに、検索用の現在のフィルタが表示されます。「フィルタ」ボックスのすぐ下の「フィルタの追加」フィールドを使用して、別のフィルタを入力できます。
新規フィルタが前のフィルタの下のフィールドに表示されます。
ディレクトリ・ツリーのこの部分の検索を許可するユーザーとグループは、次のパネルで定義します。
たとえば、次のようになります。
ワークフロー作成時にターゲット・ドメイン（またはワークフロー・ドメイン）のフィルタを指定する場合、完全なLDAP URLは使用しないでください。LDAPフィルタのみを使用できます。たとえば、ldap:///ou=Partners,o=Company,c=US??sub?(cn=Shutterbug Canavan)ではなく、cn=Shutterbug Canavanとするのが適切です。
ログインしているかどうかにかかわらず、すべてのユーザーにこの権限を付与する場合、「匿名」を選択します。
User Manager、Group ManagerまたはOrganization Managerにログインしている任意のユーザーにこの権限を付与する場合、「すべてのユーザー」を選択します。
|
注意 匿名アクセスは、User ManagerおよびOrganization Managerの「自己登録」機能でのみ使用されます。また、匿名アクセスは、ルールとして構成された表示タイプ属性（チェック・ボックス、ラジオ・ボタンまたはリスト）にのみ適用されます。たとえば、LDAPフィルタの(objectclass=organizationalunit)を使用するルールを備えたリスト表示タイプとしてou属性を構成するとします。自己登録でこの属性を構成するには、organizationalUnitのOrganization Managerタブにアクセスし、クラス属性の属性アクセスを構成します（匿名アクセス権の付与方法の詳細は、「LDAP属性権限の設定と変更」を参照してください）。 |
ある検索ベースから別の検索ベースにユーザーやグループをコピーするには、「コピー」のクリック、「リセット」のクリック、別の検索ベース・ドメインとターゲット・ドメインの選択、「貼付け」のクリックの順に操作を実行します。ユーザーとグループが、対応する個々のボックスに表示されます。
groupOfUniqueNamesオブジェクト・クラスに検索ベースを設定し、検索ベースを定義するグループを選択できます。グループに設定された検索ベース内のエントリの参照をグループのメンバーに許可するには、グループ・クラスのグループ・プロファイル・ページに対する読取り権限を構成する必要があります。「LDAP属性権限の設定と変更」を参照してください。
非結合検索ベースは、IDシステム設定時に選択した検索ベースを補足する検索ベースです。非結合検索ベースを作成して、ユーザー・データの存在する追加のLDAPディレクトリ・ツリーを指定できます。
1つのドメインに複数の非結合検索ベースを追加できます。次の手順では、非結合検索ベースを追加および削除する方法について説明します。
非結合検索ベースの管理方法の詳細は、「複数のディレクトリ検索ベースの操作」を参照してください。
「タブの構成」ページが表示されます。
ディレクトリ・プロファイルに構成されている検索ベースは、そのプロファイルの「ネームスペース」フィールドで確認できます。非結合ドメインでは、検索ベースごとに1つのディレクトリ・プロファイルが存在します。詳細は、「LDAPディレクトリ・サーバー・プロファイルの作成」およびを参照してください。
削除済の検索ベースに定義されたポリシーが存在する場合、ノードにその検索ベースを保持するユーザーは、クエリー・ビルダーを使用してその検索ベースを基準とするフィルタを作成できます。
クエリー・ビルダーにより、検索ベースの設定などのアクティビティを実行する際にLDAPフィルタを記述できます。
IDシステムでは、問合せのヒット数は20までに制限されています。この制限は、セレクタとクエリー・ビルダーの両方に適用されます。検索や問合せの結果が20ヒットを超えると、切り捨てられた結果が戻されます。検索の制限を変更する手順の詳細は、『Oracle Access Managerカスタマイズ・ガイド』に記載されているcookieBustLimitパラメータの説明を参照してください。
クエリー・ビルダー機能には、「フィルタの作成」ボタンからアクセスします。この機能は、検索ベースの設定時などに使用できます。詳細は、「検索ベースの設定」を参照してください。
これらはIDシステム・アプリケーションです。
「クエリー・ビルダー」ページが表示されます。デフォルトでは、「Basic」問合せページが表示されます。
たとえば、次のようになります。
Admin
属性がフィルタに追加されます。
たとえば、次のようになります。
次以上
使用可能な一致方法は、属性に応じて異なります。詳細は、「一致を取得するための方法」を参照してください。
たとえば、次のようになります。
January 22 2003
たとえば、「管理者」属性を持ち、かつ開始日が2003年1月22日より後の（より大きい）すべてのユーザーを検索できます。
結果が多すぎるか少なすぎる場合は、基準の制限範囲を調整します。
「保存」をクリックすると、前のページの「フィルタの作成」ボタンの下にフィルタが表示されます。
クエリー・ビルダーで選択できる一致方法は、属性の表示タイプに応じて異なります。たとえば、属性の表示タイプとして、リストまたはラジオ・ボタンのセットを使用できます。詳細は、「属性の表示タイプ」を参照してください。クエリー・ビルダーを使用して、リストなどの複数の値を含む表示タイプの属性にフィルタを作成すると、フィルタ基準を満たすのが1つの値のみであっても問合せで一致結果が戻されます。
フィルタを作成する場合、属性の表示タイプがチェック・ボックスまたはラジオ・ボタンである場合にのみ、1つの行で属性の複数の値を選択できます。
表4-4に、クエリー・ビルダーで使用できる一致方法をリストします。
フィルタでは、複数の属性を操作し、AND、OR、NOTなどの論理演算子を使用できます。
「拡張」ページが表示されます。
「拡張」タブをクリックしても「拡張」ページが表示されない場合、URLが長すぎる可能性があります。URLの長さは、ブラウザにより決定されます。
詳細は、「クエリー・ビルダーを使用したLDAPフィルタの記述」を参照してください。
属性は、「構築されたビジュアル・フィルタ」ボックスに追加されます。
「LDAPフィルタ」ボックスにLDAP文字列が表示されます。このボックスのテキストを編集して、「ビジュアル・フィルタの更新」をクリックできます。LDAPフィルタの例は、「静的LDAP検索フィルタ」および「動的LDAP検索フィルタの例」を参照してください。
非常に複雑なフィルタを手動で入力した場合、「構築されたビジュアル・フィルタ」ボックスではそのフィルタを正しく解釈できないことがあります。ただし、フィルタは正常に動作します。
フィルタに準拠した出力がIDシステムに表示されます。
「保存」のクリック時に不正なリクエストであるというメッセージが戻された場合、問合せ文字列がブラウザにとって長すぎます。ブラウザではフィルタをURLとして扱うため、問合せ文字列がブラウザの最大URL長を超えるとエラーが発生します。
属性に対する権限が構成されるまで、どのユーザーもUser Manager、Group ManagerおよびOrganization Managerに表示される属性を参照できません。たとえば、User Managerですべてのユーザーに従業員の仕事用電話番号を表示する一方で、マネージャにのみ自宅電話番号を表示するよう設定できます。
マスターID管理者または適切な権限を保持する委任管理者の場合、ユーザー権限を構成できます。デフォルトでは、Identity Serverのインストール時に指定されたマスター管理者は、すべての属性に対する完全なアクセス権を保持します。デフォルト設定を変更するには、次の場所のBypassAccessControlForDirAdminパラメータをfalseに設定します。
IdentityServer_install_dir/identity/oblix/apps/common/bin
「属性アクセス制御」機能を使用して、各LDAP属性の値を参照および変更できるユーザーを決定する権限を指定します。また、属性が変更されたときに通知を受けるユーザーまたはグループのリストを作成します。検索ベースを設定した場合と同様に、この機能はLDAP属性にのみ適用されます。テンプレート・オブジェクトに対する権限は、ワークフロー・ステップに参加者を追加するときに構成します。詳細は、第5章「ID機能とワークフローの連携」を参照してください。
属性を表示するには、ユーザーは定義された検索ベースと読取り権限を保持している必要があります。たとえば、User Manager、Group ManagerまたはOrganization Managerタブでクラス属性を表示するには、ユーザーはそのクラス属性に対応する適切な検索ベース・ドメインの受託者であり、その属性の読取り権限を保持している必要があります。
「構成」ページが表示されます。
アプリケーションの証明書を信頼するかどうかを尋ねるプロンプトが表示された場合は、「常に信頼」オプションを選択してください。
「属性アクセス制御」ページが表示されます。
初め、このフィールドには製品設定時に定義された検索ベースが表示されます。この検索ベースは、システム設定を再実行した場合にのみ変更できます。ツリーの下位レベルを選択すると、そのブランチにアクセス制御が適用されます。たとえば、「フルネーム」属性を選択し、営業（Sales）などの下位レベルの部門を選択すると、プロファイルにフルネームを含む営業部門のすべての人々にアクセス制御が適用されます。
フィルタにより、参照または変更可能な属性が絞り込まれます。フィルタを指定しない場合、IDシステムではobjectclass=*が使用されます。
「フィルタの追加」フィールドにフィルタを追加します。構成を保存すると、フィルタが「フィルタ」リストに追加されます。後で別のフィルタを指定する場合は、元の検索ベースを削除して新規構成を作成する必要があります。
フィルタの詳細は、「ルールとフィルタの使用方法」を参照してください。
たとえば、マネージャに「役職」属性に対する読取り権限と変更権限を付与できます。ユーザー・プロファイルでこの属性値が変更されたときに、人事管理部門に通知が送信されるよう設定できます。自己登録ステップの電子メール事後通知の詳細は、「ステップ・アクションの説明」を参照してください。
複数選択を行う場合、「複数の属性を選択するためのキー」を参照してください。
ロール: ユーザーのロールに基づいて権限を割り当てます。「ロール」領域には、データ型がDNで表示タイプが「オブジェクト・セレクタ」であるすべての属性が表示されます。IDシステムには、「自己」および「匿名」ロールが付属しています。各アプリケーションには、構成済の属性に大きく依存する様々なロールが含まれます。たとえば、User Managerの構成によっては、「マネージャ」ロールが含まれる一方で、秘書属性に基づくロールは含まれない可能性があります。共通ロールは、次のとおりです。
ルール: 「フィルタの作成」をクリックし、クエリー・ビルダーを使用してルールを作成します。詳細は、「クエリー・ビルダーを使用したLDAPフィルタの記述」を参照してください。
人々: 「ユーザーの選択」をクリックし、セレクタを使用して1人以上のユーザーを指定します。
グループ: 「グループの選択」をクリックし、セレクタを使用して1つ以上のグループを指定します。
権限の評価順序の詳細は、「LDAP属性権限の評価」を参照してください。
次のキーを組み合せて使用すると、複数の属性に対するアクセス制御を一度に構成できます。
プラットフォーム固有のキーの組合せは、次のとおりです。
| ブラウザ・タイプ | 機能 |
|---|---|
|
Windowsブラウザ |
|
|
UNIXブラウザ |
権限を表示および変更するための複数の方法が割り当てられている場合、IDシステムでは、それらの方法が次の順序で評価されます。
IDシステムは、一致を検出した時点でチェックを終了します。たとえば、User=Lou Reedに「名前」属性に対する読取り権限を付与する一方で、Lou Reed以外のすべてのユーザーを許可する(&(!(cn=Lou Reed)) objectclass=person object class)というルールを指定するとします。この場合、Lou Reedは、評価順序でルールより先にユーザーとして評価されるため、アクセス権を付与されます。別の例として、人事管理部門へのアクセスを拒否するルールを指定する一方で、ユーザー・セレクタを使用して人事管理部門の個々の従業員を指定する場合では、ルールおよびユーザー・カテゴリの組合せにより、指定した従業員にアクセス権が付与されます。
次の各項では、アプリケーション構成の様々な例について説明します。User Manager、Group ManagerおよびOrganization Manager用の個別の例を示します。
ユーザー・プロファイルのヘッダー・パネルに写真を表示できます。関連する属性に対するセルフサービス権限を保持するユーザーは、自分の写真を管理できます。
IDシステムに写真を格納する場合、次の2つの方法があります。
両方の方法を使用することはできません。ディレクトリまたはファイル・システムのいずれかにすべての写真を格納する必要があります。
写真またはその他のイメージをディレクトリに格納する場合、まずIdentity Serverに写真を配置します。次に、IDシステムを使用して、それらの写真をディレクトリにインポートし、属性を写真属性として構成します。独自の属性を作成するか、既存の属性を使用することが可能です。ディレクトリでは、属性をバイナリ型として定義する必要があります。また、IDシステムでは、属性を「GIFイメージ」表示タイプの「写真」セマンティク型として定義する必要があります。「GIFイメージ」表示タイプは、GIF形式とJPEG形式に対応しており、Webサーバーでサポートされるその他のイメージ・ファイル形式にも対応しています。 ユーザーのIDに写真を関連付ける前に、写真のファイル名が「ログイン」セマンティク型の属性の値に基づいていることを確認します。たとえば、「ログイン」セマンティク型がuid属性に割り当てられている場合、次のファイル名表記規則を使用します。
attribute_value_of_uid.gif or attribute_value_of_uid.jpg or attribute_value_of_uid.jpeg
「ログイン」セマンティク型がuid以外の属性に割り当てられている場合、かわりにその属性をファイル名に使用します。たとえば、「ログイン」セマンティク型が電子メール属性に割り当てられている場合、写真のファイル名は次のように指定する必要があります。
attribute_value_of_mail.gif or attribute_value_of_mail.jpg or attribute_value_of_mail.jpeg
ファイル拡張子は、Webサーバーでサポートされる画像ファイル形式に準拠します。
IDシステムで写真やイメージをインポートすると、ファイルはBase64形式に変換されます。このデータは、「写真」属性の値となります。IDシステムでは、「ログイン」属性と、写真またはイメージ・ファイルの名前を使用して、各ユーザー・エントリに関連付けられた写真を特定します。
次の手順では、IDシステムを構成して写真を使用する方法について説明します。
これで、すべてのGIFイメージとJPEGイメージがディレクトリにインポートされます。
ユーザーID用のイメージおよび写真を格納するもう1つの方法は、写真をディレクトリとは別の場所に格納することです。この方法は、GIFイメージとJPEGイメージに適しており、Webサーバーでサポートされるその他のイメージ・ファイル形式にも対応しています。 ファイルの格納場所には、Identity ServerのWebPassでアクセスできる必要があります。写真またはイメージ・ファイルの名前には、Webサーバーで認識およびサポートされる有効なファイル名を使用します。ファイル名に空白などの特殊文字を使用することは避けてください。特殊文字を使用したファイル名は、Webサーバーで認識されない可能性があります。
WebPass_install_dir/identity/oblix/lan/langTag/style0
ここで、WebPass_install_dirはWebPassがインストールされているディレクトリであり、langTagは使用中の特定の言語が含まれるフォルダです。
たとえば、イメージが次の場所にある場合:
c:¥COREid¥WebComponent¥identity¥oblix¥apps¥lang¥en-us¥style0¥user1.gif
写真の場所として次のように設定します。
user1.gif
写真のURL属性に複数値を設定すると、複数のGIFイメージを表示できます。
IDシステムには、デフォルトの写真イメージが付属しています。このイメージは、ユーザーに写真イメージが指定されていない場合に表示されます。このイメージは、Identity Serverのstyle0にCIMAGEdefaultphoto.gifとして格納されています。
IDシステムでは、デフォルトでOrganization Managerに「ロケーション」タブが含まれます。このタブにより、マップを作成し、ユーザーやオブジェクトをそれらのマップ上のロケーションに関連付けることができます。
これで、適切な権限を保持するユーザーは、ユーザーまたはオブジェクトのロケーションを参照できます。
グループの作成ワークフローを定義するときに、グループを作成する権限をユーザーに割り当てます。グループを作成できるのは、ワークフローの参加者として指定されたユーザーのみです。ワークフローの作成方法の詳細は、第5章「ID機能とワークフローの連携」を参照してください。
ユーザーにグループ・タイプを変更する権限を付与できるのは、ユーザーがそのグループ・タイプに対応するグループの作成ワークフローの参加者である場合です。また、ユーザーは、そのグループ・タイプ属性に対する書込み権限も保持している必要があります。グループ・タイプの詳細は、「Group Managerタブへの補助オブジェクト・クラスおよびテンプレート・オブジェクト・クラスの追加」を参照してください。グループ・タイプ属性の変更権限を割り当てる方法の詳細は、「LDAP属性権限の設定と変更」を参照してください。
複数のActive DirectoryインスタンスでIDシステムを実行し、動的フィルタを使用してグループを作成する場合、フィルタ属性は複数値属性である必要があります。
NDSディレクトリでIDシステムを実行している場合に「保存」をクリックすると、グループのメンバーとして選択したユーザーがページから消去されます。この状況を回避するには、NDSディレクトリに移動し、uniquememberが最初に読み取られるよう属性の順序を変更します。また、userCertificate属性がNDSのuserCertificate;binary属性より前に出現していることを確認します。
次の各項では、エンド・ユーザーが構成後のGroup Managerアプリケーションとどのようにやり取りするかについて説明します。
グループ・メンバーは、「グループ・プロファイル」ページで参照および管理できます（マスターID管理者がグループ・メンバー属性を選択して「グループ・プロファイル」ページに表示している場合）。詳細は、「タブのプロファイル・ページおよびパネルの構成」を参照してください。
グループに大規模なメンバー・リストが含まれると、システム・パフォーマンスに悪影響を及ぼす可能性があります。マスターID管理者は、「グループ・プロファイル」ページにグループ・メンバーを表示しないよう選択できます。「Group Managerタブのオプションの構成」を参照してください。
「グループ・メンバーの管理」ページでは、指定した基準に従ってグループのメンバーを参照できます。このページには、次の各表が含まれます。
検索結果は、Group ManagerおよびUser Managerアプリケーションに構成されている検索ベースと属性アクセス制御に応じて変化します。詳細は、「LDAP属性権限の設定と変更」を参照してください。
ユーザーがグループの動的メンバー属性に対する読取り権限を保持していない場合、動的メンバー表には何も表示されず、「動的メンバーに対する読取り権限がありません」というエラー・メッセージが表示されます。
ネストされたメンバー表では、グループ内にネストされた動的グループが含まれる場合に、ユーザーがネストされた一部のグループの動的メンバー属性に対する読取り権限を保持していないと、動的メンバーは表示されません。この場合、エラー・メッセージは表示されません。
グループ・プロファイルが表示されます。
「グループ・メンバーの管理」ページに、2つのレベルのネストされたグループとそのメンバーが検索結果として表示されます。これには、ネストされた子グループ、そのメンバー、およびその子が含まれます。
検索結果に表示されるグループ・メンバーは、「グループ・メンバーの管理」ページで削除できます。削除できるのは、静的メンバーのみです。動的メンバーやネストされたメンバーは削除できません。
「グループ・メンバーの検索」を参照してください。
グループにメンバーを追加できます。
「セレクタ」ページが表示されます。詳細は、「セレクタ」を参照してください。
Group Managerでは、グループを対象としたサブスクライブとサブスクライブ解除が可能です。
サブスクリプション・ポリシーを含むことができるのは、拡張グループとして構成されたグループのみです。グループ操作に必要とされる属性を提供するため、IDシステムにはoblixAdvancedGroupが付属しています。表4-5に、oblixAdvancedGroupの内容を示します。
ユーザーがグループにサブスクライブするには、次の3つの方法があります（マスターID管理者がそのグループのグループ・サブスクリプション・ポリシーを構成している場合）。
ユーザーは、プロファイルに表示されている選択されたグループにサブスクライブできます。
ユーザーは、ユーザーの作成ワークフローの最後のステップで複数のグループにサブスクライブできます。詳細は、第5章「ID機能とワークフローの連携」を参照してください。
ユーザーは、「サブスクリプションの管理」ページで複数のグループにサブスクライブできます。
サブスクライブ済のグループのリストが表示されます。内容は次のとおりです。
各IDアプリケーションで実行されたユーザー・アクションに関する情報を取得できます。取得された情報は、IDシステム・イベントの監査として格納されます。
監査ポリシーは、アプリケーションごとに構成します。これらの設定により、監査ファイルに取得されるデータが決定されます。Identity Serverごとに監査ファイルの出力場所を構成します。監査ファイルのパスを変更する方法の詳細は、「Identity Serverの管理」を参照してください。
監査ポリシーは、各IDシステム・アプリケーションで表示できます。
次の情報を含む「アプリケーション監査ポリシーの構成」ページが表示されます。
| 項目 | 説明 |
|---|---|
|
プロファイル属性 |
このアプリケーションにプロファイル属性が構成されている場合にのみ表示されます。 |
|
イベント名 |
監査対象のIDシステム操作です。 |
|
アプリケーション監査有効 |
このイベントの監査を有効化するかどうかを示します。 |
|
監査成功 |
イベントの成功を監査するかどうかを示します。 |
|
監査失敗 |
イベントの失敗を監査するかどうかを示します。 |
適切な権限を保持している場合、表示可能な監査ポリシーを変更できます。これらの設定は、IDシステム・コンソールの「共通構成」の「グローバル監査ポリシー」に含まれる「グローバル監査ポリシー」機能とは重複しません。
「アプリケーション監査ポリシーの変更」ページが表示されます。
たとえば、すべての「ロケーションの変更」イベントを監査すると同時に、「プロファイルの表示」イベントの失敗のみを監査できます。
前のページに戻ります。
レポートを使用すると、オブジェクト・クラスに関する情報を表示できます。レポートは、検索のかわりに使用できる方法であり、検索で表示されない属性を出力できます。
マスターID管理者は、ユーザーがUser Managerアプリケーションでレポートを表示できるように、IDシステム・コンソールでレポートを定義する必要があります。
たとえば、「タブ構成情報の表示と変更」の手順に従ってUser Managerで「従業員」タブを構成すると、特定の建物内の従業員、特定の役職名の従業員、または特定の部門に属する従業員のリストを含むレポートを作成できます。
レポート機能では、クエリー・ビルダーを使用して、基本検索では使用できない複雑な検索基準を定義できます。これにより、基本検索では対応できない様々なタイプの属性を詳細に指定して検索できます。レポートには、次の2つのタイプがあります。
レポートを最初に作成する場合、次のページが表示されます。
この基準の形式は、属性の表示タイプに応じて変化します。
検証ページが表示されます。
次のようなページが表示されます。いくつかのボタンが使用可能となります（次のスクリーン・ショットでハイライト表示されています）。これらのボタンは、次の手順で使用します。
レポートの表示は、アクセス制御と検索ベースの設定に準拠します。
適切な言語パックをインストールしており、各言語の構成を完了している場合、レポートの名前や説明を複数の言語で表示できます。詳細は、「Oracle Access Managerでの複数の言語の構成」を参照してください。
生成されたレポートをIDシステム・アプリケーションでエクスポートする際に、レポートの値に非ASCII文字が含まれる場合、.txt拡張子を使用してファイル名を変更する必要があります。これにより、Excelのインポート・ウィザードで使用可能となり、非ASCII文字は正しく表示されます。
OpenOfficeで開かれた.csvファイルは、インポート・ウィザードで使用できます。このアプリケーションでは、ファイル名を*.txtに変更することなくエンコーディングを選択できます。
他のユーザーが参照できるようレポートを公開する方法の詳細は、「レポートの構成」を参照してください。
既存のすべてのレポートがページにリストされます。
レポートの詳細がページに表示されます。
「レポートの公開」ページが表示されます。このページには、すべてのインストール済言語のリンクが含まれます。
この情報はオプションです。
User Managerにレポートが表示されます。
次の各項では、動的グループの拡張、ディレクトリ検索の有効範囲の制限、およびXMLファイルの編集による属性権限の構成について説明します。
グループのメンバーシップがLDAPフィルタにより決定される場合、グループを拡張することで静的メンバーシップ・リストを生成できます。静的リストの生成により、IDシステムでは、グループ・アクセスごとにLDAPフィルタを実行する必要がなくなります。
グループ拡張では、動的メンバーシップを指定するLDAPルールを実行し、その結果を静的メンバー属性に格納することで静的リストを更新します。多くのIDシステム機能で、グループのメンバーシップがテストされます。静的メンバーシップのテストは動的メンバーシップのテストより高速であるため、静的リストでメンバーを検索することが推奨されます。また、サード・パーティ・アプリケーションでチェックできるのは、静的メンバーシップのみである場合があります。サード・パーティ・アプリケーションの場合、頻繁に拡張を行うことで静的メンバーシップを正確に維持します。
グループ拡張操作は、それ自体がコストのかかるプロセスです。ただし、バックグラウンド・プロセスとしてグループを拡張することで、ユーザーへの影響を回避できます。
グループを拡張するには、次の2つの条件が満たされている必要があります。
IDシステムが提供するグループ属性の詳細は、「グループ・サブスクリプションの管理」の表を参照してください。
「構成」ページが表示されます。
「動的グループの拡張」ページが表示されます。
「拡張されたグループ」ページに、拡張されたすべてのグループのリストが表示されます。
IDシステムの一部の機能では、外部のXMLファイルを呼び出して構成情報を取得します。globalparams.xmlファイルは、そのようなファイルの1つです。このファイルにより、特に検索の有効範囲を制御できます。
デフォルトでは、検索の有効範囲はIDシステムのサブツリーに設定されており、検索は検索ベースの開始ポイントから始まってその子までを含みます。ディレクトリのサイズによっては、ResourceFilterSearchScopeパラメータを使用して検索のデフォルト有効範囲を変更できます。このパラメータに使用可能な値は、次のとおりです。
図4-1は、ResourceFilterSearchScopeの設定が1の場合には戻されるエントリが少数に限定される一方で、2の場合には大量のエントリが戻されることを示しています。
IdentityServer_install_dir/identity/oblix/apps/common/bin
簡易属性権限を使用すると、グループ作成者は、「LDAP属性権限の設定と変更」の手順に従って各属性の権限を設定することなく、読取り、書込みおよび通知の各権限を選択できます。
簡易権限は、ポリシーの管理ドメインが新規グループのDNである新規作成グループに適用されます。これらのポリシーは、後からアクセス制御機能を通じて変更できます。
管理者は、必要に応じて希望する数の簡易権限のセットを構成できます。権限は、IdentityServer_install_dir/oblix/apps/groupservcenter/bin/gscaclparams.xmlファイルで作成します。
このファイルには、モデルが適用されるロール、ユーザー、グループを定義するための埋込みの複合リスト、割当て権限、および権限が適用される属性が含まれます。このファイルが新規グループに適用されると、ファイル内の権限ごとにアクセス制御エントリが作成されます。
次に、gscaclparams.xmlファイルの権限セットの例を示します。モデル名は、Publicです。
<?xml version="1.0"?> <ParamsCtlg xmlns="http(s)://www.oblix.com" CtlgName="gscaclparams"> <!--#----------------------------------------------------> <!-- #Access Control Functions --> <!--#----------------------------------------------------> <!--#----------------------------------------------------> <!-- # Public access --> <!--#----------------------------------------------------> <CompoundList ListName=""> <CompoundList ListName="Public"> <CompoundList ListName="entry1"> <ValList ListName="roles" > <ValListMember Value="ob_any"> </ValList> <ValList ListName="rights" > <ValListMember Value="READ" Operation="Add"/> </ValList> <ValList ListName="attributes" > <ValListMember Value="description"/> <ValListMember Value="cn"/> <ValListMember Value="uniquemember"/> <ValListMember Value="owner"/> </ValList> </CompoundList> <CompoundList ListName="entry2"> <ValList ListName="roles" > <ValListMember Value="owner" Operation="Add"/> </ValList> <ValList ListName="rights" > <ValListMember Value="WRITE" Operation="Add"/> </ValList> <ValList ListName="attributes" > <ValListMember Value="description" Operation="Add"/> <ValListMember Value="cn" Operation="Add"/> <ValListMember Value="uniquemember" Operation="Add"/> <ValListMember Value="owner" Operation="Add"/> </ValList> </CompoundList>
次の表に、簡易権限の予約語をまとめます。
「コンテナ制限」機能を使用すると、組織単位とそのオブジェクト・クラスのオブジェクト（および子オブジェクト）の数を制御できます。管理者は、制限に到達しそうになったときに通知するユーザーを定義できます。たとえば、エクストラネットの顧客を格納しているディレクトリ・ツリーの組織単位があるとします。このとき、エクストラネットのポータルにアクセスする顧客の数を10,000人に制限できます。
「コンテナ制限」ページが表示されます。
この例では、ページ内の「現在の数」表から、gensiteOrgPersonオブジェクト・クラスがDITの現在のレベルに9個の子を格納しており、そのレベル以下に合計718個の子を格納していることがわかります。
「現在の数」ボックスに、選択したエントリに関連付けられたすべての構成済構造化クラスと、その子の数が表示されます。
「オブジェクト・クラス」表に、選択したDITエントリのコンテナ制限、強制および通知ポリシーがオブジェクト・クラスごとにリストされます。
2番目の「コンテナ制限」ページが表示されます。このページには、前の画面で選択した管理ドメインとオブジェクト・クラスが含まれます。
「ユーザー」、「ロール」および「ルール」フィールドには、OR関係が適用されます。どのフィールドに指定したユーザーにも通知が実行されます。
コンテナ制限は、あるドメインから別のドメインにコピーできます。
「コンテナ制限」画面が表示されます。
「現在の数」ボックスに、選択したエントリに関連付けられた構造化クラスと、その子の数が表示されます。
「オブジェクト・クラスにコンテナ制限を追加」の表に、現在選択されているDITエントリのコンテナ制限、強制および通知ポリシーがオブジェクト・クラスごとにリストされます。
コンテナ制限ポリシーが選択したDITエントリに追加されます。
コンテナ制限は変更できます。「Organization Managerでのコンテナ制限の設定」を参照してください。
「構成」画面が表示されます。
「コンテナ制限」画面が表示されます。
「現在の数」ボックスに、選択したエントリに関連付けられたすべての構成済構造化クラスと、その子の数が表示されます。
2番目の「コンテナ制限」画面が表示されます。
各フィールドの詳細は、「Organization Managerでのコンテナ制限の設定」を参照してください。
コンテナ制限は削除できます。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|