This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Cookie Policy. Click Preferences to customize your cookie settings.
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.
Tutorial
In this tutorial we will provide two use-case examples:
- 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.
- 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: {
'10.50.51.37:30845': '10.50.51.37:3000',
'yourcompany.com:30845': '10.50.51.37:3001', //'http://${attribute}.tenant.sso.com'
},
logout: {
'10.50.51.37:30845': 'http://logoutwebsite.com',
},
//loginURLParameter: 'domain',
//loginParameterMapping: {
// 1: 'http://tenantA.sso.com',
// 2: 'http://tenantB.sso.com'
//}
};
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 http://10.50.51.37:30835 will be routed to the handler on the 3000 port or another SSO handler destination we set in config.js. Users accessing by URL http://yourcompany.com:30845 will be routed to the handler on port 3001.
So, with the SSO handler example above, http://10.50.51.37:30835 will be logged in as [email protected], and http://yourcompany.com:30845 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:
http://10.50.70.211:30845/app/main/home?domain=1 for the first SSO handler
http://10.50.70.211:30845/app/main/home?domain=2 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 http://sisense.dns.com/app/main#/home?embed=true with
http://sisense.dns.com/app/main%23/home?embed=true
const config = {
login: {
'10.50.70.211:30845': '10.50.70.211:3000',
'${attribute}.tenant': 'http://${attribute}:3001'
},
logout: {
'10.50.51.37:30845': 'http://logouturl.com',
},
loginURLParameter: 'domain',
loginParameterMapping: {
1: '10.50.70.211:3000',
2: '10.50.70.211:3001'
}
};
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, http://10.50.70.211:30845/app/main/home?domain=1 will log in us as [email protected], and http://10.50.70.211:30845/app/main/home?domain=2 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.
Linux
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.
Windows
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 http://logouturl.com in our example.
This is expected behavior. We suggest keeping the Cookies option.
If you need additional help, please contact Sisense Support.
