Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

SSO Integration Configuration: SAML / OIDC Protocol Selection, IdP Configuration Parameters, and User Permission Mapping Rules

SSO integration is often the most underestimated aspect of partner delivery, because it involves not only “can users log in” but also user identification, role mapping, organization synchronization, and logout behavior.

The public sources for this topic are not as concentrated as deployment documentation, but there are still two reliable sources: one is the Enterprise-side public description of authentication capabilities, and the other is community articles about Dify Enterprise login authentication. This means the topic has enough support for a first version of training material, though it is still worthwhile to supplement with your internal list of supported IdP types and field mapping templates.

1. SSO Training Boundaries Confirmed by Public Sources

1. SSO Is Not Simply a Login Button Configuration

Public experience articles have explicitly pointed out that Enterprise login authentication involves protocol selection, IdP configuration, field mapping, and the permission boundaries after a user logs in. Therefore, training must also cover “how the system identifies and authorizes users after successful authentication.”

2. The Choice Between OIDC and SAML Depends on the Customer’s Existing Identity Infrastructure

While this is not unique to Dify, it is critical in enterprise delivery: if the customer already has a modern OAuth / OIDC system, OIDC is more natural; if the customer uses a traditional enterprise IdP system, SAML is often more common.

3. Public Sources Confirm the Framework, but Details Often Require Internal Templates

Public sources are sufficient to establish direction and training priorities, but specific field examples for Okta, Azure AD, Google Workspace, Keycloak, and others typically need to be supplemented by your internal delivery templates.

2. Protocol Selection

  • OIDC: More common for modern application integration, closer to the OAuth ecosystem
  • SAML: Still common in traditional enterprises and certain existing IdP environments

3. Training Focus

Trainees should master:

  • The purpose of IdP metadata / issuer / client id / secret / redirect uri
  • Test environment and production environment callback URLs must not be mixed
  • What field to use as the unique user identifier

4. Permission Mapping Recommendations

At minimum, clarify:

  • What role is assigned after login
  • Which workspace new users are placed in by default
  • Whether automatic permission mapping by department is allowed

5. Sections Requiring Your Input

If your team already has specific SSO configuration pages, field screenshots, and integration templates for a particular IdP (such as Okta / Azure AD), it is recommended to add them here.

Public Source References

note.com

  • Gradually learning Keycloak | https://note.com/noritux/n/na1dbd9b6cde8

zenn.dev / Official Documentation / Other Public Pages

  • Dify Enterprise: Login Authentication Features | https://zenn.dev/upgradetech/articles/1029808cbc6991
  • Dify Enterprise Docs | https://enterprise-docs.dify.ai/

Confirmed Information from Public Sources

  • SSO integration involves protocol selection, IdP parameters, and post-login permission mapping
  • OIDC / SAML should be selected based on the customer’s existing identity system, not as a one-size-fits-all choice
  • Specific field mappings and IdP templates are better supplied by internal delivery documentation