4.1 プロビジョニング要求定義エディタについて
プロビジョニング要求定義エディタを使用することにより、豊富なEclipseベースの設計ツールを使用してカスタムプロビジョニング要求定義を作成できます。プロビジョニング要求定義エディタでは、プロビジョニング要求の基本特性の定義、関連するワークフローの定義、初期要求フォームと承認フォームのモデル作成を行えます。
Identity Managerには、定義の作成に使用できるプロビジョニング要求テンプレートのセットが用意されています。テンプレートはいくつかの一般的なワークフロー設計パターンのモデルとしています。しかし、ワークフローの動作をすべて制御できるようにするために、プロビジョニング要求定義を独自に作成することもできます。
メモ:テンプレート使用の詳細については、「セクション 4.4, インストールされているテンプレートでの作業」を参照してください。
4.1.1 プロビジョニング要求定義エディタをIdentity Managerアーキテクチャに適合させる方法
ワークフローベースのプロビジョニングで、Identity Managerの主要な機能で、組織のセキュアリソースへのユーザアクセスを管理するプロセスです。このようなリソースには、ユーザアカウント、コンピュータ、データベースなどのデジタルエンティティが含まれます。プロビジョニングされたリソースはIdentity Managerエンタイトルメントまたはディレクトリ抽象化レイヤのエンティティにマップされます。
Identity Managerは広い範囲のプロビジョニング要求に対応しています。プロビジョニング要求は、組織リソースへのアクセスの許可または取り消しのための、ユーザまたはシステムのアクションです。プロビジョニング要求は、Identity Managerユーザアプリケーションからエンドユーザが直接開始することもできますし、識別ボールト（eDirectory™）で発生するイベントに対応して間接的に開始することもできます。
プロビジョニング要求に対して、組織内の1人以上の個人による承認が必要な場合、ワークフローが開始されます。このワークフローでは、要求の処理に必要な承認が調整されます。1人の個人からの承認を必要とするプロビジョニング要求もあれば、複数の個人からの承認を必要とするプロビジョニング要求もあります。場合によっては、承認なしに実行できる要求もあります。
承認手順が順次実行される連続方式の処理を必要とするワークフローもあれば、並行処理をサポートするワークフローもあります。プロビジョニング要求を定義する場合、ワークフローが、連続処理または並行処理のどちらをサポートするかを指定します。
プロビジョニング要求を設定するには、リソースをワークフローにバインドするプロビジョニング要求定義を作成します。Identity Managerにはプロビジョニング要求定義エディタが用意されていて、プロビジョニング要求とそれに関連付けられているワークフローのすべての動作を制御できます。Identity ManagerにはiManagerプラグインのセットも含まれています。このプラグインを使用してすでに展開されているプロビジョニング要求定義をカスタマイズすることもできます。iManagerツールを使用して、プロビジョニング要求定義の動作に小さな変更を加えたり、処理中のワークフローを管理したりできます。
次の図は、プロビジョニング要求定義エディタがIdentity Managerによって組み込まれたワークフローベースのプロビジョニングシステムにどのように適合するかを示しています。
図 4-1 プロビジョニング要求定義エディタとワークフローアーキテクチャ
4.1.2 プロビジョニングおよびワークフローの例
ITシステムのアカウントを必要とするユーザがいると想定します。アカウントを設定するには、ユーザは、Identity Managerユーザアプリケーションを使用して要求を開始します。この要求によりワークフローが開始され、ワークフローは承認プロセスを調整します。必要な承認が付与されると、要求が実行されます。このプロセスは4つの基本的なステップからなっています。
ステップ1: 要求の開始
Identity Managerユーザアプリケーションで、ユーザはリソースリストをカテゴリで参照し、プロビジョニングを行うリソースを1つ選択します。識別ボールトで、選択したプロビジョニング対象リソースがプロビジョニング要求定義に関連付けられます。プロビジョニング要求定義は、プロビジョニングシステムで最も重要なオブジェクトです。プロビジョニング要求定義は、プロビジョニング対象リソースをワークフローにバインドし、ワークフロープロセスをエンドユーザに明らかにする手段としての役割を果たします。プロビジョニング要求定義は、初期要求形式を表示したり、初期要求に続くフロー開始したりするために必要なすべての情報を提供します。
この例では、ユーザは新規アカウントリソースを選択します。ユーザが要求を開始すると、Webアプリケーションは、プロビジョニングシステムから関連する初期要求データの初期要求形式およびdescription属性を取得します。すると、プロビジョニング要求定義からこれらのオブジェクトを取得します。
プロビジョニング要求が開始されると、プロビジョニングシステムによってイニシエータと受信者が追跡されます。 イニシエータとは、要求を作成した人物です。受信者とは、作成された要求の宛先の人物です。場合によっては、イニシエータおよび受信者が同一人物ということもあります。
各プロビジョニング要求には、それぞれに関連付けられた操作があります。ユーザがリソースを許可するか取り消しするかは、操作により指定されます。
ステップ2: 要求の承認
ユーザが要求を開始すると、プロビジョニングシステムはワークフロープロセスを開始します。ワークフロープロセスは、承認を調整します。この例では、2つのレベルの承認が必要です。1つはユーザのマネージャからの承認で、もう1つはマネージャのスーパバイザからの承認です。承認がワークフロー内のユーザに拒否された場合、フローは終了し、要求は拒否されます。
ワークフローは承認を順次に、または並行に処理できます。順次ワークフローでは、次の図に示されているように、1つの承認タスクを処理してから、次の承認タスクを開始する必要があります。
図 4-2 2つの承認の順次ワークフロー
並行ワークフローでは、次の図に示されているように、ユーザが複数の承認タスクを同時に処理できます。
図 4-3 2つの承認の並行ワークフロー
メモ:表示ラベル（1次承認、2次承認など）はアプリケーション要件に合わせて簡単に変更できます。並行フローの場合、順次処理を意味しないラベルを指定する必要があります。たとえば、One of Three Parallel Approvals、Two of Three Parallel Approvalsなどのラベルを割り当てる場合です。
ワークフロー定義は、次の表に示されているコンポーネントで構成されています。
表 4-1 ワークフロー定義コンポーネント
開始アクティビティ: ワークフロープロセスは、開始アクティビティの実行により開始されます。アクティビティはユーザに対して初期要求フォームを表示します。ユーザが初期要求データを指定すると、アクティビティはこのデータを使用して作業ドキュメントを初期化します。開始アクティビティはイニシエータ、受信者などの複数のシステム値をバインドし、これらの値をスクリプト式で使用できるようにします。
承認アクティビティ: 開始アクティビティの実行が終了すると、ワークフローシステムはフロー内の1次承認アクティビティの処理に進みます。承認アクティビティは承認者に電子メールを送信し、注意を向ける必要があることを通知します。ユーザがタスクを要求すると、承認アクティビティは承認フォームを表示し、このフォームを使用してユーザは要求を実行できます。ステップ2: 要求の承認に示したワークフローの例では、［1次承認］および［2次承認］が承認アクティビティの例になります。承認アクティビティの表示ラベルは、使用する国の要件を満たすためにローカライズできます。
承認アクティビティの結果には5種類あり、それぞれはアクティビティからの異なるフローパスで示されています。
-
Approved
-
Denied
-
Refused
-
エラー
-
タイムアウト
メモ:「エラー」と「タイムアウト」の結果は、ユーザがどのアクションも実行しなかった場合にも発生します。
ユーザが要求を承認すると、ワークフローは承認済みフローパスをたどってフロー内の次のアクティビティに進みます。これ以上承認が必要ない場合は、リソースがプロビジョニングされます。ユーザが要求を拒否すると、ワークフローは拒否されたフローパスをたどってフロー内の次のアクティビティに進みます。または、（ユーザが組織マネージャまたはユーザアプリケーション管理者である場合は）ユーザがタスクを再割り当てすることもできます。すると、ワーク項目は別のユーザのキューに送られます。
承認アクティビティが割り当てられる人を「宛先」と呼びます。アクティビティの宛先に、割り当てられたタスクを電子メールで通知することもできます。アクティビティに関連付けられた作業を実行する場合、宛先は電子メールにあるURLをクリックし、ワークリスト（キュー）にあるタスクを見つけ、タスクを要求します。
宛先ユーザは指定時間内に承認アクティビティに応答する必要があります。応答しないとアクティビティでタイムアウトが発生します。通常、タイムアウト間隔は、ユーザが応答できるだけの十分な時間を時間単位または日単位で指定します。
アクティビティのタイムアウトが発生した場合、そのアクティビティに指定された再試行回数により、ワークフロープロセスはアクティビティを再試行します。場合によっては、ワークフロープロセスは、タイムアウトの発生したアクティビティをエスカレートするように設定されます。この場合、このアクティビティは新しい宛先（たとえばユーザのマネージャ）に再割り当てされ、新しい宛先ユーザがこのアクティビティの作業を完了できるようにします。最後の再試行でタイムアウトが発生した場合、ワークフローの設定内容に従い、そのアクティビティは承認済みまたは却下済みとしてマークされます。
ログアクティビティ: ログアクティビティはログにメッセージを書き込むシステムアクティビティです。ワークフロープロセスの状態に関する情報をログとして記録するとき、ワークフローシステムはNovell® Auditとのやり取りを行います。ワークフローは、その処理中、発生したさまざまなイベントについての情報を記録します。ログデータは、Novell Auditレポーティングツールを使用して確認できます。
ブランチアクティビティとマージアクティビティ: 並行処理をサポートするワークフローでは、ブランチアクティビティにより、2人のユーザが1つの作業項目の異なる領域を同時に作業できます。ユーザが作業を完了すると、マージアクティビティにより、フローに合流するブランチが同期化されます。
条件アクティビティ: ワークフロープロセスの実行中、次の作業を決定するために、結果のテストとチェックが実行されます。条件アクティビティがこの機能を提供しています。条件アクティビティは、スクリプト式を使用して評価する条件を定義します。ステップ2: 要求の承認に示したワークフローの例では、［承認条件］が条件アクティビティの例です。
条件アクティビティは、3種類の取りうる結果または終了パスをサポートします。
-
True
-
False
-
エラー
ステップ3: 要求の実行
プロビジョニング要求が承認されると、ワークフローシステムはプロビジョニングのステップを開始できます。この時点で、制御はプロビジョニングシステムに戻ります。
プロビジョニング要求を実行するにあたり、プロビジョニングシステムは、Identity Managerエンタイトルメントを実行することも、eDirectoryオブジェクトおよびその属性を直接操作することもできます。これらのアクションはエンタイトルメントアクティビティまたはエンティティアクティビティのどちらかによって実行されます。
エンタイトルメントアクティビティ: エンタイトルメントアクティビティは、エンタイトルメントの許可または取り消しによってプロビジョニング要求を実行します。通常必要な承認すべてが与えられない限り、エンタイトルメントアクティビティは実行されません。
エンティティアクティビティ: エンティティアクティビティは、eDirectoryオブジェクトおよびその属性を直接操作することにより、プロビジョニング要求を実行します。通常必要な承認すべてが与えられない限り、エンティティアクティビティは実行されません。
ステップ4: ワークフローの完了
他のすべてのアクティビティが終了すると、ワークフローは完了アクティビティを実行します。
完了アクティビティ: 完了アクティビティは、ワークフローの最後のアクティビティです。フロー内のすべてのアクティビティが完了し、フローの最終結果が有効な場合、完了アクティビティが実行できます。完了アクティビティは最後の電子メール通知を送信して、ワークフローの完了を参加者に知らせます。