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'.
Data Security Search Limit Max
The Data Security tab's group/user assignment window currently has a max search limit of 20 results. The "results" search limit should be configurable because we have approx. 50 groups that need to be assigned, & it is very difficult to find/assign/manage all of the groups when the search window does not return all of the appropriate results.
