Sun Identity Manager 8.1 ビジネス管理者ガイド

第 6 章管理

この章では、Identity Manager 管理者と組織の作成と管理など、Identity Manager システムで一連の管理レベルタスクを実行するための情報と手順を説明します。また、Identity Manager でのロール、機能、管理者ロールの使用方法についても説明します。

この章は、次のトピックで構成されています。

Identity Manager の管理について

Identity Manager 管理者は、Identity Manager の拡張特権を持つユーザーです。

Identity Manager 管理者は、次のものを管理します。

ユーザーアカウント
ロールやリソースなどのシステムオブジェクト
組織

ユーザーとは異なり、Identity Manager の管理者には機能と管理する組織が割り当てられます。これらは次のように定義されます。

「機能」。Identity Manager のユーザー、組織、ロール、およびリソースへのアクセス権を与える一連の権限。
「管理する組織」。組織の管理を割り当てられると、管理者は、その組織内と、階層内でその組織の子孫であるすべての組織のオブジェクトを管理できます。

委任された管理

ほとんどの企業では、管理タスクを実行する従業員は、それぞれ固有の役割を持っています。その結果、これらの管理者が実行可能なアカウント管理タスクの範囲が制限されます。

たとえば、管理者は Identity Manager ユーザーアカウントを作成する役割しか持たない場合があります。このように役割の範囲が制限されている場合、管理者には、ユーザーアカウントを作成するリソースについての特定の情報や、システム内に存在するロールまたは組織についての情報は必要ないと思われます。

Identity Manager で、管理者の役割を定義した範囲内の特定のタスクに限定することもできます。

Identity Manager は、役割の分離および委任された管理モデルを次のようにサポートします。

機能の割り当て。管理者を特定の職務に限定します
管理する組織の割り当て。特定の組織とその組織内のオブジェクトの管理のみに管理者を限定します
「ユーザーの作成」および「ユーザーの編集」ページのフィルタ付きビューにより、職務に関係のない情報が管理者に表示されないようにします

新しいユーザーアカウントを設定したり、ユーザーアカウントを編集したりする場合に、「ユーザーの作成」ページからユーザーの委任を指定できます。

また、「作業項目」タブから承認リクエストなどの作業項目を委任することもできます。委任の詳細については、「作業項目の委任」を参照してください。

管理者の作成と管理

この節は、次のトピックで構成されています。

管理者を作成する

管理者を作成するには、ユーザーに 1 つ以上の機能を割り当て、それらの機能を適用する組織を指定します。

管理者インタフェースで、メニューバーの「アカウント」をクリックします。

「ユーザーリスト」ページが開きます。

既存のユーザーに管理特権を与えるには、ユーザー名をクリックして (「ユーザーの編集」ページが開きます)、「セキュリティー」タブをクリックします。

新しいユーザーアカウントを作成する必要がある場合は、「ユーザーの作成およびユーザーアカウントの操作」を参照してください。

管理する属性を指定します。

設定できる属性は次のとおりです。
- 「機能」。この管理者に割り当てる 1 つ以上の機能を選択します。この情報は必須です。詳細については、「機能とその管理について」を参照してください。
- 「管理する組織」。管理者に割り当てる 1 つ以上の組織を選択します。管理者は、割り当てた組織内と、階層内でその組織の下にある任意の組織内のオブジェクトを管理します。この情報は必須です。詳細については、「Identity Manager の組織について」を参照してください。
- 「ユーザーフォーム」。Identity Manager ユーザーの作成および編集時にこの管理者が使用するユーザーフォームを選択します (その機能が割り当てられている場合)。ユーザーフォームを直接割り当てない場合、管理者は自分の所属する組織に割り当てられたユーザーフォームを継承します。ここで選択されたフォームは、この管理者の組織で選択されたどのフォームよりも優先されます。
- 「承認リクエスト転送先」。現在保留中のすべての承認リクエストを転送するユーザーを選択します。この管理者設定は、「承認」ページからも設定できます。
- 「作業項目の委任先」。使用可能な場合は、このオプションを使用して、このユーザーアカウントの委任を指定します。1 人または複数の選択したユーザーを管理者のマネージャーに指定するか、承認委任先規則を使用します。

管理者ビューのフィルタ

組織と管理者にユーザーフォームを割り当てることにより、ユーザー情報についての特定の管理者ビューを設定できます。

ユーザー情報へのアクセスは、次の 2 つのレベルで設定されます。

「組織」。組織を作成するときには、その組織内のすべての管理者が Identity Manager ユーザーの作成および編集時に使用するユーザーフォームを割り当てます。管理者レベルで設定されたフォームはすべて、ここで設定したフォームよりも優先されます。管理者または組織に対してフォームが選択されていない場合は、親組織に対して選択したフォームが継承されます。親組織に対してフォームが設定されていない場合は、システム設定のデフォルトのフォームが使用されます。
「管理者」。ユーザー管理機能を割り当てるときには、管理者にユーザーフォームを直接割り当てることができます。フォームを割り当てない場合、管理者は自分の組織に割り当てられたフォームを継承します。組織にフォームが設定されていない場合は、システム設定のデフォルトのフォームになります。

割り当て可能な Identity Manager の組み込み機能については、「機能とその管理について」を参照してください。

管理者パスワードの変更

管理者パスワードは、管理パスワード変更機能を割り当てられた管理者か、管理者所有者が変更できます。

管理者は、次のフォームを使用して別の管理者のパスワードを変更できます。

「Change User Password」フォーム。このフォームを開くには 2 つの方法があります。
- メニューの「アカウント」をクリックします。「ユーザーリスト」が開きます。管理者を選択し、「ユーザーアクション」リストの「パスワードの変更」を選択します。「ユーザーパスワードの変更」ページが開きます。
- メニューの「パスワード」をクリックします。「ユーザーパスワードの変更」ページが開きます。
タブ付きユーザーフォーム。メニューの「アカウント」をクリックします。「ユーザーリスト」が開きます。管理者を選択し、「ユーザーアクション」メニューの「編集」を選択します。「ユーザーの編集」ページ (タブ付きユーザーフォーム) が開きます。「ID」フォームタブの「パスワード」と「パスワードの確認」フィールドに新しいパスワードを入力します。

管理者は、「パスワード」領域から自分自身のパスワードを変更できます。メニューの「パスワード」をクリックし、「自分のパスワードの変更」をクリックします。

注 –

アカウントに適用された Identity Manager アカウントポリシーは、パスワードの有効期限、リセットオプション、通知選択など、パスワードに関する制限を決定します。管理者のリソースにパスワードポリシーを設定することにより、パスワード制限を追加設定することができます。

管理者のアクションの認証

Identity Manager では、管理者がアカウントの変更処理を行う前に、パスワードの入力を求めるように設定できます。認証に失敗すると、アカウントの変更は取り消されます。

管理者がユーザーパスワードの変更に使用できるフォームは 3 つあります。タブ付きユーザーフォーム、「Change User Password」フォーム、および「Reset User Password」フォームです。Identity Manager でユーザーアカウントの変更が処理される前に、管理者にパスワードの入力を確実に要求するために、3 つのフォームすべてを必ず更新してください。

タブ付きユーザーフォームでパスワード認証の要求を有効にする

タブ付きユーザーフォームでパスワード認証を要求するには、次の手順に従います。

管理者インタフェースで、ブラウザに次の URL を入力して Identity Manager デバッグページ (「Identity Manager デバッグページ」) を開きます (このページを開くにはデバッグ機能が有効である必要があります)。

http://<AppServerHost>:< Port>/idm/debug/session.jsp

システム設定ページ (Identity Manager デバッグページ) が表示されます。

「List Objects」ボタンにあるドロップダウンメニューから「UserForm」を選択して、「List Objects」ボタンをクリックします。

「List Objects of type: UserForm」ページが開きます。

本稼働しているタブ付きユーザーフォームのコピーを検索して、「Edit」をクリックします (Identity Manager で配布されているタブ付きユーザーフォームはテンプレートなので、変更しないでください)。

<Form> 要素内に次のコードを追加します。

<Properties>
  <Property name=’RequiresChallenge’>
    <List>
      <String>password</String>
      <String>email</String>
      <String>fullname</String>
    </List>
  </Property>
</Properties>

プロパティーの値は、次のユーザー表示属性名を 1 つ以上格納できるリストです。

applications
adminRoles
assignedLhPolicy
capabilities
controlledOrganizations
email
firstname
fullname
lastname
organization
password
resources
roles

変更を保存します。

「Change User Password」および「Reset User Password」フォームでパスワード認証を有効にする

「Change User Password」および「Reset User Password」フォームでパスワード認証を要求するには、次の手順に従います。

管理者インタフェースで、ブラウザに次の URL を入力して Identity Manager デバッグページ (「Identity Manager デバッグページ」) を開きます (このページを開くにはデバッグ機能が有効である必要があります)。

http://<AppServerHost>:< Port>/idm/debug/session.jsp

システム設定ページ (Identity Manager デバッグページ) が表示されます。

「List Objects」ボタンにあるドロップダウンメニューから「UserForm」を選択して、「List Objects」ボタンをクリックします。

「List Objects of type: UserForm」ページが開きます。

本稼働している「Change User Password」フォームのコピーを検索して、「Edit」をクリックします (Identity Manager で配布されている「Change User Password」フォームはテンプレートなので、変更しないでください)。

<Form> 要素を見つけ、<Properties> 要素に移動します。

<Properties> 要素内に次の行を追加し、変更を保存します。

<Property name=’RequiresChallenge’ value=’true’/>

本稼働の「Reset User Password フォーム」のコピーの編集を除いて、手順 3 から 5 を繰り返します。

秘密の質問の回答の変更

「パスワード」領域を使用して、アカウントの秘密の質問に設定した回答を変更することができます。メニューバーの「パスワード」を選択し、「自分の秘密の質問の回答の変更」を選択します。

認証の詳細については、第 3 章ユーザーとアカウントの管理の「ユーザー認証」を参照してください。

管理者インタフェースでの管理者名の表示のカスタマイズ

Identity Manager 管理者インタフェースの一部のページおよび領域では、Identity Manager 管理者をアカウント ID ではなく属性 (email や fullname など) に基づいて表示できます。

たとえば、次の領域では Identity Manager 管理者を属性で表示できます。

「ユーザーの編集」(承認選択リストを転送する)
ロールテーブル
「ロールの作成」/「ロールの編集」
「リソースの作成」/「リソースの編集」
「組織の作成」/「組織の編集」/「ディレクトリジャンクション」
承認

表示名を使用するように Identity Manager を設定するには、次のように UserUIConfig オブジェクトに追加します。

<AdminDisplayAttribute>
  <String>attribute_name</String>
</AdminDisplayAttribute>

たとえば、email 属性を表示名として使用するには、次の属性名を UserUIconfig に追加します。

<AdminDisplayAttribute>
  <String>email</String>
</AdminDisplayAttribute>

Identity Manager の組織について

組織を使用して、次のことができます。

ユーザーアカウントと管理者を論理的かつセキュアに管理する
リソース、アプリケーション、ロール、およびその他の Identity Manager オブジェクトへのアクセスを制限する

組織を作成してユーザーを組織階層内のさまざまな場所に割り当てることで、委任された管理のステージが設定されます。1 つ以上の組織を含む組織は、親組織と呼ばれます。

すべての Identity Manager ユーザー (管理者を含む) は、1 つの組織に静的に割り当てられます。ユーザーを別の組織に動的に割り当てることもできます。

Identity Manager 管理者はさらに、管理する組織にも割り当てられます。

組織の作成

組織を作成する

Identity Manager の「アカウント」領域で組織を作成します。

管理者インタフェースで、メニューバーの「アカウント」をクリックします。

「ユーザーリスト」ページが開きます。

「新規作成アクション」メニューの「新規組織」を選択します。

ヒント –
組織階層内の特定の場所に組織を作成するには、リストで組織を選択してから、「新規作成アクション」メニューの「新規組織」を選択します。

図 6–1 に、「組織の作成」ページを示します。

図 6–1 「組織の作成」ページ

組織へのユーザーの割り当て

各ユーザーは 1 つの組織の静的なメンバーですが、複数の組織の動的なメンバーになることもできます。

次のいずれかの方法を使用して、組織のメンバーシップを定義します。

「直接 (静的) 割り当て」。「ユーザーの作成」ページまたは「ユーザーの編集」ページで「ID」フォームタブを選択して、ユーザーを組織に直接割り当てます。ユーザーは、1 つの組織に直接割り当てる必要があります。
「規則に基づく (動的) 割り当て」。組織に割り当てられているユーザーメンバー規則を使用して、ユーザーを組織に割り当てます。規則が評価されると、メンバーユーザーの一覧が返されます。

Identity Manager は、次の場合にユーザーメンバー規則を評価します。
- 組織内のユーザーの一覧を出力する
- 「ユーザーの検索」ページでユーザーを検索するときに、ユーザーメンバー規則による組織内のユーザーの検索を含める
- ユーザーへのアクセスをリクエストする (現在の管理者がユーザーメンバー規則を持つ組織を管理している場合)

注 –

Identity Manager で規則を作成および操作する方法については、『Sun Identity Manager Deployment Reference』の第 4 章「Working with Rules」を参照してください。

「組織の作成」ページの「ユーザーメンバー規則」メニューでユーザーメンバー規則を選択します。次の図に、ユーザーメンバー規則の例を示します。

次の例は、組織のユーザーメンバーシップを動的に管理するための、サンプルのユーザーメンバー規則の構文を示しています。

注 –

ユーザーメンバー規則を作成する前に、次の点に注意してください。

規則を「ユーザーメンバー規則」オプションボックスに表示する場合は、authType を authType=’UserMembersRule’ に設定する必要があります。
コンテキストは、現在認証されている Identity Manager ユーザーのセッションです。
定義された変数 (defvar) Team players は、Windows Active Directory のPro Ball Team 組織単位 (OU) から、そのすべてのメンバーユーザーの識別名 (DN) を取得します。
メンバーユーザーが検出されると、append ロジックは、Pro Ball Team OU のメンバーユーザーの DN に Identity Manager リソースの名前を連結し、先頭にコロンを付加します (:smith-AD など)。
結果は、Identity Manager リソース名が連結された DN (dn:smith-AD など) のリストとして返されます。

例 6–1 ユーザーメンバー規則の例

<Rule name=’Get Team Players’ authType=’UserMembersRule’>
  <defvar name=’Team players’>
    <block>
      <defvar name=’player names’>
        <list/>
      </defvar>
  <dolist name=’users’>
    <invoke class=’com.waveset.ui.FormUtil’ name=’getResourceObjects’>
      <ref>context</ref>
      <s>User</s>
      <s>singleton-AD</s>
      <map>
        <s>searchContext</s>
        <s>OU=Pro Ball Team,DC=dev-ad,DC=waveset,DC=com</s>
        <s>searchScope</s>
        <s>subtree</s>
        <s>searchAttrsToGet</s>
        <list>
          <s>distinguishedName</s> 
        </list> 
      </map> 
    </invoke> 
    <append name=’player names’> 
    <concat> 
      <get> 
        <ref>users</ref>
        <s>distinguishedName</s>
      </get>
        <s>:sampson-AD</s>
    </concat>
    </append> 
  </dolist> 
    <ref>player names</ref>
  </block>
   </defvar> 
    <ref>Team players</ref>
</Rule>

注 –

Waveset.properties の一部のプロパティーを設定して、規則に基づくユーザーメンバーリストのキャッシュを制御できます。これは、メモリーとパフォーマンスに影響します。詳細については、『Sun Identity Manager 8.1 System Administrator’s Guide』の「Tracing Rule-Driven Members Caches」を参照してください。

管理する組織の割り当て

「ユーザーの作成」または「ユーザーの編集」ページから、1 つ以上の組織の管理を割り当てます。「セキュリティー」フォームタブを選択すると、「管理する組織」フィールドが表示されます。

また、「管理者ロール」フィールドから 1 つ以上の管理者ロールを割り当てる方法で、管理する組織を割り当てることもできます。

ディレクトリジャンクションおよび仮想組織について

「ディレクトリジャンクション」は、階層的に関連する一連の組織で、ディレクトリリソースの実際の階層型コンテナのセットをミラー化したものです。ディレクトリリソースは、階層型コンテナを使用して、階層的な名前空間を使用するリソースです。ディレクトリリソースの例には、LDAP サーバーおよび Windows Active Directory リソースがあります。

ディレクトリジャンクション内の各組織は、仮想組織です。ディレクトリジャンクションの最上位の仮想組織は、リソース内に定義されたベースコンテキストを表すコンテナをミラー化したものです。ディレクトリジャンクション内の残りの仮想組織は、最上位の仮想組織の直接または間接的な子であり、定義済みリソースのベースコンテキストコンテナの子であるディレクトリリソースコンテナのいずれかをミラー化しています。この構造を図 6–2 に示します。

図 6–2 Identity Manager 仮想組織

ディレクトリジャンクションは、既存の Identity Manager 組織構造の任意の場所に接合することができます。ただし、ディレクトリジャンクションは既存のディレクトリジャンクション内またはその下で接合することはできません。

ディレクトリジャンクションを Identity Manager 組織ツリーに追加すると、そのディレクトリジャンクションのコンテキスト内で仮想組織を作成または削除することができます。また、ディレクトリジャンクションを構成する一連の仮想組織を任意の時点で更新して、ディレクトリリソースコンテナと同期しているかどうかを確認できます。ディレクトリジャンクション内に非仮想組織を作成することはできません。

Identity Manager オブジェクト (ユーザー、リソース、ロールなど) を、Identity Manager 組織と同様の方法で仮想組織のメンバーにして、仮想組織から使用可能にすることができます。

ディレクトリジャンクションの設定

この節では、ディレクトリジャンクションの設定方法について説明します。

ディレクトリジャンクションを設定する

管理者インタフェースでメニューバーの「アカウント」を選択します。

「ユーザーリスト」ページが開きます。

「アカウント」リストで Identity Manager 組織を選択します。

選択した組織は、設定する仮想組織の親組織になります。

「新規作成アクション」メニューの「新規ディレクトリジャンクション」を選択します。

「ディレクトリジャンクションの作成」ページが表示されます。

「ディレクトリジャンクションの作成」ページのオプションを使用して、仮想組織を設定します。

次のオプションがあります。
- 「親組織」。このフィールドには、「アカウント」リストで選択した組織が表示されます。リストから別の親組織を選択することもできます。
- 「ディレクトリリソース」。構造を仮想組織にミラー化する、既存のディレクトリを管理するディレクトリリソースを選択します。
- 「ユーザーフォーム」。この組織の管理者に適用するユーザーフォームを選択します。
- 「Identity Manager アカウントポリシー」。ポリシーを選択します。デフォルトのオプション (継承) を選択すると、親組織からポリシーが継承されます。
- 「承認者」。この組織に関係するリクエストを承認できる管理者を選択します。

仮想組織の更新

このプロセスでは、選択した組織の下位にある、関連付けられたディレクトリリソースを持つ仮想組織を更新して同期し直します。リストで仮想組織を選択し、「組織アクション」リストから「組織の更新」を選択します。

仮想組織の削除

仮想組織を削除する場合は、次の 2 つの削除オプションから選択できます。

Identity Manager 組織のみを削除する。Identity Manager ディレクトリジャンクションのみを削除します。
Identity Manager 組織とリソースコンテナを削除する。Identity Manager ディレクトリジャンクションと、ネイティブリソース上の対応する組織を削除します。

いずれかのオプションを選択して、「削除」をクリックします。

機能とその管理について

機能は、Identity Manager システム内の権限のグループです。機能は、パスワードのリセットやユーザーアカウントの管理などの管理ジョブの役割を表します。各 Identity Manager 管理ユーザーには、1 つ以上の機能が割り当てられ、データ保護を危険にさらすことなく、一連の特権を提供します。

すべての Identity Manager ユーザーに機能を割り当てる必要はありません。機能を割り当てる必要があるのは、Identity Manager で 1 つ以上の管理操作を実行するユーザーだけです。たとえば、ユーザーが自分のパスワードを変更する場合は、機能が割り当てられている必要はありませんが、別のユーザーのパスワードを変更する場合には機能が必要になります。

割り当てられた機能により、Identity Manager 管理者インタフェースのどの領域にアクセスできるかが決まります。

Identity Manager 管理ユーザーはすべて、Identity Manager の次の領域にアクセスできます。

「ホーム」および「ヘルプ」タブ
「パスワード」タブ (「自分のパスワードの変更」および「自分の秘密の質問の回答の変更」サブタブのみ)
「レポート」 (管理者の持つ役割に関連するレポートタイプのみ)

注 –

Identity Manager のデフォルトのタスクベース機能と実用上の機能 (定義を含む) のリストについては、付録 D 機能の定義を参照してください。この付録では、タスクベースの各機能でアクセス可能なタブおよびサブタブも示します。

機能のカテゴリ

Identity Manager では、機能を次のように定義しています。

タスクベース。これらはもっとも単純なタスクレベルにある機能です。
実用上。実用上の機能は、1 つ以上の実用上の機能またはタスクベース機能で構成されます。

組み込み機能 ( システムに付属の機能) は保護されており、編集することができません。ただし、この機能を、自分で作成した機能の中で使用することはできます。

保護された (組み込み) 機能は、赤い鍵 (または赤い鍵とフォルダ) のアイコンとしてリストに示されます。ユーザーが作成し、編集できる機能は、緑色の鍵 (または緑色の鍵とフォルダ) アイコンとして機能リストに示されます。

機能の操作

この節では、機能の作成、編集、割り当て、および名前の変更を行う方法について説明します。これらのタスクは「機能」ページから実行します。

「機能」ページの表示

「機能」ページは「セキュリティー」タブにあります。

「機能」ページを開く

管理者インタフェースでトップメニューの「セキュリティー」をクリックします。

二次的なメニューで「機能」をクリックします。

「機能」ページが開き、Identity Manager の機能一覧が表示されます。

機能の作成

機能を作成するには、次の手順に従います。機能の「複製」については、「機能の保存と名前の変更」を参照してください。

機能を作成する

管理者インタフェースでトップメニューの「セキュリティー」をクリックします。

二次的なメニューで「機能」をクリックします。

「機能」ページが開き、Identity Manager の機能一覧が表示されます。

「新規」をクリックします。

「機能の作成」ページが開きます。

次のようにフォームを設定します。
1. 新しい機能に名前を付けます。
2. 「機能」セクションの矢印ボタンを使って、ユーザーに割り当てる機能を「割り当てられた機能」ボックスに移動します。
3. 「譲渡者」ボックスで、この機能のほかのユーザーへの割り当てを許可する 1 人以上のユーザーを選択します。
  - ユーザーを選択しない場合、この機能を割り当てることのできるユーザーは、機能を作成したユーザーのみになります。
  - 機能の作成者に「ユーザーへの機能の割り当て」機能が割り当てられていない場合は、少なくとも 1 人のユーザーが別のユーザーに機能を割り当てられるように、1 人または複数のユーザーを選択する必要があります。
4. 「組織」ボックスで、この機能を使用できるようにする 1 つ以上の組織を選択します。
5. 「保存」をクリックします。
  
  注 –
  譲渡者の選択元となる一連のユーザーには、機能の割り当て権限を割り当てられているユーザーが含まれます。

機能の編集

保護されていない機能は編集できます。

保護されていない機能を編集する

管理者インタフェースでトップメニューの「セキュリティー」をクリックします。

二次的なメニューで「機能」をクリックします。

「機能」ページが開き、Identity Manager の機能一覧が表示されます。

リスト内の機能を右クリックし、「編集」を選択します。「機能の編集」ページが開きます。

変更を行い、「保存」をクリックします。

組み込み機能は編集できません。ただし、それらを別の名前で保存して、独自の機能を作成することはできます。作成する機能の中で組み込み機能を使用することもできます。

機能の保存と名前の変更

既存の機能に新しい名前を付けて保存することにより、新しい機能を作成できます。この操作は機能の「複製」とも呼ばれます。

機能を複製する

管理者インタフェースでトップメニューの「セキュリティー」をクリックします。

二次的なメニューで「機能」をクリックします。

「機能」ページが開き、Identity Manager の機能一覧が表示されます。

リスト内の機能を右クリックし、「名前を付けて保存」を選択します。

新しい機能の名前を入力するダイアログボックスが開きます。

名前を入力して「OK」をクリックします。

これで新しい機能を編集できるようになります。

ユーザーへの機能の割り当て

「ユーザーの作成」ページ (「ユーザーの作成およびユーザーアカウントの操作」) または「ユーザーの編集」ページ (「ユーザーの編集」) を使用して、機能をユーザーに割り当てます。インタフェースの「セキュリティー」領域で設定した管理者ロールを割り当てる方法で、ユーザーに機能を割り当てることもできます。詳細については、「管理者ロールとその管理について」を参照してください。

注 –

管理者ロールとその管理について

「管理者ロール」では 2 つのもの、つまり一連の機能と制御の範囲を定義します。「制御の範囲」という語は、管理対象の 1 つ以上の組織を指します。管理者ロールを定義してから、それを 1 人以上の管理者に割り当てることができます。

注 –

ロールと管理者ロールを混同しないようにしてください。ロールは、エンドユーザーの外部リソースへのアクセスを管理するために使用するのに対し、管理者ロールは主に、Identity Manager 管理者の Identity Manager オブジェクトへのアクセスを管理するために使用します。

この節の情報は、管理者ロールのみに限定されています。ロールの詳細については、「ロールとその管理について」を参照してください。

1 人の管理者に複数の管理者ロールを割り当て可能です。これによって、管理者は 1 つの制御の範囲内ではある一連の機能を持ち、別の制御の範囲内では別の一連の機能を持つことができます。たとえば、管理者にある管理者ロールを割り当てて、その管理者ロールで指定された管理する組織のユーザーの作成および編集の権限を与えます。次に 2 つ目の管理者ロールを同じ管理者に割り当てますが、今度はその管理者ロールで定義した管理する組織の別個のセット内に「ユーザーのパスワードの変更」権限のみを与えます。

管理者ロールによって、機能と管理範囲の組み合わせの再利用が可能になります。管理者ロールで、多数のユーザーに対する管理者特権の管理を簡素化することもできます。個々のユーザーに機能と管理する組織を直接割り当てるのではなく、管理者ロールを使用して管理者特権を付与するようにしてください。

機能または組織 (またはその両方) の管理者ロールへの割り当ては、直接または動的 (間接的) に行うことができます。

直接。機能や管理する組織を、明示的に管理者ロールに割り当てます。たとえば、管理者ロールに User Report Administrator 機能と管理する組織「Top」を割り当てることが考えられます。
動的 (間接)。この方法では、機能および管理する組織を割り当てる規則を使用します。管理者ロールが割り当てられた管理者がログインするごとに、規則が評価されます。管理者が認証されると、割り当てられる機能や管理する組織のセットが、規則に基づいて動的に決定されます。

たとえば、ユーザーがログインする場合、次のようになります。
- ユーザーの Active Directory (AD) ユーザータイトルが「manager」 (マネージャー) である場合、機能規則は割り当てる機能として「アカウント管理者」を返します。
- ユーザーの Active Directory (AD) ユーザー部署が「marketing」 (マーケティング) である場合、管理する組織の規則は割り当てる管理組織として「マーケティング」を返します。

管理者ロールのユーザーへの動的割り当ては、ユーザーインタフェース、管理者インタフェースなどログインインタフェースごとに有効または無効にできます。この場合は、次のシステム設定属性を true または false に設定します。

security.authz.checkDynamicallyAssignedAdminRolesAtLoginTo.logininterface

すべてのインタフェースのデフォルトは false です。

システム設定オブジェクトを編集する方法については、「Identity Manager 設定オブジェクトの編集」を参照してください。

管理者ロールの規則

Identity Manager には、管理者ロールの規則を作成するためのサンプル規則が用意されています。これらの規則は、Identity Manager インストールディレクトリの sample/adminRoleRules.xml にあります。

表 6–1 に、規則の名前と各規則に指定する authType を示します。

表 6–1 管理者ロールのサンプル規則


規則名	`authType`
管理する組織の規則	`ControlledOrganizationsRule`
機能規則	`CapabilitiesRule`
ユーザーへの管理者ロール割り当て規則	`UserIsAssignedAdminRoleRule`

注 –

サービスプロバイダユーザー管理者ロールのサンプル規則については、第 17 章サービスプロバイダの管理の「サービスプロバイダユーザーの委任管理」を参照してください。

ユーザー管理者ロール

Identity Manager には、「ユーザー管理者ロール」という組み込みの管理者ロールがあります。デフォルトでは、割り当てられた機能や管理する組織の割り当てはありません。また、このロールを削除することはできません。この管理者ロールは、ログインするインタフェース (ユーザー、管理者、コンソール、Identity Manager IDE など) にかかわらず、ログイン時に暗黙的にすべてのユーザー、つまりエンドユーザーと管理者に割り当てられます。

注 –

サービスプロバイダユーザーの管理ロールの作成については、第 17 章サービスプロバイダの管理の「サービスプロバイダユーザーの委任管理」を参照してください。

ユーザー管理者ロールは、管理者インタフェースで「セキュリティー」を選択してから「管理者ロール」を選択することによって編集できます。

この管理者ロールによって静的に割り当てられる機能または管理する組織はすべてのユーザーに割り当てられるので、機能および管理する組織の割り当ては規則を通して行うことをお勧めします。そうすることで、異なるユーザーが異なる機能を持つまたは機能を持たないようにすることができ、ユーザーがだれか、ユーザーがどの部署に所属するか、またはユーザーが管理者であるかなど、規則のコンテキスト内で問い合わせ可能な要素に基づいて割り当ての範囲が設定されます。

ユーザー管理者ロールによって、ワークフローで使用される authorized=true フラグの有用性が低下したり、そのフラグが完全に取って代わられるわけではありません。ワークフローが実行中である場合を除き、ワークフローがアクセスするオブジェクトに対してユーザーがアクセス権を持っていないときには、依然としてこのフラグのほうが適しています。基本的には、このときユーザーは「スーパーユーザーとして実行」モードに入ります。

ただし、ユーザーに、ワークフローの外部 (および状況によっては内部) にある 1 つ以上のオブジェクトへの特定のアクセス権があるとよい場合も考えられます。そのような場合には、機能および管理する組織を動的に割り当てる規則を使用して、それらのオブジェクトに対するきめ細かい承認を行うことができます。

管理者ロールの作成および編集

管理者ロールを作成または編集するには、Admin Role Administrator 機能が必要です。

管理者ロールにアクセスするには、管理者インタフェースで「セキュリティー」をクリックしてから「管理者ロール」タブをクリックします。「管理者ロール」リストページでは、Identity Manager ユーザーとサービスプロバイダユーザーの管理者ロールを作成、編集、および削除できます。

既存の管理者ロールを編集するには、リスト内の名前をクリックします。管理者ロールを作成するには、「新規」をクリックします。「管理者ロールの作成」のオプションが表示されます (図 6–3)。「管理者ロールの作成」画面には 4 つのタブが表示されます。これらを使用して一般的な属性、機能、新しい管理者ロールの範囲、ユーザーへのロールの割り当てを指定します。

図 6–3 「管理者ロールの作成」ページ: 「一般」タブ

「一般」タブ

「管理者ロールの作成」または「管理者ロールの編集」画面の「一般」タブを使用して、管理者ロールの次の一般的な特性を指定します。

「名前」。この管理者ロールの一意の名前。

たとえば、財務部門 (または組織) のユーザーの管理機能を持つユーザーに対して財務管理者ロールを作成できます。
「タイプ」。タイプには「アイデンティティーオブジェクト」または「サービスプロバイダユーザー」を選択します。このフィールドは必須です。

Identity Manager ユーザー (またはオブジェクト) の管理者ロールを作成している場合は、「アイデンティティーオブジェクト」を選択します。サービスプロバイダユーザーにアクセス権限を与える管理者ロールを作成している場合は、「サービスプロバイダユーザー」を選択します。

注 –

管理者ロールを作成してサービスプロバイダユーザーにアクセス権限を与える方法については、第 17 章サービスプロバイダの管理の「サービスプロバイダユーザーの委任管理」を参照してください。

「譲渡者」。この管理者ロールをほかのユーザーに割り当てることができるようにするユーザーを、選択または検索します。選択の対象となるユーザーセットには、「割り当て機能」権を割り当てられたユーザーが含まれます。

ユーザーを選択しなかった場合、管理者ロールを割り当てることのできるユーザーは、それを作成したユーザーのみになります。管理者ロールを作成したユーザーに「ユーザーへの機能の割り当て」機能が割り当てられていない場合、少なくとも 1 人のユーザーが管理者ロールをほかのユーザーに割り当てることができるように、1 人または複数のユーザーを「譲渡者」として選択します。
「組織」。この管理者ロールを使用できる組織を 1 つまたは複数選択します。このフィールドは必須です。

管理者は、割り当てられた組織のオブジェクト、および階層内でその組織の下位にあるすべての組織のオブジェクトを管理できます。

制御の範囲

Identity Manager では、どのユーザーをエンドユーザーの制御範囲に置くかを管理できます。

「制御の範囲」タブ (図 6–4) を使用して、この組織のメンバーで管理可能な組織を指定するか、管理者ロールのユーザーによって管理される組織を決定する規則を指定し、管理者ロールのユーザーフォームを選択します。

図 6–4 「管理者ロールの作成」: 「制御の範囲」

「管理する組織」。「利用可能な組織」リストから、この管理者ロールが管理する権利を持つ組織を選択します。

「管理する組織の規則」。ユーザーログイン時に評価の対象となる、この管理者ロールが割り当てられたユーザーによって管理される組織に対する規則を選択します。選択する規則は、ControlledOrganizationsRule authType を持つ必要があります。デフォルトで、管理する組織の規則は選択されていません。

EndUserControlledOrganizations 規則を使用して必要なロジックを定義し、組織のニーズに応じて委任に適した一連のユーザーを選択可能にすることができます。

ユーザーが管理者インタフェースとエンドユーザーインタフェースのどちらにログインしていても、管理者に表示されるユーザーリストの範囲が同じになるようにするには、EndUserControlledOrganizations 規則を変更します。

認証中のユーザーが管理者かどうかを最初にチェックするように規則を変更し、それから次のように設定します。

ユーザーが管理者でない場合は、そのユーザー自身の組織など、エンドユーザーによって管理される一連の組織を返します (例: waveset.organization)。

ユーザーが管理者である場合はどの組織も返さず、管理者であるために割り当てられた組織のみをそのユーザーが管理するようにします。

たとえば、次のようにします。

<Rule protectedFromDelete=’true’
      authType=’EndUserControlledOrganizationsRule’
      id=’#ID#End User Controlled Organizations’
      name=’End User Controlled Organizations’>
  <Comments>
    If the user logging in is not an Idm administrator,
    then return the organization that they are a member of.
    Otherwise, return null.
  </Comments>
  <cond>
    <and>
      <isnull><ref>waveset.adminRoles</ref></isnull>
      <isnull><ref>waveset.capabilities</ref></isnull>
      <isnull><ref>waveset.controlledOrganizations</ref></isnull>
    </and>
    <ref>waveset.organization</ref>
  </cond>
  <MemberObjectGroups>
    <ObjectRef type=’ObjectGroup’ id=’#ID#Top’ name=’Top’/>
  </MemberObjectGroups>
</Rule>

動的な組織に所属しているユーザーまたは管理者は、検索結果に返されません。

ただし、動的な組織のユーザーを返すように規則を作成することもできます。次のサンプル規則で、Idm Schema Configuration オブジェクトで定義されている Identity Manager ユーザースキーマ定義に新しい属性を追加し、このオブジェクトをインポートして、Identity Manager サーバーを再起動します。

        <IDMAttributeConfigurations>
            ...
            <IDMAttributeConfiguration name='region'
                                       syntax='STRING'
                                       description='region of the country'/>
        </IDMAttributeConfigurations>

        <IDMObjectClassConfigurations>
            ...
            <IDMObjectClassConfiguration name='User'
                                         extends='Principal'
                                           description='User description'>
                ...
                <IDMObjectClassAttributeConfiguration name='region'
                                                      queryable='true'/>
            </IDMObjectClassConfiguration>
        </IDMObjectClassConfigurations>

Next, import the following Identity Manager objects:

<!-- User member rule that will include all users whose region attribute 
matches the region organization display name -->

<Rule name="Region User Member Rule" authType="UserMembersRule">
  <Description>User Member Rule</Description>
  <list>
    <new class='com.waveset.object.AttributeCondition'>
      <s>region</s>
      <s>equals</s>
      <ref>userMemberRuleOrganizationDisplayName</ref>
    </new>
  </list>
  <MemberObjectGroups>
    <ObjectRef type="ObjectGroup" id="#ID#All" name="All"/>
  </MemberObjectGroups>
</Rule>

<!-- North & South Region organizations with user member rule assigned -->

<ObjectGroup id='#ID#North Region' name='North Region' 
displayName='North Region'> <UserMembersRule cacheTimeout='3600000'>
    <ObjectRef type='Rule' name='Region User Member Rule'/>
  </UserMembersRule>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' name='Top' id='#ID#Top'/>
  </MemberObjectGroups>
</ObjectGroup>

<ObjectGroup id='#ID#South Region' name='South Region' 
displayName='South Region'>  <UserMembersRule cacheTimeout='3600000'>
    <ObjectRef type='Rule' name='Region User Member Rule'/>
  </UserMembersRule>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' name='Top' id='#ID#Top'/>
  </MemberObjectGroups>
</ObjectGroup>

<!-- Organization containing all employees -->

<ObjectGroup id='#ID#Employees' name='Employees' displayName='Employees'>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' name='Top' id='#ID#Top'/>
  </MemberObjectGroups>
</ObjectGroup>

<!-- End user controlled organization rule that give each user control 
of the regional organization they are a member of -->

<Rule protectedFromDelete='true' 
      authType='EndUserControlledOrganizationsRule' 
      id='#ID#End User Controlled Organizations' 
      name='End User Controlled Organizations' 
      primaryObjectClass='Rule'>
  <switch>
    <ref>waveset.attributes.region</ref>
    <case>
      <s>North Region</s>
      <s>North Region</s>
    </case>
    <case>
      <s>South Region</s>
      <s>South Region</s>
    </case>
    <case>
      <s>East Region</s>
      <s>East Region</s>
    </case>
    <case>
      <s>West Region</s>
      <s>West Region</s>
    </case>
  </switch>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' id='#ID#Top' name='Top'/>
  </MemberObjectGroups>
</Rule>

<!-- 4 employees (2 in North and 2 in South region) -->

<User name='emp1' primaryObjectClass='User' asciipassword='1111'>
  <Attribute name='firstname' type='string' value='Employee'/>
  <Attribute name='fullname' type='string' value='Employee One'/>
  <Attribute name='lastname' type='string' value='One'/>
  <Attribute name='region' type='string' value='North Region'/>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' 
     displayName='Employees'/>
  </MemberObjectGroups>
</User>

<User name='emp2' primaryObjectClass='User' asciipassword='1111'>
  <Attribute name='firstname' type='string' value='Employee'/>
  <Attribute name='fullname' type='string' value='Employee Two'/>
  <Attribute name='lastname' type='string' value='Two'/>
  <Attribute name='region' type='string' value='North Region'/>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' 
     displayName='Employees'/>  
  </MemberObjectGroups>
</User>

<User name='emp4' primaryObjectClass='User' asciipassword='1111'>
  <Attribute name='firstname' type='string' value='Employee'/>
  <Attribute name='fullname' type='string' value='Employee Four'/>
  <Attribute name='lastname' type='string' value='Four'/>
  <Attribute name='region' type='string' value='South Region'/>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' 
     displayName='Employees'/>
  </MemberObjectGroups>
</User>

<User name='emp5' primaryObjectClass='User' asciipassword='1111'>
  <Attribute name='firstname' type='string' value='Employee'/>
  <Attribute name='fullname' type='string' value='Employee Five'/>
  <Attribute name='lastname' type='string' value='Five'/>
  <Attribute name='region' type='string' value='South Region'/>
  <MemberObjectGroups>
    <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' 
     displayName='Employees'/>
  </MemberObjectGroups>
</User>

続いて、Identity Manager エンドユーザーインタフェースを使用して、North 地域のユーザー emp1 としてログインします。「委任」、「新規」の順に選択します。検索を変更します。条件として「が次の文字で始まる」を選択し、値を emp に変更して「検索」を選択します。これにより、利用可能なユーザーのリストに emp2 が返されます。

「管理する組織のユーザーフォーム」。この管理者ロールが割り当てられたユーザーが、この管理者ロールの管理する組織のメンバーであるユーザーを作成または編集する場合に使用するユーザーフォームを選択します。デフォルトで、「管理する組織のユーザーフォーム」は選択されていません。

管理者ロールを介して割り当てられたユーザーフォームは、管理者がメンバーになっている組織から継承したすべてのユーザーフォームよりも優先されます。ただし、管理者に直接割り当てられたユーザーフォームよりも優先されることはありません。

管理者ロールへの機能の割り当て

管理者ロールに割り当てられる機能によって、この管理者ロールが割り当てられたユーザーの管理権限が決まります。たとえば、この管理者ロールが管理者ロールの管理する組織のユーザーの作成のみに制限される場合があります。この場合、「ユーザーの作成」機能を割り当てます。

「機能」タブで次のオプションを選択します。

「機能」。これらは、管理者ロールのユーザーが管理する組織に対して持つ特定の機能 (管理権限) です。利用可能な機能のリストから 1 つ以上の機能を選択して、「割り当てられた機能」リストに移動します。
「機能規則」。ユーザーログインの評価時に、管理者ロールが割り当てられたユーザーに与えられる機能のリストを決定する規則を選択します。選択する規則は、CapabilitiesRule authType を持つ必要があります。

管理者ロールへのユーザーフォームの割り当て

管理者ロールのメンバーにユーザーフォームを指定することができます。「管理者ロールの作成」または「管理者ロールの編集」画面の「ユーザーに割り当てる」タブを使用して、割り当てを指定します。

管理者ロールを割り当てられた管理者は、その管理者ロールによって管理されている組織内のユーザーを作成または編集するときにこのユーザーフォームを使用します。管理者ロールを介して割り当てられたユーザーフォームは、管理者がメンバーになっている組織から継承したすべてのユーザーフォームよりも優先されます。このユーザーフォームが、管理者に直接割り当てられたユーザーフォームよりも優先されることはありません。

ユーザーを編集するときに使用されるユーザーフォームは、次の優先順位で決定されます。

ユーザーフォームが管理者に直接割り当てられている場合は、そのユーザーフォームが使用されます。
管理者にはユーザーフォームが直接割り当てられていないが、作成または編集しているユーザーがメンバーとなる組織を制御してユーザーフォームを指定する管理者ロールが割り当てられている場合は、そのユーザーフォームが使用されます。
管理者に直接割り当てられているユーザーフォームがない、または管理者ロールを介して間接的に割り当てられているユーザーフォームがない場合は、管理者のメンバー組織 (管理者のメンバー組織から Top 組織のすぐ下の組織まで) に割り当てられているユーザーフォームが使用されます。
ユーザーフォームが管理者のメンバー組織に割り当てられていない場合は、デフォルトのユーザーフォームが使用されます。

管理者に、同じ組織を管理しながら異なるユーザーフォームを指定している複数の管理者ロールが割り当てられている場合、その組織内のユーザーを作成または編集しようとするとエラーが表示されます。管理者が、同じ組織を管理しながら異なるユーザーフォームを指定している複数の管理者ロールを割り当てようとすると、エラーが表示されます。この相反する状況を解決するまで変更は保存できません。

エンドユーザー組織

エンドユーザー組織は、管理者が、リソースやロールなど特定のオブジェクトをエンドユーザーが使用できるようにする場合に便利です。エンドユーザーはユーザーインタフェースを使用して、指定したオブジェクトを表示したり、状況によっては自分自身に割り当てる (承認プロセスを保留する) ことができます (「Identity Manager エンドユーザーインタフェースへのログイン」を参照)。

注 –

エンドユーザー組織は、Identity Manager Version 7.1.1 で導入されました。

以前は、ロール、リソース、タスク、その他の Identity Manager 設定オブジェクトへのアクセス権をエンドユーザーに付与するために、管理者は設定オブジェクトを編集して、エンドユーザータスク、エンドユーザーリソース、およびエンドユーザー authType を使用する必要がありました。

今後は、「エンドユーザー」組織を使用して、エンドユーザーに Identity Manager 設定オブジェクトへのアクセス権を付与することをお勧めします。

エンドユーザー組織はすべてのユーザーによって暗黙的に管理され、すべてのユーザーが、タスク、規則、ロール、リソースなどいくつかのオブジェクトのタイプを表示できます。ただし、最初は、この組織にメンバーオブジェクトはありません。

エンドユーザー組織は Top 組織のメンバーであり、子組織を持つことはできません。また、エンドユーザー組織は「アカウント」ページの一覧に表示されません。ただし、ロール、管理者ロール、リソース、ポリシー、タスク、その他のオブジェクトを編集する場合は、管理者ユーザーインタフェースを使用して任意のオブジェクトをエンドユーザー組織で使用できるようにすることができます。

エンドユーザーがエンドユーザーインタフェースにログインすると、次の処理が発生します。

エンドユーザーに EndUser 組織 (ObjectGroup) の管理権限が付与されます。
Identity Manager が、組み込みの「エンドユーザーが管理する組織」規則を評価します。これにより、規則によって返される組織名の管理権限が自動的にユーザーに与えられます。この規則は、Identity Manager Version 7.1.1 で追加されました。詳細については、「「エンドユーザーが管理する組織」規則」を参照してください。
エンドユーザーに、EndUser 機能で指定されたオブジェクトタイプに対する権限が付与されます。

「エンドユーザーが管理する組織」規則

「エンドユーザーが管理する組織」規則には、入力引数として認証中のユーザーのビューを指定します。Identity Manager では、この規則から、エンドユーザーインタフェースにログイン中のユーザーが管理する 1 つ以上の組織が返されることを想定しています。返される組織が 1 つの場合は文字列、複数の場合はリストになります。

これらのオブジェクトを管理するには、ユーザーに End User Administrator 機能が必要です。End User Administrator 機能が割り当てられたユーザーは、「エンドユーザーが管理する組織」規則の内容を表示および変更できます。これらのユーザーは、EndUser 機能で指定されたオブジェクトタイプの表示と変更も行えます。

End User Administrator 機能は、デフォルトでは Configurator ユーザーに割り当てられます。リストの変更や「エンドユーザーが管理する組織」規則の評価によって返される組織の変更が、ログイン済みのユーザーに動的に反映されることはありません。変更を確認するには、ログアウトしてもう一度ログインしてください。

「エンドユーザーが管理する組織」規則から、無効な組織 (Identity Manager に存在しない組織など) が返された場合、その問題がシステムログに記録されます。問題に対処するには、管理者ユーザーインタフェースにログインして、規則を修正します。

作業項目の管理

Identity Manager のタスクによって発生する一部のワークフロープロセスでは、アクションアイテムまたは「作業項目」が作成されます。これらの作業項目は、承認のリクエストや Identity Manager アカウントに割り当てられたその他の操作リクエストです。

Identity Manager では、保留中のリクエストを集中的に表示して対応できるように、すべての作業項目をインタフェースの「作業項目」領域にグループ化します。

作業項目のタイプ

作業項目は次のいずれかのタイプである場合があります。

「承認」。新しいアカウントまたはアカウントへの変更の承認リクエスト。
「アテステーション」。ユーザーのエンタイトルメントのレビューおよび承認リクエスト。
「是正」。ユーザーアカウントポリシー違反の是正または受け入れリクエスト。
その他。標準タイプ以外のアクションアイテムリクエスト。これは、カスタマイズされたワークフローから発生した操作リクエストである場合があります。

各作業項目タイプの保留中の作業項目を表示するには、メニューの「作業項目」をクリックします。

注 –

作業項目の所有者が Identity Manager ユーザーインタフェースにログインしたときに、保留中の作業項目 (または委任された作業項目) がある場合は、そのユーザーの作業項目リストが表示されます。

作業項目リクエストの操作

作業項目リクエストに応答するには、インタフェースの「作業項目」の作業項目タイプのうち 1 つをクリックします。リクエストのリストから項目を選択して、使用できるボタンの 1 つをクリックして、実行する操作を示します。作業項目オプションは、作業項目タイプによって異なります。

リクエストへの応答の詳細については、次のトピックを参照してください。

作業項目履歴の表示

「作業項目」領域の「履歴」タブを使用して、以前の作業項目操作の結果を表示できます。

図 6–5 に、作業項目履歴の表示例を示します。

図 6–5 作業項目履歴の表示

作業項目の委任

作業項目の所有者は、作業項目を他のユーザーに一定期間委任して作業負荷を管理できます。メインメニューから「作業項目」を選択し、「自分の作業項目の委任」ページを使用すると、承認リクエストなどの今後発生する作業項目を 1 人以上のユーザー (被委任者) に委任できます。ユーザーを委任先にするために、承認者としての機能は必要ありません。

注 –

委任機能は、将来の作業項目にのみ適用されます。既存の作業項目 (「自分の作業項目」の下に一覧表示される項目) は転送機能で選択的に転送されます。

作業項目は、次のようにほかのページからも委任できます。

管理者インタフェースでは、「ユーザーの作成」および「ユーザーの編集」ページから作業項目を委任できます (「ユーザーページ (作成/編集/表示)」)。「委任」フォームタブをクリックしてください。
エンドユーザーインタフェースで (「Identity Manager エンドユーザーインタフェース」)、「委任」メニュー項目をクリックします。

被委任者は有効な委任期間中、作業項目の所有者の代わりに作業項目を承認できます。委任された作業項目には、委任先の名前が含まれます。

どのユーザーも、自分の将来の作業項目に対する 1 つ以上の委任を作成できます。ユーザーを編集できる管理者も、そのユーザーに代わって委任を作成できます。ただし、ユーザーが委任できない人に、管理者が委任することはできません。委任に関しては、管理者の管理範囲は、委任を代わってもらうユーザーの管理範囲と同じです。

監査ログエントリ

委任された作業項目が承認または拒否されると、監査ログエントリに委任者の名前が記録されます。ユーザーが作成または修正されると、ユーザーの委任承認者情報の変更が監査ログエントリの詳細変更セクションに記録されます。

現在の委任の表示

「現在の委任」ページに委任を表示します。

現在の委任を表示する

管理者インタフェースでメインメニューの「作業項目」をクリックします。

二次的なメニューで「自分の作業項目の委任」をクリックします。

Identity Manager の「現在の委任」ページが表示され、現在の有効な委任を表示および編集できます。

以前の委任の表示

「以前の委任」ページに以前の委任を表示します。

以前の委任を表示する

管理者インタフェースでメインメニューの「作業項目」をクリックします。

二次的なメニューで「自分の作業項目の委任」をクリックします。

「現在の委任」ページが開きます。

「委任履歴 (Previous)」をクリックします。

「以前の委任」ページが開きます。以前に委任された作業項目を利用して、新しい委任を設定できます。

委任の作成

「新しい委任」ページを使用して委任を作成します。

委任を作成する

管理者インタフェースでメインメニューの「作業項目」をクリックします。

「自分の作業項目の委任」をクリックします。

「現在の委任」ページが開きます。

「新規」をクリックします。

「新しい委任」ページが開きます。

次のようにフォームを設定します。
1. 「委任する作業項目タイプの選択」選択リストから作業項目タイプを選択します。すべての作業項目を委任するには、「すべての作業項目タイプ」を選択します。
  
  ロールタイプ、組織、またはリソースの作業項目を委任する場合は、矢印を使って「利用可能」列から「選択」列に項目を移動すると、指定した特定のロール、組織、またはリソースによってこの委任が定義されます。
2. 「作業項目の委任先」。
  
  次のオプションのいずれかを選択します。
  - 「選択されたユーザー」。自分の制御の範囲内で、委任するユーザーを名前で検索して選択します。また、選択した被委任者のいずれかが、この作業項目をさらに別のユーザーに委任した場合、今後リクエストされる作業項目は被委任者の被委任者に委任されることになります。
  - 「選択されたユーザー」領域で 1 人以上のユーザーを選択。もう 1 つの方法として、「検索して追加」をクリックし、検索機能を開いてユーザーを検索します。見つけたユーザーをリストに追加するには、「追加」をクリックします。リストから委任先を削除するには、その委任先を選択し、「削除」をクリックします。
    - 「自分のマネージャー」。作業項目リクエストを自分のマネージャーに委任する場合は、これを選択します (マネージャーが割り当てられている場合)。
    - 「作業項目委任規則」。選択された作業項目タイプを委任できる Identity Manager ユーザー名のリストを返す規則を選択します。
3. 「開始日」。作業項目の委任を開始する日付を選択します。デフォルトでは、選択した日付の午前 12 時 1 分に開始します。
4. 「終了日」。作業項目の委任が終了する日付を選択します。デフォルトでは、選択した日付の午後 11 時 59 分に終了します。
  
  注 –
  開始日と終了日を同じにして、作業項目を 1 日だけ委任することもできます。
5. 「OK」をクリックして選択を保存し、承認待ち作業項目のリストに戻ります。
  
  注 –
  委任を設定したあと、有効な委任期間中に作成されたすべての作業項目は、委任先のリストに追加されます。委任を終了するか委任期間が満了すると、委任された作業項目は委任者のリストに戻ります。そのため、委任者のリストで作業項目が重複する可能性があります。ただし、一方の作業項目を承認または却下すると、重複していた作業項目はリストから自動的に削除されます。

削除されたユーザーへの委任

保留中の作業項目を所有しているユーザーを削除すると、Identity Manager は次の処理を行います。

保留中の作業項目が委任されていて、委任者がまだ削除されていない場合、保留中の作業項目は委任者に返されます。
保留中の作業項目が委任されていない場合、または保留中の作業項目が委任済みであるが、委任者が削除されている場合は、ユーザーの保留中の作業項目が解決されるか別のユーザーに転送されるまで、削除は失敗します。

委任の終了

「現在の委任」ページで 1 つ以上の委任を終了します。

1 つ以上の委任を終了する

管理者インタフェースでメインメニューの「作業項目」をクリックします。

二次的なメニューで「自分の作業項目の委任」をクリックします。

「現在の委任」ページが開きます。

終了する 1 つまたは複数の委任を選択し、「終了」をクリックします。

Identity Manager は選択した委任設定を削除し、選択されているタイプのすべての委任済み作業項目を保留中の作業項目のリストに戻します。

ユーザーアカウントの承認

ユーザーが Identity Manager システムに追加された場合、新しいアカウントに対する承認者として割り当てられている管理者は、アカウント作成を検証する必要があります。

Identity Manager は、3 つの承認カテゴリをサポートします。

「組織」。組織に追加されるユーザーアカウントに承認が必要です。
「ロール」。ロールに割り当てられるユーザーアカウントに承認が必要です。
「リソース」。リソースに対するアクセス権を与えられるユーザーアカウントに承認が必要です。

加えて、変更承認が有効にされている状態でロールが変更された場合、変更承認作業項目が、指定されたロール所有者に送信されます。

Identity Manager は、「ロール定義」による変更承認をサポートします。管理者がロール定義を変更すると、指定されたロール所有者からの変更承認が必要になります。変更を実行するには、ロール所有者が作業項目を承認する必要があります。

注 –

Identity Manager では、デジタル署名された承認を設定できます。手順については、「デジタル署名付き承認およびアクションの設定」を参照してください。
Identity Manager に慣れていない管理者は、「承認」の概念と「アテステーション」の概念を混同しないように注意してください。意味は同じように思えますが、承認とアテステーションでは発生するコンテキストが異なります。

承認は、新しいユーザーアカウントの検証に関連があります。ユーザーが Identity Manager に追加されると、その新しいアカウントの認可を検証するために、1 つ以上の承認が必要になります。

アテステーションは、既存のユーザーが適切なリソースに対する適切な特権のみを持っていることの検証に関連があります。定期的アクセスレビュープロセスの一環として、Identity Manager ユーザー (アテスター) が、別のユーザーのアカウントの詳細 (つまり、そのユーザーの割り当て済みリソース) が有効かつ適切であることを保証するように求められる場合があります。このプロセスをアテステーションといいます。

アカウント承認者の設定

組織、ロール、およびリソースを承認するアカウント承認者の設定は省略可能ですが、推奨されています。アカウントの作成では、承認者を設定するカテゴリごとに、少なくとも 1 つの承認が必要です。1 人の承認者がリクエストの承認を拒否した場合、アカウントは作成されません。

各カテゴリに複数の承認者を割り当てることができます。1 つのカテゴリ内で必要な承認は 1 つのみであるため、複数の承認者を設定して、ワークフローが遅延または停止していないかどうかを確認できます。1 人の承認者が利用不可能な場合は、ほかの承認者を利用してリクエストを処理できます。承認は、アカウント作成にのみ適用されます。デフォルトでは、アカウントの更新と削除に承認は必要ありません。承認を必要とするように、このプロセスをカスタマイズすることもできます。

Identity Manager IDE を使用すると、承認の流れを変更したり、アカウントの削除や更新を取得して、ワークフローをカスタマイズすることができます。

Identity Manager IDE の詳細については、https://identitymanager.dev.java.net を参照してください。作業項目の詳細と、承認ワークフローの変更例については、『Sun Identity Manager Deployment Reference』の第 1 章「Workflow」を参照してください。

Identity Manager 承認者は、承認リクエストを承認または拒否できます。

管理者は、Identity Manager インタフェースの「作業項目」領域で、保留中の承認を表示および管理することができます。保留中の承認を表示するには、「作業項目」ページで「自分の作業項目」をクリックします。承認を管理するには、「承認」タブをクリックします。

承認の署名

デジタル署名を使用して作業項目を承認する場合は、「デジタル署名付き承認およびアクションの設定」の説明に従って、まずデジタル署名を設定する必要があります。

承認を署名する

Identity Manager 管理者インタフェースで、「作業項目」を選択します。

「承認」タブをクリックします。

リストから承認を 1 つまたは複数選択します。

承認のコメントを入力して、「承認」をクリックします。

Identity Manager からアプレットを信頼するかどうか尋ねられます。

「常時」をクリックします。

承認の概要が日付付きで表示されます。

キーストアの場所を入力するか、「参照」をクリックして指定します。この場所は、署名付き承認の設定 (「PKCS12 を使用した署名付き承認のサーバー側設定を有効にする」の手順 10m) で設定します。

キーストアのパスワードを入力します。このパスワードは、署名付き承認の設定 (「PKCS12 を使用した署名付き承認のサーバー側設定を有効にする」の手順 10l) で設定します。

「署名」をクリックしてリクエストを承認します。

その後の承認の署名

承認に署名すると、それ以後の承認アクションでは、キーストアパスワードを入力して「署名」をクリックするだけで済みます。Identity Manager は、前回の承認で使用したキーストアの場所を記憶します。

デジタル署名付き承認およびアクションの設定

次の情報と手順を使用して、デジタル署名を設定します。次のものにデジタル署名できます。

承認 (変更承認を含む)
アクセスレビューアクション
コンプライアンス違反の是正

この節では、& Product_IDMgr; に署名付き承認の証明書と CRL を追加するために必要な、サーバー側とクライアント側の設定について説明します。

署名付き承認に関するサーバー側の設定を有効にする

システム設定オブジェクトを開いて、security.nonrepudiation.signedApprovals=true と設定します。

システム設定オブジェクトを編集する方法については、「Identity Manager 設定オブジェクトの編集」を参照してください。

PKCS11 を使用している場合は、security.nonrepudiation.defaultKeystoreType=PKCS11 も設定する必要があります。

カスタム PKCS11 キープロバイダを使用している場合は、さらに security.nonrepudiation.defaultPKCS11KeyProvider=<プロバイダ名> も設定する必要があります。

注 –
カスタムプロバイダを記述する必要がある状況の詳細については、REF キットの次の項目を参照してください。
com.sun.idm.ui.web.applet.transactionsigner.DefaultPKCS11KeyProvider (Javadoc) REF/transactionsigner/SamplePKCS11KeyProvider
REF (Resource Extension Facility) キットは、製品の CD の /REF ディレクトリまたはインストールイメージにあります。

自分の認証局 (CA) の証明書を信頼できる証明書として追加します。そのためには、まず証明書のコピーを取得する必要があります。

たとえば、Microsoft CA を使用している場合には、行う手順は次のようになります。
1. http://IPAddress/certsrv にアクセスして、管理特権でログインします。
2. 「CA 証明書または証明書失効リストの取得」を選択して、「次へ」をクリックします。
3. CA 証明書をダウンロードして保存します。

この証明書を Identity Manager に信頼できる証明書として追加します。
1. 管理者インタフェースで、「セキュリティー」を選択し、「証明書」を選択します。「証明書」ページが表示されます。
  
  図 6–6 「証明書」ページ
2. 「信頼できる認証局証明書」領域で、「追加」をクリックします。「証明書のインポート」ページが表示されます。
3. 信頼できる証明書を参照および選択して、「インポート」をクリックします。
  
  選択した証明書が、信頼できる証明書のリストに表示されます。

次の手順で、CA の証明書失効リスト (CRL) を追加します。
1. 「証明書」ページの「CRL」領域で、「追加」をクリックします。
2. CA の CRL の URL を入力します。
  
  注 –
  - 証明書失効リスト (CRL) は、失効したか有効ではない証明書シリアル番号のリストです。
  - CA の CRL の URL は http または LDAP にすることができます。
  - CRL 配布先の URL は CA ごとに異なりますが、CA 証明書の「CRL 配布点」拡張を参照して決めることができます。

「テスト接続」をクリックして、URL を確認します。

「保存」をクリックします。

jarsigner を使用して applets/ts2.jar に署名します。

注 –
詳細については、http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/jarsigner.html を参照してください。Identity Manager とともに提供されている ts2.jar ファイルは、自己署名付き証明書を使用して署名されているため、本稼働システムには使用しないでください。本稼働では、信頼できる CA によって発行されたコード署名証明書を使用して、このファイルを署名し直すことをお勧めします。

PKCS12 を使用した署名付き承認のサーバー側設定を有効にする

PKCS12 を使用した署名付き承認のための設定情報は、次のとおりです。証明書と非公開鍵を取得して、PKCS#12 キーストアにエクスポートします。たとえば、Microsoft CA を使用している場合には、行う手順は次のようになります。

始める前に

Identity Manager では、JRE 1.5 以上が必要になりました。

Internet Explorer を使用して、http://IPAddress /certsrv を参照し、管理特権でログインします。

証明書のリクエストを選択して、「次へ」をクリックします。

リクエストの詳細設定を選択して、「次へ」をクリックします。

「次へ」をクリックします。

「証明書テンプレート」で「ユーザー」を選択します。

次のオプションを選択します。
1. エクスポート可能なキーとして指定する
2. 秘密キーの強力な保護を有効にする
3. ローカルコンピュータストアを使用する

「送信」をクリックして、「OK」をクリックします。

「この証明書のインストール」をクリックします。

「ファイル名を指定して実行」を選択し、mmc と入力して mmc を起動します。

証明書スナップインを追加します。
1. 「コンソール」、「スナップインの追加と削除」の順に選択します。
2. 「追加」をクリックします。
3. 「コンピュータアカウント」を選択します。
4. 「次へ」をクリックして、「完了」をクリックします。
5. 「閉じる」をクリックします。
6. 「OK」をクリックします。
7. 「証明書」、「個人」、「証明書」の順に選択します。
8. 「管理者」を右クリックして、「すべてのタスク」、「エクスポート」の順に選択します。
9. 「次へ」をクリックします。
10. 「次へ」をクリックして、非公開鍵がエクスポートされていることを確認します。
11. 「次へ」をクリックします。
12. パスワードを設定して、「次へ」をクリックします。
13. 証明書の場所を指定します。
14. 「次へ」をクリックして、「完了」をクリックします。「OK」をクリックして確認します。
  
  注 –
  クライアント側の設定の手順 10l (パスワード) と 10m (証明書の場所) で使用した情報をメモしておいてください。この情報は、承認の署名のために必要です。

PKCS11 を使用した署名付き承認のクライアント側設定を有効にする

署名付き承認に PCCS11 を使用している場合は、次の操作を行います。

REF キットにある次のリソースを参照して、設定情報を確認します。
com.sun.idm.ui.web.applet.transactionsigner.DefaultPKCS11KeyProvider (Javadoc) REF/transactionsigner/SamplePKCS11KeyProvider
REF (Resource Extension Facility) キットは、製品の CD の /REF ディレクトリまたはインストールイメージにあります。

トランザクション署名の表示

この節では、Identity Manager 監査ログレポートで、トランザクション署名を表示する方法について説明します。

トランザクション署名を表示する

Identity Manager 管理者インタフェースで、「レポート」を選択します。

「レポートの実行」ページで、オプションの「新規...」リストから「監査ログレポート」を選択します。

「レポートタイトル」フィールドに、タイトルを入力します (「承認」など)。

「組織」選択領域で、すべての組織を選択します。

「アクション」オプションを選択して、「承認」を選択します。

「保存」をクリックしてレポートを保存し、「レポートの実行」ページに戻ります。

「実行」をクリックして、「承認」レポートを実行します。

詳細リンクをクリックして、トランザクション署名情報を表示します。

表示されるトランザクション署名情報は、次のとおりです。
- 発行者
- 主体
- 証明書シリアル番号
- 署名されたメッセージ
- 署名
- 署名アルゴリズム

XMLDSIG 形式の署名付き承認の設定

Identity Manager では、RFC 3161 準拠のデジタルタイムスタンプを含む XMLDSIG 形式の署名付き承認を、Identity Manager 承認プロセスに追加できます。XMLDSIG 署名付き承認を使用するように Identity Manager を設定する場合、監査ログで承認を確認しないかぎり、承認者が認識できる変更はありません。監査ログレコードに格納される署名付き承認の形式だけが変更されます。

これまでの Identity Manager の署名付き承認と同様、クライアントマシンでアプレットが起動され、承認者に対して署名のための承認情報が表示されます。承認者は承認の署名に使用するキーストアとキーを選択します。

承認者が承認に署名すると、承認データを含む XMLDSIG ドキュメントが作成されます。このドキュメントは、XMLDSIG 署名付きドキュメントを検証するサーバーに返されます。処理が成功し、RFC 3161 デジタルタイムスタンプが設定されている場合は、このドキュメントに対してデジタルタイムスタンプも生成されます。タイムスタンプ証明局 (TSA) から取得したタイムスタンプのエラーがチェックされ、証明書の有効性が確認されます。問題がなければ、最後に Identity Manager は監査ログレコードを生成し、XMLDSIG 形式の署名付き証明書オブジェクトを XML のブロブ列に格納します。

承認データの形式

XMLDSIG 形式の証明書オブジェクトは、次のような形式になります。

<XMLSignedData signedContent="...base64 transaction text ...">
   <XMLSignature>
      <TSATimestamp>
         ...The base64 encoded PKCS7 timestamp token returned by the TSA...
      </TSATimestamp
      <Signature>
        <SignedInfo>...XMLDSIG stuff...</SignedInfo>
        <SignatureValue>...base64 signature value</SignatureValue>
        <KeyInfo>...cert info for signer</KeyInfo>
      </Signature>
   </XMLSignature>
</XMLSignedData>

次の点に注意してください。

base64 承認データは、アプレットで承認者に表示される実際の承認データテキストで構成され、base64 形式でエンコードされます。
<TSATimestamp> 要素には、base64 でエンコードされた、タイムスタンプ証明局 (TSA) からの PKCS7 タイムスタンプ応答が含まれます。
<Signature> 全体で、XMLDSIG 署名データを構成します。

この XMLDSIG ドキュメントは、監査ログ承認レコードの XML 列に格納されます。

インストールと設定

XMLDSIG 署名付き承認を使用するためのインストールと設定の要件は、「署名付き承認に関するサーバー側の設定を有効にする」で説明した要件と同じです。ただし、追加の手順が 1 つだけあります。ts2.jar ファイルへの署名に加えて、xmlsec-1.4.2.jar ファイルにも署名が必要です。

承認の設定

システム設定属性を使用して、次の操作を実行できます。

SignedData 形式または XMLSignedData 形式を選択できます。一度に設定できるのはどちらか一方の形式だけです。管理者は必要に応じて、この設定を変更できます。
設定された RFC 3161 タイムスタンプ証明局 (TSA) から取得した、デジタルタイムスタンプを含めることができます。
このタイムスタンプを取得する URL を、HTTP のみで指定できます。

これらの属性を編集するには、Identity Manager デバッグページを使用して、システム設定オブジェクトを編集します。これらの設定はすべて、ほかの署名付き承認属性と一緒に security.nonrepudiation 以下で指定します。

XMLDSIG 属性には次のものがあります。

security.nonrepudiation.useXmlDigitalSignatures は、XMLDSIG 署名を有効にするブール型の値です。
security.nonrepudiation.timestampXmlDigitalSignatures は、XMLDSIG 署名に RFC 3161 デジタルタイムスタンプを含めるブール型の値です。
security.nonrepudiation.timestampServerURL は、タイムスタンプを取得する HTTP ベースの TSA の URL を指定する文字列値です。

注 –

これらの属性を有効にするには、既存の useSignedApprovals 属性を true に設定する必要があります。
Identity Manager は、一般的なプロビジョニングリクエストで、1 つの承認または複数の署名付き承認に対して複数の署名をサポートしません。

第 6 章 管理

Identity Manager の管理について

委任された管理

管理者の作成と管理

管理者を作成する

管理者ビューのフィルタ

管理者パスワードの変更

管理者のアクションの認証

タブ付きユーザーフォームでパスワード認証の要求を有効にする

「Change User Password」および「Reset User Password」フォームでパスワード認証を有効にする

秘密の質問の回答の変更

管理者インタフェースでの管理者名の表示のカスタマイズ

Identity Manager の組織について

組織の作成

組織を作成する

図 6–1 「組織の作成」ページ

組織へのユーザーの割り当て

例 6–1 ユーザーメンバー規則の例

管理する組織の割り当て

ディレクトリジャンクションおよび仮想組織について

図 6–2 Identity Manager 仮想組織

ディレクトリジャンクションの設定

ディレクトリジャンクションを設定する

仮想組織の更新

仮想組織の削除

機能とその管理について

機能のカテゴリ

機能の操作

「機能」ページの表示

「機能」ページを開く

機能の作成

機能を作成する

機能の編集

保護されていない機能を編集する

機能の保存と名前の変更

機能を複製する

ユーザーへの機能の割り当て

管理者ロールとその管理について

管理者ロールの規則

ユーザー管理者ロール

管理者ロールの作成および編集

図 6–3 「管理者ロールの作成」ページ: 「一般」タブ

「一般」タブ

制御の範囲

図 6–4 「管理者ロールの作成」: 「制御の範囲」

管理者ロールへの機能の割り当て

管理者ロールへのユーザーフォームの割り当て

エンドユーザー組織

「エンドユーザーが管理する組織」規則

作業項目の管理

作業項目のタイプ

作業項目リクエストの操作

作業項目履歴の表示

図 6–5 作業項目履歴の表示

作業項目の委任

監査ログエントリ

現在の委任の表示

現在の委任を表示する

以前の委任の表示

以前の委任を表示する

委任の作成

委任を作成する

削除されたユーザーへの委任

委任の終了

1 つ以上の委任を終了する

ユーザーアカウントの承認

アカウント承認者の設定

承認の署名

承認を署名する

その後の承認の署名

デジタル署名付き承認およびアクションの設定

署名付き承認に関するサーバー側の設定を有効にする

図 6–6 「証明書」ページ

PKCS12 を使用した署名付き承認のサーバー側設定を有効にする

始める前に

PKCS11 を使用した署名付き承認のクライアント側設定を有効にする

トランザクション署名の表示

トランザクション署名を表示する

XMLDSIG 形式の署名付き承認の設定

承認データの形式

第 6 章管理