Starburst Enterprise platform (SEP) supports multiple authentication types to ensure all users of the system are authenticated. Different authenticators allow user management in one or more systems. Using TLS and a configured shared secret are required for all authentications types.
You can configure one or more authentication types with the
http-server.authentication.type property. The following authentication types
and authenticators are available:
OAUTH2for OAuth 2.0 authentication
SAMLfor SAML 2.0 authentication
OKTAfor Okta authentication
KERBEROSfor Kerberos authentication
CERTIFICATEfor Certificate authentication
JWTfor JWT authentication
HEADERfor Header authenticator
Get started with a basic password authentication configuration backed by a password file:
Multiple authentication types#
You can use multiple authentication types, separated with commas in the configuration:
Authentication is performed in order of the entries, and the first successful authentication results in access, using the mapped user from that authentication method.
Multiple password authenticators#
You can use multiple password authenticator types by referencing multiple configuration files:
In the preceding example, the configuration files
ldap2.properties are regular LDAP authenticator configuration files. The
password.properties is a password file authenticator configuration file.
Relative paths to the installation directory or absolute paths can be used.
User authentication credentials are first validated against the LDAP server from
ldap1, then the separate server from
ldap2, and finally the password
file. First successful authentication results in access, and no further
authenticators are called.
Multiple header authenticators#
You can use multiple header authenticator types by referencing multiple configuration files:
You can use either relative or absolute paths to the installation directory.
The pre-configured headers are first validated against the
authenticator, then the
azureAD authenticator. First successful
authentication results in access, and no further authenticators are called.