アイデンティティ・オーケストレーション・コンポーネント
アイデンティティ・オーケストレーション・コンポーネントは、多様なシステムを統合し、企業のアイデンティティ・ライフサイクルを効果的に管理するビルディング・ブロックとして機能します。これには、間接統合用のOracle Access Governanceエージェント、データの一貫性を確保するためのインバウンドおよびアウトバウンドのデータ変換ルール、コンポジット・プロファイルを作成するための相関ルール、データのロードに使用されるリソースを効果的に管理し、ソースを制御するための編成済システム・リソースが含まれます。
ガバナンス・エージェントへのアクセス
Oracle Access Governanceエージェントはdockerイメージで、これによってOracle Access Governanceは直接接続が使用できない認可ソースまたは管理対象システムと継続的または定期的に同期することができます。
エージェントは、スケジュールされた分散抽出-変換-ロード(ETL)ジョブを実行して、ユーザー、ロール、アプリケーション・インスタンス、エンタイトルメント、エンタイトルメントの割当てなどのリモート・アイデンティティ・データをOracle Access Governanceに完全または増分的に同期します。登録してインストールすると、エージェントをOracle Access Governanceコンソールでモニターできます。エージェントは、ローカル(顧客)環境にあるドック環境で実行されます。この環境は次の前提条件を満たしている必要があります:
- 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では、認証ソースまたはマネージド・システムからの受信IDおよびアカウント・データ、またはマネージド・システムにプロビジョニングされる送信データを操作および変換できます。データ値は、導出値を含めるか、書式設定の一貫性を確保するなど、要件を満たすように変更できます。これにより、データの一貫性とシステム統合が保証されます。
- インバウンド変換ルールを使用して、認可ソースからOracle Access Governanceに収集される受信アイデンティティ属性を強化します。たとえば、ユーザー名を大文字に設定したり、ファミリ名を名前と連結して表示名を作成できます。
- インバウンド変換ルールを使用して、管理対象システムからOracle Access Governanceに収集される受信アカウント属性を強化します。たとえば、ユーザー名をデフォルト・ドメインと連結して、Oracle Access Governance内のプライマリ電子メールを設定できます。
- Oracle Access Governanceに組み込まれたコンポジット・アイデンティティ属性をカスタマイズして、受信属性を照合できるようにします。たとえば、データベース・ユーザー管理アプリケーションはユーザー名を特定の形式で格納し、アカウント・データのみが含まれるため、Oracle Access Governanceのコンポジット・アイデンティティ属性をカスタマイズして、受信DBUMユーザー名がOracle Access Governanceで使用可能なアイデンティティ属性と一致するようにする必要があります。
- Oracle Access Governanceによる管理対象システムへのアカウント・プロビジョニングのアイデンティティ属性を強化することで、アカウント属性を定義します。たとえば、NULL値がある場合、jobDescriptionを固定値に設定します。
変換タイプとそのワークフロー
Oracle Access Governanceで使用可能な変換のタイプとそのワークフローを見てみましょう:
- 最初に、Orchestratedシステムを追加して、Authoritative Sourceを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'
アウトバウンド・データの変換
アイデンティティ・オーケストレーションには、アクセスのリクエスト(セルフ・サービス)、アクセスのリクエスト(他のユーザー用)、またはポリシー・ベースのアクセス機能を使用してアカウントをプロビジョニングする機能が含まれます。このプロセスの一環として、管理対象システム・アカウントにプロビジョニングされたデータにデータ変換を適用できます。「パスワードのリセット」や「アカウントの作成」などのプロビジョニング操作が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の値がアカウント属性 userLoginと異なるため、これらの属性を一致させることはできません。コンポジット・アイデンティティ属性変換は、John.Doe@o.comをJohn_Doe@o.comに変換し、Oracle Access Governance内に作成されたuserNameMysqlに格納します。これが完了すると、受信値 John_Doe@o.comが一致します。
ベスト・プラクティスとして、インバウンド変換を使用してアイデンティティ属性を変換し、コンポジット・アイデンティティ・プロファイルで変換ルールを適用する使用を制限することをお薦めします。アカウントのプロビジョニングを妨げる可能性があります。
取引先属性
管理者は、Oracle Access Governanceのアカウント属性を使用して、オーケストレートされたシステムでサポートされているデフォルトのアカウント属性を超えて追加のアカウント属性を構成できます。アカウント属性の値は、管理対象システムから、グローバル・キー値参照ファイルから、またはアクセス・バンドルの作成時に定義できます。
オーケストレート済システムを構成すると、ソースとして使用している特定のターゲット・システムに対して定義されているアカウントの詳細を示すデフォルトの属性セットが含まれます。場合によっては、ターゲット・システムに存在するがデフォルトで公開されていない追加の属性を統合に含める必要があります。ここでは、アカウント属性が入ります。
- ユーザーは、指定したオーケストレート済システムのアカウント属性を表示できます。ユーザーは、オーケストレーションされたシステム初期化の一部として作成されたデフォルト属性と、ユーザーが作成したアカウント属性を表示できます。
- ユーザーは、オーケストレート済システム定義でアカウント属性を作成できます。
- ユーザーは、オーケストレート済システム定義のアカウント属性を編集できます。
- ユーザーは、オーケストレート済システム定義のアカウント属性を削除できます。
- 勘定科目属性では、単純データ型と複合データ型の両方がサポートされています。
- 勘定科目属性は、インバウンド変換とアウトバウンド変換の両方で使用できます。
- アカウント属性は、管理対象システム・モードで構成されたオーケストレート済システムに対してサポートされます。
- 勘定科目属性は、次に対してサポートされていません。
- Oracle Cloud Infrastructure(OCI)のオーケストレートされたシステム。
- Oracle Identity Governanceオーケストレート済システム。
- 認可ソース・モードで構成されたオーケストレート済システム。
- ユーザー作成アカウント属性は、次には使用できません。
- データベース・アプリケーション表オーケストレート済システム。
- 汎用RESTオーケストレート済システム。
いくつかの簡単な使用例を見てみましょう。
ユースケース: アクセス・バンドル定義を使用したアカウント属性の追加
このユースケースでは、管理者がアカウント属性を作成し、管理対象システムの「説明」属性をマップし、バンドルにアクセスするための値ソースを設定しています。また、アカウント属性を含むアクセス・バンドルも定義されています。ユーザーがアクセス・バンドルをリクエストすると、「説明」の値を入力するように求められます。アクセス・バンドル・リクエストが承認されると、アカウントは管理対象システムにプロビジョニングされます。ユーザーが入力した「説明」属性の値は、アウトバウンド変換の対象となる場合とされない場合があります。最後に、「説明」の値は、ユーザーに対して作成されたアカウントの一部としてプロビジョニングされます。
ユースケース: アカウント属性でアイデンティティ属性の更新を反映
この場合、管理者はアカウント属性postalCodeを作成し、管理対象システムにマップされるだけでなく、アイデンティティ属性Locationにも関連付けられます。Oracle Access GovernanceのユーザーAliceのアイデンティティがあるとします。Aliceのアイデンティティは、Oracle HCMなどの信頼できるソースから導出されます。Aliceが家を移動すると、Oracle HCMの「場所」の値が変更されます。次のデータ・ロードでは、この更新がOracle Access Governanceに反映され、Aliceのidentity:Location属性が更新されます。アカウント属性では、この変更によってアカウントの更新アクティビティもトリガーされ、account:postalCodeの値がidentity:Locationの内容で更新されます。このようにして、アカウント属性を認可ソースから導出された値と同期できます。
アカウント・プロファイル- アクセス・バンドル生成の再利用可能なテンプレート
Oracle Access Governanceのアカウント・プロファイルは、アカウント属性のデフォルト値を事前に定義および格納することで、管理対象システムでの新規ユーザー・アカウントの作成を標準化および簡素化する再利用可能なテンプレートとして機能します。これにより、ユーザー・プロビジョニングが合理化され、データの一貫性が保証され、手作業が削減されます。
Oracle Access Governanceのアカウント・プロファイル概要
Oracle Access Governanceから管理対象システムに新しいユーザー・アカウントをプロビジョニングする場合は、必須情報または共通属性をいくつか渡す必要があります。アカウント・プロファイルはブループリントとして機能し、管理対象システムに必要な共通属性に対してデフォルト値を1回定義できます。
これにより、プロビジョニングの一貫性が確保され、各アクセス・バンドルにアカウント詳細を頻繁に手動で入力する必要がなくなり、権限管理が簡素化されます。
アカウント・プロファイルの定義時に、デフォルト値を指定するか、セルフサービス要求時に値を指定するように依頼者に依頼するかを選択できます。
アカウント・プロファイルをアクセス・バンドルにリンクすると、Oracle Access Governanceは、ユーザーのプロビジョニング中に必要なデフォルト情報をシームレスに移入し、正確で一貫性のあるデータを使用して新しいアカウントが正常に作成されます。
アカウント・プロファイルは、1つのアカウント・プロファイルに固有ではないため、複数のアクセス・バンドルにリンクできます。
アクセス・バンドルに割り当てることができるのは、1つのアカウント・プロファイルのみです。
アカウント・プロファイルの主な機能
主な機能を調べることで、アカウント・プロファイルの機能を確認します。
- 参照整合性:アカウント・プロファイルがアクセス・バンドルにリンクされている場合、そのアカウント・プロファイルの削除を防止し、データの整合性と参照整合性を維持します。
- 集中更新:アカウント・プロファイル属性値を更新すると、関連するすべてのアクセス・バンドルにその変更が伝播されます。これにより、アカウント属性値が更新された影響を受けるユーザーに対するプロビジョニング・リクエストがトリガーされます。これにより、個々のアクセス・バンドルを更新する手作業が不要になります。
- 再利用可能なテンプレート:異なるアクセス・バンドル間で簡単に再利用でき、冗長な構成を排除できる属性のバンドル・スナップショットとして機能します。
一致ルール
Oracle Access Governanceでは、相関ルール(照合ルール)を利用して、異なる認可ソースから取り込まれたアイデンティティ・データを照合し、コンポジット・アイデンティティ・プロファイルを作成します。同様に、管理対象システムからのデータ取込み中に、アイデンティティに対して複数のアカウントが存在する場合があります。この場合、アカウント・データを取り込んで、それぞれのアイデンティティと照合する必要があります。アカウント照合ルールを利用して、ダウンストリーム・アプリケーションから取り込まれたユーザー・アカウントをOracle Access Governanceのアイデンティティに関連付けることができます。Oracle Access Governance内でAuthoritative SourceとManaged Systemの両方として機能するシステムがある場合、同じシステムに対してアイデンティティ・マッチングとアカウント・マッチングを実装できます。
アイデンティティおよびアカウント属性を使用して、Oracle Access Governanceでこれらの相関ルールを簡単に作成できます。アカウントをアイデンティティと自動的に照合できない場合、Oracle Access Governanceでは、この一致しないアカウントのマイクロ認証が作成され、アイデンティティと手動で照合したり、管理対象システムから修正できます。
一致ルールのタイプ
オーケストレート済システムからデータを受信すると、Oracle Access Governanceでは、データがアイデンティティまたはアカウントとしてすでにオンボードされているデータと一致するかどうかがチェックされます。Oracle Access Governanceでは、次の照合タイプがサポートされています。
- アイデンティティの一致: この一致では、受信アイデンティティが既存のアイデンティティと一致するか、Oracle Access Governanceに新規であるかがチェックされます。一致する場合、受信データは既存のアイデンティティと相関します。一致がない場合は、データがOracle Access Governanceで新しいアイデンティティの作成に使用されます。
- アカウント照合: この照合では、受信アカウントが既存のアイデンティティと一致するかどうかがチェックされます。一致がある場合、アカウント情報は一致するIDと関連付けられます。一致が見つからない場合、取引先には不一致のフラグが付けられます。
照合結果のインサイト
インサイトを使用して、一致した、一致しない、または複数一致のアイデンティティやアカウントを含む、受信アカウントまたはアイデンティティのリストを表示します。
- 一致なし: 受信アイデンティティまたはアカウントが既存のアイデンティティにリンクされていません。手動で正しい識別情報に一致させるか、システムに対して適切な修正アクションを実行します。
- 照合ルール: アイデンティティまたは勘定科目は、構成済の照合ルールに基づいて自動的に照合されます。
- 複数一致: アイデンティティ、レビュー・アカウントまたはアイデンティティに対して複数の一致が見つかり、正しいアイデンティティに手動で一致します。
- Provisioned by AG: アカウントは、Oracle Access Governanceを使用して作成またはプロビジョニングされたために照合されます。アカウントをリンクしない場合は、アカウントのリンクを解除します。
オーケストレーションされたシステム・リソース
Oracle Access Governanceへのデータのロードに使用されるソースを完全に制御できるように、システムから取り込むリソースを決定できます。オーケストレート済システムから移入されるリソースを管理できます。この機能は、Oracle Identity Governanceに固有です。
一般的なユース・ケースとして、Oracle Identity Governance (OIG)によって管理されるアイデンティティ・データがあり、クラウド環境に完全に移行するまでのハイブリッド方式でガバナンスが必要な場合があります。デフォルトでは、認可ソースおよび管理対象システムから取り込まれたすべてのリソースがOracle Access Governanceで使用可能になります。Oracle Access Governanceとシステムの間に直接接続を追加すると、プライマリ・ガバナンス・システムからこれらを削除して、データの重複を回避できます。
オーケストレート済システムの仮想システムの理解
仮想システムを使用すると、単一のオーケストレートされた統合によって、複数の関連するアプリケーションまたはドメインを論理サブシステムとして表現および管理できます。これは、企業に複数のドメインまたはサブシステムがあり、それぞれ異なるデータを持ち、同じ構造スキーマを共有する必要がある場合に役立ちます。
仮想システムでは、ドメインごとに別々のオーケストレート済システムを作成および管理するのではなく、次のことが可能です。
- 単一のオーケストレート済システムで複数のアプリケーションをグループ化します。
- マッピングに従って、アプリケーションごとにデータファイルを格納および処理します。
- アクセス制御機能のプロビジョニングのために、これらのアプリケーションを個別に管理します。
適用対象: フラット・ ファイル
例
企業が3つの ADドメイン(Alpha、Beta、および Gamma)を統合するとします。仮想システムがない場合、それぞれに個別のオーケストレート済システムが必要になります。
- 単一のオーケストレート済システム(
Flatfile-MultiApp-01など)を構成し、仮想システムを有効にします。 - IDと名前を含むCSVをアップロードします:
ID 名前 virtual_ad_123 アルファ virtual_ad_456 ベータ版 virtual_ad_789 ガンマ - 統合が成功したら、バケット構造を参照してください。
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などのサブ・フォルダは、仮想システムが有効化されている場合にのみ作成されます。 - 構成後のステップを実行して、各フォルダにデータファイルを追加します。オーケストレート済システムのスキーマ拡張は、すべての仮想システムに適用されます。詳細は、「フラット・ファイルとの統合- 構成後」を参照してください。