アイデンティティモデルに関しては、B2B 製品は独自の領域にあります。マルチテナンシーの複雑さをナビゲートしながら、さまざまなサービスやアプリケーションにわたる統一された従業員のアイデンティティおよびアクセス管理に対する企業の要求を満たす必要があります。Logto も顧客からこれらの要求に直面しています。本記事では、製品志向のアプローチで SP 開始の SSO を理解し、顧客のニーズにどのように対応するかを学びます。
まず、理解する必要があるいくつかの重要な要素を紹介しましょう：
- サービスプロバイダー (SP): あなたのアプリケーションまたはサービスで、単一のアイデンティティシステムを共有する一つまたは複数のアプリが含まれます。
- 企業アイデンティティプロバイダー (IdP): 企業クライアントが従業員のアイデンティティとアプリケーションの権限を管理するために使用するアイデンティティプロバイダーです。Okta、Azure AD、Google Workspace、またはカスタムビルドされた IdP など、さまざまなプロバイダーを使用する可能性があります。
- サービスプロバイダーの組織 (SP Org): B2B アプリは、異なるクライアント組織のためのマルチテナンシーをサポートすることがよくあります。
- アイデンティティプロバイダーの組織 (IdP Org): IdP も異なるクライアント組織のためのマルチテナンシーをサポートします。理想的には、1 つの企業がその IdP Org を SP Org とリンクし、従業員のアイデンティティを複製することができるべきですが、現実はもっと複雑です。
- 企業ユーザーアカウント: 通常、会社のメールドメインを使用してログインすることで識別されます。この企業のメールアカウントは最終的には会社に帰属します。
次に、SSO と 2 つの主要なプロトコルについて詳しく見ていきましょう：
- シングルサインオン (SSO): SSO は、ユーザーが単一の資格情報セットで複数のサービスやアプリケーションにアクセスできるようにします。これにより、アクセス管理が簡素化され、セキュリティが向上します。
- SAML と OIDC プロトコル: SSO は、認証と認可のためにこれらのプロトコルに依存しており、それぞれに利点と欠点があります。
考慮すべき主な SSO トリガーメカニズムは次の 2 つです：
- IdP 開始の SSO: IdP 開始の SSO では、アイデンティティプロバイダー (IdP) がシングルサインオン プロセスを主に制御します。ユーザーは IdP のインターフェースから認証を開始します。
- SP 開始の SSO: SP 開始の SSO では、サービスプロバイダー (SP) がシングルサインオン プロセスの開始と管理を主導し、B2B シナリオで好まれることが多いです。
では、SP 開始の SSO を詳細に探っていきましょう。
表面的な部分: ユーザーエクスペリエンス#
B2C 製品がいくつかの固定されたソーシャル IdP サインインボタンを提供できるのとは異なり、B2B 製品は各顧客が使用する特定の企業 IdP を指示することはできません。したがって、ユーザーはまず自分のアイデンティティを宣言する必要があります。彼らが SSO を有効にした企業のメンバーであることを確認した後、彼らはそれぞれの企業 IdP にログインするためにリダイレクトされます。
これを達成するためには、サインインページで、ユーザーが SSO を通してサインインする必要があるか、どの IdP にリダイレクトするべきかを判断する必要があります。一般的な方法には次のものがあります：
- メールドメインマッピング: メールドメインを特定の IdP コネクタに関連付けます。これにより、そのドメインのメールアドレスを持つユーザーに影響を与えます。悪意のある構成を防ぐためにドメイン所有権の確認を行ってください。
- 組織名マッピング: 組織名を IdP コネクタとリンクさせ、ユーザーが自分の組織名を覚えているという前提に依存します。
- ユーザー個人のメールマッピング: これにより、ユーザーアカウントが SSO に対応しているかを直接判断でき、メールドメインや組織名に依存しないようにします。ユーザーを手動で招待し、SSO の必要なルールをカスタマイズするか、ディレクトリ同期を通じてアカウントを自動的に同期することでこれを実現できます。
サインインホームページのデザインには、製品のビジネスに応じて次の 2 つのフォームが一般的に選ばれます：
- B2B 製品: SSO が必要な企業のクライアントメンバーにとって直感的に使いやすいように、SSO ボタンを直接表示することをお勧めします。
- B2C および B2B の両方に対応した製品: 大多数のユーザーは SSO を使用しないため、メール ドメインを評価して SSO が必要かどうかを判断します。ユーザーの身元が確認されるまで資格情報の確認を保留し、最初は隠してから表示することができます。
内在する複雑さ: ユーザーアイデンティティモデル#
ただ、サインインページに SSO ボタンを追加するだけでなく、SSO をアイデンティティ システムに統合するにははるかに複雑です。多くの要素を考慮する必要があります。
主要な要素の関係は一対一のことはまれで、一対多や多対多のシナリオを考慮する必要があります。これらのバリエーションを段階的に探ってみましょう：
- 複数のメールドメインを持つ 1 つの IdP Org: メールドメインに基づいてユーザーアイデンティティを判断する場合、複数のドメインバインディングをサポートする必要があります。
- 複数の IdP Org に対応する 1 つのメールドメイン: ドメインが複数の IdP Org に属している場合、ユーザーはシングルサインオンのために使用したい IdP を選択する必要があります。
- 複数の SP Org にリンクされた 1 つの IdP Org: 1 つの IdP を複数の SP Org に接続する迅速な機能を提供することを検討してください。
- 複数の IdP Org と SP Org に属する 1 つのユーザーアカウント: 異なる SP Org が異なる IdP を通じて認証を求めることがあります。
企業内での SSO の有効化または無効化は、ユーザー認証の方法を変更する可能性があり、安全でスムーズな移行が必要です。
- SSO アクティベーションの意思決定: SSO が特定のテナント SP Org だけに影響を与えるか、すべてのテナント SP Org に影響を与えるかを決定する必要があります。前者は柔軟性を提供し、後者は企業全体のアイデンティティとアクセス制御のトレンドに一致します。
- 移行期間の考慮: SP としては、サードパーティー IdP サービスの不確実性に対応する必要があります。企業管理者は、移行期間中も認証情報オプションとして SSO または資格情報を使用してアプリにアクセスする必要がありますし、企業メンバーも同様です。
これらはさまざまなシナリオに対応するためのポイントの一部に過ぎず、さらに多くの機能と詳細を探求することができます。
SP 開始の SSO に関するこの分析が、企業のアイデンティティ ソリューションに新たな視点を提供することを願っています。良いニュースは、Logto がシンプルな構成と SSO 認証エクスペリエンスを提供するソリューションを精力的に開発していることです。今後のリリースにご注目ください。具体的な SP 開始の SSO ソリューションについてさらに詳しく解説します。
