Fabric allows you to configure both web access and console access according to the authentication methods you choose.
All configuration is managed in Fabric’s main configuration file — config.ini.
For more details about this file, see Fabric Main Configuration Files.
Locate the relevant parameters in the following sections:
Web Access
Controlled by the WEB_AUTHENTICATION_PROTOCOL
property, which can be set to one of two values:
SAML
— Fabric uses SAML as its identity provider (IDP). When this option is selected, the [saml]
section properties must be configured as described later in this article. SERVER_AUTHENTICATOR
— Fabric uses the authenticators defined in the [server_authenticator]
section. WEB_AUTHENTICATION_PROTOCOL
entry may be left commented out.Console Access
Always based on the definitions in the [server_authenticator]
section.
The server_authenticator
property defines which authenticator Fabric should use.
If SAML is not enabled, this property also applies to web access.
Fabric includes five built-in authenticators, which are considered reserved names:
fabric
Uses Fabric itself (system_db) as the authenticator.
cassandra
Uses the Fabric local Cassandra instance as the Fabric System DB.
cassandra.yaml
configuration file, ensure that both parameters are set: authenticator = PasswordAuthenticator
authorizer = CassandraAuthorizer
Important notes:
Note: Fabric supports Cassandra versions 3.11.14, 4.0.3, and 4.1.3 as system DBs.
The requiredauthenticator
andauthorizer
settings apply consistently across all supported versions.
ldap
Connects to a standard LDAP server.
[ldap_auth]
section.adldap
Connects to an Active Directory/LDAP server.
[adldap_auth]
section.block_all
Denies all access.
server_authenticator
property is not defined, the default authenticator is fabric. You can configure a sequence of authenticators by listing them as a comma-separated list in the server_authenticator
property. They are evaluated in order; each serves as a fallback for the one before it.
Example syntax:
server_authenticator=<auth_1>[,<auth_2>,<auth_3>...]
server_authenticator=ldap,fabric
In this setup:
Each authenticator in the sequence must have its corresponding configuration section. For the example above, define the [ldap_auth] section (no extra section is required for fabric).
If you need multiple authenticators of the same type (e.g., two LDAP servers where one is a fallback for the other), follow these steps:
server_authenticator=ldap1,ldap2,fabric
[ldap1_auth]
class_name=com.k2view.fabric.authentication.providers.LdapAuthenticator
# url=ldaps://ldap1.example.com
# admin_dn=cn=admin,dc=example,dc=com
# admin_password=********
# users_base_dn=ou=users,dc=example,dc=com
[ldap2_auth]
class_name=com.k2view.fabric.authentication.providers.LdapAuthenticator
# url=ldaps://ldap2.example.com
# admin_dn=cn=admin,dc=example,dc=com
# admin_password=********
# users_base_dn=ou=users,dc=example,dc=com
This pattern ensures Fabric correctly recognizes and evaluates each authenticator—even when multiple instances of the same type are used.
Integrating Fabric with a SAML Identity Provider (IdP) requires an exchange of configuration details between the Identity Provider (IdP) and the Service Provider (SP) (Fabric). Each side must upload and configure the information provided by the other.
Obtain the following values from your IdP’s administration interface:
IdP Entity ID
A unique identifier for the IdP.
IdP Service URL
The IdP endpoint to which Fabric redirects users for authentication.
Certificate File
The IdP’s public key certificate. Import it into the Fabric truststore with the following command:
keytool -importcert \
-alias <ALIAS-NAME> \
-file <full-path-to-downloaded-cert-file> \
-storetype JKS \
-keystore <full-path-to-truststore-file>
The truststore path and related parameters are defined in the jvm.options
file.
In the TLS/SSL SETTINGS section, check the property:
$K2_HOME/.cassandra_ssl/cassandra.truststore
The chosen alias name must also be set in the configuration for the IDP_CERT_ALIAS property. (You may use any alias name, as long as it matches here and in the configuration.)
keytool -export \
-alias <ALIAS-NAME> \
-storepass <password> \
-file <output-filename>.cer \
-keystore <full-path-to-keystore-file>
The keystore path and related parameters are set in the jvm.options
file. In the TLS/SSL SETTINGS section, review the javax.net.ssl.keyStore
property. These values are configured for a hardened environment. For example: $K2_HOME/.cassandra_ssl/keystore.jks
.
The specified alias name must be used for the SP_CERT_ALIAS property in your configuration. fabric_cert
is used by default in the config.ini. Ensure that you use the alias of the already stored certificate. Please verify the alias using the keytool list command.
Use the same alias value in the configuration for the SP_CERT_ALIAS
property. Confirm the alias exists by running:
```bash
keytool -list -keystore <full-path-to-keystore-file>
```
If you need to generate a self-signed certificate, you can follow the steps of the Generating a Self-Signed Certificate in Fabric article explains how to create using the certificates.sh
helper script, and alternatively, how to use the keytool
utility directly.
You can verify the certification keys by using this command: keytool -list -storepass <password> -keystore <path to the JKS repository file>
. JKS (Java KeyStore) is a repository of security certificates – either authorization certificates or public key certificates – along with their corresponding private keys.
While running this command after running the above two keytool's import and export commands, you will see the corresponding two entries and notice, for each entry, its alias, last modified date, its type, and its fingerprint. Below is an example of the command's output using Okta as IDP:
okta, Apr 28, 2021, trustedCertEntry, Certificate fingerprint (SHA1): 7F:CD:76:A6:B2:47:53:7E:BD:9E:20:44:B0:25:6B:78:A9:E3:25:40
k2view, Apr 18, 2021, PrivateKeyEntry, Certificate fingerprint (SHA1): 2C:9B:F3:8E:60:E6:BC:9F:82:84:A6:55:BE:62:2B:87:7D:42:BB:46
For more information about keystore handling, please read here.
For more information and guidelines as to where and how this information should be set in IDPs, refer to Azure AD SAML Setup Guide and Okta SAML Setup Guide.
The following configuration actions should be applied in the Fabric config.ini configuration file, using the information set and acquired during the preparation step.
Edit these properties in the [saml]
section:
https://<HOSTNAME>:<PORT>/api/authenticate
. The host name should be the Fabric load balancer hostname (a DNS name can also be used). This property is also populated on the IDP side.Moreover, the WEB_AUTHENTICATION_PROTOCOL
property's value shall be set to "SAML".
When Fabric is running on a Windows OS, typically during project implementation or testing, when working locally, the following additional steps are required in relation to the certification files.
When LDAP is used as an authenticator, an admin role is automatically created for Fabric Bootstrap. The admin role's name should be configured in the admin_privileges configuration file (Use $K2_HOME/config.template/admin_privileges.template file as reference).
The LDAP owner should provide the name of the role.
When working with LDAPS (this is a secure LDAP), you must get a certificate file from the LDAP owner and import it into the Fabric truststore as shown:
The adldap_auth
or ldap_auth
sections must define the following:
The LDAP owner should provide the values.
The instructions for using LDAP and LDAPS can be found here.
To use a custom authenticator, do the following in the config.ini:
server_authenticator
authenticator list.<authenticator_name>_auth
. For more information about customer authenticator implementation, read here.
Fabric allows you to configure both web access and console access according to the authentication methods you choose.
All configuration is managed in Fabric’s main configuration file — config.ini.
For more details about this file, see Fabric Main Configuration Files.
Locate the relevant parameters in the following sections:
Web Access
Controlled by the WEB_AUTHENTICATION_PROTOCOL
property, which can be set to one of two values:
SAML
— Fabric uses SAML as its identity provider (IDP). When this option is selected, the [saml]
section properties must be configured as described later in this article. SERVER_AUTHENTICATOR
— Fabric uses the authenticators defined in the [server_authenticator]
section. WEB_AUTHENTICATION_PROTOCOL
entry may be left commented out.Console Access
Always based on the definitions in the [server_authenticator]
section.
The server_authenticator
property defines which authenticator Fabric should use.
If SAML is not enabled, this property also applies to web access.
Fabric includes five built-in authenticators, which are considered reserved names:
fabric
Uses Fabric itself (system_db) as the authenticator.
cassandra
Uses the Fabric local Cassandra instance as the Fabric System DB.
cassandra.yaml
configuration file, ensure that both parameters are set: authenticator = PasswordAuthenticator
authorizer = CassandraAuthorizer
Important notes:
Note: Fabric supports Cassandra versions 3.11.14, 4.0.3, and 4.1.3 as system DBs.
The requiredauthenticator
andauthorizer
settings apply consistently across all supported versions.
ldap
Connects to a standard LDAP server.
[ldap_auth]
section.adldap
Connects to an Active Directory/LDAP server.
[adldap_auth]
section.block_all
Denies all access.
server_authenticator
property is not defined, the default authenticator is fabric. You can configure a sequence of authenticators by listing them as a comma-separated list in the server_authenticator
property. They are evaluated in order; each serves as a fallback for the one before it.
Example syntax:
server_authenticator=<auth_1>[,<auth_2>,<auth_3>...]
server_authenticator=ldap,fabric
In this setup:
Each authenticator in the sequence must have its corresponding configuration section. For the example above, define the [ldap_auth] section (no extra section is required for fabric).
If you need multiple authenticators of the same type (e.g., two LDAP servers where one is a fallback for the other), follow these steps:
server_authenticator=ldap1,ldap2,fabric
[ldap1_auth]
class_name=com.k2view.fabric.authentication.providers.LdapAuthenticator
# url=ldaps://ldap1.example.com
# admin_dn=cn=admin,dc=example,dc=com
# admin_password=********
# users_base_dn=ou=users,dc=example,dc=com
[ldap2_auth]
class_name=com.k2view.fabric.authentication.providers.LdapAuthenticator
# url=ldaps://ldap2.example.com
# admin_dn=cn=admin,dc=example,dc=com
# admin_password=********
# users_base_dn=ou=users,dc=example,dc=com
This pattern ensures Fabric correctly recognizes and evaluates each authenticator—even when multiple instances of the same type are used.
Integrating Fabric with a SAML Identity Provider (IdP) requires an exchange of configuration details between the Identity Provider (IdP) and the Service Provider (SP) (Fabric). Each side must upload and configure the information provided by the other.
Obtain the following values from your IdP’s administration interface:
IdP Entity ID
A unique identifier for the IdP.
IdP Service URL
The IdP endpoint to which Fabric redirects users for authentication.
Certificate File
The IdP’s public key certificate. Import it into the Fabric truststore with the following command:
keytool -importcert \
-alias <ALIAS-NAME> \
-file <full-path-to-downloaded-cert-file> \
-storetype JKS \
-keystore <full-path-to-truststore-file>
The truststore path and related parameters are defined in the jvm.options
file.
In the TLS/SSL SETTINGS section, check the property:
$K2_HOME/.cassandra_ssl/cassandra.truststore
The chosen alias name must also be set in the configuration for the IDP_CERT_ALIAS property. (You may use any alias name, as long as it matches here and in the configuration.)
keytool -export \
-alias <ALIAS-NAME> \
-storepass <password> \
-file <output-filename>.cer \
-keystore <full-path-to-keystore-file>
The keystore path and related parameters are set in the jvm.options
file. In the TLS/SSL SETTINGS section, review the javax.net.ssl.keyStore
property. These values are configured for a hardened environment. For example: $K2_HOME/.cassandra_ssl/keystore.jks
.
The specified alias name must be used for the SP_CERT_ALIAS property in your configuration. fabric_cert
is used by default in the config.ini. Ensure that you use the alias of the already stored certificate. Please verify the alias using the keytool list command.
Use the same alias value in the configuration for the SP_CERT_ALIAS
property. Confirm the alias exists by running:
```bash
keytool -list -keystore <full-path-to-keystore-file>
```
If you need to generate a self-signed certificate, you can follow the steps of the Generating a Self-Signed Certificate in Fabric article explains how to create using the certificates.sh
helper script, and alternatively, how to use the keytool
utility directly.
You can verify the certification keys by using this command: keytool -list -storepass <password> -keystore <path to the JKS repository file>
. JKS (Java KeyStore) is a repository of security certificates – either authorization certificates or public key certificates – along with their corresponding private keys.
While running this command after running the above two keytool's import and export commands, you will see the corresponding two entries and notice, for each entry, its alias, last modified date, its type, and its fingerprint. Below is an example of the command's output using Okta as IDP:
okta, Apr 28, 2021, trustedCertEntry, Certificate fingerprint (SHA1): 7F:CD:76:A6:B2:47:53:7E:BD:9E:20:44:B0:25:6B:78:A9:E3:25:40
k2view, Apr 18, 2021, PrivateKeyEntry, Certificate fingerprint (SHA1): 2C:9B:F3:8E:60:E6:BC:9F:82:84:A6:55:BE:62:2B:87:7D:42:BB:46
For more information about keystore handling, please read here.
For more information and guidelines as to where and how this information should be set in IDPs, refer to Azure AD SAML Setup Guide and Okta SAML Setup Guide.
The following configuration actions should be applied in the Fabric config.ini configuration file, using the information set and acquired during the preparation step.
Edit these properties in the [saml]
section:
https://<HOSTNAME>:<PORT>/api/authenticate
. The host name should be the Fabric load balancer hostname (a DNS name can also be used). This property is also populated on the IDP side.Moreover, the WEB_AUTHENTICATION_PROTOCOL
property's value shall be set to "SAML".
When Fabric is running on a Windows OS, typically during project implementation or testing, when working locally, the following additional steps are required in relation to the certification files.
When LDAP is used as an authenticator, an admin role is automatically created for Fabric Bootstrap. The admin role's name should be configured in the admin_privileges configuration file (Use $K2_HOME/config.template/admin_privileges.template file as reference).
The LDAP owner should provide the name of the role.
When working with LDAPS (this is a secure LDAP), you must get a certificate file from the LDAP owner and import it into the Fabric truststore as shown:
The adldap_auth
or ldap_auth
sections must define the following:
The LDAP owner should provide the values.
The instructions for using LDAP and LDAPS can be found here.
To use a custom authenticator, do the following in the config.ini:
server_authenticator
authenticator list.<authenticator_name>_auth
. For more information about customer authenticator implementation, read here.