SSO Errors and Troubleshooting
Overview
This page covers common SSO errors and troubleshooting techniques.
Error: Missing context: SSO request did not originate from here
This error can occur for two reasons:
1. You attempted to browse to the RiSE SSO page directly. OpenID / OAuth 2 protocols specify that the third party must initiate the SSO process. You cannot start the SSO flow from RiSE, you must first go to the connecting application's website. That system must initiate the SSO process.
2. You accidentally used the OpenID callback URL instead of the SAML callback URL. When configuring SAML, the callback URL that you enter into iMIS ends with /saml/imis/callback, whereas the OpenID callback just ends with /imis/callback. You get this error when you want to configure a SAML application, but you entered the OpenID callback URL in iMIS when configuring the RiSE Client Application. Correct the RiSE client application to use the correct callback URL.
There was a problem loading this area
If you see this error on the SSO page you've set up in RiSE (where your SSO iPart is), then there was an internal error within iMIS and it could not process the SSO request.
If you are self-hosted, check the Windows Event Log for errors / exceptions related to RiSE Client Applications or SSO.
If you are hosted by ASI, submit an SMR and note the exact date/time that you received the error, and ask them to review the application event log for any SSO / Client Application errors.
In some cases, this error can be caused by the RiSE Client Application record becoming corrupt in iMIS. You can try to re-create it following these steps:
Delete the RiSE Client Application record.
Create a new record with a new password, keeping the Callback URL field the same as before.
On the RiSE content page where your SSO iPart lives, edit that page, modify the SSO iPart to point to the new RiSE Client Application record, then save and publish the page.
In the Cloud SSO, under System Settings, modify the Client Application record that corresponds to the one that you just recreated (SAML or OpenID), entering in the new secret value.
Invalid token or client application
This error is an internal iMIS error / bug that indicates that the RiSE Client Application record has become corrupt.
To fix this error, delete the RiSE Client Application record, and RiSE page, associated with the CSI Cloud SSO app. Then, refer to the Cloud SSO Onboarding Guide beginning with Step 3 and recreate the RiSE Client Application, and RiSE page, and reconfigure the Cloud SSO settings with the new information. Then try the SSO flow end-to-end again.
405 Method Not Allowed / Missing Context
The specific endpoints (such as /imis/callback or /openid/authenticate) cannot be accessed directly via a browser. These endpoints are part of the end-to-end SSO flow, and accessing them directly will result in an error. This is by design.
To initiate an SSO flow, you must begin at the third-party, or specifically for SAML, you may also use the IdP-initiation link.
To verify if your SSO instance is online, visit the root / homepage of your SSO domain, for example, https://sso.example.org.
WebException: The underlying connection was closed: An unexpected error occurred on a send
These (or similarly worded) errors are the result of a TLS handshake issue, which occurs when the server and client can't agree on a TLS version or cipher suite.
As of July 2022, the Cloud SSO only supports TLS 1.1, 1.2, and 1.3. TLS 1.0 has been deprecated.
As of June 12, 2023, the Cloud SSO will only support TLS 1.2 connections. Please refer to the Cloud SSO TLS 1.2 Guidelines article for more information.
Fix TLS Issues
There are two possibilities for fixing TLS issues. (Note: You may need to try both of these options together.)
1. Download IISCrypto (nartac.com) and run it on the iMIS App server. Ensure that TLS 1.2 is enabled (TLS 1.1 is also okay), and ensure that at least one of the cipher suites listed on the Ciphers tab matches up with one of the ones in the list above.
2. Download the following registry key update: Enable TLS 1.2.zip and apply it onto the iMIS App Server. Then, from an administrative command prompt, run the command iisreset
If you'd prefer to make the registry changes by hand, please add or update the following keys:
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319Key: SchUseStrongCryptoValue: [DWORD] = 1
Path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319Key: SchUseStrongCryptoValue: [DWORD] = 1
What does this registry change do?
On older operating systems (Windows Server 2016 and prior), the default behavior of .NET Framework and ASP.NET applications is to attempt to connect via TLS starting with the lowest protocol and searching "up". So first it would try SSL3, then TLS 1.0, then TLS 1.1, etc.
When SchUseStrongCrypto is enabled, it instructs the server to attempt the TLS handshake in reverse order, attempting to connect using the newest protocol first. So it tries (if supported) TLS 1.3, then 1.2, then 1.1, etc.