Troubleshooting SSO Using JWT

Authentication Flow

This figure illustrates the authentication flow using JWT.

The following table describes the steps of the authentication flow based on the figure above. This includes the configuration involved in the attributes/properties used in the process, the output of action/data, and the technical requirements to successfully execute each step.

#

Action

Configuration Source

Output

Requirements

1

User sends a request to load a given Sisense resource.

n/a

URL request to Sisense site.

https://customer.sisense.com:30845/app/main

The user needs to have access to the Sisense site.

2

If Sisense is enabled for SSO, and given a user has no active session, a redirect request is sent back to the user browser with the Sisense return address to the Sisense page the user was trying to access.

After authentication the user is brought back to the page requested.

Sisense Admin > SSO Login Configuration. Remote Login URL, designates the customer login site.

URL request redirects from Sisense to Browser.

https://login.customer.com:port/login?return_to=/app/main

User workstation needs access to the SSO site (Identity Provider).

3

User session is redirected to the designated user Remote Login page where the user enters login credentials.

n/a

URL request to customer login site with the return URL attached.

https://login.customer.com:port/login?return_to=/app/main

User has access to the customer login site.z

4

Login page is displayed to the user to insert the login credential (or the user already has an active login session) which invokes the SSO handler with the user HTTP context.

The SSO handler coded by the customer has been configured to redirect back to the Sisense site.

URL request back to Sisense original return URL, including an encrypted token with encoded shared secret.

n/a

5

Sisense receives the URL request with the token, shared secret, and return URL

n/a

User session details are updated into MongoDB.

Token is validated. Shared secret must match what is in the Sisense SSO configuration.

6

Sisense sends the Sisense page to the URL (e.g., dashboard)

n/a

Page context is sent back to the browser.

Only in the case of cross domain setup with embedding, the user browser needs to accept third-party cookies and have access to both Sisense and SSO sites.

6*

Optional setup.

Sisense redirects the user to a customer site that has Sisense embedded in it. This can be used when the customer wants its users to land on their own site.

Base SSO return to URL

URL redirect

Sisense has access to the customer site with the Sisense embedding.

Analyzing and Testing

The following are various tools and logs to use during an end-to-end investigation of an SSO issue.

HTTP Archive Format and Server Logs

HTTP Archive format (HAR) files are generated using your browser's Developer Tools and can be exported for offline troubleshooting of browser communication. You can use the import option in Developer Tools to analyze and validate the flow of communication. The Network tab provides details about exchanges between Sisense, Customer Login Site/SSO Handler, and end user browser.

The following table describes the entries in both HAR files and server logs involved in each successful step in the authentication flow. This does not illustrate log entries of exceptions and failures that occurred. These are described in Troubleshooting Scenarios.

Not all information reflecting the SSO workflow is captured on the server-side logs of API gateway and/or identity.log. As a workaround, the combined.log captures additional log entries showing the SSO flow, and the entries can be invoked by switching on and off the given SSO protocol from the Sisense SSO Admin page. Once you switch off to on and save, the combined log is added with the additional logs.

This is described in the following table:

#

HAR Entries

Server Logs

Login

1

Shows the first step in a user's access from the Browser to the Sisense site.

Name > main

Headers:

Request URL: https://customer.sisense.com:port

Request Method: GET

Status Code: 302 Found

Remote Address: 10.20.4.174:7000

Referrer Policy: strict-origin-when-cross-origin

API gateway.log and Identity log do not include a log entry for this step.

The combined.log does not include an entry for this step of the flow.

2

Name > login?return_to=/app/main

Headers:

Request URL: https://login.customer.com:port/login?return_to=/app/main

Request Method: GET

Status Code: 302 Found

Remote Address: login.customer.com:port

Referrer Policy: strict-origin-when-cross-origin

API gateway.log and Identity log do not include a log entry for this step.

The combined.log does not include an entry for this step of the flow.

3

Name > jwt?jwt=

Headers:

Request URL: Click here

Status Code: 302 Found

Remote Address: 10.50.83.39:30845

Referrer Policy: strict-origin-when-cross-origin

API gateway.log and Identity log do not include a log entry for this step.

The combined.log file includes an entry for this step:

2021-06-29T01:36:08.917, sisense, api-gateway, [4679.678690603] [[34mINFO[39m] [2021-6-29 08:36:08.916] [undefined] [41]:[] [/usr/src/app/node_modules/@sisense/sisense-logger/index.js:174] [X-request:af7022e0-b414-4287-bff5-e4c3a95eeb24] [Start handling request =>

GET /jwt?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE2MjQ5NTU3NjQsInN1YiI6ImlyaW5hLm1hc2x5dWtvdmErbmV3dmVyeXVzZXJAc2lzZW5zZS5jb20iLCJmaXJzdE5hbWUiOiJKV1QiLCJsYXN0TmFtZSI6IlVzZXIiLCJncm91cHMiOlsiSldUX0dyb3VwMSIsIkpXVF9Hcm91cDIiXSwianRpIjoiY2RndmRlYTEifQ.vKFl0cXHjoXCG3nr_7Eud9020Z_12vN3CQ7qO7ofY84&return_to=%2F]

2021-06-29T01:36:08.985, sisense, api-gateway, [4679.747432527] [[34mINFO[39m] [2021-6-29 08:36:08.985] [undefined] [41]:[] [/usr/src/app/node_modules/@sisense/sisense-logger/index.js:179] [X-request:af7022e0-b414-4287-bff5-e4c3a95eeb24] [Finished handling request =>

GET /jwt?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE2MjQ5NTU3NjQsInN1YiI6ImlyaW5hLm1hc2x5dWtvdmErbmV3dmVyeXVzZXJAc2lzZW5zZS5jb20iLCJmaXJzdE5hbWUiOiJKV1QiLCJsYXN0TmFtZSI6IlVzZXIiLCJncm91cHMiOlsiSldUX0dyb3VwMSIsIkpXVF9Hcm91cDIiXSwianRpIjoiY2RndmRlYTEifQ.vKFl0cXHjoXCG3nr_7Eud9020Z_12vN3CQ7qO7ofY84&return_to=%2F 302]

4

Name > main

Headers:

Request URL: https://customer.sisense.com:30845/app/main

Request Method: GET

Status Code: 200 OK

Remote Address: 10.50.83.39:30845

Referrer Policy: strict-origin-when-cross-origin

Both API Gateway and Identity logs contain the final steps in which the user session is received from the SSO handler.
This information is only available when log level is set for the API Gateway and Identity servers to "DEBUG".

The information below shows an SSO JWT authentication performed with the given user.

2021-05-11T13:24:03.066, sisense, api-gateway, [9482.894437841]
							
[DEBUG] [2021-5-11 10:24:03.066] [] [api-gateway] [41]:[auditLogUtils]
[/usr/src/app/src/common/auditLog.util.js:24] [X-request:e24048da-c903-4846-9a10-b883e2e83f4f]
[Sending audit message event {
2021-05-11T13:24:03.066, sisense, api-gateway, action: 'login',
2021-05-11T13:24:03.066, sisense, api-gateway, entity: 'user',
2021-05-11T13:24:03.066, sisense, api-gateway, event: {
2021-05-11T13:24:03.066, sisense, api-gateway, userName: 'testuser@sisense.com',
2021-05-11T13:24:03.066, sisense, api-gateway, httpReferrer: 'http://10.50.83.39:30845/'
2021-05-11T13:24:03.066, sisense, api-gateway, },
2021-05-11T13:24:03.066, sisense, api-gateway, requester: undefined,
2021-05-11T13:24:03.066, sisense, api-gateway, operation: 'SSO_JWT_login'
2021-05-11T13:24:03.066, sisense, api-gateway, }]

The Identity log below shows the session information stored in MongoDB that will be used to validate the user session.

2021-05-11T15:55:34.049, sisense, identity, [18577.68726537] [DEBUG]
							
[2021-5-11 12:55:34.049] [] [identity-service] [44]:
[sisense-mongo] [/usr/src/app/node_modules/@sisense/sisense-mongo/mongo.util.js:377]
[X-request:4cedfbef-1a74-48aa-a234-258f6f780486]
[mongoDB query: collection=users, command=updateOne, query=
{"_id":"HASH_ID<<8bc0870dbd7546ebb392c51a34936b30>>"},

2021-05-11T15:55:34.049, sisense, identity, options={"$set":
							
{"roleId":"60857e09765de0b9efc1ced3","userName
'testuser@sisense.com ","firstName":"'testuser@sisense.com",
"email":"'testuser@sisense.com","active":true,
"created":"2021-05-11T10:39:41.666Z","lastUpdated":
"2021-05-11T12:55:34.041Z","lastLogin":"2021-05-11T12:55:24.323Z",
"secrets":{"tokens":{"sso":"673a3852-49c4-25d0-a20f-acfaa9992d96"}},
"activationToken":"25f0429a5f45d51b2a5d0a5cb25c321de336ef72",
"activationExpires":1621334381726,"createdSso":"jwt",
"tenantId":"60857e0b1a19a6001b525eac"}}, responseSize=1, took=1 ms]

Log out

1

Logout redirect occurs when a user logs out of the site.

Request URL: http://0.0.0.0:30845/api/auth/logout

Request Method: GET

Status Code: 200 OK

Remote Address: 0.0.0.0:30845

Referrer Policy: strict-origin

n/a

2

Redirect to the logout page that was configured in the Sisense SSO setup.

Request URL: Click here

Request Method: GET

Status Code: 302 Found

Remote Address: 18.216.23.72:443

Referrer Policy: strict-origin

n/a

Useful Tools

A JWT is an encoded token that contains the session information being passed from the SSO handler. This information is passed in Base64 encoded format. To view the content of the token, use the following site:

https://jwt.io

Copy the value of the encoded JWT from the Developer Tools in the browser and paste it into the Encoded box, the decoded token set values are displayed on the right.

MongoDB

MongoDB is the context of SSO (and for a regular login) used to store the last session of the logged in user including the additional SSO parameters that are passed via the SSO handshake.

If a user has previously logged in successfully, a set of validations are performed between the passed-in parameter via SSO token and the data in the document. This validation is part of a security assessment of the user's login attempt.

The following table describes the various scenarios available for a user that logs in via SSO, where the option to automate the creation of the user is used as part of the SSO process:

Allow creation of new
users via SSO

User setup in Sisense

Action

Off

No

Deny user login

Off

Yes

Accept user and update MongoDB record for the user

On

No

Accept user login and insert a new MongoDB record for the user

On

Yes

Accept user and update MongoDB record for the user

The record for a given user contains values that pertain to the SSO handshake. The user record can be found in MongoDB prismWebD under Collections >> users.

The table below describes keys in the SSO process, and which validations are performed between the token set values and the previous user records in the MongoDB.

Key

Value

Validation

SSO Protocol Attribute

L2021.3.1.x

SSO

true/false

n/a

n/a

createdSSO

Contains the protocol used for SSO, such as JWT, SAML, OIDC.

The value set indicates which protocol was used to login via SSO.

n/a

n/a

ssoToken

Contains a unique string sent via the SSO handler.

n/a

jti

ssotokenlat

This is the latency from the UNIX epoch time that was sent by the SSO handler in the previous user login session.

Value must be an integer, for example 1620636612.

The session token value must be equal or greater than what is set in MongoDB.

iat

email

The user login email is passed from the token.

If the user exists, it will update the record of all other validations passed.

If the user does not exist and Sisense is configured to create a new user automatically with SSO enabled, it will use this to create the user account.

Configured field name for token in SSO Login configuration page

userName

The user login name is passed from the token.

If the user exists, the system updates the record of all other validations passed.

If the user does not exist and Sisense is configured to create a new user automatically with SSO enabled, the system uses the userName to create the user account.

Configured field name for token in SSO Login configuration page

lastName

The user's last name.

n/a

Configured field name for token in SSO Login configuration page

firstName

The user's first name.

n/a

Configured field name for token in SSO Login configuration page

Troubleshooting

Gathering Information

Attribute

General Information

Sisense deployment

  • Which version of Sisense is installed?
  • Is this an on-premises or hosted deployment?
  • Which operating system is the customer using? Is the customer using the Windows or Linux version of Sisense?
  • Is the customer directly accessing or embedding Sisense?
    • If embedding: using SisenseJS, Frame SDK, or Iframe embedding? Which version are they using?
  • Is the customer using Active Directory (AD), full SSO integration, or a combination?
    • Is the customer using only AD for authentication and NOT SSO? → Not an SSO issue
    • Is the customer using AD only for user import and using Sisense Direct signing? → Not an SSO issue
    • Is the customer using AD for the purpose of importing the users and using SSO integration for authentication?

Customer project stage

  • Is it a new or an existing customer that is using SSO for the first time?
  • What stage is the customer at?
    • Development of the SSO handler (e.g., the customer is looking for development help)
    • Testing the handshake (e.g., the customer is looking for troubleshooting and configuration help)
    • Going live for the first time
    • In production
  • Going live for first time and SSO login is not working
    • For everyone
    • For unrelated users (e.g., same organization/same network)
    • For related users or groups of users (e.g. same organization/same network)
  • In production and SSO login stopped working
    • Potential causes
      • Has the customer just upgraded to a new version of Sisense which led to the issue?
      • Same release and experiencing issues with a previously working SSO?
      • Has the customer switched from Windows to Linux?
    • Effects
      • For all
      • For unrelated users (e.g., same organization/same network)
      • For related users or groups of users (e.g., same organization/same network)

Network and infrastructure

  • Is there a firewall, private network, or proxy between the SSO handler and Sisense server?
  • Do the SSO handler and Sisense servers reside on different domains?
  • Have any changes been made within the infrastructure of the customer organization?
  • Has a certificate been updated recently?

SSO development

  • Were any recent codes updated that might have led to the problem performed by the customers?
  • Has there been a release upgrade to Sisense that might have led to a compatibility issue?

Sisense configuration

  • Have there been any configuration changes made in the SSO settings in Sisense?

End user analysis

  • What browser is the user using to access the platform?
  • Is the user experiencing a production issue with all users, a subset of users, or a particular user. What is unique about the user and the method in which they access Sisense?
  • Has the user experiencing issues previously logged in successfully?
  • The type of users having issues are:
    • Internal within the organization of the customer
    • External users
  • Is the user accessing the platform over the Internet? Behind a firewall or proxy server? Is there a VPN software on the user's workstation?
  • Has the customer organization or individual user recently made any changes to their workstation or within their organizational infrastructure?
  • Have there been any changes made to the browser configuration with regard to site security and cookies?

Gathering Assets

To troubleshoot and test SSO, gather the following logs and configuration data:

Asset

Notes

HAR files (or screen captures of the specific sections in the browser Developer Tools)

This enables the user experiencing issues with their SSO login to view communication between Sisense and the user's browser.

In some instances this information cannot be shared due to security issues. Direct the customer to use screen captures and/or provide text extracts of the values that are outlined in the HTTP Archive Format and Server Logs section of this document.

Sisense Server-side log/API Gateway.log

The version in this document requires you to have a log level for the service set to DEBUG to view valid SSO connectivity flow or errors in the process.

Sisense Server-side log/Identity.log

The version in this document requires you to have a log level for this service setup to DEBUG.

Sisense Server-side log/Combined.log

The log contains some entries written as a result of the login performed via SSO. However, some of the information might be incomplete.

As a workaround, more complete log details will be written by going to the Sisense Admin page for SSO and changing the protocol to a different protocol and back to the protocol that is being implemented. This action immediately creates log entries that can be used to analyze the full workflow for the SSO workflow implemented.

MongoDB

Go to prismWebDB > users collection to gain access to the document in MongoDB that contains the user having issues with SSO access.

SSO handler code

Request the code or the lines of code from the customer developer that pertain to the integration for SSO.

Sisense configuration

Refer to the HTTP Archive Format and Server Logs section pertaining to SSO and review the configuration, below.

Troubleshooting Scenarios

The following table describes potential end-user issues with SSO login. Each incident may have one or more possible causes.

#

Issue

Browser Error

Possible Causes

1

The user is not able to access the Sisense site.

This site cannot be reached.

1

2

The user is logging in successfully on the customer login page (Identity Provider) however; when redirected to Sisense, the login fails.

An error occurred while trying to authenticate using SSO. Ask your administrator for assistance. Administrators may log in using the manual Login page.

2, 3, 5, 6, 7, 8, 9, 10, 11, 13, 14, 15

3

The user is able to log in, but not to their intended Sisense account. The default value has been applied rather than the intended one.

n/a

4

4

After logging in it appears that the browser page is stuck in a reload loop.

The request is terminated, and depending on the browser, an error message is displayed.

Example: This page cannot be displayed.

12, 16

The following table describes the diagnostic procedure for the issues described in the table above.

Each procedure starts with a possible cause, a suggested procedure, the files that provide you with the evidence, and a resolution.

#

Issue Category

Possible Cause

Diagnostic Procedure

HAR File

API Gateway.log
(Only in DEBUG level)

Resolution

1

Connectivity

The user has no access to the Sisense site.

Have the user or IT ping the Sisense URL to ensure proper access.

Check the HAR log to see if the user registers on the Sisense site. Under the Name tab in Network a "jwt?jwt=" entry with Header:

Request URL: https://

Request

Method: GET

Status Code: 200 OK

n/a

Work with IT support to solve the user's access issue.

2

SSO handler

The itl that is passed via the SSO handler is the same UNIX epoch time or earlier than what is set from the previous user session in MongoDB.

This could be due to clock differences.

Compare between the value set in iat in the token to what is set in MongoDB for the given user document in field ssoTokenlat.

From the entry in Name "jwt?jwt=" copy the value of the token and decode it in https://jwt.io to get the itl value.

sisense, api-gateway, [24432.695145228] [ERROR] [2021-5-12 13:11:05.354] [] [api-gateway] [41]:[sso-middleware] [/usr/src/app/src/middlewares/sso.middleware.js:132] [X-request:c8a87f88-ab3d-4c3d-b04a-cc2d252cfeab] [Creation time not synchronized]

Make sure clocks are synchronized within the deviations limits set in the platform (e.g., 5 minutes). Check the code to make sure the correct logic is used to generate the integer that designates offset from UNIX epoch time.

3

Sisense user admin

User has not been set up in Sisense and SSO Create User Capability has not been turned on in the Sisense configuration.

Check the value of the parameter set in the token and compare it to what is set in Sisense.

From the entry in Name "jwt?jwt=" copy the value of the token and decode it in https://jwt.io to get the field value that designates the account.

sisense, api-gateway, [25773.459583621] [ERROR] [2021-5-12 13:33:26.119] [] [api-gateway] [41]:[sso-middleware] [/usr/src/app/src/middlewares/sso.middleware.js:132] [X-request:e13ff1f9-cee9-4c72-bb8b-68d67ad40a46] [An error occurred while trying to authenticate you using Single-Sign-On.

sisense, api-gateway, Ask your administrator for assistance.]

2021-05-12T16:33:26.120, sisense, api-gateway, [25773.459976232] [ERROR] [2021-5-12 13:33:26.119] [] [api-gateway] [41]:[sso-middleware] [/usr/src/app/src/middlewares/sso.middleware.js:134] [X-request:e13ff1f9-cee9-4c72-bb8b-68d67ad40a46] [Error: Disable automatic creation of users via SSO]

Make sure that the correct user email is set up in Sisense that corresponds to what is set up on the SSO customer side.

4

SSO handler

The user ID (e.g., user email) being passed to Sisense is different from the user ID in the Sisense setup.

Check the value of the parameter set in the token and compare it to the value in Sisense.

From the entry in Name "jwt?jwt=", copy the value of the token and decode it in https://jwt.io to get the field value that designates the account.

n/a

In the SSO handler code, fix the values of the intended user account that is passed in the cookie/http context to the correct token attribute.

5

SSO handler

Sisense application server and handler servers must be able to communicate via web traffic, in the same security-type group.

Linux: open a command line and use "wget" from the Sisense application server to the server that the SSO handler is running on and ensure that connection is successful.

Windows: try to telnet to the ip/port specified in the code for the Sisense site.

From the entry in Name "jwt?jwt=", check the Header section for what request URL is specified, and check if it is the correct Sisense IP.

n/a

Fix the connectivity issue or enter to the SSO handler the URL or IP that points to the redirect to Sisense.

6

SSO handler

When comparing the itl value passed via the SSO handler to the one set by the previous user session in MongoDB, validation fails for instance due to data-type mismatch.

For example, a float value is set in MongoDB and an integer value was set in the SSO handler.

Compare the value in MongoDB for the given user of ssoTokenlat and check if it is correct (e.g., convert the UNIX epoch time to a date/time format).

From the entry in Name "jwt?jwt=" copy the value of the token and decode it in https://jwt.io to get the itl value.

sisense, api-gateway, [24432.695145228] [ERROR] [2021-5-12 13:11:05.354] [] [api-gateway] [41]:[sso-middleware] [/usr/src/app/src/middlewares/sso.middleware.js:132] [X-request:c8a87f88-ab3d-4c3d-b04a-cc2d252cfeab] [Creation time not synchronized]

Delete the user entry in MongoDB (in prismWebDB under Collections >> users).

7

SSO handler

The shared secret passed from the SSO handler and what is specified in the Sisense SSO configuration does not match.

Check that the secret set in the code is the same as what is configured in Sisense configuration.

The secret is encoded into the token and cannot be seen.

sisense, api-gateway, [2571.564445757] [ERROR] [2021-5-13 11:18:04.440] [] [ap i-gateway] [42]:[sso-middleware] [/usr/src/app/src/middlewares/sso.middleware.js:132] [X-request:9beb6e 7a-daf4-4fe6-9396-bac0214d4b66] [invalid signature]

Match value in code with configuration.

8

Sisense license admin

When automatically creating a user with a given role (e.g., viewer) the license does not allow for the additional user to be created. It exceeds the total of allowed users.

Check the license configuration for Sisense.

n/a

n/a

Configure the license appropriately.

9

SSO handler

The token jti value is not unique because it has already been used previously to log in.

Check the MongoDB user session information in prismWebDB > Collection > Users > ssToken against the JWT itl value assigned in the failed login.

From the entry in Name "jwt?jwt=" copy the value of the token and decode it in https://jwt.io

to get the jtl value.

sisense, api-gateway, [3481.493798061] [ERROR] [2021-5-13 11:33:14.369] [] [api-gateway] [42]:[sso-middleware] [/usr/src/app/src/middlewares/sso.middleware.js:132] [X-request:ba0f7223-900f-4f57-b9ba-a69364925cf2] [Invalid Token, Initiate a new one]

Check the SSO handler code and make sure a unique token jti is always created for a new login session.

10

SSO handler

The token does not have a proper user name (email) set.

Check the value that is set for the user in the token.

From the entry in Name "jwt?jwt=" copy the value of the token and decode it in https://jwt.io to verify that there is a value in the user field. (e.g., sub is a hardcoded field name, which contains the username in it. In the newer version sub has become configurable.)

sisense, api-gateway, [4579.678082682] [ERROR] [2021-5-13 11:51:32.553] [] [api-gateway] [42]:[sso-middleware] [/usr/src/app/src/middlewares/sso.middleware.js:132] [X-request:0f02955a-e650-45fd-bf5e-8ed46d80368b] [jwt must contain sub]

Correct the code to set the field properly.

11

SSO handler

The shared secret passed from the SSO handler and the one in the Sisense SSO configuration do not match.

Check the secret in the handler code. You are not able to see the secret information in the decoded message.

n/a

n/a

Change the secret in the handler code or make the SSO Sisense configuration match the handler code.

12

Cookie

The browser is set to block all 3rd party cookies.

This is only applicable for cross-domain deployment where Sisense and the customer are residing under different domains.

Determine if cross-domain setup is appropriate, and that cookies and admin are set up correctly.

Check that the cookie is set to SameSite = None by looking at the cookie section under the HAR file entries.

n/a

Go to the Security setting under Admin and change the setting for Support Cross Site Cookies for embedding to None.

13

Admin

When a session for a given user starts, Sisense checks the value of iat in the token and compares it to the value in MongoDB.

The user is not able to log in due to data-type mismatch.

n/a

n/a

n/a

Delete the user entry from MongoDB and change the code to set the data type for the itl.

14

SSO handler

The value set for the previous session in MongoDB for the given user is incompatible with the values in the JWT token.

Retrieve the values of the last login attempt for the given user.

The values in the JWT token are not compatible with what is already in MongoDB. If the values are as indicated, the following error occurs:

Mongo.user.ssoToken = JWT.jti

API Gateway log


Make sure the JWT handler is sending correct values in jti and iat.

Check the date/time server set.

15

SSO handler

User account ID value, which is supposed to be set to the user login, is not passed from the SSO handler.

Check that a proper user ID is passed from the handler.

From the entry in Name "jwt?jwt=" copy the value of the token and decode it in https://jwt.io to see if there is a user field set (e.g., "sub" or in newer versions the configured field).

n/a

Correct the code to include the required parameters.

16

Embedding

When Sisense is embedded across domains while using Incognito mode, the cookie is blocked causing the page not to work.

Check the browser setting to allow cookies in Incognito mode.

n/a

n/a

Allow for 3rd party cookies to work in Incognito mode.

17

SSO handler

The token is not set to encode using the required HS256 encryption algorithm.

Check the code or setup of the platform running the handler and ensure encryption is set appropriately.

From the entry in Name "jwt?jwt=" copy the value of the token and decode it in https://jwt.io to see if the header alg = HS256.

n/a

Make changes to code to explicitly set the correct encryption algorithm.