Support multi SSO options for authentication
Sisense currently provides SSO support via JWT, SAML 2.0 and OpenID Connect but only one of them can be used if you do not have multi-tenant system. We have a use-case where we want to move all of our internal users i.e. developers and similar roles to OKTA which currently access Sisense UI via the internal /app/account url path. But doing so is becoming a challenge since it would mean that our existing logic for our external users i.e. customers accessing dashboard via our website also has to move to OKTA. Currently our customers are getting authenticated via JWT and to move them to OKTA would involve a considerable amount of work and would impact the user experience as well (testing it for different customers is again a challenge). Supporting multiple SSO options for a single-tenant system would be able to solve for such a use-case and would give us more flexibility for choosing authentication support that work best for a use-case.
Native Support for Salesforce Connected App Authentication
Salesforce has announced that API Access Control must be enforced, and once fully enforced, the username/password + security token method will no longer be permitted for API integrations. https://help.salesforce.com/s/articleView?id=005228838&type=1 While the current Sisense guidance allows us to continue using token-based authentication, we belive this is only a temporary gap in Salesforce’s enforcement. We expect that Salesforce will require all integrations to authenticate exclusively through an allowlisted Connected App using OAuth. This is not a feature request in the traditional sense. It is a compliance requirement dictated by Salesforce’s security model, and other analytics and reporting tools that integrate with Salesforce already support Connected App–based OAuth authentication natively. To ensure long term compatibility and security, Sisense needs to provide: Native support for OAuth via Salesforce Connected App, without requiring manual JDBC string assembly or custom development A UI-driven configuration aligned with Salesforce’s allowlisting and API Access Control policies Clear guidance for customers migrating away from token-based authentication Without this capability, Sisense will no longer be able to integrate with Salesforce once Salesforce completes enforcement. Please escalate this as a priority compliance feature.
Enable ability to audit users by login methods.
When accessing "/users/$id" The response documents the following fields: _id [...] email [...] userName [...] firstName [...] lastName [...] roleId [...] active [...] groups [...] adgroups [...] activeDirectory [...] principalName [...] objectSid [...] uSNChanged [...] dn [...] preferences {...} uiSettings {...} created [...] lastLogin [...] lastUpdated [...] ldapDomainId [...] pendingExpiration [...] createdSso [...] I see 'createdSso', but that doesn't seem to indicate which users can log in via what method. When we're auditing users, we need to know which users have a password that bypasses SSO, These users are high risk, as without a way to audit them, we can't easily discover discover when users have a password configured that allows them to bypass organization SSO.Enable end-to-end tracing visibility for Sisense services to complement existing metric monitoring.
Description: We are looking to send Sisense application traces to SignalFx (Splunk Observability Cloud) and would like guidance on leveraging the OpenTelemetry framework to achieve this integration. Currently, OpenTelemetry is not configured in our environment. We would like to understand: Whether Sisense supports OpenTelemetry out of the box for traces, The required steps to enable and configure OpenTelemetry in a Sisense deployment (Linux EC2, single-node, Kubernetes-based), How to route traces from Sisense to SignalFx, including configuration files, environment variables, and any required Sisense plugins or modules, Any limitations or known issues with trace capture for Sisense microservices, Example configuration snippets or reference documentation for this setup.
WAT and ACL Security Model - Default to no access
We have found that if an ACL in a WAT does not match the Elasticube table/column security field, it defaults to providing 'all data'. To avoid a potential human error where a table/column has been renamed, we would like the default position to be 'nothing'.
