Follow these instructions to start an HEAVY.AI server with an encrypted main port.
You need the following PKI (Public Key Infrastructure) components to implement a Secure Binary Interface.
A CRT (short for certificate) file containing the server's PKI certificate. This file must be shared with the clients that connect using encrypted communications. Ideally, this file is signed by a recognized certificate issuing agency.
A key file containing the server's private key. Keep this file secret and secure.
A Java TrustStore containing the server's PKI certificate. The password for the trust store is also required.
Although in this instance the trust store contains only information that can be shared, the Java TrustStore program requires it to be password protected.
A Java KeyStore and password.
In a distributed system, add the configuration parameters to the heavyai.conf file on the aggregator and all leaf nodes in your HeavyDB cluster.
You can use OpenSSL utilities to create the various PKI elements. The server certificate in this instance is self-signing, and should not be used in a production system.
Generate a new private key.
Use the private key to generate a certificate signing request.
Self sign the certificate signing request to create a public certificate.
Use the Java tools to create a key store from the public certificate.
To generate a keystore file from your server key:
Copy server.key to server.txt. Concatenate it with server.crt.
Use server.txt to create a PKCS12 file.
Use server.p12 to create a keystore.
Start the server using the following options.
Alternatively, you can add the following configuration parameters to heavyai.conf to establish a Secure Binary Interface. The following configuration flags implement the same encryption shown in the runtime example above:
Passwords for the SSL truststore and keystore can be enclosed in single (') or double (") quotes.
The server.crt file and the Java truststore contain the same public key information in different formats. Both are required by the server to establish both the secure client communication with the various interfaces and with its Calcite server. At startup, the Java truststore is passed to the Calcite server for authentication and to encrypt its traffic with the HEAVY.AI server.
HEAVY.AI supports LDAP authentication using an IPA Server or Microsoft Active Directory.
You can configure HEAVY.AI Enterprise edition to map LDAP roles 1-to-1 to HEAVY.AI roles. When you enable this mapping, LDAP becomes the main authority controlling user roles in HEAVY.AI.
LDAP mapping is available only in HEAVY.AI Enterprise edition.
HEAVY.AI supports five configuration settings that allow you to integrate with your LDAP server.
To find the ldap-role-query-url and ldap-role-query-regex to use, query your user roles. For example, if there is a user named kiran on the IPA LDAP server ldap://myldapserver.mycompany.com, you could use the following curl command to get the role information:
When successful, it returns information similar to the following:
ldap-dn matches the DN, which is uid=kiran,cn=users,cn=accounts,dc=mycompany,dc=com.
ldap-role-query-url includes the LDAP URI + the DN + the LDAP attribute that represents the role/group the member belongs to, such as memberOf.
ldap-role-query-regex is a regular expression that matches the role names. The matching role names are used to grant and revoke privileges in HEAVY.AI. For example, if we created some roles on an IPA LDAP server where the role names begin with MyCompany_ (for example, MyCompany_Engineering, MyCompany_Sales, MyCompany_SuperUser), the regular expression can filter the role names using MyCompany_.
ldap-superuser-role is the role/group name for HEAVY.AI users who are superusers once they log on to the HEAVY.AI database. In this example, the superuser role name is MyCompany_SuperUser.
Make sure that LDAP configuration appears before the [web] section of heavy.conf.
Double quotes are not required for LDAP properties in heavy.conf. For example, both of the following are valid:
ldap-uri = "ldap://myldapserver.mycompany.com"
ldap-uri = ldap://myldapserver.mycompany.com
To integrate LDAP with HEAVY.AI, you need the following:
A functional LDAP server, with all users/roles/groups created (ldap-uri, ldap-dn, ldap-role-query-url, ldap-role-query-regex, and ldap-superuser-role) to be used by HEAVY.AI. You can use the curl command to test and find the filters.
A functional HEAVY.AI server, version 4.1 or higher.
Once you have your server information, you can configure HEAVY.AI to use LDAP authentication.
Locate the heavy.conf file and edit it to include the LDAP parameter. For example:
Restart the HEAVY.AI server:
Log on to heavysql as MyCompany user, or any user who belongs to one of the roles/groups that match the filter.
When you use LDAP authentication, the default admin user and password HyperInteractive do not work unless you create the admin user with the same password on the LDAP server.
If your login fails, inspect $HEAVYAI_STORAGE/mapd_log/heavyai_server.INFO to check for any obvious errors about LDAP authentication.
Once you log in, you can create a new role name in heavysql, and then apply GRANT/REVOKE privileges to the role. Log in as another user with that role and confirm that GRANT/REVOKE works.
If you refresh the browser window, you are required to log in and reauthenticate.
To use LDAPS, HEAVY.AI must trust the LDAP server's SSL certificate. To achieve this, you must have the CA for the server's certificate, or the server certificate itself. Install the certificate as a trusted certificate.
To use IPA as your LDAP server with HEAVY.AI running on CentOS 7:
Copy the IPA server CA certificate to your local machine.
Update the PKI certificates.
Edit /etc/openldap/ldap.conf to add the following line.
Locate the heavy.conf file and edit it to include the LDAP parameter. For example:
Restart the HEAVY.AI server:
To use IPA as your LDAP server with HEAVY.AI running on Ubuntu:
Copy the IPA server CA certificate to your local machine.
Rename ipa-ca.crm to ipa-ca.crt so that the certificates bundle update script can find it:
Update the PKI certificates:
Edit /etc/openldap/ldap.conf to add the following line:
Locate the heavy.conf file and edit it to include the LDAP parameter. For example:
Restart the HEAVY.AI server:
1. Locate the heavy.conf file and edit it to include the LDAP parameter.
Example 1:
Example 2:
2. Restart the HEAVY.AI server:
Other LDAP user authentication attributes, such as userPrincipalName, are not currently supported.
Parameter | Description | Example |
| LDAP server host or server URI. | |
| LDAP distinguished name (DN). | |
| Returns the role names a user belongs to in the LDAP. | |
| Applies a regex filter to find matching roles from the roles in the LDAP server. | |
| Identifies one of the filtered roles as a superuser role. If a user has this filtered ldap role, the user is marked as a superuser. | |
HEAVY.AI supports data security using a set of database object access privileges granted to users or roles.
When you create a database, the admin superuser is created by default. The admin superuser is granted all privileges on all database objects. Superusers can create new users that, by default, have no database object privileges.
Superusers can grant users selective access privileges on multiple database objects using two mechanisms: role-based privileges and user-based privileges.
Grant roles access privileges on database objects.
Grant roles to users.
Grant roles to other roles.
When a user has privilege requirements that differ from role privileges, you can grant privileges directly to the user. These mechanisms provide data security for many users and classes of users to access the database.
You have the following options for granting privileges:
Each object privilege can be granted to one or many roles, or to one or many users.
A role and/or user can be granted privileges on one or many objects.
A role can be granted to one or many users or other roles.
A user can be granted one or many roles.
This supports the following many-to-many relationships:
Objects and roles
Objects and users
Roles and users
These relationships provide flexibility and convenience when granting/revoking privileges to and from users.
Granting object privileges to roles and users, and granting roles to users, has a cumulative effect. The result of several grant commands is a combination of all individual grant commands. This applies to all database object types and to privileges inherited by objects. For example, object privileges granted to the object of database type are propagated to all table-type objects of that database object.
Only a superuser or an object owner can grant privileges for on object.
A superuser has all privileges on all database objects.
A non-superuser user has only those privileges on a database object that are granted by a superuser.
A non-superuser user has ALL privileges on a table created by that user.
Roles can be created and dropped at any time.
Object privileges and roles can be granted or revoked at any time, and the action takes effect immediately.
Privilege state is persistent and restored if the HEAVY.AI session is interrupted.
There are five database object types, each with its own privileges.
ACCESS - Connect to the database. The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
ALL - Allow all privileges on this database except issuing grants and dropping the database.
SELECT, INSERT, TRUNCATE, UPDATE, DELETE - Allow these operations on any table in the database.
ALTER SERVER - Alter servers in the current database.
CREATE SERVER - Create servers in the current database.
CREATE TABLE - Create a table in the current database. (Also CREATE.)
CREATE VIEW - Create a view for the current database.
CREATE DASHBOARD - Create a dashboard for the current database.
DELETE DASHBOARD - Delete a dashboard for this database.
DROP SERVER - Drop servers from the current database.
DROP - Drop a table from the database.
DROP VIEW - Drop a view for this database.
EDIT DASHBOARD - Edit a dashboard for this database.
SELECT VIEW - Select a view for this database.
SERVER USAGE - Use servers (through foreign tables) in the current database.
VIEW DASHBOARD - View a dashboard for this database.
VIEW SQL EDITOR - Access the SQL Editor in Immerse for this database.
Users with SELECT privilege on views do not require SELECT privilege on underlying tables referenced by the view to retrieve the data queried by the view. View queries work without error whether or not users have direct access to referenced tables. This also applies to views that query tables in other databases.
To create views, users must have SELECT privilege on queried tables in addition to the CREATE VIEW privilege.
SELECT, INSERT, TRUNCATE, UPDATE, DELETE - Allow these SQL statements on this table.
DROP - Drop this table.
Users with SELECT privilege on views do not require SELECT privilege on underlying tables referenced by the view to retrieve the data queried by the view. View queries work without error whether or not users have direct access to referenced tables. This also applies to views that query tables in other databases.
To create views, users must have SELECT privilege on queried tables in addition to the CREATE VIEW privilege.
SELECT - Select from this view. Users do not need privileges on objects referenced by this view.
DROP - Drop this view.
Users with SELECT privilege on views do not require SELECT privilege on underlying tables referenced by the view to retrieve the data queried by the view. View queries work without error whether or not users have direct access to referenced tables. This also applies to views that query tables in other databases.
To create views, users must have SELECT privilege on queried tables in addition to the CREATE VIEW privilege.
VIEW - View this dashboard.
EDIT - Edit this dashboard.
DELETE - Delete this dashboard.
DROP - Drop this server from the current database.
ALTER - Alter this server in the current database.
USAGE - Use this server (through foreign tables) in the current database.
Privileges granted on a database-type object are inherited by all tables of that database.
The following example shows a valid sequence for granting access privileges to non-superuser user1 by granting a role to user1 and by directly granting a privilege. This example presumes that table1 and user1 already exist, and that user1 has ACCESS privileges on the database where table1 exists.
Create the r_select role.
Grant the SELECT privilege on table1 to the r_select role. Any user granted the r_select role gains the SELECT privilege.
Grant the r_select role to user1, giving user1 the SELECT privilege on table1.
Directly grant user1 the INSERT privilege on table1.
Create a role. Roles are granted to users for role-based database object access.
This clause requires superuser privilege and <roleName> must not exist.
<roleName>
Name of the role to create.
Create a payroll department role called payrollDept.
Remove a role.
This clause requires superuser privilege and <roleName> must exist.
<roleName>
Name of the role to drop.
Remove the payrollDept role.
Grant role privileges to users and to other roles.
The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
This clause requires superuser privilege. The specified <roleNames> and <userNames> must exist.
<roleNames>
Names of roles to grant to users and other roles. Use commas to separate multiple role names.
<userNames>
Names of users. Use commas to separate multiple user names.
Assign payrollDept role privileges to user dennis.
Grant payrollDept and accountsPayableDept role privileges to users dennis and mike and role hrDept.
Remove role privilege from users or from other roles. This removes database object access privileges granted with the role.
This clause requires superuser privilege. The specified <roleNames> and <userNames> must exist.
<roleNames>
Names of roles to remove from users and other roles. Use commas to separate multiple role names.
<userName>
Names of the users. Use commas to separate multiple user names.
Remove payrollDept role privileges from user dennis.
Revoke payrollDept and accountsPayableDept role privileges from users dennis and fred and role hrDept.
Define the privilege(s) a role or user has on the specified table. You can specify any combination of the INSERT, SELECT, DELETE, UPDATE, DROP, or TRUNCATE privilege or specify all privileges.
The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
This clause requires superuser privilege, or <tableName> must have been created by the user invoking this command. The specified <tableName> and users or roles defined in <entityList> must exist.
<privilegeList>
<tableName>
Name of the database table.
<entityList>
Name of entity or entities to be granted the privilege(s).
Permit all privileges on the employees table for the payrollDept role.
Permit SELECT-only privilege on the employees table for user chris.
Permit INSERT-only privilege on the employees table for the hrdept and accountsPayableDept roles.
Permit INSERT, SELECT, and TRUNCATE privileges on the employees table for the role hrDept and for users dennis and mike.
Remove the privilege(s) a role or user has on the specified table. You can remove any combination of the INSERT, SELECT, DELETE, UPDATE, or TRUNCATE privileges, or remove all privileges.
This clause requires superuser privilege or <tableName> must have been created by the user invoking this command. The specified <tableName> and users or roles in <entityList> must exist.
<privilegeList>
<tableName>
Name of the database table.
<entityList>
Name of entities to be denied the privilege(s).
Prohibit SELECT and INSERT operations on the employees table for the nonemployee role.
Prohibit SELECT operations on the directors table for the employee role.
Prohibit INSERT operations on the directors table for role employee and user laura.
Prohibit INSERT, SELECT, and TRUNCATE privileges on the employees table for the role nonemployee and for users dennis and mike.
Define the privileges a role or user has on the specified view. You can specify any combination of the SELECT, INSERT, or DROP privileges, or specify all privileges.
This clause requires superuser privileges, or <viewName> must have been created by the user invoking this command. The specified <viewName> and users or roles in <entityList> must exist.
<privilegeList>
<viewName>
Name of the database view.
<entityList>
Name of entities to be granted the privileges.
Permit SELECT, INSERT, and DROP privileges on the employees view for the payrollDept role.
Permit SELECT-only privilege on the employees view for the employee role and user venkat.
Permit INSERT and DROP privileges on the employees view for the hrDept and acctPayableDept roles and users simon and dmitri.
Remove the privileges a role or user has on the specified view. You can remove any combination of the INSERT, DROP, or SELECT privileges, or remove all privileges.
This clause requires superuser privilege, or <viewName> must have been created by the user invoking this command. The specified <viewName> and users or roles in <entityList> must exist.
<privilegeList>
<viewName>
Name of the database view.
<entityList>
Name of entity to be denied the privilege(s).
Prohibit SELECT, DROP, and INSERT operations on the employees view for the nonemployee role.
Prohibit SELECT operations on the directors view for the employee role.
Prohibit INSERT and DROP operations on the directors view for the employee and manager role and for users ashish and lindsey.
Define the valid privileges a role or user has on the specified database. You can specify any combination of privileges, or specify all privileges.
The ACCESS privilege is a prerequisite for all other privileges at the database level. Without the ACCESS privilege, a user or role cannot perform tasks on any other database objects.
This clause requires superuser privileges.
<privilegeList>
<dbName>
Name of the database, which must exist, created by CREATE DATABASE.
<entityList>
Name of the entity to be granted the privilege.
Permit all operations on the companydb database for the payrollDept role and user david.
Permit SELECT-only operations on the companydb database for the employee role.
Permit INSERT, UPDATE, and DROP operations on the companydb database for the hrdept and manager role and for users irene and stephen.
Remove the operations a role or user can perform on the specified database. You can specify privileges individually or specify all privileges.
This clause requires superuser privilege or the user must own the database object. The specified <dbName> and roles or users in <entityList> must exist.
<privilegeList>
<dbName>
Name of the database.
<entityList>
Prohibit all operations on the employees database for the nonemployee role.
Prohibit SELECT operations on the directors database for the employee role and for user monica.
Prohibit INSERT, DROP, CREATE, and DELETE operations on the directors database for employee role and for users max and alex.
Define the valid privileges a role or user has for working with servers. You can specify any combination of privileges or specify all privileges.
This clause requires superuser privileges, or <serverName> must have been created by the user invoking the command.
<privilegeList>
<serverName>
Name of the server, which must exist on the current database, created by CREATE SERVER ON DATABASE.
<entityList>
Grant DROP privilege on server parquet_s3_server to user fred:
Grant ALTER privilege on server parquet_s3_server to role payrollDept:
Grant USAGE and ALTER privileges on server parquet_s3_server to role payrollDept and user jamie:
Remove privileges a role or user has for working with servers. You can specify any combination of privileges or specify all privileges.
This clause requires superuser privileges, or <serverName> must have been created by the user invoking the command.
<privilegeList>
<serverName>
Name of the server, which must exist on the current database, created by CREATE SERVER ON DATABASE.
<entityList>
Revoke DROP privilege on server parquet_s3_server for user inga:
Grant ALTER privilege on server parquet_s3_server for role payrollDept:
Grant USAGE and ALTER privileges on server parquet_s3_server for role payrollDept and user marvin:
Define the valid privileges a role or user has for working with dashboards. You can specify any combination of privileges or specify all privileges.
This clause requires superuser privileges.
<privilegeList>
<dashboardId>
ID of the dashboard, which must exist, created by CREATE DASHBOARD. To show a list of all dashboards and IDs in heavysql, run the \dash command when logged in as superuser.
<entityList>
Permit all privileges on the dashboard ID 740 for the payrollDept role.
Permit VIEW-only privilege on dashboard 730 for the hrDept role and user dennis.
Permit EDIT and DELETE privileges on dashboard 740 for the hrDept and accountsPayableDept roles and for user pavan.
Remove privileges a role or user has for working with dashboards. You can specify any combination of privileges, or all privileges.
This clause requires superuser privileges.
<privilegeList>
<dashboardId>
ID of the dashboard, which must exist, created by CREATE DASHBOARD.
<entityList>
Revoke DELETE privileges on dashboard 740 for the payrollDept role.
Revoke all privileges on dashboard 730 for hrDept role and users dennis and mike.
Revoke EDIT and DELETE of dashboard 740 for the hrDept and accountsPayableDept roles and for users dante and jonathan.
The following privilege levels are typically recommended for non-superusers in Immerse. Privileges assigned for users in your organization may vary depending on access requirements.
These examples assume that tables table1 through table4 are created as needed:
The following examples show how to work with users, roles, tables, and dashboards.
Use the \dash command to list all dashboards and their unique IDs in HEAVY.AI:
Here, the Marketing_Summary dashboard uses table2 as a data source. The role marketingDeptRole2 has select privileges on that table. Grant view access on the Marketing_Summary dashboard to marketingDeptRole2:
The following table shows the roles and privileges for each user created in the previous example.
Use the following commands to list current roles and assigned privileges. If you have superuser access, you can see privileges for all users. Otherwise, you can see only those roles and privileges for which you have access.
Results for users, roles, privileges, and object privileges are returned in creation order.
Lists all dashboards and dashboard IDs in HEAVY.AI. Requires superuser privileges. Dashboard privileges are assigned by dashboard ID because dashboard names may not be unique.
Example
heavysql> \dash database heavyai
Dashboard ID | Dashboard Name | Owner
1 | Marketing_Summary | heavyai
Reports all privileges granted to the specified object for all roles and users. If the specified objectName does not exist, no results are reported. Used for databases and tables only.
Example
Reports all object privileges granted to the specified role or user. The roleName or userName specified must exist.
Example
Reports all roles granted to the given user. The userName specified must exist.
Example
Reports all roles.
Example
Lists all users.
Example
The following example demonstrates field-level security using two views:
view_users_limited, in which users only see three of seven fields: userid, First_Name, and Department.
view_users_full, users see all seven fields.
User readonly1 sees no tables, only the specific view granted, and only the three specific columns returned in the view:
User readonly2 sees no tables, only the specific view granted, and all seven columns returned in the view:
HEAVY.AI can accept a set of encrypted credentials for secure authentication of a custom application. This topic provides a method for providing an encryption key to generate encrypted credentials and configuration options for enabling decryption of those encrypted credentials.
Generate a 128- or 256-bit encryption key and save it to a file. You can use to generate a suitable encryption key.
Set the file path of the encryption key file to the encryption-key-file-path web server parameter in heavyai.conf:
Alternatively, you can set the path using the --encryption-key-file-path=path/to/file command-line argument.
Generate encrypted credentials for a custom application by running the following Go program, replacing the example key and credentials strings with an actual key and actual credentials. You can also run the program in a web browser at .
Security Assertion Markup Language (SAML) is used for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions (statements that service providers use to make decisions about access control) to pass information about a principal (usually an end user) between a SAML authority, named an Identity Provider (IdP), and a SAML consumer, named a Service Provider (SP). SAML enables web-based, cross-domain, single sign-on (SSO), which helps reduce the administrative overhead of sending multiple authentication tokens to the user.
If you use SAML for authentication to HEAVY.AI, and SAML login fails, HEAVY.AI automatically falls back to log in using LDAP if it is configured.
If both SAML and LDAP authentication fail, you are authenticated against a locally stored password, but only if the allow-local-auth-fallback flag is set.
These instructions use as the IdP and HEAVY.AI as the SP in an SP-initiated workflow, similar to the following:
A user uses a login page to connect to HEAVY.AI.
The HEAVY.AI login page redirects the user to the Okta login page.
The user signs in using an Okta account. (This step is skipped if the user is already logged in to Okta.)
Okta returns a base64-encoded SAML Response to the user, which contains a SAML Assertion that the user is allowed to use HEAVY.AI. If configured, it also returns a list of SAML Groups assigned to the user.
Okta redirects the user to the HEAVY.AI login page together with the SAML response (a token).
HEAVY.AI verifies the token, and retrieves the user name and groups. Authentication and authorization is complete.
In addition to Okta, the following SAML providers are also supported:
1) Log into your Okta account and click the Admin button.
2) From the Applications menu, select Applications.
3) Click the Add Application button.
4) On the Add Application screen, click Create New App.
5) On the Create a New Application Integration page, set the following details:
Platform: Web
Sign on Method: SAML 2.0
And then, click Create.
6) On the Create SAML Integration page, in the App name field, type Heavyai and click Next.
7) In the SAML Settings page, enter the following information:
Audience URI (SP Entity ID): Your Heavy Immerse web URL with the suffix saml-post.
Default RelayState: Forward slash (/).
Application username: HEAVY.AI recommends using the email address you used to log in to Okta.
Leave other settings at their default values, or change as required for your specific installation.
After making your selections, click Next.
8) In the Help Okta Support... page, click I'm an Okta customer adding an internal app. All other questions on this page are optional.
After making your selections, click Finish.
Your application is now registered and displayed, and the Sign On tab is selected.
Before configuring SAML, make sure that HTTPS is enabled on your web server.
On the Sign On tab, configure SAML settings for your application:
1) On the Settings page, click View Setup Instructions.
2) On the How to Configure SAML 2.0 for HEAVY.AI Application page, scroll to the bottom, copy the XML fragment in the Provide the following IDP metadata to your SP provider box, and save it as a raw text file called idp.xml.
3) Upload idp.xml to your HEAVY.AI server in $HEAVYAI_STORAGE.
4) Edit heavy.conf and add the following configuration parameters:
saml-metadata-file: Path to the idp.xml file you created.
saml-sp-target-url: Web URL to your Heavy Immerse saml-post endpoint.
saml-signed-assertion: Boolean value that determines whether Okta signs the assertion; true by default.
saml-signed-response: Boolean value that determines whether Okta signs the response; true by default.
For example:
In the web section, add the full physical path to the servers.json file; for example:
5) On the How to Configure SAML 2.0 for HEAVY.AI Application page, copy the Identity Provider Single Sign-On URL, which looks similar to this:
6) If the servers.json file you identified in the [web] section of heavy.conf does not exist, create it. In servers.json, include the SAMLurl property, using the same value you copied in Identify Provider Single Sign-On URL. For example:
7) Restart the heavyai_server and heavyai_web_server services.
Users can be automatically created in HEAVY.AI based on group membership:
1) Go to the Application Configuration page for the HEAVY.AI application in Okta.
2) On the General tab, scroll to the SAML Settings section and click the Edit button.
3) Click the Next button, and then in the Group Attribute Statements section, set the following:
Name: Groups
Filter: Set to the desired filter type to determine the set of groups delivered to HEAVY.AI through the SAML response. In the text box next to the Filter type drop-down box, enter the text that defines the filter.
Click Next, and then click Finish.
Any group that requires access to HEAVY.AI must be created in HEAVY.AI before users can log in.
Modify your heavyai.conf file by adding the following parameter:
The heavyai.conf entries now look like this:
Restart the heavyai_server and heavyai_web_server processes.
Users whose group membership in Okta contains a group name that exists in HeavyDB can log in and have the privileges assigned to their groups.
1) On the Okta website, on the Assignments tab, click Assign > Assign to People.
2) On the Assign HEAVY.AI to People panel, click the Assign button next to users that you want to provide access to HEAVY.AI.
3) Click Save and Go Back to assign HEAVY.AI to the user.
) Repeat steps 2 and 3 for all users to whom you want to grant access. Click Done when you are finished.
Verify that the SAML is configured correctly by opening your Heavy Immerse login page. You should be automatically redirected to the Okta login page, and then back to Immerse, without entering credentials.
When you log out of Immerse, you see the following screen:
Logging out of Immerse does not log you out of Okta. If you log back in to Immerse and are still logged in to Okta, you do not need to reathenticate.
If authentication fails, you see this error message when you attempt to log in through Okta:
To resolve the authentication error:
Add the license information by either:
Adding heavyai.license to your HEAVY.AI data directory.
Logging in to HeavyDB and run the following command:
Reattempt login through Okta.
The Information about authentication errors can be found in the log files.
See for a more complete example.
E
Begin by adding your SAML application in Okta. If you do not have an Okta account, you can sign up on the .
Single sign on URL: Your Heavy Immerse web URL with the suffix saml-post; for example, . Select the Use this for Recipient URL and Destination URL checkbox.
User accounts assigned to the HEAVY.AI application in Okta must exist in HEAVY.AI before a user can log in. To have users created automatically based on their group membership, see .
Parameter Value | Descriptions |
| Grant all possible access privileges on <tableName> to <entityList>. |
| Grant ALTER TABLE privilege on <tableName> to <entityList>. |
| Grant DELETE privilege on <tableName> to <entityList>. |
| Grant DROP privilege on <tableName> to <entityList>. |
| Grant INSERT privilege on <tableName> to <entityList>. |
| Grant SELECT privilege on <tableName> to <entityList>. |
| Grant TRUNCATE privilege on <tableName> to <entityList>. |
| Grant UPDATE privilege on <tableName> to <entityList>. |
Parameter Value | Descriptions |
| Name of role. |
| Name of user. |
Parameter Value | Descriptions |
| Remove all access privilege for <entityList> on <tableName>. |
| Remove ALTER TABLE privilege for <entityList> on <tableName>. |
| Remove DELETE privilege for <entityList> on <tableName>. |
| Remove DROP privilege for <entityList> on <tableName>. |
| Remove INSERT privilege for <entityList> on <tableName>. |
| Remove SELECT privilege for <entityList> on <tableName>. |
| Remove TRUNCATE privilege for <entityList> on <tableName>. |
| Remove UPDATE privilege for <entityList> on <tableName>. |
Parameter Value | Descriptions |
| Name of role. |
| Name of user. |
Parameter Value | Descriptions |
| Grant all possible access privileges on <viewName> to <entityList>. |
| Grant DROP privilege on <viewName> to <entityList>. |
| Grant INSERT privilege on <viewName> to <entityList>. |
| Grant SELECT privilege on <viewName> to <entityList>. |
Parameter Value | Descriptions |
| Name of role. |
| Name of user. |
Parameter Value | Descriptions |
| Remove all access privilege for <entityList> on <viewName>. |
| Remove DROP privilege for <entityList> on <viewName>. |
| Remove INSERT privilege for <entityList> on <viewName>. |
| Remove SELECT privilege for <entityList> on <viewName>. |
Parameter Value | Descriptions |
| Name of role. |
| Name of user. |
Parameter Value | Descriptions |
| Grant ACCESS (connection) privilege on <dbName> to <entityList>. |
| Grant all possible access privileges on <dbName> to <entityList>. |
| Grant ALTER TABLE privilege on <dbName> to <entityList>. |
| Grant ALTER SERVER privilege on <dbName> to <entityList>. |
| Grant CREATE SERVER privilege on <dbName> to <entityList>; |
| Grant CREATE TABLE privilege on <dbName> to <entityList>. Previously |
| Grant CREATE VIEW privilege on <dbName> to <entityList>. |
| Grant CREATE DASHBOARD privilege on <dbName> to <entityList>. |
| Grant CREATE privilege on <dbName> to <entityList>. |
| Grant DELETE privilege on <dbName> to <entityList>. |
| Grant DELETE DASHBOARD privilege on <dbName> to <entityList>. |
| Grant DROP privilege on <dbName> to <entityList>. |
| Grant DROP privilege on <dbName> to <entityList>. |
| Grant DROP VIEW privilege on <dbName> to <entityList>. |
| Grant EDIT DASHBOARD privilege on <dbName> to <entityList>. |
| Grant INSERT privilege on <dbName> to <entityList>. |
| Grant SELECT privilege on <dbName> to <entityList>. |
| Grant SELECT VIEW privilege on <dbName> to <entityList>. |
| Grant SERVER USAGE privilege on <dbName> to <entityList>. |
| Grant TRUNCATE privilege on <dbName> to <entityList>. |
| Grant UPDATE privilege on <dbName> to <entityList>. |
| Grant VIEW DASHBOARD privilege on <dbName> to <entityList>. |
| Grant VIEW SQL EDITOR privilege in Immerse on <dbName> to <entityList>. |
Parameter Value | Descriptions |
| Remove ACCESS (connection) privilege on <dbName> from <entityList>. |
| Remove all possible privileges on <dbName> from <entityList>. |
| Remove ALTER SERVER privilege on <dbName> from <entityList> |
| Remove ALTER TABLE privilege on <dbName> from <entityList>. |
| Remove CREATE TABLE privilege on <dbName> from <entityList>. Previously |
| Remove CREATE VIEW privilege on <dbName> from <entityList>. |
| Remove CREATE DASHBOARD privilege on <dbName> from <entityList>. |
| Remove CREATE privilege on <dbName> from <entityList>. |
| Remove CREATE SERVER privilege on <dbName> from <entityList>. |
| Remove DELETE privilege on <dbName> from <entityList>. |
| Remove DELETE DASHBOARD privilege on <dbName> from <entityList>. |
| Remove DROP privilege on <dbName> from <entityList>. |
| Remove DROP SERVER privilege on <dbName> from <entityList>. |
| Remove DROP VIEW privilege on <dbName> from <entityList>. |
| Remove EDIT DASHBOARD privilege on <dbName> from <entityList>. |
| Remove INSERT privilege on <dbName> from <entityList>. |
| Remove SELECT privilege on <dbName> from <entityList>. |
| Remove SELECT VIEW privilege on <dbName> from <entityList>. |
| Remove SERVER USAGE privilege on <dbName> from <entityList>. |
| Remove TRUNCATE privilege on <dbName> from <entityList>. |
| Remove UPDATE privilege on <dbName> from <entityList>. |
| Remove VIEW DASHBOARD privilege on <dbName> from <entityList>. |
| Remove VIEW SQL EDITOR privilege in Immerse on <dbName> from <entityList>. |
Parameter Value | Descriptions |
| Name of role. |
| Name of user. |
Parameter Value | Descriptions |
| Grant DROP privileges on <serverName> on current database to <entityList>. |
| Grant ALTER privilege on <serverName> on current database to <entityList>. |
| Grant USAGE privilege (through foreign tables) on <serverName> on current database to <entityList>. |
Parameter Value | Descriptions |
| Remove DROP privileges on <serverName> on current database for <entityList>. |
| Remove ALTER privilege on <serverName> on current database for <entityList>. |
| Remove USAGE privilege (through foreign tables) on <serverName> on current database for <entityList>. |
Parameter Value | Descriptions |
| Grant all possible access privileges on <dashboardId> to <entityList>. |
| Grant CREATE privilege to <entityList>. |
| Grant DELETE privilege on <dashboardId> to <entityList>. |
| Grant EDIT privilege on <dashboardId> to <entityList>. |
| Grant VIEW privilege on <dashboardId> to <entityList>. |
Parameter Value | Descriptions |
| Revoke all possible access privileges on <dashboardId> for <entityList>. |
| Revoke CREATE privilege for <entityList>. |
| Revoke DELETE privilege on <dashboardId> for <entityList>. |
| Revoke EDIT privilege on <dashboardId> for <entityList>. |
| Revoke VIEW privilege on <dashboardId> for <entityList>. |
Privilege | Command Syntax to Grant Privilege |
Access a database |
|
Create a table |
|
Select a table |
|
View a dashboard |
|
Create a dashboard |
|
Edit a dashboard |
|
Delete a dashboard |
|
User | Roles Granted | Table Privileges |
salesDeptEmployee1 | salesDeptRole1 | SELECT on Tables 1, 3 |
salesDeptEmployee2 | salesDeptRole2 | SELECT on Table 3 |
salesDeptEmployee3 | salesDeptRole2 | SELECT on Table 3 |
salesDeptEmployee4 | salesDeptRole3 | SELECT on Table 4 |
salesDeptManagerEmployee5 | salesDeptRole1, salesDeptRole2, salesDeptRole3 | SELECT on Tables 1, 3, 4 |
marketingDeptEmployee1 | marketingDeptRole1 | SELECT on Tables 1, 2 |
marketingDeptEmployee2 | marketingDeptRole2 | SELECT on Table 2 |
marketingDeptManagerEmployee3 | marketingDeptRole1, marketingDeptRole2, salesDeptRole1, salesDeptRole2, salesDeptRole3 | SELECT on Tables 1, 2, 3, 4 |
SQL | Description |
Create role. |
Drop role. |
Grant role to user or to another role. |
Revoke role from user or from another role. |
Grant role privilege(s) on a database table to a role or user. |
Revoke role privilege(s) on database table from a role or user. |
Grant role privilege(s) on a database view to a role or user. |
Revoke role privilege(s) on database view from a role or user. |
Grant role privilege(s) on database to a role or user. |
Revoke role privilege(s) on database from a role or user. |
Grant role privilege(s) on server to a role or user. |
Revoke role privilege(s) on server from a role or user. |
Grant role privilege(s) on dashboard to a role or user. |
Revoke role privilege(s) on dashboard from a role or user. |
Parameter Value | Descriptions |
| Name of role, which must exist. |
|
Parameter Value | Descriptions |
| Name of role, which must exist. |
|
Parameter Value | Descriptions |
| Name of role, which must exist. |
|
Parameter Value | Descriptions |
| Name of role, which must exist. |
|
Parameter Value | Descriptions |
| Name of role, which must exist. |
|
Name of user, which must exist. See .
Name of user, which must exist. See .
Name of user, which must exist. See .
Name of user, which must exist. See .
Name of user, which must exist. See .
