17 アクセス・ポリシーの管理
Oracle Identity Managerのアクセス・ポリシー管理機能を使用すると、各種アクセス・ポリシーの理解、アクセス・ポリシーの作成と管理、アクセス・ポリシーによる同じリソースの複数インスタンスのプロビジョニングの管理が可能になります。
内容は次のとおりです。
17.1 アクセス・ポリシーで使用される用語
アクセス・ポリシー管理で使用される重要な用語は、アクセス・ポリシー所有者、リソース、アカウント、アカウント識別子およびアプリケーション・インスタンスです。
次に、アクセス・ポリシーに関連する用語を示します。
-
アクセス・ポリシー所有者: アクセス・ポリシー所有者には特別な権限はありませんが、Identity Self-Serviceのアクセス・ポリシー構成UIを使用できます。また、アクセス管理APIでアクセス・ポリシー所有者に基づいて追加される認可チェックもありません。
-
リソース: リソースは、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リソース・タイプの詳細は、このセクションの「ITリソース・タイプ」の説明を参照してください。
-
アカウント: アカウントは、Oracle Identity Managerで作成され、ユーザーまたは組織にプロビジョニングされるリソースの実際のインスタンスです。たとえば、Exchangeサーバー上の電子メール・アカウントは、リソース・タイプExchangeのアカウント(インスタンス)です。
アカウントには、関連フォームの属性に対して特定の値があります。
-
アカウント識別子: アカウント識別子は、アカウントが作成される論理エンティティを一意に識別するフォームの属性のコレクションです。この用語は、大まかにターゲットと呼ばれる場合があります。たとえば、ADサーバーの場合、アカウント識別子は、「ADサーバー」(タイプ「ITリソース」の属性)と「組織名」の組合せにできます。
属性にアカウント識別子のマークを付けるには、「フォーム」フィールドのアカウント識別子プロパティを「True」に設定します。
-
アプリケーション・インスタンス: アプリケーション・インスタンスは、ITリソース・インスタンス(ターゲットの接続性とコネクタ構成)およびリソース・オブジェクト(プロビジョニング・メカニズム)の組合せです。
17.2 アクセス・ポリシーの機能
アクセス・ポリシー管理の主な機能には、直接プロビジョニング、ポリシーの取消しまたは無効化、ロール階層、リソースの拒否、ポリシーの評価、リコンサイルおよびバルク・ロードされるアカウントのポリシーの評価、アクセス・ポリシーの優先度、アクセス・ポリシー・データ、アクセス・ポリシーによる同じリソースの複数インスタンスのプロビジョニングなどがあります。
この項では、次の各項でアクセス・ポリシー・エンジンによって提供される様々な機能について説明します。
17.2.2 ポリシーの失効または無効化
ポリシーが適用されなくなった場合に、そのポリシー内のリソースを失効または無効化するかどうかを指定する必要があります。ユーザーにポリシーが適用されなくなると、選択した内容に従って、リソースがそのユーザーに対して自動的に失効されるか、無効化されます。ポリシーが適用されなくなった場合、アカウントと権限は失効または無効化できます。
アクセス・ポリシーに関連付けられているリソースごとに、次のいずれかのオプションを選択する必要があります。
-
失効: このオプションを選択すると、アクセス・ポリシーが適用されなくなったときに、そのアクセス・ポリシーに関連付けられているアカウントと権限が失効されます。
-
無効化: このオプションを選択すると、アクセス・ポリシーが適用されなくなったときに、そのアクセス・ポリシーに関連付けられているアカウントが無効化され、権限が失効されます。
- 権限がアクセス・ポリシー外でプロビジョニングされた場合、アカウントをアクティブに維持: このオプションを選択すると、ユーザーにこのリソースのアクセス・ポリシー外でプロビジョニングされた権限がある場合、アカウントはアクティブのままになります。
ノート:
このオプションは、デフォルトでは選択されていません。
「失効」オプションまたは「無効化」オプションが選択されていると、そのポリシーが適用されなくなったときに権限は必ず失効されます。「無効化」オプションが選択されている場合、権限はロールの付与に伴って付与されるものであるため、そのポリシーが適用されなくなったときにはリソースに関連付けられている権限が失効されます。そのロールが再度付与されると、権限がリソース・インスタンスに追加されます。
ポリシー定義に同じリソースを含む2つのポリシーがあり、一方のポリシーでは「失効」オプションが選択されていて、もう一方のポリシーでは「無効化」オプションが選択されているときには、「失効」オプションよりも「無効化」オプションが優先されます。つまり、ポリシーが適用されなくなった場合、リソースは(失効ではなく)無効になります。
17.2.3 ロール階層
アクセス・ポリシーにはロール階層のサポートを使用できます。この機能を有効にするには、システム・プロパティXL.AllowRoleHierarchicalPolicyEvalの値をtrueに設定します。ロール階層が有効化されていると、アクセス・ポリシー・エンジンはアクセス・ポリシーの評価時に直接ロールと間接ロールの両方を考慮するようになります。
17.2.4 リソースの拒否
アクセス・ポリシーの作成時には、プロビジョニングするリソースとともに拒否するリソースを選択できます。プロビジョニングするリソースを選択してから、同じリソースを拒否するように選択すると、リソースがすでに追加されているというエラー・メッセージが表示されます。同じリソースが異なる2つのポリシーに追加されたときに、一方のポリシーでリソースが拒否され、もう一方のポリシーでプロビジョニングされているとします。さらに、この両方のポリシーがユーザーにされると、拒否されたリソースが優先されます。
ノート:
アクセス・ポリシーによって拒否されたリソースは、別のポリシーによってプロビジョニングされても、常に拒否されます。リソースの拒否は、アクセス・ポリシーの優先度とは関係ありません。優先度の低いアクセス・ポリシーによってリソースが拒否された場合でも、より優先度の高いアクセス・ポリシーより優先されます。
17.2.5 ポリシーの評価
アクセス・ポリシーの評価は、次のように動作します。
-
ユーザーへのロールの付与またはポリシー定義の更新の後、ポリシー評価の必要なユーザーが識別され、USER_PROVISIONING_ATTRS表のエントリが更新または追加されます。
-
ポリシーの評価が必要なユーザーを決定するためにUSER_PROVISIONING_ATTRS.POLICY_EVAL_NEEDEDに格納されたフラグが使用されます。
-
「ユーザー・ポリシーの評価」スケジュール済ジョブは、ポリシー評価とそれに続くアカウントに対するアクションを開始するために実行されます。このタスクはデフォルトで有効になっており、10分ごとに実行されるようスケジュールされています。「ユーザー・ポリシーの評価」スケジュール済タスクの詳細は、『Oracle Identity Governanceの管理』の事前定義済のスケジュール済タスクに関する項を参照してください。 -
スケジュールされたタスクは、20スレッドを使用してデフォルト・バッチ・サイズ500 (更新日の昇順に25レコード/スレッド)で、USER_PROVISIONING_ATTRSにある個別ユーザー・レコードを選択します(この表の各レコードには個別ユーザーに関する情報が含まれる)。アクセス・ポリシーの評価の対象となるユーザーごとにJMSメッセージが送信されます。
図17-1に、アクセス・ポリシーの評価を示します。
Retrofit = trueとしてポリシーが作成されているときに、ポリシー定義が次のいずれかの方法で変更された場合、次のようになります。
-
ユーザーがロールに追加、またはロールから削除された場合。そのユーザーに対するポリシーは、追加または削除の操作の一部として評価されます。
-
ポリシーに更新フラグが設定されている場合。評価は次のようなシナリオで行われます。
-
ポリシー定義は更新されます。ポリシーの評価は、該当するすべてのユーザーに対して行われます。
-
ロールがポリシーの定義に追加、またはポリシーの定義から削除された場合。ポリシーの評価は、追加または削除されたロールに対してのみ行われます。
ノート:
ロールがユーザーに適用された後、「ユーザー・ポリシーの評価」スケジュール済ジョブを実行して、アクセス・ポリシーを適用可能にする必要があります。
-
リソースが追加または削除された場合や、リソースに対する「失効」または「無効化」オプションが変更された場合。
「失効」と「無効化」オプションを一方から他方に変更した場合、既存のリソース・インタンスはすぐには再評価されません。このポリシーの変更は、次に「ユーザー・ポリシーの評価」スケジュール済タスクによってポリシーが評価されるまで有効になりません。
-
ポリシー・データが更新または削除された場合。これには、親と子の両方のフォーム・データが含まれます。ポリシーの評価は、該当するすべてのユーザーに対して行われます。
-
ポリシーにロールを割り当てるか、ポリシーからロールを削除した場合は、Retrofitフラグの設定とは無関係に、ユーザーはポリシー評価の対象として即時マークされます。Retrofitフラグは、次のようなアクセス・ポリシー定義の変更のためにユーザーをポリシー評価の対象としてマークする必要があるかどうかを判断するためにのみ使用できます。
-
ポリシーの優先度の変更
-
ポリシーに関連付けられたリソースの変更
-
「失効」または「無効化「オプションの変更
-
親または子のデータの変更。この場合、
Retrofitがfalseに設定されていると、ポリシー定義が変更されていてもユーザーはポリシー評価の対象としてマークされません。
ノート:
「無効」ステータスのユーザーのアクセス・ポリシーの評価を管理するには、システム・プロパティXL.DoNotEvaluateAPForDisableUsersの値を設定します。詳細は、Oracle Identity Managerのデフォルトのシステム・プロパティに関する項を参照してください17.2.6 リコンサイルされたアカウントとバルク・ロードで作成されたアカウントのポリシーの評価
アクセス・ポリシー・エンジンは、リコンサイルされたアカウントおよびバルク・ロード・ユーティリティで作成されたアカウントに、アクセス・ポリシーをリンクできます。その後、アクセス・ポリシーは、「ユーザー・ポリシーの評価」スケジュール済ジョブを使用して評価されます。この機能を有効にする場合は、次のようにしてください。
-
XL.AllowAPHarvestingおよびXL.AllowAPBasedMultipleAccountProvisioningシステム・プロパティの値をTRUEに設定します。これらのシステム・プロパティの詳細とシステム・プロパティの値の設定方法は、Oracle Identity Governanceの管理のシステム・プロパティの作成と管理に関する項を参照してください。
-
「アクセス・ポリシーの更新」を選択して、リンクされるポリシーの更新フラグをONに設定します。
更新フラグの詳細は、「アクセス・ポリシーの作成」を参照してください。ポリシー定義の更新の詳細は、「アクセス・ポリシーの管理」を参照してください。
-
アクセス・ポリシー・デフォルトのITリソース・フィールドに値を移入します。
ITリソース・フィールドに値が移入されていないと、プロビジョニング・エンジンはアカウントに関連付けるアプリケーション・インスタンスを決定できなくなり、そのアカウントはUIに表示されなくなります。
-
プロセス・フォームのフィールドを識別子フィールドとして指定し、「アカウント識別子」プロパティの値を
Trueに設定します。次に、アカウント識別子フィールドのアクセス・ポリシーのデフォルトを設定します。識別子フィールドの設定の詳細は、「複数アカウント・プロビジョニングの有効化」を参照してください。
リコンサイルされたアカウントおよびバルク・ロード・ユーティリティで作成されたアカウントにアクセス・ポリシーをリンクする機能を有効にした後、アクセス・ポリシーの収集の流れを図17-2に示しています。
17.2.7 直接プロビジョニングされたアカウントとリクエストで作成されたアカウントのポリシーの評価
アクセス・ポリシー・エンジンは、リクエストによって作成されたアカウントおよび直接プロビジョニングされたアカウントにアクセス・ポリシーをリンクできます。これらの機能を有効にするには、「リコンサイルされたアカウントとバルク・ロードで作成されたアカウントのポリシーの評価」で説明されているリコンサイルされたアカウントとバルク・ロードで作成されたアカウントの機能の有効化と同様のステップを実行しますが、次の例外があります:
-
リクエストによって作成されたアカウントへのアクセス・ポリシーのリンクを有効にするには、
XL.APHarvestRequestAccount、XL.AllowAPHarvestingおよびXL.AllowAPBasedMultipleAccountProvisioningシステム・プロパティの値をTRUEに設定します。 -
直接プロビジョニングされたアカウントへのアクセス・ポリシーのリンクを有効にするには、
XL.APHarvestDirectProvisionAccount、XL.AllowAPHarvestingおよびXL.AllowAPBasedMultipleAccountProvisioningシステム・プロパティの値をTRUEに設定します。 -
アクセス・ポリシーにリンクされているアカウントのポリシー・デフォルトでアカウント・データを更新できるようにするには、
XL.APHarvesting.AllowAccountDataUpdate、XL.AllowAPHarvesting、XL.APHarvestRequestAccount、XL.APHarvestDirectProvisionAccountおよびXL.AllowAPBasedMultipleAccountProvisioningシステム・プロパティの値をTRUEに設定します。
これらのシステム・プロパティの詳細は、Oracle Identity Governanceのデフォルトのシステム・プロパティに関する項を参照してください。
17.2.8 アクセス・ポリシーの優先度
ポリシー優先度は、作成する各アクセス・ポリシーに対する一意の数値を含む数値フィールドです。数値が小さいほどアクセス・ポリシーの優先度が高くなります。たとえば、優先度に1を指定すると、ポリシーの優先度が最も高いことを意味します。Oracle Identity System Administrationを使用してアクセス・ポリシーを定義する場合は、現行の最低優先度の値に必ず値1が加算され、結果の値が「優先度」フィールドに自動的に移入されます。この値を別の数値に変更すると、他のすべてのアクセス・ポリシーの優先度が再調整され、優先度の一貫性が保証されます。優先度値には次のアクションが関連付けられています。
-
入力された優先度値が1より小さい場合、その値はOracle Identity Managerにより1(最も高い優先度)に変更されます。
-
入力された優先度値がMより大きい場合(Mは現在最も低い優先度)、その値はOracle Identity ManagerによりM+1以下として強制的に指定されます。
-
2つのアクセス・ポリシーに同じ優先度値は指定できません。そのため、あるアクセス・ポリシーに既存の優先度値を割り当てた場合、それより優先度が低いポリシーはすべて、優先度が1つずつ下がることになります。
複数のアクセス・ポリシーが同じユーザーに適用されていると、競合が発生する場合があります。アクセス・ポリシーを介してユーザーにプロビジョニングされるリソースのインスタンスは1つであるため、Oracle Identity Managerでは最も優先度が高いポリシー・データが親フォームに使用されます。子フォームには、該当するポリシーすべての累積レコードが使用されます。
同じリソースに対して複数のアクセス・ポリシーが作成されたが、異なる権限セットが付与されており、ポリシーが適用されなくなったときの動作が異なる場合は、アクセス・ポリシーの優先度とは関係なく、「適用しなくなった場合は無効化」(DLNA)オプションが有効になっているアクセス・ポリシーの優先度が最も高くなります。たとえば、「適用しなくなった場合は失効」(RLNA)オプションが有効になっているアクセス・ポリシーとDLNAオプションが有効になっている別のポリシーがある場合、DLNAオプションが有効になっているポリシーの優先度の方が高くなります。ポリシーが適用された順序とは関係なく、DLNAオプションが有効になっているポリシーがユーザーに適用されているかぎり、ポリシーが適用されなくなった場合にそのアカウントは必ず無効化されます。
「適用しなくなった場合は無効化」のポリシーがその後「適用しなくなった場合は失効」に変換された場合、ポリシーに関連付けられる既存アカウントはRLNAに更新されません。将来作成されるアカウントにのみ、変更内容は有効になります。
RLNAのポリシーが後でDLNAに変換された場合、失効されているアカウントは影響を受けません。この変更は、このポリシーに現在関連付けられているアカウントまたはこれ以降に作成されるアカウントのみに対してのみ有効です。
17.2.9 アクセス・ポリシー・データ
プロビジョニング時のリソースにプロセス・フォーム・データが提供される場合、複数の方法があります。Oracle Identity Managerに組み込まれた優先度の順序は次のとおりです。
-
Oracle Identity Manager Design Consoleを使用したフォーム定義のデフォルト値
-
事前移入アダプタ
-
アクセス・ポリシー・データ(ポリシーに基づいてリソースがプロビジョニングされる場合)
-
プロセス・タスクで更新されたデータ
指定したオプションが使用可能な場合、それ以外の使用頻度の低いオプションは無視されます。たとえば、オプション4が使用可能な場合は、オプション3、2および1は無視されます。
ノート:
XL.AllowRequestDataToPrepopAdapterシステム・プロパティがtrueに設定されていると、事前移入アダプタ・データがアクセス・ポリシー・データよりも優先されます。つまり、プロビジョニングするアクセス・ポリシー・データは、事前移入アダプタ・データによってオーバーライドされるようになります。このシステム・プロパティの詳細は、Oracle Identity Governanceの管理のOracle Identity Governanceのデフォルトのシステム・プロパティに関する項を参照してください。
17.2.10 アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング
以前のリリースのOracle Identity Managerでは、アクセス・ポリシーはリソース・オブジェクトに対する単一アカウントの管理にのみ使用できます。つまり、リソースをすでにユーザーにプロビジョニングしている(アカウントがターゲット・システムに作成されている)場合に、同じリソースの別のインスタンスをアクセス・ポリシーを介して同じユーザーにプロビジョニングする場合、これは以前のリリースのOracle Identity Managerでは実行できません。ユーザーにリソースの複数インスタンスをプロビジョニングする機能を実行するために、アクセス・ポリシーの拡張前のOracle Identity Managerでは、Oracle Identity Managerでターゲット・システムを表すコネクタをクローンする必要があります。コネクタのクローニングはエラーが発生しやすいため、クローンされたリソースのテスト/メンテナンス用に多数の作業が必要です。リソースの複数インスタンスのプロビジョニングのためにOracle Identity Managerで実施されたアクセス・ポリシーの拡張によって、コネクタのクローニングに要する時間と労力が少なくなります。
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では、アクセス・ポリシーによって、同じターゲット・システム内の複数アカウントのプロビジョニングに加えて、同じターゲット・システムの複数インスタンスにおける単一アカウントのプロビジョニングも可能です。アクセス・ポリシーの評価時およびユーザーへのリソースのプロビジョニング時に、Oracle Identity Managerによって、リソースがユーザーにすでにプロビジョニングされているかどうかがチェックされます。これは、ユーザーにプロビジョニングされたリソースのリソース・キー(OBJ_KEY)をチェックして判断されます。アクセス・ポリシーを介して複数インスタンスをプロビジョニングするには、同じリソースの複数インスタンスを識別するために、OBJ_KEYに加えて、アカウント識別子と呼ばれる別の基準が必要です。したがって、アクセス・ポリシーでは、リソース・キーとアカウント識別子がチェックされ、リソースがプロビジョニングされているかどうかが判定されます。
アカウント識別子は、同じユーザーの2つのアカウントを識別する、プロセス・フォーム上のフィールド(アカウント・データ)であり、同じターゲット・システム上または異なるターゲット・システム上に存在できます。たとえば:
-
ユーザーJane.Doeに、2つの異なるUNIXサーバー上の2つのアカウントがプロビジョニングされている場合は、ITリソースをアカウント識別子として使用できます。
-
ユーザーJohn.Doeに、同じデータベース・インスタンス上の2つのアカウントがプロビジョニングされている場合は、異なるログインIDをアカウント識別子として使用できます。
関連項目:
複数のターゲット・システムからデータをプロビジョニングするステップは、「アクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング」を参照してください。
17.2.11 アクセス・ポリシーの認可
次に示すアクセス・ポリシーに関連する認可機能は、アクセス・ポリシーへの適切なアクセスを取得するためにユーザーに割り当てる必要があります。
-
アクセス・ポリシー - 作成
-
アクセス・ポリシー - 削除
-
アクセス・ポリシー - 変更
-
アクセス・ポリシー - 表示/検索
管理ロールおよび管理ロールの機能の詳細は、「管理ロールの管理」を参照してください。各種の機能とその詳細は、「機能」を参照してください。
17.3 アクセス・ポリシーの作成
「アクセス・ポリシー」ページを使用すると、ポリシーでロールが定義されているユーザーにリソースをプロビジョニングするためのアクセス・ポリシーを定義できます。
ノート:
-
アイデンティティ監査ポリシー(SoD)は、アクセス・ポリシーの作成時に評価されません。
-
アクセス・ポリシーへのロールの関連付けは、アクセス・ポリシーUIを介してではなく、ロール管理の一部として行います。
アクセス・ポリシーを作成するには:
-
Oracle Identity Self Serviceにログインします。
-
「管理」タブをクリックします。
-
「ロールとアクセス・ポリシー」ボックスをクリックして、「アクセス・ポリシー」を選択します。「アクセス・ポリシー」ページが表示されます。
-
「作成」をクリックして、「アクセス・ポリシーの作成」ページを開きます。
-
アクセス・ポリシー名や説明など、アスタリスク(*)で示されている必須フィールドに情報を入力します。
ノート:
次の特殊文字はアクセス・ポリシー名で使用できません。
セミコロン(;)
ハッシュ(#)
パーセンテージ(%)
等しい(=)
バー(|)
プラス(+)
カンマ(,)
スラッシュ(/)
円記号(¥)
一重引用符(')
二重引用符(")
小なり記号(<)
大なり記号(>)
-
「所有者」リストから、ポリシー・タイプとして「USER」または「ROLE」を選択します。選択内容に基づいて、参照アイコンをクリックし、ポリシー所有者としてユーザーまたはロールを選択します。
ポリシー所有者タイプを選択しない場合、アクセス・ポリシーは、デフォルトのポリシー所有者タイプがUSERとして、所有者がログイン・ユーザーとして作成されます。
ポリシー所有者タイプを選択していて、ポリシー所有者の値(USERまたはROLE)を選択していないときに、「次」をクリックすると、検証エラーが表示されて次の画面に進めなくなります。
-
このアクセス・ポリシーを作成時に更新するには、「更新」を選択します。
「更新」 オプションを設定すると、アクセス・ポリシー・データの変更が既存のユーザーに更新されます。ロールにアクセス・ポリシーを割り当てる方法の詳細は、「「アクセス・ポリシー」タブ」を参照してください。
このオプションを選択しない場合、既存のロール・メンバーシップは考慮されません。
-
適切な「優先度レベル」を入力します。
-
「次」をクリックします。「Application」ページが表示されます。
-
「プロビジョニング・アプリケーション」ペインで「追加」をクリックして、プロビジョニングする必要のあるアプリケーション・インスタンスを選択します。「アプリケーション・インスタンスの追加」ウィンドウが表示されます。
フィルタ検索メニューを使用して、アプリケーション・インスタンスを選択します。
-
結果表からアプリケーション・インスタンスの名前を選択してから、「選択した項目の追加」をクリックします。
ノート:
子アプリケーションが別のアプリケーションに依存している場合は、子アプリケーション・インスタンスを追加することで、その親アプリケーション・インスタンスが自動的に追加されます。子アプリケーション・インスタンスが追加されている間は、親アプリケーション・インスタンスの削除は許可されません。重複する子フォームのレコードは許可されません。「保存」をクリックしたときに自動的に削除されます。
-
「選択済」リストに、プロビジョニングする目的のアプリケーション・インスタンスの名前が表示されます。
-
選択したアプリケーションの割当てを解除するには、「選択済」リストでアプリケーション・インスタンスを選択して、「削除」をクリックします。
-
-
「選択」をクリックします。
-
ページにリストされたアプリケーション・インスタンスごとに、次のいずれかのオプションを選択します。
-
失効: このオプションを選択すると、アクセス・ポリシーが適用されなくなったときに、そのアクセス・ポリシーに関連付けられているアカウントと権限が失効されます。
-
無効化: このオプションを選択すると、アクセス・ポリシーが適用されなくなったときに、そのアクセス・ポリシーに関連付けられているアカウントが無効化され、権限が失効されます。
アクセス・ポリシーが適用されなくなった場合にアカウントおよび権限を失効または無効化する方法の詳細は、「ポリシーの失効または無効化」および「ポリシーの評価」を参照してください。
-
-
選択したアプリケーション・インスタンスに親データや子データなどの追加情報を指定するには、選択したアプリケーション・インスタンスの「表示名」リンクをクリックします。「アクセス・ポリシーの作成」の「一般属性」ページが開きます。
必要な情報を入力して、「保存」をクリックします。
-
「拒否されたアプリケーション」パネルの「追加」をクリックして、拒否する必要のあるアプリケーション・インスタンスを選択します。「アプリケーション・インスタンスの追加」ウィンドウが表示されます。
フィルタ検索メニューを使用して、アプリケーション・インスタンスを選択します。
-
結果表からアプリケーション・インスタンスの名前を選択してから、「選択した項目の追加」をクリックします。
-
「選択済」リストに、拒否する目的のアプリケーション・インスタンスの名前が表示されます。
-
選択したアプリケーションの割当てを解除するには、「選択済」リストでアプリケーション・インスタンスを選択して、「削除」をクリックします。
-
-
「終了」をクリックして、アクセス・ポリシーを作成します。
成功メッセージがアクセス・ポリシー名とともに表示されます。
17.5 アクセス・ポリシーの削除
不要または未使用のアクセス・ポリシーを削除します。
- Oracle Identity Self Serviceにログインします。
- 「管理」タブをクリックします。
- 「ロールとアクセス・ポリシー」ボックスをクリックして、「アクセス・ポリシー」を選択します。「アクセス・ポリシー」ページが表示されます。
- 削除するアクセス・ポリシーを検索します。「名前」または「説明」を入力して、「検索」アイコンをクリックします。
- 削除するアクセス・ポリシーを選択して、ツールバーの「削除」をクリックします。
ノート:
アクセス・ポリシーは、どのようなロールも関連付けられていない場合にのみ削除できます。アクセス・ポリシーの削除前に、すべての依存性を削除してください。
17.6 アクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング
アカウント識別子を使用したアクセス・ポリシーによる同じリソースの複数インスタンスのプロビジョニングには、複数アカウントのプロビジョニングの有効化、単一ターゲット・システム上の同じユーザーと同じリソースに対する個別のアカウントの作成、1つのリソースの複数インスタンスの複数ターゲット・システムへのプロビジョニングおよびアクセス・ポリシーによる1つのリソースの複数インスタンスのプロビジョニングの制限が含まれます。
この項の内容は次のとおりです。
17.6.1 複数アカウント・プロビジョニングの有効化
デフォルトでは、Oracle Identity Managerで複数アカウント・プロビジョニングはサポートされていません。複数アカウント・プロビジョニングを有効化するには:
XL.AllowAPBasedMultipleAccountProvisioningシステム・プロパティの値をTRUEに設定します。このシステム・プロパティの詳細は、『Oracle Identity Governanceの管理』のシステム・プロパティの作成と管理に関する項を参照してください。
複数アカウント・プロビジョニングが有効化されている場合は、適切なアカウント識別子属性を定義する必要があります。そのように行うには:
-
Design Consoleにログインします。
-
プロセス・フォームを次のように更新します。
-
「開発ツール」を開き、「フォーム・デザイナ」をダブルクリックします。
-
プロセス・フォームを検索して開きます。
-
「フォーム・デザイナ」タブで、「新しいバージョンの作成」をクリックします。
-
「新しいバージョンの作成」ダイアログ・ボックスで、「ラベル」フィールドにラベルを入力して「保存」をクリックします。
-
「現行のバージョン」リストから、作成したバージョンを選択します。
-
「プロパティ」タブで、識別子フィールドとして指定するフィールドを選択して「プロパティの追加」をクリックします。
-
「プロパティの追加」ダイアログ・ボックスで、プロパティ名として「アカウント識別子」を選択し、「プロパティ値」フィールドに
Trueと入力して「保存」をクリックします。 -
「バージョンをアクティブにする」をクリックし、「OK」をクリックします。
-
「保存」をクリックします。
-
17.6.2 単一ターゲット・システムにおける同じユーザーおよび同じリソースに対する個別アカウントの作成
アクセス・ポリシーを介して、単一ターゲット・システム上に同じユーザーおよび同じリソースに対する2つの異なるアカウントを作成できます。たとえば、単一のADインスタンス上に、ユーザー・アカウントとサービス・アカウントの2つのアカウントを作成する必要があるとします。Active Directoryターゲット・システムは、Oracle Identity ManagerではADユーザー・リソースで表されます。これは、次の方法で実装されます。
17.6.3 複数ターゲット・システムへのリソースの複数インスタンスのプロビジョニング
次に、アクセス・ポリシーを介して、リソース・オブジェクトの複数インスタンスを複数ターゲット・システムにプロビジョニングするステップの概要を示します。
17.6.4 アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングの制限
アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングには、次の制限があります。
-
単一のアクセス・ポリシーで、リソースの複数インスタンスをユーザーにプロビジョニングすることはできません。リソースの複数インスタンスをプロビジョニングするには、複数のアクセス・ポリシーを作成する必要があります。プロビジョニングする同じリソースのインスタンスと同じ数のアクセス・ポリシーを作成する必要があります。
-
リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがある場合は、これらのフィールドの値を、そのリソースをプロビジョニングするアクセス・ポリシーで指定する必要があります。そうしないと、次にポリシーが評価されるときに複数のアカウントがプロビジョニングされるなどの問題が発生する場合があります。
-
リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがあり、アクセス・ポリシー・エンジンを使用してこのリソースを1人以上のユーザーにプロビジョニングする場合、アカウント識別子フィールドの値は、アカウントのライフサイクルを通じて一定のままである必要があります。つまり、アカウント識別子フィールドの値は変更しないでください。これは、アクセス・ポリシー・エンジンで、新しいアカウントをユーザーにプロビジョニングするかどうかを決定するために、リソース・オブジェクト・キーおよびアカウント識別子の値が使用されるためです。
アカウント識別子の値を変更すると、プロビジョニングの決定が行われる基礎を変更することになるため、アクセス・ポリシー・エンジンの動作が不確定になります。したがって、アカウント識別子の値は変更しないことをお薦めします。また、アカウント識別子フィールドのプロセス・フォームの値は変更しないでください。
-
アクセス・ポリシーが異なるアカウント識別子の値で構成されている場合は、異なるアカウントがユーザーにプロビジョニングされます。
ノート:
大文字/小文字のみが異なるアカウント識別子の値(たとえば、abcとaBc)も異なる値として処理されます。このデータの場合、2つのアカウントがエンド・ユーザーにプロビジョニングされます。
17.7 「ユーザー・ポリシーの評価」スケジュール済ジョブに関する問題のトラブルシューティング
場合によっては、「ユーザー・ポリシーの評価」スケジュール済タスクがトリガーされないことや、ユーザーを処理しない(または少数のユーザーのみを処理する)ことがあります。
考えられる原因は次のとおりです。
-
「ユーザー・ポリシーの評価」スケジュール済タスクは実行されているが、ポリシー評価のマークが付けられたユーザーが存在しない。
-
ユーザーにはポリシー評価のマークが付けられているが、そのユーザーがアクティブでない。
-
ポリシー評価は完了したが、プロビジョニング操作が失敗した。
この場合、プロビジョニングに関連するイベント・ハンドラはCANCELLED状態になります。その結果、アカウントまたは権限はユーザーにプロビジョニングされなくなります。
-
「ユーザー・ポリシーの評価」スケジュール済タスクが、スケジューラに関する問題のためにトリガーされていない。
この場合は、スケジューラの問題を個別にトラブルシューティングする必要があります。
この問題がアクセス・ポリシー、プロビジョニングまたはスケジューラのどれに関連しているかを特定するには、MetaLinkノート1563379.1に記載されているステップを実行してください。