| Oracle® Fusion Middleware Oracle Identity Managerの管理 11g リリース2 (11.1.2.3.0) E61959-10 |
|
 前 |
 次 |
アクセス・ポリシーは、ロールに割り当てられるルールであり、これらのロールを割り当てられたユーザーに対してプロビジョニングまたはプロビジョニング解除できるターゲット・システムを指示します。本質的には、自動化されたユーザーへのターゲット・システムのプロビジョニング方法です。これについて、次の例を使用して説明します。
あるユーザーがOracle Identity Managerで作成された複数のロールに属しています。ロールVision Northには、メンバーシップ・ルールが割り当てられているとします。メンバーシップ・ルールは、Organization Name = "Vision North America"など、ユーザーが属している組織に基づいて設計できます。ロールにはアクセス・ポリシーを割り当てることができます。アクセス・ポリシーでは、アクセス・ポリシーの適用時に、ロールに対してプロビジョニングまたは拒否(あるいはその両方)されるリソースが示されます。そのため、Vision North Americaの組織でユーザーが作成された場合、これはメンバーシップ・ルールを満たし、Vision Northロールをユーザーに付与します。次に、ロールに割り当てられているアクセス・ポリシーがトリガーされ、アクセス・ポリシーに記述されているリソースがプロビジョニングまたは拒否されます。
このリリースのOracle Identity Managerでは、アクセス・ポリシーを検索した後にアイデンティティ・セルフ・サービスのロール・ウィザードで、ロールにアクセス・ポリシーを割り当てることができます。アイデンティティ・システム管理のアクセス・ポリシーの構成セクションで、アクセス・ポリシーにロールを割り当てることはできません。
この章では、Oracle Identity Managerでユーザーおよびリソースに対してアクセス・ポリシーを作成、使用する方法について説明します。次の項で構成されます。
次に、アクセス・ポリシーに関連する用語を示します。
アクセス・ポリシー所有者
このリリースでは、アクセス・ポリシー所有者は、特別な権限を持ちません。アイデンティティ・システム管理でアクセス・ポリシーの構成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リソース・タイプ」を参照)。
アカウント
アカウントは、Oracle Identity Managerで作成され、ユーザーまたは組織にプロビジョニングされるリソースの実際のインスタンスです。たとえば、Exchangeサーバー上の電子メール・アカウントは、リソース・タイプExchangeのアカウント(インスタンス)です。
アカウントには、関連フォームの属性に対して特定の値があります。
ITリソース・タイプ
ITリソース・タイプは、物理ターゲットとそのすべての属性のモデル化に使用されるOracle Identity Managerの論理エンティティであり、属性には、物理コンピュータへの接続に必要な接続情報や資格証明などがあります。たとえば、ITリソース・タイプ「ADサーバー」は、実際のADサーバーをモデル化するために使用されます。
ITリソース・インスタンス
これらは、実際の物理ターゲットを表す、特定のITリソース・タイプの実際のインスタンスです。これらには、IPアドレス、ポート、ユーザー名、パスワードなど、物理ターゲットのすべての属性に対する特定の値もあります。デプロイメント内の2つの物理ADサーバーは、ITリソース・タイプ「ADサーバー」の2つのインスタンスで表されます。
親データのアクセス・ポリシー・デフォルトにはITリソース・インスタンスを必ず指定する必要があります。
アカウント識別子
アカウント識別子は、アカウントが作成される論理エンティティを一意に識別する、フォーム上の属性の集合です。この用語は、大まかにターゲットと呼ばれる場合があります。たとえば、ADサーバーの場合、アカウント識別子は、「ADサーバー」(タイプ「ITリソース」の属性)と「組織名」の組合せにできます。
通常、アカウント識別子は、タイプ「ITリソース」の属性です。
属性にアカウント識別子のマークを付けるには、「フォーム」フィールドのアカウント識別子プロパティを「True」に設定します。
ここでは、ポリシー・エンジンによって提供される様々な機能について次の各項で説明します。
アクセス・ポリシーが適用される際に、リクエストを生成しないでリソースが直接プロビジョニングまたは拒否されます。
Oracle Identity Managerのアクセス・ポリシーは、サブロールには適用されません。ポリシーは、そのアクセス・ポリシーに定義されているロールの直下のメンバーシップ・ユーザー(サブロールのメンバーではないユーザー)にのみ適用されます。ポリシーが適用されなくなった場合に、そのポリシー内のリソースを失効または無効化するかどうかを指定する必要があります。ユーザーにポリシーが適用されなくなると、選択した内容に従って、リソースがそのユーザーに対して自動的に失効されるか、無効化されます。ポリシーが適用されなくなった場合、アカウントと権限は失効または無効化できます。
アクセス・ポリシーに関連付けられているリソースごとに、次のいずれかのオプションを選択する必要があります。
適用しなくなった場合は失効: このオプションを選択すると、アクセス・ポリシーが適用されなくなった場合に、そのアクセス・ポリシーに関連付けられているアカウントと権限が失効されます。
適用しなくなった場合は無効化: このオプションを選択すると、アクセス・ポリシーが適用されなくなった場合に、そのアクセス・ポリシーに関連付けられているアカウントと権限が無効化されます。
「適用しなくなった場合は失効」オプションまたは「適用しなくなった場合は無効化」オプションが選択されている場合、このポリシーが適用されなくなったときに権限は必ず失効されます。「適用しなくなった場合は無効化」オプションが選択されている場合、権限はロールの付与に伴って付与されるものであるため、このポリシーが適用されなくなったときに、リソースに関連付けられている権限が失効されます。そのロールが再度付与されると、権限がリソース・インスタンスに追加されます。
|
注意: Oracle Identity Manager 11g リリース2 (11.1.2.3.0)のアップグレード時に、「適用しなくなった場合は失効」オプションの選択が解除されていたポリシーは、「適用しなくなった場合は無効化」に変換されます。これらのポリシーに関連付けられているユーザーは更新されませんが、これ以降にポリシーを更新すると、それらのユーザーに「適用しなくなった場合は無効化」フラグが付けられます。 |
ポリシー定義に同じリソースを持つ2つのポリシーがあり、1つのポリシーで「適用しなくなった場合は失効」オプションが選択され、他のポリシーで「適用しなくなった場合は無効化」オプションが選択されている場合、「適用しなくなった場合は無効化」オプションは、「適用しなくなった場合は失効」オプションよりも優先されます。つまり、両方のポリシーが適用されなくなった場合、リソースは(失効ではなく)無効になります。
アクセス・ポリシーの作成中には、ロールに対してプロビジョニングするリソースに加え、拒否するリソースを選択できます。プロビジョニングするリソースとして一旦選択したリソースを、後で拒否するリソースとして選択すると、そのリソースはOracle Identity Managerによりプロビジョニングするリソースのリストから削除されます。つまり、拒否するリソースが優先されます。
|
注意: アクセス・ポリシーによって拒否されたリソースは、別のポリシーによってプロビジョニングされても、常に拒否されます。リソースの拒否は、アクセス・ポリシーの優先度とは関係ありません。優先度の低いアクセス・ポリシーによってリソースが拒否された場合でも、より優先度の高いアクセス・ポリシーより優先されます。 |
アクセス・ポリシーの評価は、次のように動作します。
ユーザーへのロールの付与またはポリシー定義の更新の後、ポリシー評価の必要なユーザーが識別され、USER_PROVISIONING_ATTRS表のエントリが更新または追加されます。
ポリシーの評価が必要なユーザーを決定するためにUSER_PROVISIONING_ATTRS.POLICY_EVAL_NEEDEDに格納されたフラグが使用されます。
ポリシーの評価およびアカウントに対するその他のアクションを起動するためにEvaluate User Policiesスケジュール済ジョブが実行されます。デフォルトでは、このタスクは有効であり、10分ごとに実行するようにスケジュールされています。「ユーザー・ポリシーの評価」スケジュール済タスクの詳細は、「事前定義済のスケジュール済タスク」を参照してください。
スケジュールされたタスクは、20スレッドを使用してデフォルト・バッチ・サイズ500 (更新日の昇順に25レコード/スレッド)で、USER_PROVISIONING_ATTRSにある個別ユーザー・レコードを選択します(この表の各レコードには個別ユーザーに関する情報が含まれる)。アクセス・ポリシーの評価の対象となるユーザーごとにJMSメッセージが送信されます。
図5-1に、アクセス・ポリシーの評価を示します。
Retrofit = trueとしてポリシーが作成されているときに、ポリシー定義が次のいずれかの方法で変更された場合、次のようになります。
ユーザーがロールに追加、またはロールから削除された場合。そのユーザーに対するポリシーは、追加または削除の操作の一部として評価されます。
ポリシーに更新フラグが設定されている場合。評価は次のようなシナリオで行われます。
ポリシー定義は更新されます。ポリシーの評価は、該当するすべてのユーザーに対して行われます。
ロールがポリシーの定義に追加、またはポリシーの定義から削除された場合。ポリシーの評価は、追加または削除されたロールに対してのみ行われます。
|
注意: 11gリリース2 (11.1.2.3.0)では、ロールがユーザーに適用された後、「ユーザー・ポリシーの評価」スケジュール済ジョブを実行して、アクセス・ポリシーを適用可能にする必要があります。 |
リソースが追加または削除されたか、リソースに対する「適用しなくなった場合は失効」または「適用しなくなった場合は無効化」オプションが変更された場合。
「適用しなくなった場合は失効」と「適用しなくなった場合は無効化」オプションをもう一方に変更した場合、既存のリソース・インタンスはすぐには再評価されません。このポリシーの変更は、次に「ユーザー・ポリシーの評価」スケジュール済タスクによってポリシーが評価されるまで有効になりません。
ポリシー・データが更新または削除された場合。これには、親と子の両方のフォーム・データが含まれます。ポリシーの評価は、該当するすべてのユーザーに対して行われます。
ポリシーにロールを割り当てるか、ポリシーからロールを削除した場合は、Retrofitフラグの設定とは無関係に、ユーザーはポリシー評価の対象として即時マークされます。Retrofitフラグは、次のようなアクセス・ポリシー定義の変更のためにユーザーをポリシー評価の対象としてマークする必要があるかどうかを判断するためにのみ使用できます。
ポリシーの優先度の変更
ポリシーに関連付けられたリソースの変更
「適用しなくなった場合は失効」または「適用しなくなった場合は無効化」オプションの変更
親または子のデータの変更。この場合、Retrofitがfalseに設定されていると、ポリシー定義が変更されていてもユーザーはポリシー評価の対象としてマークされません。
アクセス・ポリシー・エンジンは、リコンサイルされたアカウントおよびバルク・ロード・ユーティリティで作成されたアカウントに、アクセス・ポリシーをリンクできます。その後、アクセス・ポリシーは、Evaluate User Policiesスケジュール済ジョブを使用して評価されます。この機能を有効にする場合は、次のようにしてください。
XL.AllowAPHarvestingおよびXL.AllowAPBasedMultipleAccountProvisioningシステム・プロパティの値をTRUEに設定します。
これらのシステム・プロパティの詳細は、「Oracle Identity Managerのシステム・プロパティ」を参照してください。システム・プロパティの値の設定に関する詳細は、「システム・プロパティの作成と管理」を参照してください。
「アクセス・ポリシーの更新」を選択して、リンクされるポリシーの更新フラグをONに設定します。
更新フラグの詳細は、「アクセス・ポリシーの作成」を参照してください。ポリシー定義の更新の詳細は、「アクセス・ポリシーの管理」を参照してください。
アクセス・ポリシー・デフォルトのITリソース・フィールドに値を移入します。
ITリソース・フィールドに値が移入されていないと、プロビジョニング・エンジンはアカウントに関連付けるアプリケーション・インスタンスを決定できなくなり、そのアカウントはUIに表示されなくなります。
プロセス・フォーム上の1つのフィールドを識別子フィールドとして指定して、アカウント識別子プロパティの値をTrueに設定します。その後で、アカウント識別子フィールドのアクセス・ポリシー・デフォルトを移入します。
識別子フィールドの設定の詳細は、「複数アカウント・プロビジョニングの有効化」を参照してください。
リコンサイルされたアカウントおよびバルク・ロード・ユーティリティで作成されたアカウントにアクセス・ポリシーをリンクする機能を有効にした後、アクセス・ポリシーの収集の流れを図5-2に示しています。
ポリシー優先度は、作成する各アクセス・ポリシーに対する一意の数値を含む数値フィールドです。数値が小さいほどアクセス・ポリシーの優先度が高くなります。たとえば、優先度に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オプションが有効になっているポリシーの優先度の方が高くなります。ポリシーが適用された順序とは関係なく、DNLAを含むポリシーのみが適用されなくなくなり、その他のRNLAを含むポリシーがまだ適用される場合、リソースはプロビジョニング済ステータスのままになります。そのリソースに対するすべてのアクセス・ポリシーが適用されなくなった後にのみ、リソースは無効ステータスになります。
「適用しなくなった場合は無効化」のポリシーがその後「適用しなくなった場合は失効」に変換された場合、ポリシーに関連付けられる既存アカウントはRLNAに更新されません。将来作成されるアカウントにのみ、変更内容は有効になります。
RLNAのポリシーが後でDLNAに変換された場合、失効されているアカウントは影響を受けません。この変更は、このポリシーに現在関連付けられているアカウントまたはこれ以降に作成されるアカウントのみに対してのみ有効です。
プロビジョニング時のリソースにプロセス・フォーム・データが提供される場合、複数の方法があります。Oracle Identity Managerに組み込まれた優先度の順序は次のとおりです。
Oracle Identity Manager Design Consoleを使用したフォーム定義のデフォルト値
事前移入アダプタ
アクセス・ポリシー・データ(ポリシーに基づいてリソースがプロビジョニングされる場合)
プロセス・タスクで更新されたデータ
指定したオプションが使用可能な場合、それ以外の使用頻度の低いオプションは無視されます。たとえば、オプション4が使用可能な場合は、オプション3、2および1は無視されます。
以前のリリースのOracle Identity Managerでは、アクセス・ポリシーはリソース・オブジェクトに対する単一アカウントの管理にのみ使用できます。つまり、リソースをすでにユーザーにプロビジョニングしている(アカウントがターゲット・システムに作成されている)場合に、同じリソースの別のインスタンスをアクセス・ポリシーを介して同じユーザーにプロビジョニングする場合、これは以前のリリースのOracle Identity Managerでは実行できません。リソースの複数インスタンスをユーザーにプロビジョニングする機能を実行するには、Oracle Identity Manager 11g リリース2 (11.1.2.3.0)でアクセス・ポリシーを拡張する前に、Oracle Identity Managerでターゲット・システムを表すコネクタをクローンする必要があります。コネクタのクローニングは、クローンされたリソースのテスト/メンテナンス用に多数の作業を必要とする、エラーが発生しやすい処理でした。Oracle Identity Manager 11g リリース2 (11.1.2.3.0)におけるリソースの複数インスタンスのプロビジョニングに対して行われたアクセス・ポリシー拡張によって、コネクタのクローニングに要する時間と作業が節約されます。
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 リリース2 (11.1.2.3.0)では、アクセス・ポリシーによって、同じターゲット・システム内における複数アカウントのプロビジョニング、および同じターゲット・システムの複数インスタンスにおける単一アカウントのプロビジョニングが可能です。アクセス・ポリシーの評価時およびユーザーへのリソースのプロビジョニング時に、Oracle Identity Managerによって、リソースがユーザーにすでにプロビジョニングされているかどうかがチェックされます。これは、ユーザーにプロビジョニングされたリソースのリソース・キー(OBJ_KEY)をチェックして判断されます。アクセス・ポリシーを介して複数インスタンスをプロビジョニングするには、同じリソースの複数インスタンスを識別するために、OBJ_KEYに加えて、アカウント識別子と呼ばれる別の基準が必要です。したがって、アクセス・ポリシーでは、リソース・キーとアカウント識別子がチェックされ、リソースがプロビジョニングされているかどうかが判定されます。
アカウント識別子は、同じユーザーの2つのアカウントを識別する、プロセス・フォーム上のフィールド(アカウント・データ)であり、同じターゲット・システム上または異なるターゲット・システム上に存在できます。例:
ユーザーJane.Doeに、2つの異なるUNIXサーバー上の2つのアカウントがプロビジョニングされている場合は、ITリソースをアカウント識別子として使用できます。
ユーザーJohn.Doeに、同じデータベース・インスタンス上の2つのアカウントがプロビジョニングされている場合は、異なるログインIDをアカウント識別子として使用できます。
「アクセス・ポリシー」ウィザードを使用して、ポリシーに定義されているロールがあるユーザーに、リソースをプロビジョニングするためのアクセス・ポリシーを定義できます。
|
注意:
|
アクセス・ポリシーを作成するには、次の手順を実行します。
Oracle Identity System Administrationにログインします。
「ポリシー」で、「アクセス・ポリシー」をクリックします。「アクセス・ポリシーの管理」ウィンドウが表示されます。
「アクセス・ポリシーの作成」をクリックして、アクセス・ポリシーの作成ページを開きます。
アクセス・ポリシー名や説明など、アスタリスク(*)で示されている必須フィールドに情報を入力します。
|
注意: 次の特殊文字はアクセス・ポリシー名で使用できません。セミコロン(;) ハッシュ(#) パーセンテージ(%) 等しい(=) バー(|) プラス(+) カンマ(,) スラッシュ(/) 円記号(¥) 一重引用符(') 二重引用符(") 小なり記号(<) 大なり記号(>) |
「ポリシー所有者」リストから、ポリシー・タイプとして「USER」または「ROLE」を選択します。選択内容に基づいて、参照アイコンをクリックし、ポリシー所有者としてユーザーまたはロールを選択します。
ポリシー所有者タイプを選択しない場合、アクセス・ポリシーは、デフォルトのポリシー所有者タイプがUSERとして、ポリシー所有者がログイン・ユーザーとして作成されます。
ポリシー所有者タイプを選択するが、ポリシー所有者値(USERまたはROLE)を選択せずに、「続行」をクリックすると、検証エラーが表示され、次の画面に進めなくなります。
アクセス・ポリシーの作成時に更新するようにするには、「アクセス・ポリシーの更新」を選択します。
「アクセス・ポリシーの更新」オプションを選択した場合、アクセス・ポリシーは、このアクセス・ポリシーが関連付けられたすべてのロールに適用されます。ロールへのアクセス・ポリシーの割当ての詳細は、『Oracle Identity Managerでのセルフ・サービス・タスクの実行』の「アクセス・ポリシー」タブに関する項を参照してください。
このオプションを選択しない場合、既存のロール・メンバーシップは考慮されません。
「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ2: リソースの選択(プロビジョニング)」ページが表示されます。
このアクセス・ポリシーに対してプロビジョニングするリソースを指定します。
フィルタ検索のメニューを使用してリソースを検索します。
結果表からリソース名を選択して、「追加」をクリックします。
プロビジョニングする目的のリソースの名前が「選択済」リストに表示されます。リソースを拒否するだけのアクセス・ポリシーを作成する場合は、リソースを選択しないで「続行」をクリックします。
選択されているリソースの割当てを解除するには、「選択済」リストでリソースを選択し、「削除」をクリックします。
「続行」をクリックします。
このリソースに関連付けられたフォームがある場合は、後続のページに必須フィールドが表示されます。選択したリソースごとにプロセスの詳細を入力します。このitresフィールドは必須フィールドであるため、ITリソースの値を指定する必要があります。ITリソースが移入されていない場合、次のエラー・メッセージが表示されます。
Either values for some required fields are missing or a value for a required field is invalid.
フォーム・フィールドを編集しない場合は、「このステップをスキップ」をクリックします。「アクセス・ポリシーの作成 - ステップ2: 失効または無効化の選択フラグ」ページが表示されます。
|
注意: パスワードおよび暗号化された属性に対しては、ポリシーのデフォルトを指定しないことをお薦めします。 |
ページにリストされているリソースごとに、次のいずれかのオプションを選択します。
適用しなくなった場合は失効: このオプションを選択すると、アクセス・ポリシーが適用されなくなった場合に、そのアクセス・ポリシーに関連付けられているアカウントと権限が失効されます。
適用しなくなった場合は無効化: このオプションを選択すると、アクセス・ポリシーが適用されなくなった場合に、そのアクセス・ポリシーに関連付けられているアカウントと権限が無効化されます。
アクセス・ポリシーが適用されなくなった場合にアカウントおよび権限を失効または無効化することの詳細は、「ポリシーの失効または無効化」および「ポリシーの評価」を参照してください。
「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ3: リソースの選択(拒否)」ページが表示されます。
このページを使用して、このアクセス・ポリシーにより拒否されるリソースを選択します。
拒否されるリソースを選択するには、次の手順を実行します。
結果表からリソースを選択します。
「選択済」リストにリソースを移動するには、「追加」をクリックします。
プロビジョニングするリソースを選択しなかった場合は、拒否するリソースを少なくとも1つ選択する必要があります。プロビジョニングするものと同じリソースを拒否対象に選択すると、プロビジョニングするリソースとしての割当ては解除されます。
同様に、ステップaで、すでに拒否するように選択したものと同じリソースをプロビジョニング対象に割り当てると、拒否対象に選択されたリソースから自動的に削除されます。拒否対象として選択済のリソースを削除できます。これは、「選択済」リストから削除するリソースを選択し、「削除」をクリックして実行します。
「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ5: アクセス・ポリシー情報の検証」ページが表示されます。
この手順のこれより前のステップで選択した内容を変更する場合は、「変更」をクリックして、ウィザードの対応するページに移動します。必要な変更が終了したら、「続行」をクリックして、「ステップ5: アクセス・ポリシー情報の検証」ページに戻ります。
|
注意: 「ポリシー所有者タイプ」および「ポリシー所有者」フィールドが表示されるのは、手順5で説明しているように、これらのフィールドが指定されている場合のみです。 |
「アクセス・ポリシーの作成」をクリックして、アクセス・ポリシーを作成します。
|
注意: プロセス・フォームに「パスワード」フィールドが含まれているリソースにアクセス・ポリシーを作成した場合、パスワード・ポリシーは評価されません。パスワード・ポリシーの詳細は、次を参照してください。 |
Oracle Identity System Administrationを使用すると、既存のアクセス・ポリシーの情報を変更できます。
アクセス・ポリシーを管理するには、次の手順を実行します。
Identity System Administrationの「ポリシー」で、「アクセス・ポリシー」をクリックします。
「アクセス・ポリシーの管理」ページが表示されます。
検索基準フィールドのメニューを使用して、アクセス・ポリシー属性を選択します。アスタリスク(*)ワイルドカード文字を使用すると、選択した属性に任意の値を持つすべてのアクセス・ポリシー・インスタンスを検索できます。「アクセス・ポリシーの検索」をクリックします。
「アクセス・ポリシーの管理」ページに検索結果が表示されます。
目的のアクセス・ポリシーの詳細を表示するには、アクセス・ポリシー名をクリックします。
「アクセス・ポリシー詳細」ページが表示されます。このアクセス・ポリシーを変更するには、各選択カテゴリの末尾にある「変更」リンクを使用します。必要な変更が終了したら、「アクセス・ポリシーの更新」をクリックし、変更を保存します。
「ポリシー所有者タイプ」および「ポリシー所有者」フィールドが表示されるのは、アクセス・ポリシーの作成時にこれらのフィールドが指定されている場合のみです。「ポリシー所有者タイプ」および「ポリシー所有者」フィールドの値は両方とも変更できます。「ポリシー所有者タイプ」の値をUSERまたはROLEから「ポリシー所有者タイプの選択」に変更すると、既存のポリシー所有者タイプおよびポリシー所有者が保持されます。
|
注意:
|
選択カテゴリに必要な変更が完了したら、「終了」をクリックします。
|
関連項目: ロールへのアクセス・ポリシーの追加、およびロールに割り当てられたアクセス・ポリシーの削除の詳細は、『Oracle Identity Managerでのセルフ・サービス・タスクの実行』の「アクセス・ポリシー」タブに関する項を参照してください。 |
アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニングの内容は、次のとおりです。
デフォルトでは、Oracle Identity Managerで複数アカウント・プロビジョニングはサポートされていません。複数アカウント・プロビジョニングを有効化する手順は、次のとおりです。
XL.AllowAPBasedMultipleAccountProvisioningシステム・プロパティの値をTRUEに設定します。このシステム・プロパティの詳細は、「Oracle Identity Managerのシステム・プロパティ」を参照してください。システム・プロパティの値の設定に関する詳細は、「システム・プロパティの作成と管理」を参照してください。
複数アカウント・プロビジョニングが有効化されている場合は、適切なアカウント識別子属性を定義する必要があります。これを行うには、次のようにします。
Design Consoleにログインします。
プロセス・フォームを次のように更新します。
「開発ツール」を開き、「フォーム・デザイナ」をダブルクリックします。
プロセス・フォームを検索して開きます。
「フォーム・デザイナ」タブで、「新しいバージョンの作成」をクリックします。
「新しいバージョンの作成」ダイアログ・ボックスで、「ラベル」フィールドにラベルを入力して「保存」をクリックします。
「現行のバージョン」リストから、作成したバージョンを選択します。
「プロパティ」タブで、識別子フィールドとして指定するフィールドを選択して「プロパティの追加」をクリックします。
「プロパティの追加」ダイアログ・ボックスで、プロパティ名として「アカウント識別子」を選択し、「プロパティ値」フィールドにTrueと入力して「保存」をクリックします。
「バージョンをアクティブにする」をクリックし、「OK」をクリックします。
「保存」をクリックします。
アクセス・ポリシーを介して、単一ターゲット・システム上に同じユーザーおよび同じリソースに対する2つの異なるアカウントを作成できます。たとえば、単一のADインスタンス上に、ユーザー・アカウントとサービス・アカウントの2つのアカウントを作成する必要があるとします。Active Directoryターゲット・システムは、Oracle Identity ManagerではADユーザー・リソースで表されます。これは、次の方法で実装されます。
ADユーザー・リソースを作成します。
JohnDなどのユーザーを作成します。
プロセス・フォームで、UD_ADUSER_ORGNAMEに識別子フィールドのマークを付けて、2つの異なるアカウントに別々のログインIDが設定されるようにします。
2つのアクセス・ポリシーを次のように作成します。
標準アカウント用
アクセス・ポリシー名: AP1
関連付けられるロール: Role1
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ユーザーID (UD_ADUSER_ORGNAME)
アクセス・ポリシーのデフォルト値: Account1
サービス・アカウント用
アクセス・ポリシー名: AP2
関連付けられるロール: Role2
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ユーザーID (UD_ADUSER_ORGNAME)
アクセス・ポリシーのデフォルト値: Account2
|
注意: 「ユーザーID」に対する値を生成するためにプロセス・フォームと関連付ける事前移入アダプタを作成して、このフィールドに一意の値が生成されるようにする必要があります。 |
Role1とRole2をJohnDに割り当てます。ロールの割当てが完了してすぐにプロビジョニングされたリソースが表示されるわけではないことに注意してください。「ユーザー・ポリシーの評価」スケジュール済タスクが自動的に実行されるのを待つか、このスケジュール済タスクを手動で実行する必要があります。
Role1がJohnDに割り当てられると、AP1アクセス・ポリシーを介して、Account1アカウントがADユーザー・ターゲット・システムに作成されます。Role2がJohnDに割り当てられると、AP2を介して、Account2アカウントがADユーザーに作成されます。この結果、アクセス・ポリシーを介して、単一ターゲット・システム上に同じユーザーおよび同じリソースに対する2つの異なるアカウントを作成できます。
次に、アクセス・ポリシーを介して、リソース・オブジェクトの複数インスタンスを複数ターゲット・システムにプロビジョニングする手順の概要を示します。
Oracle Identity Manager Design Consoleで、「ITリソース・タイプ定義」フォームを使用して、ITリソース・タイプを作成します。このフォームの使用の詳細は、『Oracle Identity Managerのためのアプリケーションの開発とカスタマイズ』のITリソース・タイプ定義フォームに関する項を参照してください。
ステップ1で作成したITリソース・タイプのITリソース・インスタンスを複数作成します。ITリソースの作成の詳細は、「ITリソースの作成」を参照してください。
ここで、ITリソース・インスタンスはアカウント識別子です。アカウント識別子の詳細は、「アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング」を参照してください。
|
注意: ITResourceのプロセス・フォーム・デフォルトを表示します。表示は必須です。このようにすることで、アクセス・ポリシーを介してアプリケーション・インスタンスを正常にプロビジョニングできます。 |
ステップ1で作成したタイプのフィールドを含むプロセス・フォームを作成します。
リソース・オブジェクトを作成します。
プロセス定義を作成し、リソース・オブジェクトとプロセス・フォームを関連付けます。プロセス定義の作成の詳細は、『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_SERVER)プロセス・フォーム・フィールドに、識別子フィールドのマークを付けます。
2つのアクセス・ポリシーを次のように作成します。
ADServer1で作成されるアカウント用
アクセス・ポリシー名: AP3
関連付けられるロール: Role3
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ADサーバー(UD_ADUSER_SERVER)
ITResourceLookupフィールドのデフォルト値: ADServer1
ADServer2で作成されるアカウント用
アクセス・ポリシー名: AP4
関連付けられるロール: Role4
プロビジョニングするリソース: ADユーザー
識別子フィールドを設定するプロセス・フォーム: ADサーバー(UD_ADUSER_SERVER)
ITResourceLookupフィールドのデフォルト値: ADServer2
Role3とRole4をユーザーJohnDに割り当てます。
Role3がJohnDに割り当てられると、AP3アクセス・ポリシーを介して、アカウントがADServer1上のターゲット・システムに作成されます。Role4がJohnDに割り当てられると、AP4アクセス・ポリシーを介して、アカウントがADServer2上のターゲット・システムに作成されます。この結果、アクセス・ポリシーを介して、ターゲット・システムの2つの異なるインスタンス上に、同じユーザーおよび同じリソースに対する2つの異なるアカウントが作成されます。
アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングには、次の制限があります。
単一のアクセス・ポリシーで、リソースの複数インスタンスをユーザーにプロビジョニングすることはできません。リソースの複数インスタンスをプロビジョニングするには、複数のアクセス・ポリシーを作成する必要があります。プロビジョニングする同じリソースのインスタンスと同じ数のアクセス・ポリシーを作成する必要があります。
リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがある場合は、これらのフィールドの値を、そのリソースをプロビジョニングするアクセス・ポリシーで指定する必要があります。そうしないと、次にポリシーが評価されるときに複数のアカウントがプロビジョニングされるなどの問題が発生する場合があります。
リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがあり、アクセス・ポリシー・エンジンを使用してこのリソースを1人以上のユーザーにプロビジョニングする場合、アカウント識別子フィールドの値は、アカウントのライフサイクルを通じて一定のままである必要があります。つまり、アカウント識別子フィールドの値は変更しないでください。これは、アクセス・ポリシー・エンジンで、新しいアカウントをユーザーにプロビジョニングするかどうかを決定するために、リソース・オブジェクト・キーおよびアカウント識別子の値が使用されるためです。
アカウント識別子の値を変更すると、プロビジョニングの決定が行われる基礎を変更することになるため、アクセス・ポリシー・エンジンの動作が不確定になります。したがって、アカウント識別子の値は変更しないことをお薦めします。また、アカウント識別子フィールドのプロセス・フォームの値は変更しないでください。
アクセス・ポリシーが異なるアカウント識別子の値で構成されている場合は、異なるアカウントがユーザーにプロビジョニングされます。
|
注意: 大文字/小文字のみが異なるアカウント識別子の値(例: abcとaBc)も異なる値として処理されます。このデータの場合、2つのアカウントがエンド・ユーザーにプロビジョニングされます。 |
場合によっては、「ユーザー・ポリシーの評価」スケジュール済タスクがトリガーされないことや、ユーザーを処理しない(または少数のユーザーのみを処理する)ことがあります。考えられる原因は次のとおりです。
「ユーザー・ポリシーの評価」スケジュール済タスクは実行されているが、ポリシー評価のマークが付けられたユーザーが存在しない。
ユーザーにはポリシー評価のマークが付けられているが、そのユーザーがアクティブでない。
ポリシー評価は完了したが、プロビジョニング操作が失敗した。
この場合、プロビジョニングに関連するイベント・ハンドラはCANCELLED状態になります。その結果、アカウントまたは権限はユーザーにプロビジョニングされなくなります。
「ユーザー・ポリシーの評価」スケジュール済タスクが、スケジューラに関する問題のためにトリガーされていない。
この場合は、スケジューラの問題を個別にトラブルシューティングする必要があります。
この問題がアクセス・ポリシー、プロビジョニングまたはスケジューラのどれに関連しているかを特定するには、MetaLinkノート1563379.1に記載されている手順を実行してください。
