Showing results for 
Search instead for 
Did you mean: 
Sisense Team Member
Sisense Team Member

SSO Router Plugin Usage With Examples

SSO Router PlugIn Overview:

  • The SSO Router plugin allows multiple SSO providers.
  • The plugin works only with JWT SSO.
  • Installation steps are described in the Single Sign-On (SSO) Router Technical details page here.

Note that the configuration for the SSO PlugIn is in the Configuration Manager, unlike the one-tenant SSO configuration. The SSO PlugIn uses its own endpoints which are not URL based.




Basic Admin >SSO PlugIn won’t allow these values to be entered:

sso.loginUrl to /api/v1/ssoRouter/login

sso.logoutUrl to /api/v1/ssoRouter/logout




Please note an "Invalid URL Address" error after setting the correct values in the Configuration Manager is normal. The most important value on the Admin > Single Sign On page is the Shared Secret Value. 

This Shared Secret Value should be used with all SSO handlers you would like to use.

The SSO Router plugin provides new REST API endpoints to route login and logout JWT SSO requests based on the domain of the source request or URL parameter.



In this tutorial we will provide two use-case examples:

  1. A company using a multi-tenant configuration defines a URL parameter that will determine the user's tenant. When a user connects to Sisense and the URL parameter is set to his tenant's identifier, Sisense routes the request to the tenant's unique SSO handler. This way, each tenant has a unique SSO handler.
  2. A company using a multi-tenant configuration creates a unique URL parameter for each tenant. When a user connects to Sisense using a specific parameter, Sisense routes the request to the tenant's unique SSO handler.


We recommend asking your SSO expert to develop an SSO handler. In this example, we have used the simplest SSO handler based on node.js with the logic limited to single-user login. One SSO handler is running on port 3000 and configured for [email protected], and the second handler is running on port 3001 configured for [email protected] user. Both handlers use the same shared secret. In a real use case, you would most likely have the SSO handlers run on remote servers with advanced logic.



In both cases, users will have different configurations for the SSO Router plugin config.js file located at:

Linux: /ssoRouter/v1/config.js

Windows: /sisense/app/ssoRouter/src/features/ssoRouter/v1/config.js


Case 1: Different URLs

In example 1, a user has an SSO provider for your company's admin users and wishes to grant some access to their partners who use a different SSO provider. Admin users can use an IP address to log in to the partner's URL. 

const config = {

    login: {

        '': '',

        '': '', //'http://${attribute}'


    logout: {

        '': '',


    //loginURLParameter: 'domain',

    //loginParameterMapping: {

    //    1: '',

    //   2: ''



The configuration here is simple. We commented loginParameterMapping and attribute it as it is not used here. From here, we have two options. Users accessing by IP address will be routed to the handler on the 3000 port or another SSO handler destination we set in config.js. Users accessing by URL will be routed to the handler on port 3001.

So, with the SSO handler example above, will be logged in as [email protected],  and as [email protected].


Case 2: URL Parameters

In this case, the same URL will be used to log in, but first, the logic must be defined when the user’s tenant is defined by the URL parameter. For example: for the first SSO handler for the second SSO handler


If the wanted login URL includes signs like ‘#’ make sure to pass them in an encoded format (# encoded is %23)

For example:

Replace with




const config = {

    login: {

        '': '',

        '${attribute}.tenant': 'http://${attribute}:3001'


    logout: {

        '': '',


    loginURLParameter: 'domain',

    loginParameterMapping: {

        1: '',

        2: ''




If loginURLParameter and loginParameterMapping defined passed URL parameters in the URL, then those will have the priority even if the login section at the beginning defines other SSO handlers.

Using the simple SSO handler example, will log in us as [email protected], and as [email protected].


Windows vs Linux

The configuration of the SSO router is similar on both platforms, however, there’s a difference in the way user activity is kept.




Without the SSO Router plugin, changing between Cookie and Session Inactivity will then save and force log off. 

In Linux, a user is automatically re-logged in after pressing save. If the Session Inactivity option is set to automatic re-login after the period of time, this set also occurs. 


In Windows, changing between Cookie and Session Inactivity, as well as the expiration of time set in Session Inactivity will force a logoff. Please note the logoff is to the main Sisense login page instead of the page set as the logout URL in the SSO Router which is in our example.

This is expected behavior. We suggest keeping the Cookies option.

If you need additional help, please contact Sisense Support

Version history
Last update:
‎02-20-2024 01:56 PM
Updated by:
Community Toolbox

Recommended quick links to assist you in optimizing your community experience:

Developers Group:

Product Feedback Forum:

Need additional support?:

Submit a Support Request

The Legal Stuff

Have a question about the Sisense Community?

Email [email protected]

Share this page: