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.
The information below shows an SSO JWT authentication performed with the given user. 2021-05-11T13:24:03.066, sisense, api-gateway, [9482.894437841] 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-05-11T15:55:34.049, sisense, identity, options={"$set": |
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:
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 |
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 |
|
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 |
|
Customer project stage |
|
Network and infrastructure |
|
SSO development |
|
Sisense configuration |
|
End user analysis |
|
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
|
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. |