KNIME Documentation

SSO — OAuth, OIDC, SAML ​

Knime supports single sign-on (SSO) against your organization's identity provider (IdP), using either SAML 2.0 or OIDC/OAuth. Keycloak, Knime's embedded identity and access management solution, sits between your IdP and Knime.

How SSO works ​

  • SAML: Keycloak acts as the SAML Service Provider (SP), and your identity provider is the SAML IdP. Knime applications never interact with SAML directly — they always authenticate against Keycloak using OIDC, and Keycloak handles the SAML exchange with your IdP behind the scenes.
  • OIDC/OAuth: Keycloak connects directly to your OIDC/OAuth-based identity provider.

Set up SSO on a Knime-managed instance ​

Setting up SSO establishes trust between your identity provider and your instance's Keycloak server, so it's set up together with your Knime account team rather than as self-service configuration in the Knime UI.

  1. Contact your Knime account team to start SSO setup, and let them know whether you're using SAML or OIDC/OAuth.
  2. Your account team sends you a form to collect the configuration details listed below.
  3. Knime configures your instance's Keycloak server. For SAML, Knime also provides you with Keycloak's SAML metadata and signing certificate, so you can register Keycloak as a trusted Service Provider in your IdP.
  4. Test the login end to end together with your Knime contact.

Required information ​

SAML ​

  • Your IdP's SAML metadata (XML preferred), or an equivalent set of configuration details, to establish trust and configure Keycloak as a Service Provider.
  • The attribute to use as the primary user identifier (the SAML NameID).
  • User attributes sent on login: email address, first name, and last name (all required), plus any groups or roles.

Your IdP must sign the SAML assertion or response; Knime validates the signature using the IdP certificate from your metadata. Encrypting assertions is supported if required by your security policy.

OIDC/OAuth ​

  • Your identity provider's OIDC/OAuth configuration.
  • Claim mappings for email address, first name, and last name (all required), plus any groups or roles.

Map users to the global admin role ​

Include a group or role in your attribute or claim mapping that maps to the global admin role. Membership in this group determines which of your users become global admins.