プロファイルソーシング

プロファイルソースとは、ユーザーの身元の信頼できる情報源として機能するアプリのことです。アプリまたはディレクトリの［Provisioning（プロビジョニング）］タブの［To Okta（Oktaへ）］セクションで有効にすると、［Profile Sources（プロファイルソース）］ページのプロファイルソースリストに表示されます。外部のプロファイルソースが特定されていない場合、Oktaがすべてのプロファイルのソースとなります。

複数のプロファイルソースが列挙されている場合、それらのプロファイルソースに優先順位を付けて、ユーザーのプロファイル属性をその割り当てに基づいて異なるシステムからソーシングすることができます。ユーザーのプロファイルに対するプロファイルソースは、常に1つしか使用できません。

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

ここでは、プロファイルソーシングが可能なアプリやディレクトリをいくつかご紹介します。

• Active Directory
• BambooHR
• G Suite
• LDAP
• NetSuite
• Namely（ISVが構築）
• Salesforce
• SuccessFactors
• UltiPro
• Workday

プロファイルソースの有効化とユーザー属性の更新

同じアプリで［プロファイルソース］と［ユーザー属性の更新］を有効にすると、［Oktaからアプリへ］のプロファイルマッピングを最も優先度の高いプロファイルソースにプッシュすることができます。これは、属性をダウンストリームのアプリからプロファイルソースに同期させたい場合に有効です。ただし、プロファイルソースとして指定されたアプリがOktaからプロファイルの更新を受け取ることもできる場合、データが失われる可能性があります。

同じアプリで［Profile Source（プロファイルソース）］と［Update User Attributes（ユーザー属性の更新）］を有効にする前に、以下の点を考慮してください。

• 不要なプロファイルのプッシュ：Oktaの更新では、アプリが最優先のプロファイルソースであっても、アプリ内のマッピングされていない属性の値を上書きすることがあります。たとえば、Active DirectoryからOktaにcn属性がマッピングされておらず、Active Directoryに［プロファイルソース］と［ユーザー属性の更新］を設定している場合、Oktaはcnに対してデフォルトのマッピングを適用します。
• IdPをソースとする属性の上書き：［Oktaからアプリへ］の更新では、別のIDソースをソースとする属性が上書きされることがあります。部分的なプッシュオプションはありません。
• 競合条件：Oktaでは、他の更新がOktaにプッシュバックされる前に、IDソースで更新された属性を上書きすることができますたとえば、ユーザーの苗字と名前はディレクトリからOktaにインポートされ、ユーザーのメールアドレスはアプリからOktaにインポートされるというシナリオを考えてみましょう。アプリでメールアドレスの更新が行われる前に、ディレクトリでユーザーの苗字が変更された場合、Oktaはその新しい苗字と古いメールアドレスをプッシュする可能性があります。

受信インポートのルール

プロファイルソースを使用するには、新規にインポートされたユーザーと、現在のOktaユーザーの更新を明確に区別する必要があります。Oktaは一致ルールを使用して、プロファイルソースとOktaの間のリンクを維持し、競合を防ぎます。「インポートされたユーザー属性の照合］を参照してください。

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

アクセスのさまざまなサイクル（リソースへのアクセスの作成、更新、および削除）を通じたユー ザーのIDのフローは、ユーザーのライフサイクルとして知られています。プロファイルソーサーは、このサイクルの開始または終了を決定することができ、プロビジョニングおよびインポートの領域で有効です。

「プロビジョニングとデプロビジョニング」を参照してください。