SSO 連携設定：SAML / OIDC プロトコルの選択、IdP 設定パラメータ、ユーザー権限マッピングルール

SSO 連携はパートナーのデリバリーにおいて最も過小評価されがちな作業です。「ログインできるかどうか」だけではなく、ユーザー識別子、ロールマッピング、組織同期、ログアウト動作にも関わるためです。

このトピックの公開資料はデプロイドキュメントほど集中していませんが、2つの信頼できるソースがあります。1つは Enterprise 側の認証機能に関する公開説明、もう1つは Dify Enterprise のログイン認証に関するコミュニティの経験記事です。つまり、このトピックはトレーニング資料の初版を支えるのに十分ですが、内部で固定的にサポートしている IdP タイプやフィールドマッピングテンプレートがある場合は、後続で補足する価値があります。

一、公開資料から確認できる SSO トレーニングの範囲

1. SSO は単なるログインボタンの設定ではない

公開されている経験記事では、Enterprise のログイン認証がプロトコルの選択、IdP 設定、フィールドマッピング、ログイン後の権限境界に関わることが明示されています。そのため、トレーニングでは「認証成功後にシステムがどのようにユーザーを識別し認可するか」も併せて説明する必要があります。

2. OIDC と SAML の選択は企業の既存 ID 基盤に依存する

これは Dify 固有の話ではありませんが、エンタープライズデリバリーでは非常に重要です。顧客がすでにモダンな OAuth / OIDC 体系を持っている場合は OIDC がより自然であり、顧客が従来型の企業 IdP 体系を使用している場合は SAML がより一般的です。

3. 公開資料ではフレームワークを確認できるが、詳細は内部テンプレートが必要

公開資料は方向性とトレーニングの重点を示すのに十分ですが、Okta、Azure AD、Google Workspace、Keycloak などの具体的なフィールド設定例は、通常、内部デリバリーテンプレートで補足する必要があります。

二、プロトコルの選択

OIDC：モダンなアプリケーション連携でより一般的であり、OAuth エコシステムに近い
SAML：従来型の企業や一部の既存 IdP 環境では依然として一般的

三、トレーニングの重点

受講者が習得すべき内容：

IdP メタデータ / issuer / client id / secret / redirect uri それぞれの役割
テスト環境と本番環境のコールバック URL を混用してはならない
ユーザー一意識別子フィールドに何を使用するか

四、権限マッピングの推奨

最低限以下を明確にする：

ログイン後にどのロールを作成するか
新規ユーザーのデフォルトの workspace はどこか
部門に基づく自動権限マッピングを許可するか

五、補足が必要な部分

内部で具体的にサポートしている SSO ページ、フィールドのスクリーンショット、特定の IdP（Okta / Azure AD など）との連携テンプレートがある場合は、後続でここに追記することを推奨します。

公開資料の参照元

note.com

Keycloakを少しずつ | https://note.com/noritux/n/na1dbd9b6cde8

zenn.dev / 公式ドキュメント / その他公開ページ

【Dify Enterprise版】ログイン時の認証機能について | https://zenn.dev/upgradetech/articles/1029808cbc6991
Dify Enterprise Docs | https://enterprise-docs.dify.ai/

本稿で公開資料から確認できた有効情報

SSO 連携にはプロトコルの選択、IdP パラメータ、ログイン後の権限マッピングが含まれる
OIDC / SAML は顧客の既存 ID 基盤に基づいて選択すべきであり、一律に決めるべきではない
具体的なフィールドマッピングと各 IdP テンプレートは内部デリバリードキュメントで補足することがより適切