| Oracle® Fusion Middleware Oracle Identity Managerユーザーズ・ガイド 11g リリース1 (11.1.1) B66706-01 |
|
 前 |
 次 |
アクセス・ポリシーとは、ロールと、ロールに対してプロビジョニングまたはプロビジョニング解除されるリソースのリストです。アクセス・ポリシーは、ユーザーへのターゲット・システムのプロビジョニングを自動化するために使用されます。これについて、次の例を使用して説明します。
あるユーザーがOracle Identity Managerで作成された複数のロールに属しています。ロールRole1には、メンバーシップ・ルールが割り当てられているとします。メンバーシップ・ルールは、"Organization Name = "Org1"など、ユーザーが属している組織に基づいて設計できます。ロールにはアクセス・ポリシーを割り当てることができます。アクセス・ポリシーでは、アクセス・ポリシーの適用時に、ロールに対してプロビジョニングまたは拒否(あるいはその両方)されるリソースが示されます。この結果、ユーザーがOrg1組織に作成された場合は、メンバーシップ・ルールが満たされ、Role1ロールがユーザーに付与されます。次に、ロールに割り当てられているアクセス・ポリシーがトリガーされ、アクセス・ポリシーに記述されているリソースがプロビジョニングまたは拒否されます。
この章では、Oracle Identity Managerでユーザーおよびリソースに対してアクセス・ポリシーを作成、使用する方法について説明します。この章には次の項目があります。
次に、アクセス・ポリシーに関連する用語を示します。
リソース
リソースは、Oracle Identity Managerのユーザーまたは組織にプロビジョニングできる、Oracle Identity Managerの論理エンティティです。たとえば、Microsoft Active Directory (AD)、Microsoft Exchange、SAP、UNIXおよびデータベースは、Oracle Identity Managerのリソースとしてモデル化されます。
リソースは、テンプレート化された定義であり、Oracle Identity Managerでプロビジョニング・プロセスと呼ばれる1つ以上のワークフローに関連付けられ、このワークフローによって、プロビジョニング、失効、有効化、無効化方法などのライフサイクル管理がモデル化されます。
リソースには、フォームと呼ばれるエンティティも関連付けられます。フォームは、リソースに関連付けられる属性の集合を表します。たとえば、ADサーバーに関連付けられるフォームには、「SAMアカウント名」、「共通名」および「ユーザー・プリンシパル名」などの属性が含まれています。フォームには、タイプ「ITリソース」の属性も含まれています(詳細は「ITリソース・タイプ」を参照)。
リソースには「複数を許可」のマークを付けることができ、この場合、ユーザーまたは組織にリソースの複数インスタンスがプロビジョニングされます。
アカウント
アカウントは、Oracle Identity Managerで作成され、ユーザーまたは組織にプロビジョニングされるリソースの実際のインスタンスです。たとえば、Exchangeサーバー上の電子メール・アカウントは、リソース・タイプExchangeのアカウント(インスタンス)です。
アカウントには、関連フォームの属性に対して特定の値があります。
ITリソース・タイプ
ITリソース・タイプは、物理ターゲットとそのすべての属性のモデル化に使用されるOracle Identity Managerの論理エンティティであり、属性には、物理コンピュータへの接続に必要な接続情報や資格証明などがあります。たとえば、ITリソース・タイプ「ADサーバー」は、実際のADサーバーをモデル化するために使用されます。
ITリソース・インスタンス
これらは、実際の物理ターゲットを表す、特定のITリソース・タイプの実際のインスタンスです。これらには、IPアドレス、ポート、ユーザー名、パスワードなど、物理ターゲットのすべての属性に対する特定の値もあります。デプロイメント内の2つの物理ADサーバーは、ITリソース・タイプ「ADサーバー」の2つのインスタンスで表されます。
アカウント識別子
アカウント識別子は、アカウントが作成される論理エンティティを一意に識別する、フォーム上の属性の集合です。この用語は、大まかにターゲットと呼ばれる場合があります。たとえば、ADサーバーの場合、アカウント識別子は、「ADサーバー」(タイプ「ITリソース」の属性)と「組織名」の組合せにできます。
通常、アカウント識別子は、タイプ「ITリソース」の属性です。
属性にアカウント識別子のマークを付けるには、「フォーム」フィールドのアカウント識別子プロパティを「True」に設定します。
ここでは、ポリシー・エンジンによって提供される様々な機能について次の各項で説明します。
アクセス・ポリシーが適用されるたびに、次のいずれかの方法でリソースのプロビジョニングが発生します。
リソースは、リクエストが生成されることなく、ユーザーに直接プロビジョニングされます。
リクエストが作成され、リソースのプロビジョニングはリクエスト承認を必要とします。
管理およびユーザー・コンソールを使用して、アクセス・ポリシーをリクエスト承認ありで作成するか、リクエスト承認なしで作成するかを指定できます。
リクエストを使用するアクセス・ポリシーの場合
アクセス・ポリシーのデフォルト・プロセス・フォームがサポートされています。つまり、アクセス・ポリシーの作成時にデフォルト・プロセス・フォームに入力されたデータが、リクエスト・データセットの移入に使用されます。
リクエスト・データセットの必須フィールドは、次のいずれかで移入する必要があります。
アクセス・ポリシー定義時のアクセス・ポリシーのプロセス・フォーム・デフォルト: これは、対応するリクエスト・データセットの移入にプロセス・フォームのアクセス・ポリシー・デフォルトが使用されるためです。
リクエスト・データセットに対して定義された事前移入アダプタ。
リクエスト・データセットのデフォルト・データ。
アクセス・ポリシー・ベースのリクエストは、リクエスト・データベースのすべての必須フィールドが、プロセス・フォームのデフォルト、事前移入アダプタまたはリクエスト・データセットのデフォルト・データのいずれかによって移入されない場合は、作成されません。
特定のリソースに対してあるユーザーのリクエストがすでに作成されていて、次のいずれかのステータスではない場合、同じユーザーとリソースの組合せに対する新しいリクエストは作成されません。
リクエストがクローズされました
リクエストが完了しました
リクエストが取り消されました
リクエストに失敗しました
テンプレート承認が却下されました
リクエスト承認が却下されました
操作承認が却下されました
Oracle Identity Managerのアクセス・ポリシーは、サブロールには適用されません。ポリシーは、そのアクセス・ポリシーに定義されているロールの直下のメンバーシップ・ユーザー(サブロールのメンバーではないユーザー)にのみ適用されます。ポリシーが適用されなくなった場合に、そのポリシー内のリソースを失効させるかどうかを指定できます。失効させる場合、ユーザーにポリシーが適用されなくなると、これらのリソースは、Oracle Identity Managerによりそのユーザーに対して自動的に失効されます。
アクセス・ポリシーの作成中には、ロールに対してプロビジョニングするリソースに加え、拒否するリソースを選択できます。プロビジョニングするリソースとして一旦選択したリソースを、後で拒否するリソースとして選択すると、そのリソースはOracle Identity Managerによりプロビジョニングするリソースのリストから削除されます。1つのロールに2つのポリシーが定義されており、一方のポリシーではプロビジョニングするように指定されているリソースが、もう一方のポリシーでは拒否するように指定されている場合、2つのポリシーの優先度に関係なく、Oracle Identity Managerではそのリソースはプロビジョニングされません。
Oracle Identity Managerでは、次のようなシナリオでアクセス・ポリシーを評価できます。
ユーザーがロールに追加、またはロールから削除された場合
そのユーザーに対するポリシーは、追加または削除の操作の一部として評価されます。
ポリシーに更新フラグが設定されている場合
これらの評価は、アクションの直後には行われません。かわりに、ユーザー・ポリシーの評価スケジュール・タスクの次回実行時に行われます。評価は次のようなシナリオで行われます。
更新フラグがONに設定されるように、ポリシーの定義が更新された場合。ポリシーの評価は、該当するすべてのユーザーに対して行われます。
ロールがポリシーの定義に追加、またはポリシーの定義から削除された場合。ポリシーの評価は、追加または削除されたロールに対してのみ行われます。
リソースが追加または削除された場合、あるいはそのリソースに対する「適用しない場合は失効」フラグの値が変更された場合。
以前のリリースのOracle Identity Managerでは、アクセス・ポリシーで「適用しない場合は失効」オプションが選択されていて、そのポリシーが適用されなくなった場合は、アクセス・ポリシーに関連付けられているアカウントと権限(子レコード)の両方が失効します。ただし、フラグが選択されていない場合にポリシーが適用されなくなったときは、アカウントはそのまま残り、権限は失効します。したがって、権限は、ポリシーに対して設定されている「適用しない場合は失効」オプションの値に関係なく、ポリシーの適用が終了すると失効します。
Oracle Identity Manager 11g リリース1 (11.1.1)では、「適用しない場合は失効」オプションは、アカウント・レベルのみでなく権限レベルでも機能するため、オプションが選択されていない場合、権限は失効しません。この拡張が機能するには、XL.AccessPolicyRevokeIfNoLongerAppliesEnhancementシステム・プロパティの値をtrueに設定する必要があります。
XL.AccessPolicyRevokeIfNoLongerAppliesEnhancementシステム・プロパティの値がtrueの場合、「適用しない場合は失効」オプションは、「適用しなくなった場合はリソースと資格を失効」に変わります。このシステム・プロパティの値がfalseの場合、「適用しない場合は失効」オプションはそのままです。デフォルトで、両方のオプションが選択されます。このシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。
ポリシー・データが更新または削除された場合。これには、親と子の両方のフォーム・データが含まれます。ポリシーの評価は、該当するすべてのユーザーに対して行われます。
ポリシー優先度は、作成する各アクセス・ポリシーに対する一意の数値を含む数値フィールドです。数値が小さいほどアクセス・ポリシーの優先度が高くなります。たとえば、優先度に1を指定すると、ポリシーの優先度が最も高いことを意味します。Oracle Identity Manager管理およびユーザー・コンソールを使用してアクセス・ポリシーを定義する場合は、現行の最低優先度の値に必ず値1が加算され、結果の値が「優先度」フィールドに自動的に移入されます。この値を別の数値に変更すると、他のすべてのアクセス・ポリシーの優先度が再調整され、優先度の一貫性が保証されます。優先度値には次のアクションが関連付けられています。
入力された優先度値が1より小さい場合、その値はOracle Identity Managerにより1(最も高い優先度)に変更されます。
入力された優先度値がMより大きい場合(Mは現在最も低い優先度)、その値はOracle Identity ManagerによりM+1以下として指定されます。
2つのアクセス・ポリシーに同じ優先度値は指定できません。そのため、あるアクセス・ポリシーに既存の優先度値を割り当てた場合、それより優先度が低いポリシーはすべて、優先度が1つずつ下がることになります。
複数のアクセス・ポリシーが同じユーザーに適用されていると、競合が発生する場合があります。アクセス・ポリシーを介してユーザーにプロビジョニングされるリソースのインスタンスは1つであるため、Oracle Identity Managerでは最も優先度が高いポリシー・データが親フォームに使用されます。子フォームには、該当するポリシーすべての累積レコードが使用されます。
プロビジョニング時のリソースにプロセス・フォーム・データが提供される場合、複数の方法があります。Oracle Identity Managerに組み込まれた優先度の順序は次のとおりです。
フォームの定義によるデフォルト値
組織のデフォルト
データセットからプロセス・フォームへのデータ・フローで取得された値
事前移入アダプタ
アクセス・ポリシー・データ(ポリシーに基づいてリソースがプロビジョニングされる場合)
プロセス・タスクまたはエンティティ・アダプタにより更新されたデータ
指定したオプションが使用可能な場合、それ以外の使用頻度の低いオプションは無視されます。たとえば、オプション4が使用可能な場合は、オプション3、2および1は無視されます。
以前のリリースのOracle Identity Managerでは、アクセス・ポリシーはリソース・オブジェクトに対する単一アカウントの管理にのみ使用できます。つまり、リソースをすでにユーザーにプロビジョニングしている(アカウントがターゲット・システムに作成されている)場合に、同じリソースの別のインスタンスをアクセス・ポリシーを介して同じユーザーにプロビジョニングする場合、これは以前のリリースのOracle Identity Managerでは実行できません。リソースの複数インスタンスをユーザーにプロビジョニングする機能を実行するには、Oracle Identity Manager 11g リリース1 (11.1.1)でアクセス・ポリシーを拡張する前に、Oracle Identity Managerでターゲット・システムを表すコネクタをクローンする必要があります。コネクタのクローニングは、クローンされたリソースのテスト/メンテナンス用に多数の作業を必要とする、エラーが発生しやすい処理でした。Oracle Identity Manager 11g リリース1 (11.1.1)におけるリソースの複数インスタンスのプロビジョニングに対して行われたアクセス・ポリシー拡張によって、コネクタのクローニングに要する時間と作業が節約されます。
UNIXサーバー、Active Directory(AD)サーバー、データベース、SAPまたはJD Edwardsなどのターゲット・システムは、Oracle Identity Managerでユーザーにプロビジョニングする必要がある、Oracle Identity Managerの外部システムです。ターゲット・システムは、Oracle Identity Managerでリソースと呼ばれるエンティティで表されます。ターゲット・システムがインストールされているサーバーは、Oracle Identity ManagerではITリソースで表されます。また、このターゲット・システムにアクセスするユーザーに提供されるログイン資格証明は、Oracle Identity Managerではアカウントで表されます。ユーザーは、単一のターゲット・システム上で複数のアカウントを使用できます。たとえば、1つのアカウントをサービス(管理)アカウント用、もう1つを標準アカウント用にできます。したがって、単一のターゲット・システムで同じユーザーに対して2つのアカウントが必要です。さらに、複数のUNIXサーバー、データベース・サーバー、ADサーバーなど、ターゲット・システムに別々のインスタンスを設定することが可能です。この結果、同じユーザーに対して、ターゲット・システムの各インスタンスにアカウントを作成する必要があります。実装の詳細は、「単一ターゲット・システムにおける同じユーザーおよび同じリソースに対する個別アカウントの作成」を参照してください。
Oracle Identity Manager 11g リリース1 (11.1.1)では、アクセス・ポリシーによって、同じターゲット・システム内における複数アカウントのプロビジョニング、および同じターゲット・システムの複数インスタンスにおける単一アカウントのプロビジョニングが可能です。アクセス・ポリシーの評価時およびユーザーへのリソースのプロビジョニング時に、Oracle Identity Managerによって、リソースがユーザーにすでにプロビジョニングされているかどうかがチェックされます。これは、ユーザーにプロビジョニングされたリソースのリソース・キー(OBJ_KEY)をチェックして判断されます。アクセス・ポリシーを介して複数インスタンスをプロビジョニングするには、同じリソースの複数インスタンスを識別するために、OBJ_KEYに加えて、アカウント識別子と呼ばれる別の基準が必要です。したがって、アクセス・ポリシーでは、リソース・キーとアカウント識別子がチェックされ、リソースがプロビジョニングされているかどうかが判定されます。
アカウント識別子は、同じユーザーの2つのアカウントを識別する、プロセス・フォーム上のフィールド(アカウント・データ)であり、同じターゲット・システム上または異なるターゲット・システム上に存在できます。次に例を示します。
ユーザーJane.Doeに、2つの異なるUNIXサーバー上の2つのアカウントがプロビジョニングされている場合は、ITリソースをアカウント識別子として使用できます。
ユーザーJohn.Doeに、同じデータベース・インスタンス上の2つのアカウントがプロビジョニングされている場合は、異なるログインIDをアカウント識別子として使用できます。
アクセス・ポリシー評価のために、プロビジョニングする必要があるリソースが複数ある場合は、単一のバルク・リクエストが作成されます。バルク・リクエストには、単一のリクエスト・レベルの承認が必要ですが、承認者が各リクエストを操作レベルで個別に承認できる複数の操作レベルの承認も必要です。
|
関連項目:
|
アクセス・ポリシー・ウィザードを使用して、ポリシーに定義されているロールがあるユーザーに、リソースをプロビジョニングするためのアクセス・ポリシーを定義できます。
アクセス・ポリシーを作成するには、次の手順を実行します。
Oracle Identity Manager管理およびユーザー・コンソールにログインし、拡張管理にナビゲートします。
「アクセス・ポリシーの作成」ページを開くには、「ポリシー」の下にある「アクセス・ポリシーの作成」をクリックします。
アクセス・ポリシー名や説明など、アスタリスク(*)で示されている必須フィールドに情報を入力します。
|
注意: 次の特殊文字はアクセス・ポリシー名で使用できません。 セミコロン(;) ハッシュ(#) パーセンテージ(%) 等しい(=) バー(|) プラス(+) カンマ(,) スラッシュ(/) 円記号(¥) 一重引用符(') 二重引用符(") 小なり記号(<) 大なり記号(>) |
「プロビジョニング」フィールドで、次のいずれかのオプションを選択します。
承認なし: このオプションを選択すると、リクエスト承認なしのアクセス・ポリシーが作成されます。リソースは、リクエストが生成されることなく、ユーザーに直接プロビジョニングされます。
承認あり: このオプションを選択すると、リクエスト承認ありのアクセス・ポリシーが作成されます。アクセス・ポリシーの作成時に、リクエストが作成され、リソースのプロビジョニングはリクエスト承認を必要とします。
アクセス・ポリシーの作成時に更新するようにするには、「アクセス・ポリシーの更新」を選択します。
このオプションを選択しない場合、既存のロール・メンバーシップは考慮されません。
「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ2: リソースの選択(プロビジョニング)」ページが表示されます。
このアクセス・ポリシーに対してプロビジョニングするリソースを指定します。
フィルタ検索のメニューを使用してリソースを検索します。
結果表からリソース名を選択して、「追加」をクリックします。
プロビジョニングする目的のリソースの名前が「選択済」リストに表示されます。リソースを拒否するだけのアクセス・ポリシーを作成する場合は、リソースを選択しないで「続行」をクリックします。
選択されているリソースの割当てを解除するには、「選択済」リストでリソースを選択し、「削除」をクリックします。
「続行」をクリックします。
このリソースに関連付けられたフォームがある場合は、後続のページに必須フィールドが表示されます。それ以外の場合は、「アクセス・ポリシーの作成 - ステップ2: 失効するリソースの選択」ページが表示されます。パスワードおよび暗号化された属性に対しては、ポリシーのデフォルトを指定しないことをお薦めします。
適用されなくなったアクセス・ポリシーを失効させるかどうかを指定します。
結果表で、自動的に失効させるリソースのチェック・ボックスを選択します。
「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ3: リソースの選択(拒否)」ページが表示されます。
このページを使用して、このアクセス・ポリシーにより拒否されるリソースを選択します。
拒否されるリソースを選択するには、次の手順を実行します。
結果表からリソースを選択します。
「選択済」リストにリソースを移動するには、「追加」をクリックします。
プロビジョニングするリソースを選択しなかった場合は、拒否するリソースを少なくとも1つ選択する必要があります。プロビジョニングするものと同じリソースを拒否対象に選択すると、プロビジョニングするリソースとしての割当ては解除されます。
同様に、ステップaで、すでに拒否するように選択したものと同じリソースをプロビジョニング対象に割り当てると、拒否対象に選択されたリソースから自動的に削除されます。拒否対象として選択済のリソースを削除できます。これは、「選択済」リストから削除するリソースを選択し、「削除」をクリックして実行します。
「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ4: ロールの選択」ページが表示されます。
「アクセス・ポリシーの作成 - ステップ4: グループの選択」ページを使用して、グループをアクセス・ポリシーに関連付けます。
ロールをこのアクセス・ポリシーに関連付ける方法は、次のとおりです。
結果表からロールを選択して、「追加」をクリックします。少なくとも1つのロールを選択する必要があります。選択したロールの名前が、「選択済」リストに表示されます。
ロール名を削除するには、「削除」をクリックします。
「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ5: アクセス・ポリシー情報の検証」ページが表示されます。
この手順のこれより前のステップで選択した内容を変更する場合は、「変更」をクリックして、ウィザードの対応するページに移動します。必要な変更が終了したら、「続行」をクリックして、「ステップ5: アクセス・ポリシー情報の検証」ページに戻ります。
「アクセス・ポリシーの作成」をクリックして、アクセス・ポリシーを作成します。
|
注意: プロセス・フォームに「パスワード」フィールドが含まれているリソースにアクセス・ポリシーを作成した場合、パスワード・ポリシーは評価されません。パスワード・ポリシーの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。 |
Oracle Identity Manager管理およびユーザー・コンソールを使用すると、既存のアクセス・ポリシーの情報を変更できます。
アクセス・ポリシーを管理するには、次の手順を実行します。
「ポリシー」メニューの下の「アクセス・ポリシーの管理」をクリックします。
「アクセス・ポリシーの管理」ページが表示されます。
検索基準フィールドのメニューを使用して、アクセス・ポリシー属性を選択します。アスタリスク(*)ワイルドカード文字を使用すると、選択した属性に任意の値を持つすべてのアクセス・ポリシー・インスタンスを検索できます。「アクセス・ポリシーの検索」をクリックします。
「アクセス・ポリシーの管理」ページに検索結果が表示されます。
目的のアクセス・ポリシーの詳細を表示するには、「アクセス・ポリシー名」をクリックします。
「アクセス・ポリシー詳細」ページが表示されます。
このアクセス・ポリシーを変更するには、各選択カテゴリの末尾にある「変更」リンクを使用します。
必要な変更が終了したら、「アクセス・ポリシーの更新」をクリックします。
このアクセス・ポリシーが更新され、更新された情報が「アクセス・ポリシー詳細」ページに表示されます。
アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニングの内容は、次のとおりです。
アクセス・ポリシーを介して、単一ターゲット・システム上に同じユーザーおよび同じリソースに対する2つの異なるアカウントを作成できます。たとえば、単一のADインスタンス上に、ユーザー・アカウントとサービス・アカウントの2つのアカウントを作成する必要があるとします。Active Directoryターゲット・システムは、Oracle Identity ManagerではADユーザー・リソースで表されます。これは、次の方法で実装されます。
ADユーザー・リソースを作成します。
JohnDなどのユーザーを作成します。
プロセス・フォームで、UD_ADUSERとUD_ADUSER_UIDに識別子フィールドのマークを付けて、2つの異なるアカウントに別々のログインIDが設定されるようにします。
2つのアクセス・ポリシーを次のように作成します。
標準アカウント用
アクセス・ポリシー名: AP1
関連付けられるロール: Role1
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ユーザーID(UD_ADUSER_UID)
アクセス・ポリシーのデフォルト値: Account1
サービス・アカウント用
アクセス・ポリシー名: AP2
関連付けられるロール: Role2
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ユーザーID(UD_ADUSER_UID)
アクセス・ポリシーのデフォルト値: Account2
|
注意: 「ユーザーID」に対する値を生成するためにデータセットと関連付ける事前移入アダプタを作成して、このフィールドに一意の値が生成されるようにする必要があります。 |
Role1とRole2をJohnDに割り当てます。
Role1がJohnDに割り当てられると、AP1アクセス・ポリシーを介して、Account1アカウントがADユーザー・ターゲット・システムに作成されます。Role2がJohnDに割り当てられると、AP2を介して、Account2アカウントがADユーザーに作成されます。この結果、アクセス・ポリシーを介して、単一ターゲット・システム上に同じユーザーおよび同じリソースに対する2つの異なるアカウントを作成できます。
デフォルトでは、Oracle Identity Managerで複数アカウント・プロビジョニングはサポートされていません。複数アカウント・プロビジョニングを有効化する手順は、次のとおりです。
XL.AccessPolicyMultipleResourceEnhancementシステム・プロパティの値をTRUEに設定します。
このシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの事前定義システム・プロパティに関する項を参照してください。システム・プロパティの値の設定に関する詳細は、同じガイドのシステム・プロパティの作成と管理に関する項を参照してください。
システム・プロパティの変更を有効にするために、Oracle Identity Managerを再起動します。
複数アカウント・プロビジョニングが有効化されている場合は、適切なアカウント識別子属性を定義する必要があります。手順は次のとおりです。
Design Consoleにログインします。
プロセス・フォームを次のように更新します。
「開発ツール」を開き、「フォーム・デザイナ」をダブルクリックします。
プロセス・フォームを検索して開きます。
「Form Designer」タブで、「Create New Version」をクリックします。
「Create a New Version」ダイアログ・ボックスで、「Label」フィールドにラベルを入力して「Save」をクリックします。
「Current Version」リストから、作成したバージョンを選択します。
「Properties」タブで、識別子フィールドとして指定するフィールドを選択して「Add Property」をクリックします。
「Add Property」ダイアログ・ボックスで、プロパティ名として「Account Discriminator」を選択し、「Property Value」フィールドに「True」と入力して「Save」をクリックします。
「Make Version Active」をクリックし、「OK」をクリックします。
「Save」をクリックします。
既存のプロセス・フォームを変更した場合は、フォーム・バージョン制御(FVC)ユーティリティを実行します。FVCユーティリティの実行の詳細は、「フォーム・バージョン制御ユーティリティの使用」を参照してください。
次に、アクセス・ポリシーを介して、リソース・オブジェクトの複数インスタンスを複数ターゲット・システムにプロビジョニングする手順の概要を示します。
Oracle Identity Manager Design Consoleで、「ITリソース・タイプ定義」フォームを使用して、ITリソース・タイプを作成します。このフォームの使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の「ITリソース・タイプ定義」フォームに関する項を参照してください。
ステップ1で作成したITリソース・タイプのITリソース・インスタンスを複数作成します。ITリソースの作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のITリソースの作成に関する項を参照してください。
ここで、ITリソース・インスタンスはアカウント識別子です。アカウント識別子の詳細は、「アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング」を参照してください。
ステップ1で作成したタイプのフィールドを含むプロセス・フォームを作成します。プロセス・フォームの作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプロセス・フォームの開発に関する項を参照してください。
リソース・オブジェクトを作成します。リソース・オブジェクトの作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリソース・オブジェクトの作成に関する項を参照してください。
プロセス定義を作成し、リソース・オブジェクトとプロセス・フォームを関連付けます。プロセス定義の作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプロセス定義の作成に関する項を参照してください。
ロールとリソース・オブジェクトを関連付けるアクセス・ポリシーを作成します。詳細は、「アクセス・ポリシーの作成」を参照してください。
異なる物理サーバー上に同じリソースのインスタンスが2つある場合は、アクセス・ポリシーを使用して、リソースの両方のインスタンスを同じユーザーであるJohnDにプロビジョニングできます。これについて、次のシナリオを使用して説明します。
2つのADインスタンスがあり、1つはIPが10.151.14.82のサーバーで管理され、もう1つはIPが130.35.66.254のサーバーで管理されています。アクセス・ポリシー・ベースのプロビジョニングを介して、ユーザーには両方のインスタンスがプロビジョニングされます。この手順は、次のとおりです。
ADユーザー・リソースを作成します。
IPアドレスが10.151.14.82のサーバーを表す、ADServer1という名前のITリソースを作成します。
IPアドレスが130.35.66.254のサーバーを表す、ADServer2という名前のITリソースを作成します。
「ADサーバー」(UD_ADUSER_AD)プロセス・フォーム・フィールドに、識別子フィールドのマークを付けます。
2つのアクセス・ポリシーを次のように作成します。
ADServer1で作成されるアカウント用
アクセス・ポリシー名: AP3
関連付けられるロール: Role3
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ADサーバー(UD_ADUSER_AD)
ITResourceLookupフィールドのデフォルト値: ADServer1
ADServer2で作成されるアカウント用
アクセス・ポリシー名: AP4
関連付けられるロール: Role4
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ADサーバー(UD_ADUSER_AD)
ITResourceLookupフィールドのデフォルト値: ADServer2
Role3とRole4をユーザーJohnDに割り当てます。
Role3がJohnDに割り当てられると、AP3アクセス・ポリシーを介して、アカウントがADServer1上のターゲット・システムに作成されます。Role4がJohnDに割り当てられると、AP4アクセス・ポリシーを介して、アカウントがADServer2上のターゲット・システムに作成されます。この結果、アクセス・ポリシーを介して、ターゲット・システムの2つの異なるインスタンス上に、同じユーザーおよび同じリソースに対する2つの異なるアカウントが作成されます。
アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングには、次の制限があります。
単一のアクセス・ポリシーで、リソースの複数インスタンスをユーザーにプロビジョニングすることはできません。リソースの複数インスタンスをプロビジョニングするには、複数のアクセス・ポリシーを作成する必要があります。プロビジョニングする同じリソースのインスタンスと同じ数のアクセス・ポリシーを作成する必要があります。
リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがある場合は、これらのフィールドの値を、そのリソースをプロビジョニングするアクセス・ポリシーで指定する必要があります。これを実行しないと、ポリシーが次回評価されるときに複数のアカウントがプロビジョニングされるなど、不確定な動作が発生する可能性があります。
リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがあり、アクセス・ポリシー・エンジンを使用してこのリソースを1人以上のユーザーにプロビジョニングする場合、アカウント識別子フィールドの値は、アカウントのライフサイクルを通じて一定のままである必要があります。つまり、アカウント識別子フィールドの値は変更しないでください。これは、アクセス・ポリシー・エンジンで、新しいアカウントをユーザーにプロビジョニングするかどうかを決定するために、リソース・オブジェクト・キーおよびアカウント識別子の値が使用されるためです。
アカウント識別子の値を変更すると、プロビジョニングの決定が行われる基礎を変更することになるため、アクセス・ポリシー・エンジンの動作が不確定になります。したがって、アカウント識別子の値は変更しないことをお薦めします。また、アカウント識別子フィールドのプロセス・フォームの値は変更しないでください。
アクセス・ポリシーが異なるアカウント識別子の値で構成されている場合は、異なるアカウントがユーザーにプロビジョニングされます。このタイプのリソース・オブジェクトでは、「複数を許可」フラグが設定されている必要があります。それ以外の場合、プロビジョニングは失敗します。
|
注意: 大文字/小文字のみが異なるアカウント識別子の値(例: abcとaBc)も異なる値として処理されます。このデータの場合、2つのアカウントがエンド・ユーザーにプロビジョニングされます。 次のシナリオについて考えてみます。2つのアクセス・ポリシーで、同じアカウント識別子データがある同じリソースをプロビジョニングしています。ポリシーは、リクエストを介して適用されます。 これらの2つのポリシーはユーザーに適用され、ユーザーに対して再評価されます。この場合、1つのリソースのみがリクエストを介してユーザーにプロビジョニングされます。今度は、リクエスト承認が進行中であるとします。その間に、これらの2つのポリシーの優先度が交換され、優先度の高いポリシーが優先度の低いポリシーになり、もう一方が優先度の高いポリシーになるとします。リクエストが進行している間に、ポリシーがユーザーに対して再評価される場合は、同じリソースをプロビジョニングする2番目のリクエストが作成されますが、これは現在の高い優先度のポリシーによって行われます。この問題は、現在ポリシー・エンジンによって処理されません。この問題を回避するには、(リクエストを介する場合は特に)リソースをプロビジョニングするアクセス・ポリシーの優先度を変更する前に、特定のリソースに対する保留中のすべてのリクエストが承認または却下されていることを確認する必要があります。 |
