日本語

ジャストインタイム

ジャストインタイムプロビジョニングを理解する

ジャストインタイムプロビジョニングは、初回サインイン時にユーザーアカウントを即座に生成するためのアイデンティティおよびアクセス管理システムで使用されるプロセスです。この記事では、ジャストインタイムプロビジョニングの基本を説明し、その実装に関する一般的な質問に答えます。

Guamian

Product & Design

7/3/2024

ユーザー認証に何週間も費やすのはもうやめましょう

Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。

始めましょう

ジャストインタイムプロビジョニングについて説明する前に、あなたがSaaS B2Bアプリを構築していて、メンバーが簡単にワークスペース（テナント）に参加できるようにメンバーシップ機能をサポートしたいと想像してみてください。どのような機能を提案しますか？ここにチェックリストがあります：

シナリオ	フロー
管理者の招待	ユーザーは組織に参加するためのメール招待を受け取ることができます。
管理APIユーザー作成またはインポート	ユーザーは事前に作成されたユーザーアカウントを使用して組織に参加できます。
ジャストインタイムプロビジョニング	アプリに初回ログインするユーザーは組織に参加できます。
ディレクトリ同期（例: SCIM）	IdPのディレクトリ同期機能を使用して、事前にアプリにユーザーをプロビジョニングします。

ジャストインタイム (JIT) プロビジョニングは、初回サインイン時にユーザーアカウントを即座に生成するためのアイデンティティおよびアクセス管理システムで使用されるプロセスです。事前にユーザーアカウントをプロビジョニングする代わりに、JITプロビジョニングはユーザーが認証された瞬間に動的に必要なユーザーアカウントを作成し、設定します。ジャストインタイムプロビジョニングは効率性、管理作業が不要、自動的な組織参加など、独自の特徴を持つ人気のある機能です。ジャストインタイムプロビジョニングの基本を理解したので、実際の製品開発に深入りするにつれて、いくつかの質問が出てくるかもしれません。私はこれらの質問に答えますが、これらは物議を醸す可能性があり、特定のビジネスケースに大きく依存する場合があります。

製品にジャストインタイムプロビジョニングを実装する必要がありますか？

マルチテナントアーキテクチャ、企業SSO、企業との連携、またはチームのオンボーディング機能を必要とするB2Bアプリを構築する際に一般的なケースです。次に、クライアントが直面する可能性のあるいくつかの例を紹介します。

急速なオンボーディング

頻繁な採用や急速な成長を経験しているクライアントがJITプロビジョニングを使用して、新しい従業員のユーザーアカウントを迅速に設定できます。例を挙げましょう:

サラは「スーパーファンタジー」社の新しい従業員で、この会社はエンタープライズアイデンティティプロバイダーとして「Okta」を使用しています。HRチームは彼女を「[email protected]」というビジネスアイデンティティとしてOktaに一度だけ登録します。サラがこのメールを使用して社内の生産性アプリ「スマートワークスペース」に初めてサインインすると、システムは自動的にアカウントを作成し、会社のワークスペース内で彼女に適切な役割を割り当てます。この仕組みにより、サラやスーパーファンタジー社のHRチームがアカウント作成や役割の割り当てのために複数のステップを経る必要がありません。

合併・買収・一時的な従業員

他社を合併または買収しているクライアントの場合、多くの新しいユーザーに対して取得した会社のシステムにアクセスを付与するプロセスを簡略化できます。もう一つの例を挙げましょう。

ピーターは「マジックテック」社で働いており、最近「スーパーファンタジー」に買収されました。マジックテックはエンタープライズSSOを持たない小規模な組織ですが、ピーターは「スマートワークスペース」も使用しており、そこでビジネスアカウントを既に持っています。

HRチームはピーターを「Okta」に追加できます。ピーターがOktaを通じて初めてスマートワークスペースにログインすると、システムは自動的に彼の既存のビジネスアカウントをリンクし、適切なアクセスをスーパーファンタジーに対して付与します。

上記のシナリオは、JIT機能を実装するのに理想的です。

SAMLとエンタープライズSSOに特化しているのですか？

ジャストインタイム (JIT) プロビジョニングは、SAML認証のシングルサインオン (SSO) に関連付けられることが多いですが、SAMLに限定されているわけではありません。JITプロビジョニングは、OAuth 2.0やOpenID Connectなど他の認証プロトコルと組み合わせて使用することもでき、エンタープライズSSO設定を必要としない場合もあります。

例えば、メールベースのJITプロビジョニングは、メールドメインに基づいてユーザーを自動的にワークスペースに追加することで、チームのオンボーディングを簡素化できます。これは、エンタープライズSSOを購入および管理する予算とリソースが不足している組織に特に有用です。

JITプロビジョニングの基本的な考え方は、特定のプロトコルに関係なく、ユーザーがサービスに初めてアクセスしようとしたときにユーザーアカウントを自動的に作成または更新することにあります。

アプリの新規ユーザーや既存ユーザーに適用されるか？

これは厄介な質問です。ジャストインタイム (JIT) プロビジョニングは通常、アプリに初めてアクセスしようとする際に適用されます。しかし、異なる製品がこの機能を異なって捉えていることがあります。JITプロビジョニングをアイデンティティおよびアカウント作成にのみ使用する製品もあれば、再プロビジョニングや属性同期など、ジャストインタイムのアカウント更新も含める製品もあります。

自動ユーザー作成に加えて、SAML JITプロビジョニングは、プロビジョニングの一環としてグループメンバーシップの付与および取り消しを可能にします。また、プロビジョニングされたユーザーを更新して、IDプロバイダー (IDP) ユーザーストア属性とサービスプロバイダー (SP) ストアの属性を同期状態に保つこともできます。

例えば、Oracle Cloudでは、ジャストインタイムプロビジョニングはさまざまな方法で設定できます。

ジャストインタイム作成
ジャストインタイム更新

Oracle Identity Cloud Serviceの管理: SAML ジャストインタイムプロビジョニングの理解.

サインイン時にユーザーが:	フロー
存在し、JITプロビジョニングが有効。	通常のSSO失敗フロー。
存在しない、そしてJIT作成が有効。	JIT構成で対応付けられたSAMLアサーション属性で、ユーザーが作成され、プロビジョニングされます。
存在し、JIT更新が有効。	JIT設定でマッピングされたSAMLアサーション属性でユーザー属性値が更新されます。

既存のユーザーサインインシナリオを考慮したい場合は、JITシステムと共に強力なプロビジョニングシステムを持っていることを確認してください。例えば、

競合解決: アカウントが既に存在し、JITプロセス中にIdPから提供された情報と異なる場合に競合を処理するための戦略がシステムに必要です。これは、組織の方針およびIdPの設定に関する詳細な制御が必要かもしれません。
監査トレイル: JITプロセスによる新しいアカウント作成および既存アカウントの更新の両方のログを保持することは、セキュリティおよびコンプライアンスの理由から重要です。
パフォーマンス: JITプロビジョニングは迅速に行われますが、特に既存ユーザーの情報を更新する場合、サインイン時間に影響を与える可能性を考慮してください。
データの一貫性: JITプロビジョニングプロセスが既存のユーザーアカウントを更新する際にデータの一貫性を保つことを確認してください。

JITとSCIMの違いは何ですか？

ジャストインタイム (JIT) プロビジョニングに加え、SCIM (システム間アイデンティティ管理) について聞いたことがあるかもしれません。SCIMは、異なるシステムやドメイン間でのユーザーアイデンティティ管理を簡素化し、自動化するために設計されたオープンスタンダードプロトコルです。これはディレクトリ同期のシナリオでよく使用されます。

JITとSCIMの主な違いは、JITがユーザーのサインイン時にアカウントを作成するのに対して、SCIMはユーザーのログイン試行とは無関係に、オフラインの自動化されたプロセスを通じてプロビジョニングを行うことができる点です。

つまり、JITは新しいユーザーのオンボーディングに焦点を当て、SCIMはユーザーのライフサイクル全体の管理に焦点を当てています。

さらに、JITは一般的にSAMLの拡張として使用され、その実装はシステムごとに標準化されていないのに対し、SCIMはアイデンティティ管理のための明確に定義された標準化されたプロトコル (RFC 7644) です。

一部の大規模な組織では、SCIMをアカウントプロビジョニングに使用し、自社システムと統合しています。これには非常に複雑な場合があり、ケースバイケースで異なります。これらの組織は、一般的に自動化されたプロセスと管理者関与の両方を含むプロビジョニングシステムを持っています。

Logtoにおけるジャストインタイムプロビジョニング

SSOジャストインタイムプロビジョニング と メールドメインジャストインタイムプロビジョニング は、Logtoでサポートしている機能です。

Logtoでは、組織レベルでこの機能セットを実装しており、特定の条件を満たすユーザーが自動的に組織に参加し、役割を割り当てられるようになっています。

私たちは、クライアントのオンボーディングを簡素化し自動化するために、JIT機能をスケーラビリティが高く安全なレベルで実装しています。しかし、前述したように、プロビジョニングシステムは複雑であり、クライアントの特定のニーズに合わせる必要があるため、Logtoの事前に構築されたJIT機能、慎重なシステム設計、およびLogto管理APIを活用して、堅牢なプロビジョニングシステムを構築することをお勧めします。

次のダイアグラムを使って、Logtoでの仕組みを見てみましょう。

エンタープライズSSOプロビジョニング

LogtoでエンタープライズSSOを設定している場合は、組織エンタープライズSSOを選択して、ジャストインタイムプロビジョニングを有効にできます。

新規または既存のユーザーがエンタープライズSSOを通じて 初めて サインインすると、自動的に組織に参加し、デフォルトの組織ロールを取得します。

以下の表に潜在的なフローをリストします:

ユーザーのステータス	フローの説明
ユーザーが存在せず、JITが有効です。	ユーザーが作成され、自動的に対応する組織に適切な役割で参加します。
ユーザーが存在し、エンタープライズSSOと同じ確認済みメールアドレスを持ち、JITが有効です。	ユーザーのメールアドレスが自動的にエンタープライズSSOアカウントとリンクされ、対応する組織に適切な役割で参加します。
ユーザーが存在せず、JITが有効ではありません。	通常のSSO失敗フロー。
ユーザーが存在し、JITが有効ではありません。	通常のSSOフロー。

SSOプロビジョニング

メールドメインによるプロビジョニング

組織に専用のエンタープライズSSOがない場合は、メールドメインを使用してジャストインタイムプロビジョニングを有効にできます。これは、エンタープライズSSOの予算がなくても、ある程度のメンバーオンボーディング自動化とセキュリティ管理を望む中小企業に発生することが一般的です。

ユーザーがサインアップすると、組織レベルで設定されたメールドメインに対応する確認済みメールアドレスに一致する場合、対応する組織に適切な役割でプロビジョニングされます。

メールドメインによるプロビジョニング

メールドメインプロビジョニングは以下に適用されます:

メールサインアップ認証
ソーシャルサインアップ認証

既存ユーザーサインインプロセスにメールドメインプロビジョニングが適用されない理由

既存ユーザーのサインインには、特定の組織にプロビジョニングされるか、役割が付与されるかどうかを判断するためのさらなる制御が必要です。このプロセスは動的で、特定のユースケースやビジネスニーズ、またその後のログイン戦略や組織レベルのポリシーに依存します。

例えば、既存ユーザーにメールドメインプロビジョニングを有効にして、後で異なる役割を持つ別のグループをオンボードしたい場合、以前にオンボードされたユーザーには新しく設定した役割が割り当てられるべきでしょうか？

これにより、「ジャストインタイム更新」に関して複雑なシナリオが生じます。正確な動作は、アプリケーション、組織設定、IdP統合の構成方法によって異なることがよくあります。Logtoではこの制御を開発者に委ねており、プロビジョニングシステムを自由に設計し、新しいアカウント作成と組織オンボーディングのための最も頻繁なシナリオに対処できるようにしています。

メールフロー

ユーザーのステータス	フローの説明
ユーザーが存在せず、メールでサインアップし、JITが有効です。	ユーザーが作成され、自動的に対応する組織に適切な役割で参加します。
ユーザーが既に存在し、プロビジョニングされたメールドメインと同じ確認済みメールアドレスを持ち、JITが有効です。	通常のメールサインインフロー。
ユーザーが存在せず、メールでサインアップし、JITが有効ではありません。	通常のメールサインアップフロー。
ユーザーが存在し、メールでサインインし、JITが有効ではありません。	通常のメールサインインフロー。

ソーシャルフロー

ユーザーのステータス	フローの説明
ユーザーが存在せず、確認済みメールを使用してソーシャルアカウントでサインアップし、JITが有効です。	ユーザーが作成され、自動的に対応する組織に適切な役割で参加します。
ユーザーが存在せず、未確認のメールまたはメールなしでソーシャルアカウントでサインアップし、JITが有効です。	通常のソーシャルサインアップフロー。
ユーザーが既に存在し、プロビジョニングされたメールドメインと同じ確認済みメールアドレスを持ち、ソーシャルアカウントでサインインし、JITが有効です。	通常のソーシャルサインインフロー。
ユーザーが存在せず、ソーシャルアカウントでサインアップし、JITが有効ではありません。	通常のソーシャルサインアップフロー。
ユーザーが存在し、ソーシャルアカウントでサインインし、JITが有効ではありません。	通常のソーシャルサインインフロー。

メールドメインプロビジョニングとエンタープライズSSOの潜在的な競合の処理

最初にメールドメインプロビジョニングを設定し、その後同じメールドメインでエンタープライズSSOを設定した場合、次のことが起こります：

ユーザーがメールアドレスを入力すると、SSOフローにリダイレクトされ、メール認証をバイパスします。これにより、JITプロセスはトリガーされません。

これに対処するため、設定時に警告メッセージが表示されます。正しいSSOを選択してジャストインタイムプロビジョニングを有効にし、メールドメインプロビジョニングに依存しないようにしてください。

競合解決

デフォルト組織ロール

ユーザーをプロビジョニングする際に、デフォルトの組織ロールを設定できます。役割リストは組織テンプレートから取得され、役割を選択するか空にするかを選択できます。

エンタープライズSSOジャストインタイム更新

幸いなことに、エンタープライズSSOにはこの機能が既に組み込まれています！プロフィール情報が初回サインイン時または毎回サインイン時にLogtoに同期されるかどうかを選択できます。また、今後追加する予定の役割や組織マッピング、再プロビジョニングの機能も検討しています。

SSO JIT更新これをチェックして詳細を学びましょう。

ジャストインタイム機能はLogtoですぐに利用可能です。今日Logtoにサインアップし、クライアントのメンバーシップオンボーディングを自動化しましょう。

Logto Cloud を無料で試す

製品にジャストインタイムプロビジョニングを実装する必要がありますか？#

急速なオンボーディング#

合併・買収・一時的な従業員#

SAMLとエンタープライズSSOに特化しているのですか？#

アプリの新規ユーザーや既存ユーザーに適用されるか？#

JITとSCIMの違いは何ですか？#

Logtoにおけるジャストインタイムプロビジョニング#

エンタープライズSSOプロビジョニング#

メールドメインによるプロビジョニング#

メールフロー#

ソーシャルフロー#

メールドメインプロビジョニングとエンタープライズSSOの潜在的な競合の処理#

デフォルト組織ロール#

エンタープライズSSOジャストインタイム更新#