HEAVY.AI Enterprise Edition Supports two federated authentication mechanisms: LDAP & SAML. This article explains how each of these system works, comparing and contrasting both options.

Both have these features:

• Support syncing groups/roles in authentication service with configured roles in HeavyDB
• Require users to have, either via group assignment, or via prior configuration, access to the database they’re trying to access.

Further Reading on Roles/Security:
https://docs.heavy.ai/installation-and-configuration/security/roles

SAML

SAML authentication is supported for Immerse users. In a SAML configuration, the credentials never pass through HEAVY.AI. However, only Immerse is compatible with SAML authentication, not direct connection to HeavyDB.

Figure 1: Diagram of SAML Login Architecture

SAML Advantages

• If user is already authenticated with Identity Provider, user saves an extra login step, they’re immediately redirected back to SAML Endpoint with credentials.
  • Especially useful behavior for iFramed Charts in External Systems
• Credentials never pass through HEAVY.AI
• No need for firewall re-configuration, HeavyDB doesn’t directly talk to IdP, user does this step in their browser.

• User enjoys familiar login experience, optionally supporting existing 2FA infrastructure (configured on the Identity Provider Side)

SAML Drawbacks

• User typically lacks the ability to manually enter a DB to authenticate against, must be configured with DEFAULT_DB in claim or authenticate to heavyai database.
• Users cannot be designated as “super users” through SAML; this modification must be done manually if desired (although user can be granted most rights through groups)
• Logout mechanism in Immerse doesn’t log out of Identity Provider
• SAML is supported only for Immerse Users, and no fallback for Immerse Users is supported. Other applications connecting directly to HeavyDB must either authenticate directly with the DB with allow-local-auth-fallback flag OR have their own IdP interfacing software to support SAML integration.

SAML Identity Providers

• Any SAML identity provider can be used. Such a provider must:
  • Allow configuration of SAML Endpoint (Reply URL)
  • Provide XML identity file with key used for validating SAML claims
  • Optional (but necessary for best results): Provide a claim “Groups” with values for each group/role that the user is a member of in identity provider system, to be used to provide access in HEAVY.AI, matching against names of existing configured roles.
• HEAVY.AI provides instructions for using Okta and Auth0 as a SAML Identity Provider.

LDAP

LDAP(S) Server is configured on HeavyDB side, HeavyDB passes received credentials through to LDAP endpoint, and gets back user authorization and group membership, which is then used to authenticate the user.

LDAP(s) connection confirms:

• User credential validity
• User group membership

HeavyDB Authenticates:

• Access to requested database
• Against local user catalog, if allow-local-auth-fallback flag enabled

Figure 2: Diagram of LDAP Authentication Architecture

LDAP Advantages

• All login functionality, regardless of whether authentication is happening from Immerse or via direct connection to HeavyDB, can be validated through LDAP(s) server (unless using allow-local-auth-fallback flag)
• Login & Logout work exactly the same as when using local authentication

LDAP Drawbacks

• LDAPS can be difficult to configure, requires installing same certificate as used on LDAPS server as trusted local certificate in container where HeavyDB is running. 
• Firewall rules for HeavyDB reaching LDAP(s) server need to be configured. Security best practices typically dictate that an LDAP server exists within virtual private network, which can make this step challenging unless your HEAVY.AI instance exists within such a network.
• HEAVY.AI is dependent upon LDAP(s) server performance, which can suffer when reporting user groups is not performant (due to # of groups assigned).
• Users must always login to HEAVY.AI, even if already logged in with identity provider hosting LDAP(s) server.
• Credentials are not stored in HEAVY.AI but do pass through for LDAP authentication.
• Just as with local database authentication, limited options for 2FA implementation.
• LDAP itself is an older authentication service model