プロファイル・ソーシングについて

プロファイル・ソースは、ユーザーIDの真実性のソースとして機能するアプリケーションです。アプリまたはディレクトリーの[プロビジョニング]タブから有効にすると、[プロファイル・ソース]ページのプロファイル・ソース・リストに表示されます。外部プロファイル・ソースが識別されない場合、Oktaがすべてのプロファイルのソースです。

[プロファイル・ソース]ページに複数のプロファイル・ソースが表示されている場合、優先順位を付けて、ユーザーのプロファイル属性を、その割り当てに基づいて異なるシステムからソースとして使用できるようにすることができます。どの時点でも、ユーザーのプロファイルのプロファイル・ソースは1つのみ存在できます。

プロファイル・ソースは、ユーザーのライフサイクル全体（作成、更新、非アクティブ化）の管理に役立つ強力なツールです。たとえば、Workdayをプロファイル・ソースとして使用し、ユーザーの作成、更新、終了のイベントをWorkdayからOktaに送信します。

プロファイルのソーシングを可能にするアプリとディレクトリーの一部を以下に示します。

• Active Directory
• BambooHR
• G Suite
• LDAP
• NetSuite
• Namely（ISVによって構築）
• Salesforce
• SuccessFactors
• UltiPro
• Workday

プロファイル・ソースとユーザー属性の更新を有効にする

同じアプリケーションに対してプロファイル・ソースとユーザー属性の更新を有効にすると、Oktaからアプリへのプロファイル・マッピングを最も優先度の高いプロファイル・ソースにプッシュできます。これは、メール・アドレスや電話番号などの属性をダウンストリーム・アプリケーションからプロファイル・ソースに同期する場合に便利です。ただし、プロファイル・ソースとして指定されたアプリがOktaからプロファイルの更新も受信できる場合、データが失われる可能性があります。

同じアプリに対してプロファイル・ソースとユーザー属性の更新を有効にする前に、以下を考慮してください。

• 不要なプロファイルのプッシュ - Oktaの更新により、アプリのプロファイル・ソースが最も優先度が高い場合でも、アプリ内のマッピングされていない属性の値が上書きされる可能性があります。たとえば、cn属性がActive DirectoryからOktaにマッピングされておらず、プロファイル・ソースとユーザー属性の更新用にActive Directoryを構成している場合、- Oktaは cnにデフォルトのマッピングを適用します。
• 上書きされたIdPソース属性 - Oktaからアプリへの更新により、別のIDソースから提供された属性が上書きされる可能性があります。部分的なプッシュ・オプションはありません。
• 競合状態 - Oktaは、他の更新が - Oktaにプッシュバックされる前に、IDソースの更新された属性を上書きする可能性があります。たとえば、ユーザーの姓と名がディレクトリーからOktaにインポートされ、ユーザーのメール・アドレスがアプリからOktaにインポートされるシナリオを考えます。アプリで該当するメール・アドレスが更新される前に、ユーザーの姓がディレクトリーで変更されると、- Oktaによって新しい名前と古いメール・アドレスがプッシュされる可能性があります。

受信インポートのルール

プロファイル・ソースを使用するには、新しくインポートされたユーザーと現在のOktaユーザーに対する更新を明確に区別する必要があります。Oktaは一致ルールを使用してプロファイル・ソースとOkta間のリンクを維持し、競合を防ぎます。「プロビジョニングとプロビジョニング解除」の 「ユーザーの作成&一致」 を参照してください。

プロファイル・ソーシングとユーザーのライフ・サイクル

さまざまなアクセス・サイクル（リソースへのアクセスの作成、更新、削除）におけるユーザーIDのフローは、ユーザーのライフ・サイクルと呼ばれます。プロファイル・ソーサーはこのサイクルの開始を判別でき、プロビジョニングおよびインポート・スペース内で有効化されます。「プロビジョニングとプロビジョニング解除」を参照してください。