Ability to disable (but not delete) users
There needs to be a way to deactivate user accounts rather than completing removing. We have users that will no longer have access to the system, but could come back later (for example, trail users). The workarounds are currently: reassigning security groups (means those users are still taking up licenses) writing our own user admin functionality (only makes sense if we are integrating users to another platform) Adding a 'Status' or 'Disabled' flag to the user account would accomplish this.
Support API Key rotation (2+ keys per user)
We want to rotate the API key for our system user but need to make sure there's no downtime. This means we need to have 2 keys working in parallel for the same user for a period of time until we can cycle all of our services to pick up the latest api key. The problem is as soon as the API key is rotated, the old key immediately stopped working. Majority of systems out there support key rotation (like allowing a time delay before the old key expires like FB app, or ability to temporary create a second key and then we can promote it as primary once we are ready). Key rotation is a best practice for security principles.
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.User password expiration
Hi, Many customers are asking about secutiry concerns. One of it is about the feature of set a time when the password expires. For example, if a viewer has set a password expirtation time to 60 days, he needs to change the password into these days. Days before the expiration he will be notified. Thanks
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'.
Local Development Environment
Idea: Allow developers to build/test add-ons in a local environment rather than requiring a live environment. Note that this would be for the purpose of creating custom add-ons for additional functionality that would require testing on the "out of the box" Sisense UI. Background/Context: In most development workflows it is common practice to work on your code locally on your machine and deploy to a local server aka "localhost" to test/view your work in the browser. An example of this is building and deploying a local React.js app to your browser. As you make changes to the code it will recompile locally and update what you see on your localhost. If you're using Sisense out of the box however, to test/view any changes to an add-on developers are forced to upload the files in some way to a live Sisense Environment. This not only limits the innovation of add-ons to developers with an active license and live environment, it makes it painfully inefficient to develop customizations on top of the Sisense application. I understand there are likely some business concerns with allowing the use of the product locally but I'd argue that there are ways to prevent that, such as enforcing some default sample data etc., but in such a way that would give developers a "local playground" to develop/innovate on.
Add user or group params as Claim in Web Access Token
It would be very helpful to be able to pass User or Group parameters as Claims in a Web Access Token. This will allow customers to leverage the dynamic features related to User/Group Parameters (e.g. dynamic live query) when using Web Access Tokens.
