【Okta】SaaS 側のユーザーはどのタイミングで Okta と紐づくのか?Google Workspace で検証してみた

はじめに


こんにちは、ネクストモードのゆきなわです。

Okta にはアプリへの自動プロビジョニング機能の一つとして API 統合(API Integration)がありますが、要件によっては Okta Workflows などを使って独自にアプリ側のユーザーを作成するケースがあります。このとき気になるのがアプリ側に作成されたユーザーはいつ・どうやって Okta 側のアプリユーザーと紐づくのかという点です。

今回は Google Workspace を例に、プロビジョニング設定の状態別に挙動を検証してみました。

本記事の結論

今回の Google Workspace 環境では、Workflows でアプリ側にユーザーを作成しただけでは紐づけ情報である外部 ID(External ID)は連携されませんでした。外部 ID が Okta に連携されたのは、[今すぐインポート(Import Now)]または[ユーザーをプロビジョニングする(Provision User)]を実行したタイミングでした。

検証の背景


Okta の標準プロビジョニングを使わず、Okta Workflows でアプリ側にユーザーを作成する構成では次のような疑問が出てきます。

  • Okta のアプリ割り当てとアプリ側のユーザー作成が別ルートで行われた場合、両者はどう突合されるのか
  • 紐づけを示す外部 ID(Okta のアプリユーザープロファイルに格納されるアプリ側のユーザー識別子)は格納されるのか、格納されるとしたらどのタイミングか
  • プロビジョニング(API 統合)の有効/無効によって挙動はどう変わるのか

これらは外部 ID が連携されていないと後からプロビジョニングを有効化した際の突合やライフサイクル管理に影響するため、設計前に挙動を押さえておきたい重要なポイントです。

検証環境・前提


  • 対象アプリ:Google Workspace
  • アプリ側のユーザー作成:Okta Workflows(アプリ割り当てイベント (User Assigned to Application ) をトリガーに Google Workspace 側へユーザーを作成するフロー(下図)を事前に作成)

    okta-external-id-linking-timing-00-workflows
  • 検証パターン:
    1. API 統合(API Integration)は有効。ただし「ユーザーの作成(Create Users)」「ユーザー属性の更新(Update User Attributes)」「ユーザーの非アクティブ化(Deactivate Users)」は無効化
    2. API 統合(API Integration)は無効

パターン1:API 統合が有効(ただしアプリへのプロビジョニングは無効)


API 統合自体は有効にしたまま、アプリ側へのプロビジョニング機能の「ユーザーの作成(Create Users)」「ユーザー属性の更新(Update User Attributes)」「ユーザーの非アクティブ化(Deactivate Users)」を無効化した状態(下図)で、あらかじめ作成した Workflows によりアプリ割り当て時に Google Workspace 側へユーザーを作成しました。

okta-external-id-linking-timing-00-provisioning-settings

1. 割り当て直後はプロビジョニングエラーが発生

アプリ割り当てのタイミングで次のエラーが発生しました。

ユーザー〇〇のアプリ Google Workspace に対する自動プロビジョニングが失敗しました:一致するユーザーが見つかりません

okta-external-id-linking-timing-01-provisioning-error

Workflows によるユーザー作成はアプリの割り当て後に実行されるため、Okta 側から見ると割り当てたユーザーがアプリ側にまだ存在しない(一致しない)状態として扱われるようです。Okta 公式のトラブルシューティングでも、「ユーザーの作成(Create Users)」を有効にしていない場合に一致するユーザーが見つからずこのエラーになるケースが説明されています。

2. インポートを実行すると外部 ID が連携される

アプリの [インポート(Import)] > [今すぐインポート(Import Now)] を実行するとアプリ側ユーザーとの突合が行われ、外部 ID が Okta に連携されました。ただし割り当て(Assignments)画面に表示されていたプロビジョニングエラーはこの時点では消えませんでした。

なお、インポート時の突合にはアプリの「ユーザーの作成とマッチング(User Creation & Matching)」のマッチングルールが使用されるため、実環境では設定内容によって結果が変わる可能性があります。

okta-external-id-linking-timing-02-external-id-after-import

3. ユーザーにアプリを再割り当てするとエラーは解消し外部 ID は維持

その後ユーザーの割り当てを解除した後に再割り当てするとエラー表示が消え(下図)、外部 ID の値はそのまま保持されていました。なお、Google Workspace 側アカウントを削除した場合の挙動までは今回の検証では確認していません。

okta-external-id-linking-timing-03-external-id-after-unassignment

パターン2:API 統合が無効


次にプロビジョニング(API 統合)を無効にした状態で、同じく Workflows によりアプリ割り当て時に Google Workspace 側へユーザーを作成しました。この状況は Okta のプロビジョニング管理外で先にアプリ側にユーザーが存在しているケースと同等です。

1. エラーは発生しないが外部 ID も連携されない

API 統合が無効のため割り当て時にエラーは発生しません。一方で外部 ID も当然ながら連携されませんでした。

okta-external-id-linking-timing-04-external-id-not-linked

2. 後から API 統合を有効化するとエラーが表示される

この状態で API 統合を有効化すると次のメッセージが表示されました。

ユーザーは、プロビジョニングが有効になる前にこのアプリケーションを割り当てられており、ダウンストリームアプリケーションにプロビジョニングされていません。[ユーザーをプロビジョニングする]をクリックします。

okta-external-id-linking-timing-05-error-after-enabling-api

3. [ユーザーをプロビジョニングする(Provision User)]を実行

案内に従って [ユーザーをプロビジョニングする(Provision User)] で「OK」を押下します。

okta-external-id-linking-timing-06-provision-user-dialog

4. エラーが解消し外部 ID が連携される

実行後にエラーが解消され、外部 ID も Okta に連携されました。アプリ側に既に同一ユーザーが存在するため、新規作成ではなく既存ユーザーとの突合が行われたと考えられます。

 okta-external-id-linking-timing-07-external-id-linked

参考:API 統合を有効化せずにアプリ側ユーザーの ID を保持する方法


アプリ側ユーザーとの紐づけ情報を 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点です。

  • Okta の標準プロビジョニング以外のルート(Okta Workflows など)でアプリ側にユーザーを作成した場合、外部 ID は自動では連携されずインポートまたは[ユーザーをプロビジョニングする(Provision User)]の実行を契機に突合・連携される
  • API 統合が有効な状態ではアプリ側にユーザーが存在しないタイミングの割り当てはプロビジョニングエラーとして扱われる
  • 一度連携された外部 ID は一旦割り当てを解除しても保持されていた

※ただし、いずれも今回の Google Workspace 環境で確認した挙動であり、アプリ統合やマッチングルールの設定によって結果が変わる可能性がある点にご注意ください。

標準プロビジョニングと Workflows を組み合わせた構成を検討する際は、どちらを書き込みの主体とするかに加えて外部 ID の突合タイミングも考慮して設計することをおすすめします。

本記事では Google Workspace を例に、SaaS 側のユーザーが Okta と紐づくタイミングを検証・整理しました。Okta Workflows を活用したユーザー連携やプロビジョニング方式の設計を検討されている方の参考になれば幸いです。

参考ドキュメント


Okta に関するお問い合わせ

ネクストモードでは Okta の導入から運用までを支援しています。Okta の導入・活用をご検討の際はぜひお問い合わせください。