機械翻訳について

アイデンティティ・オーケストレーション・コンポーネントの確認

アイデンティティ・オーケストレーション・コンポーネントは、多様なシステムを統合し、企業のアイデンティティ・ライフサイクルを効果的に管理するビルディング・ブロックとして機能します。 これには、間接的な統合のためのOracle Access Governanceエージェント、データの一貫性を確保するためのインバウンドおよびアウトバウンドのデータ変換ルール、コンポジット・プロファイルを構築するための相関ルール、およびデータのロードに使用されるリソースと制御ソースを効果的に管理するためのオーケストレーションされたシステム・リソースが含まれます。

Access Governanceエージェント

Oracle Access Governanceエージェントは、ダウンロード可能なdockerイメージです。これにより、Oracle Access Governanceは、直接接続が使用できない認可ソースまたは管理対象システムと継続的または定期的に同期できます。

エージェントは、スケジュールされた分散抽出-変換-ロード(ETL)ジョブを実行して、ユーザー、ロール、アプリケーション・インスタンス、エンタイトルメント、エンタイトルメントの割当てなどのリモート・アイデンティティ・データをOracle Access Governanceに完全または増分的に同期します。 登録してインストールすると、エージェントをOracle Access Governanceコンソールでモニターできます。 エージェントは、ローカル(顧客)環境にあるdocker環境で実行されます。 この環境は次の前提条件を満たしている必要があります:

• DockerまたはPodmanのインストール
• 顧客のターゲット・アイデンティティ・データベースへの接続が可能
• Oracle Cloudでホストされている顧客のOracle Access Governanceインスタンスへの接続が可能。 必要に応じて、この接続はwebプロキシを介して行うことができます。

エージェントはデータを抽出し、Oracle Access Governance取込みサービスによって取得され、Oracle Access Governanceにロードされて消費されます。

履行リクエスト(アカウントのプロビジョニングまたはクローズド・ループ・アクセス修正)が管理対象システムに渡されます。 たとえば、アクセス・レビュー・キャンペーンの完了時に、Oracle Access Governanceで取り消された権限は、オーケストレーションされたシステムで取消し操作を発生させることで修正されます。 この取消しリクエストは、エージェントを介して管理対象システムに渡されます。

ノート:

エージェントは、Oracle Access Governanceで直接接続を確立できない場合にのみ適用できます。 通常、オンプレミス・システムと統合する場合はエージェントが必要です。 Oracle Access Governanceエージェントは、認可ソースまたは管理対象システムおよびOracle Access Governanceの同期をサポートするアービトレータとして機能します。

データ変換

異なるシステムはデータを異なる方法で表します。 Oracle Access Governanceを使用すると、認可ソース・システムまたは管理対象システムからの受信アイデンティティ・データおよびアカウント・データ、または管理対象システムにプロビジョニングされる送信データを操作および変換できます。 導出値を含めたり、フォーマットの一貫性を確保するなど、要件を満たすようにデータ値を変更できます。 これにより、データの一貫性とシステムの統合が保証されます。

データ変換は次のものに適用できます:

• インバウンド変換ルールを使用して、認可ソースからOracle Access Governanceに取り込まれる受信アイデンティティ属性を強化します。 たとえば、ユーザー名を大文字に設定したり、姓を名前と連結して表示名を作成できます。
• インバウンド変換ルールを使用して、管理対象システムからOracle Access Governanceに取り込まれる受信アカウント属性を強化します。 たとえば、ユーザー名をデフォルト・ドメインと連結して、Oracle Access Governance内にプライマリ電子メールを設定できます。
• 受信属性を照合できるように、Oracle Access Governanceで構築されたコンポジット・アイデンティティ属性をカスタマイズします。 たとえば、データベース・ユーザー管理アプリケーションでは、ユーザー名が特定の形式で格納され、アカウント・データのみが含まれるため、受信DBUMユーザー名がOracle Access Governanceで使用可能なアイデンティティ属性と一致するように、Oracle Access Governanceのコンポジット・アイデンティティ属性をカスタマイズする必要があります。
• Oracle Access Governanceによる管理対象システムへのアカウント・プロビジョニングのアイデンティティ属性を強化して、アカウント属性を定義します。 たとえば、NULL値がある場合、jobDescriptionを固定値に設定します。

変換タイプとそのワークフロー

Oracle Access Governanceで使用可能な変換のタイプとそのワークフローを見てみましょう:

• まず、オーケストレーション・システムを追加して、認可ソースをOracle Access Governanceと統合します。 ここでは、データ取込みプロセス中に、ソース・アイデンティティ属性データに対してインバウンド変換を実行できます。 たとえば、Oracle HCMを認可ソースとして統合し、インバウンド変換を適用してフルネームから表示名を作成できます。 これらの変換は、各オーケストレーション・システムに固有のものです。
• 認可ソース・システムを内部的に統合すると、Oracle Access Governance内に「コア」および「カスタム」属性を含むコンポジット・アイデンティティ・プロファイルが作成されます。 このコンポジット・アイデンティティ・プロファイルには、統合した様々な認可ソースからのアイデンティティ属性を含めることができます。 たとえば、Oracle Access Governanceのアイデンティティには、Oracle HCMから取り込まれた属性jobCodeおよびフラット・ファイルから取り込まれたdepartmentを含めることができます。 複数の認可ソースで同じ属性が使用可能なシナリオでは、この属性値を取得するオーケストレーション・システムを選択して変更するオプションがあります。 詳細は、「アイデンティティ属性の管理」を参照してください。 このコンポジット・アイデンティティ・プロファイルは、Oracle Access Governanceが様々なガバナンスおよびプロビジョニング操作を実行するための信頼できるソースとして機能します。
• 次に、管理対象システムを統合してアカウント属性をロードします。 これらのアカウント属性は、Oracle Access Governance内で使用可能なコンポジット・アイデンティティ属性と照合されます。
• アウトバウンド・プロビジョニングの場合、管理対象システムへの正確なアカウント・プロビジョニングのために、Oracle Access Governanceで使用可能なコンポジット・アイデンティティ属性を操作します。

インバウンド・データ変換

インバウンド・データ変換では、属性値がオーケストレーションされたシステムからOracle Access Governanceに受信されたときにどのように変換されるかを制御できます。 オーケストレーション・システムからデータをロードすると、アイデンティティ属性およびアカウント属性がOracle Access Governanceにインポートされます。 データ・ロードまたはデータ取込みプロセス中に、データ変換を属性に適用できます。

ユース・ケースの例には、次のものがあります:

• FirstName、.、LastName、@mydomain.comを連結して、Oracle Access GovernanceのprimaryEmailアイデンティティ属性を移入します。 これは、Oracle Access Governanceでこれを実現する方法です。

  user.getFullName().getGivenName().concat('.',user.getFullName().getFamilyName())+'mydomain.com'

• オーケストレーションされたシステムからの値がnullの場合、属性の値を別の値に設定します。 たとえば、組織がnullの場合、Oracle Access Governanceの値を固定値に設定します。

  user.getOrganization() != null && user.getOrganization().getDisplayName() != null ?
        user.getOrganization().getDisplayName() : 'Oracle Access Governance'

アウトバウンド・データ変換

アイデンティティ・オーケストレーションには、「アクセスのリクエスト」 (セルフ・サービス)、「アクセスのリクエスト」 (その他)、またはpolicyベースのアクセス機能を使用してアカウントをプロビジョニングする機能が含まれます。 このプロセスの一環として、管理対象システム・アカウントにプロビジョニングされたデータにデータ変換を適用できます。 「パスワードの変更」や「アカウントの作成」などのプロビジョニング操作がOracle Access Governanceでトリガーされると、アイデンティティ・データから値を導出し、文字列やその他の操作を使用してデータを変換するデータ変換ルールを起動して、アカウントのプロビジョニングが正しいアイデンティティに対して管理対象システムに行われるようにできます。

ユース・ケースの例には、次のものがあります:

• プロビジョニングされた管理対象システムのworkEmail属性に、アイデンティティのprimaryEmail属性値を移入します。
• アイデンティティtitle、userNameおよびemployeeNumberを連結して、プロビジョニングされた管理対象システムにdisplayName属性の値を作成します。
• アイデンティティ入力値がnullの場合、属性の値を別の値に設定します。 たとえば、organizationがnullの場合は、プロビジョニングされた管理対象システム・アカウントで値を固定値に設定します。

アイデンティティ属性: 変換ルールの適用によるコンポジットOracle Access Governanceアイデンティティ・プロファイルのカスタマイズ

様々な認可ソースからアイデンティティ属性をロードすると、様々なソースからのアイデンティティ属性を含むコンポジット・アイデンティティ・プロファイルがOracle Access Governanceに構築されます。 管理対象システムからアカウント属性をロードすると、このコンポジット・アイデンティティ・プロファイルで使用可能な値がアカウント属性(アイデンティティ・アカウント照合)と一致します。 特殊な状況では、様々なシステムからの受信データを照合できるように、このコンポジット・アイデンティティ・プロファイルに追加の変換ルールを適用する必要がある場合があります。 通常、このタイプの変換では、管理対象システムから受信するアカウント属性と一致するように、Oracle Access Governance内のアイデンティティ属性をカスタマイズする必要があります。

ノート:

インバウンド変換はオーケストレーション・システムに固有であり、アイデンティティ属性のカスタマイズはOracle Access Governanceで構築されたコンポジット・アイデンティティ・プロファイルに適用されます。 たとえば、Oracle HCMから取り込まれたJobCodeにインバウンド変換を適用したが、「アイデンティティの管理」ページでこの属性のソースとして「フラット・ファイル」を選択した場合、この変換はOracle Access Governanceで使用可能な値には影響しません。

シナリオ

たとえば、データベース・ユーザー管理(DBUM)は、Oracle Access Governance内のコンポジット・アイデンティティ・プロファイルで使用可能なユーザー名とは異なる、非常に特定の形式でのユーザー名などの属性を格納できます。 DBUMアカウントをOracle Access Governanceに存在するアイデンティティと照合するには、変換ルールを適用してアイデンティティ属性をカスタマイズする必要があります。 DBUMは管理対象システム・アカウントであるため、インバウンド変換ルールを適用してアイデンティティ・データを操作することはできません。 そこで、コンポジット・アイデンティティ属性をカスタマイズする必要があります。 たとえば、MySQL DBUMを接続すると、Oracle Access Governanceによって、適用可能な変換ルールを含む内部アイデンティティ属性userNameMysqlが追加されます。 次に、My SQL DBUMから受信したユーザー名をuserNameMysqlアイデンティティ属性と照合できます。 勘定科目のプロビジョニングが正確に実行されるように、アウトバウンド変換側にも同じルールが適用されます。

認可ソース	コンポジット・アイデンティティ属性	管理対象システム
アイデンティティ属性: username 値: [e-mail]	アイデンティティ属性: username 値: [e-mail]	アカウント属性: userLogin 値: [e-mail]
	内部アイデンティティ属性: userNameMysql 値: [e-mail]

アイデンティティ属性usernameの値がアカウント属性userLoginと異なるため、これらの属性を一致させることはできません。 コンポジット・アイデンティティ属性の変換により、[e-mail]が[e-mail]に変換され、Oracle Access Governance内に作成されたuserNameMysqlに格納されます。 これが完了すると、受信値[e-mail]が一致します。

ノート:

ベスト・プラクティスとして、インバウンド変換を使用してアイデンティティ属性を変換し、コンポジット・アイデンティティ・プロファイルに変換ルールを適用する使用を制限することをお薦めします。 アカウントのプロビジョニングを妨げる可能性があります。

口座属性

Oracle Access Governanceのアカウント属性を使用すると、管理者は、「オーケストレーション・システム」でサポートされているデフォルトのアカウント属性以外のアカウント属性を構成できます。 勘定科目属性の値は、「管理対象システム」からグローバル・キー値参照ファイルからソーシングするか、アクセス・バンドルの作成時に定義できます。

「オーケストレーション・システム」を構成すると、ソースとして使用している特定のターゲット・システムに定義されているアカウントの詳細を提供する属性のデフォルト・セットが含まれます。 場合によっては、ターゲット・システムに存在するがデフォルトで公開されていない追加の属性を統合に含める必要があることがあります。 ここで、アカウント属性を入力します。

アカウント属性を使用すると、「管理対象システム」からリコンサイルできる「オーケストレーション・システム」の追加属性を構成したり、ユーザーがアクセス・バンドルをリクエストしたときに渡される値として指定できます。 Oracle Access Governanceは、次のアカウント属性機能をサポートします:

• ユーザーは、指定した「オーケストレーション・システム」のアカウント属性を表示できます。 ユーザーは、「オーケストレーション・システム」初期化の一部として作成されたデフォルト属性と、ユーザーが作成したアカウント属性を表示できます。
• ユーザーは、「オーケストレーション・システム」定義でアカウント属性を作成できます。
• ユーザーは、「オーケストレーション・システム」定義のアカウント属性を編集できます。
• ユーザーは、「オーケストレーション・システム」定義のアカウント属性を削除できます。
• 勘定科目属性は、単純データ型と複合データ型の両方をサポートします。
• アカウント属性は、インバウンド変換とアウトバウンド変換の両方で使用できます。
• アカウント属性は、「管理対象システム」モードで構成された「オーケストレーション・システム」でサポートされています。
• 次の勘定科目属性はサポートされていません:
  • Oracle Cloud Infrastructure (OCI) 「オーケストレーション・システム」。
  • Oracle Identity Governance 「オーケストレーション・システム」。
  • 「権威のあるソース」モードで構成された「オーケストレーション・システム」。
• ユーザー作成アカウント属性は、次のものには使用できません:
  • データベース・アプリケーション表「オーケストレーション・システム」。
  • 汎用REST 「オーケストレーション・システム」。

いくつかの簡単なユースケースを見てみましょう:

ユースケース: アクセス・バンドル定義を使用したアカウント属性の追加

図形 - アカウント属性の追加

このユースケースでは、管理者が、「管理対象システム」の「説明」属性をマップし、バンドルにアクセスするための値ソースが設定されているアカウント属性を作成しました。 また、アカウント属性を含むアクセス・バンドルも定義されています。 ユーザーがアクセス・バンドルをリクエストすると、「説明」の値の入力を求められます。 アクセス・バンドル・リクエストが承認されると、アカウントは「管理対象システム」にプロビジョニングされます。 ユーザーが入力した「説明」属性の値は、アウトバウンド変換の対象となる場合とそうでない場合があります。 最後に、「説明」の値は、ユーザー用に作成されたアカウントの一部としてプロビジョニングされます。

ユースケース: アカウント属性でのアイデンティティ属性更新を反映

図形 - アイデンティティ属性の更新

このユースケースでは、管理者がアカウント属性postalCodeを作成し、「管理対象システム」にマップされるとともに、アイデンティティ属性「ロケーション」にも関連付けられています。 ユーザーAliceのアイデンティティがOracle Access Governanceにあるとします。 Aliceのアイデンティティは、Oracle HCMなどの「権威のあるソース」から導出されます。 Aliceは出社し、Oracle HCMの「事業所」値に変更を加えました。 次のデータ・ロード時に、この更新は、Aliceのidentity:Location属性が更新されるOracle Access Governanceに反映されます。 アカウント属性では、この変更によってアカウントの更新アクティビティもトリガーされ、account:postalCodeの値がidentity:Locationのコンテンツで更新されます。 このようにして、アカウント属性を「権威のあるソース」から導出された値と同期できます。

アカウント・プロファイル - アクセス・バンドル生成の再利用可能なテンプレート

Oracle Access Governanceのアカウント・プロファイルは、アカウント属性のデフォルト値を事前に定義して格納することで、管理対象システムでの新しいユーザー・アカウントの作成を標準化および簡素化する再利用可能なテンプレートとして機能します。 これにより、ユーザーのプロビジョニングが合理化され、データの一貫性が確保され、手作業が削減されます。

Oracle Access Governanceのアカウント・プロファイルの概要

Oracle Access Governanceから管理対象システムに新しいユーザー・アカウントをプロビジョニングする場合は、いくつかの必須情報または共通属性を渡す必要があります。 「アカウント・プロファイル」はブループリントとして機能し、管理対象システムに必要な共通属性のデフォルト値を1回定義できます。

これにより、プロビジョニングの一貫性が確保され、各アクセス・バンドルに頻繁にアカウント詳細を手動で入力する必要がなくなり、権限管理が簡素化されます。

アカウント・プロファイルの定義時に、デフォルト値を指定するか、セルフサービス・リクエスト時に値を指定するよう依頼者に依頼するかを選択できます。

アカウント・プロファイルをアクセス・バンドルにリンクすると、Oracle Access Governanceによって、ユーザー・プロビジョニング時に必要なデフォルト情報がシームレスに入力され、正確で一貫性のあるデータを使用して新しいアカウントが正常に作成されます。

アカウント・プロファイルは、単一のアクセス・バンドルに固有ではないため、複数のアクセス・バンドルにリンクできます。

ノート:

1つのアクセス・バンドルに割り当てることができるアカウント・プロファイルは1つのみです。

取引先プロファイルの主な機能

主要な機能を調べることで、アカウント・プロファイルの機能を確認します。

• 修正承認: アカウント・プロファイルがアクセス・バンドルにリンクされている場合、アカウント・プロファイルの削除を防止し、データの一貫性と参照整合性を維持します。
• 集中更新: アカウント・プロファイル属性値を更新すると、その変更が関連するすべてのアクセス・バンドルに伝播されます。 これにより、アカウント属性値が更新された影響を受けるユーザーのプロビジョニング・リクエストがトリガーされます。 これにより、個々のアクセス・バンドルを更新する手作業がなくなります。
• 再利用可能なテンプレート: 異なるアクセス・バンドル間で簡単に再利用できる属性のバンドル・スナップショットとして機能し、冗長構成を排除します。

一致規則

Oracle Access Governanceは、相関ルールまたは照合ルールを利用して、異なる認可ソースから収集されたアイデンティティ・データを照合し、コンポジット・アイデンティティ・プロファイルを作成します。 同様に、管理対象システムからのデータ取込み中に、1つのアイデンティティに対して複数のアカウントが存在する場合があります。 この場合、アカウント・データを収集し、それぞれのアイデンティティと照合する必要があります。 アカウント照合ルールを利用して、ダウンストリーム・アプリケーションから取り込まれたユーザー・アカウントをOracle Access Governanceのアイデンティティに関連付けることができます。 Oracle Access Governance内で認可ソースと管理対象システムの両方として機能するシステムがある場合、同じシステムに対してアイデンティティ照合とアカウント照合を実装できます。

アイデンティティおよびアカウント属性を使用して、これらの相関ルールをOracle Access Governanceに簡単に作成できます。 アカウントをアイデンティティと自動的に照合できない場合、Oracle Access Governanceは、この不一致アカウントに対してマイクロ認証を作成し、アイデンティティと手動で照合したり、管理対象システムから修正できるようにします。

照合ルールのタイプ

オーケストレーションされたシステムからデータを受信する場合、Oracle Access Governanceは、データがアイデンティティまたはアカウントとしてすでにオンボーディングされているデータと一致するかどうかを確認します。 Oracle Access Governanceでは、次の照合タイプがサポートされます:

• アイデンティティ照合: この一致は、受信アイデンティティが既存のアイデンティティと一致するか、Oracle Access Governanceの新機能であるかどうかをチェックします。 一致する場合、受信データは既存のアイデンティティと相関します。 一致がない場合は、データがOracle Access Governanceに新しいアイデンティティを作成するために使用されます。
• アカウント照合: この照合では、受信アカウントが既存のアイデンティティと一致するかどうかがチェックされます。 一致がある場合、アカウント情報は一致するアイデンティティと相関します。 一致が見つからない場合、アカウントには不一致のフラグが付けられます。
• 手動照合済アカウント: 不一致アカウントを手動で照合した場合は、これらの下に手動で照合されたアカウントが表示されます。

オーケストレーションされたシステム・リソース

Oracle Access Governanceへのデータのロードに使用されるソースを完全に制御できるように、システムから取り込むリソースを決定できます。 オーケストレーションされたシステムから移入されるリソースを管理できます。 この機能は、Oracle Identity Governanceに固有です。

一般的なユース・ケースは、Oracle Identity Governance (OIG)によって管理されるアイデンティティ・データがあり、クラウド環境に完全に移行するまでのハイブリッド方式でガバナンスが必要な場合です。 デフォルトでは、認可ソースおよび管理対象システムから取り込まれたすべてのリソースがOracle Access Governanceで使用可能になります。 Oracle Access Governanceとシステム間の直接接続を追加するときに、プライマリ・ガバナンス・システムからこれらを削除して、データの重複を回避できます。

たとえば、Oracle Access GovernanceのOIGオーケストレーション・システムを使用して、Oracle Unified Directory (OUD)からアイデンティティをオンボーディングしたとします。 OIGからではなく、OUDアイデンティティを直接移行するには、Oracle Access GovernanceでOUDシステムとの直接統合を確立します。 この直接構成をテストおよび実装したら、Oracle Identity Governanceオーケストレーション・システムでOracle Unified Directoryリソースを無効にできます。 Oracle Identity Governance Orchestratedシステムで有効な残りのリソースは、通常どおり続行されます。

オーケストレート済システムの仮想システムの理解

仮想システムにより、単一のオーケストレートされた統合により、複数の関連アプリケーションまたはドメインを論理サブシステムとして表現および管理できます。 これは、企業で複数のドメインまたはサブシステムを管理する必要があり、それぞれ異なるデータを使用して同じ構造スキーマを共有している場合に役立ちます。

仮想システムでは、ドメインごとに個別のオーケストレート済システムを作成および管理するかわりに、次のことを実行できます。

• 複数のアプリケーションを単一のオーケストレーション・システムでグループ化します。
• マッピングに従って、アプリケーションごとにデータ・ファイルを格納および処理します。
• アクセス制御機能のプロビジョニングのために、これらのアプリケーションを個別に管理します。

適用対象: フラット・ファイル

例

企業が3つのADドメイン(「アルファ」、「ベータ」および「ガンマ」)を統合するとします。 仮想システムがない場合、それぞれに別々のオーケストレーションされたシステムが必要になります。

仮想システムを使用

1. 単一のオーケストレート済システム(Flatfile-MultiApp-01など)を構成し、仮想システムを有効にします。
2. IDおよび名前のCSVをアップロードします。

   ID	名前
   virtual_ad_123	Alpha
   virtual_ad_456	ベータ
   virtual_ad_789	GAMMA

3. 統合が成功したら、バケット構造を参照してください。

   inbox/
   	IDENTITY/
   		virtual_ad_123
   		virtual_ad_456
   		virtual_ad_789
   	PERMISSION/
   		virtual_ad_123
   		virtual_ad_456
   		virtual_ad_789
   	TARGETACCOUNT/
   		virtual_ad_123
   		virtual_ad_456
   		virtual_ad_789

   ノート:

   virtual_ad_123、virtual_ad_456などのサブ・フォルダは、仮想システムが有効になっている場合にのみ作成されます。
4. 構成後のステップを実行して、各フォルダにデータファイルを追加します。 オーケストレートされたシステムのスキーマ拡張はすべて、すべての仮想システムに適用されます。 詳細は、「フラット・ファイルとの統合- 構成後」を参照してください。

---

タイトルおよび著作権情報

Copyright ©2024,2025,

Oracle and/or its affiliates.

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。 詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。