こんにちは、ネクストモードのゆきなわです。
Okta にはアプリへの自動プロビジョニング機能の一つとして API 統合（API Integration）がありますが、要件によっては Okta Workflows などを使って独自にアプリ側のユーザーを作成するケースがあります。このとき気になるのがアプリ側に作成されたユーザーはいつ・どうやって Okta 側のアプリユーザーと紐づくのかという点です。
今回は Google Workspace を例に、プロビジョニング設定の状態別に挙動を検証してみました。
本記事の結論
今回の Google Workspace 環境では、Workflows でアプリ側にユーザーを作成しただけでは紐づけ情報である外部 ID（External ID）は連携されませんでした。外部 ID が Okta に連携されたのは、［今すぐインポート（Import Now）］または［ユーザーをプロビジョニングする（Provision User）］を実行したタイミングでした。
Okta の標準プロビジョニングを使わず、Okta Workflows でアプリ側にユーザーを作成する構成では次のような疑問が出てきます。
これらは外部 ID が連携されていないと後からプロビジョニングを有効化した際の突合やライフサイクル管理に影響するため、設計前に挙動を押さえておきたい重要なポイントです。
API 統合自体は有効にしたまま、アプリ側へのプロビジョニング機能の「ユーザーの作成（Create Users）」「ユーザー属性の更新（Update User Attributes）」「ユーザーの非アクティブ化（Deactivate Users）」を無効化した状態（下図）で、あらかじめ作成した Workflows によりアプリ割り当て時に Google Workspace 側へユーザーを作成しました。
アプリ割り当てのタイミングで次のエラーが発生しました。
ユーザー〇〇のアプリ Google Workspace に対する自動プロビジョニングが失敗しました：一致するユーザーが見つかりません
Workflows によるユーザー作成はアプリの割り当て後に実行されるため、Okta 側から見ると割り当てたユーザーがアプリ側にまだ存在しない（一致しない）状態として扱われるようです。Okta 公式のトラブルシューティングでも、「ユーザーの作成（Create Users）」を有効にしていない場合に一致するユーザーが見つからずこのエラーになるケースが説明されています。
アプリの [インポート（Import）] > [今すぐインポート（Import Now）] を実行するとアプリ側ユーザーとの突合が行われ、外部 ID が Okta に連携されました。ただし割り当て（Assignments）画面に表示されていたプロビジョニングエラーはこの時点では消えませんでした。
なお、インポート時の突合にはアプリの「ユーザーの作成とマッチング（User Creation & Matching）」のマッチングルールが使用されるため、実環境では設定内容によって結果が変わる可能性があります。
その後ユーザーの割り当てを解除した後に再割り当てするとエラー表示が消え（下図）、外部 ID の値はそのまま保持されていました。なお、Google Workspace 側アカウントを削除した場合の挙動までは今回の検証では確認していません。
次にプロビジョニング（API 統合）を無効にした状態で、同じく Workflows によりアプリ割り当て時に Google Workspace 側へユーザーを作成しました。この状況は Okta のプロビジョニング管理外で先にアプリ側にユーザーが存在しているケースと同等です。
API 統合が無効のため割り当て時にエラーは発生しません。一方で外部 ID も当然ながら連携されませんでした。
この状態で API 統合を有効化すると次のメッセージが表示されました。
ユーザーは、プロビジョニングが有効になる前にこのアプリケーションを割り当てられており、ダウンストリームアプリケーションにプロビジョニングされていません。［ユーザーをプロビジョニングする］をクリックします。
案内に従って [ユーザーをプロビジョニングする（Provision User）] で「OK」を押下します。
実行後にエラーが解消され、外部 ID も Okta に連携されました。アプリ側に既に同一ユーザーが存在するため、新規作成ではなく既存ユーザーとの突合が行われたと考えられます。
アプリ側ユーザーとの紐づけ情報を Okta に保持する方法としては、API 統合による外部 ID 連携のほかにWorkflows で取得した ID を Okta のカスタムユーザープロファイル属性に格納しておく方法も考えられます。
Google Workspace の場合、Workflows の Google Workspace Admin コネクターで「ユーザーの作成（Create User）」アクションを実行すると、出力として外部 ID に相当する一意識別子のユーザーID（User ID）が返却されます。この値をカスタム属性に保存しておけば、API 統合を有効化しなくてもアプリ側ユーザーとの対応関係を Okta 上で管理できます。
ただし、カスタム属性への格納はアプリユーザープロファイルの外部 ID を設定するものではなく、Okta 標準プロビジョニング上の紐づけが成立するわけではありません。保存した ID を使ったユーザーの検索・更新・無効化は Workflows 側のフローとして設計する必要があります。
今回の検証結果を整理すると次のとおりです。
| パターン | 割り当て時の挙動 | 外部 ID が連携されるタイミング |
|---|---|---|
| API 統合が有効（Create 等は無効） | 「一致するユーザーが見つかりません」エラー | [インポート（Import）] > [今すぐインポート（Import Now）] の実行時 |
| API 統合が無効 | エラーなし（外部 ID も未連携） | API 統合を有効化して [ユーザーをプロビジョニングする（Provision User）] を実行したとき |
ポイントは以下の3点です。
※ただし、いずれも今回の Google Workspace 環境で確認した挙動であり、アプリ統合やマッチングルールの設定によって結果が変わる可能性がある点にご注意ください。
標準プロビジョニングと Workflows を組み合わせた構成を検討する際は、どちらを書き込みの主体とするかに加えて外部 ID の突合タイミングも考慮して設計することをおすすめします。
本記事では Google Workspace を例に、SaaS 側のユーザーが Okta と紐づくタイミングを検証・整理しました。Okta Workflows を活用したユーザー連携やプロビジョニング方式の設計を検討されている方の参考になれば幸いです。
ネクストモードでは Okta の導入から運用までを支援しています。Okta の導入・活用をご検討の際はぜひお問い合わせください。