iMIS Power Suite - SSO Premium

SSO errors and troubleshooting

This page outlines common SSO errors, what they mean, and how to resolve them.

Context errors

OpenID: Missing context: SSO request did not originate from here

SAML: Critical information missing from session state (clientId or serialized request). This often indicates that cookies are being blocked.

These errors typically occur for one of the following reasons:

1. The user attempted to browse to the RiSE SSO page directly.
OpenID/OAuth2 flows require the third-party system to initiate the SSO request. You cannot begin the SSO flow from RiSE. Instead, start at the third-party website, which will pass the correct request parameters into iMIS.

2. The wrong callback URL was used for SAML.
When configuring a SAML application, the callback URL must end with /saml/imis/callback. If the OpenID callback (/imis/callback) was entered by mistake, iMIS cannot process the request. Update the RiSE Client Application to use the correct SAML callback URL.

“There was a problem loading this area”

This message indicates an internal iMIS error while processing the SSO request on your RiSE SSO page.

If you are self-hosted: Check the Windows Event Log for errors related to RiSE Client Applications or SSO.

If you are hosted by ASI: Submit an SMR with the exact date and time of the error and request a review of the application event log for SSO-related errors.

In some cases, this can occur when the RiSE Client Application record becomes corrupt. Try re-creating it:

  • Delete the existing RiSE Client Application record.
  • Create a new record with a new password, using the same Callback URL.
  • Edit the RiSE content page that contains your SSO iPart. Update the iPart to reference the new Client Application record, then save and publish.
  • In iMIS SSO under System Settings, update the corresponding Client Application (SAML or OpenID) with the new secret value.

Invalid token or client application

This internal iMIS error indicates that the RiSE Client Application record has become corrupt.

To resolve the issue:

  • Delete the RiSE Client Application record and the RiSE page associated with the iMIS SSO Premium app.
  • Recreate both following the iMIS SSO Onboarding Guide, beginning with Step 3.
  • Reconfigure iMIS SSO using the new client application information.
  • Test the SSO flow end-to-end.

405 Method Not Allowed / Missing Context

Certain SSO endpoints—such as /imis/callback or /openid/authenticate—cannot be accessed directly via a browser. They are only valid within an active SSO flow.

This behavior is expected and prevents invalid or incomplete authentication attempts.

To begin an SSO flow:

  • Start from the third-party system (required for OpenID/OAuth2).
  • For SAML, you may also begin through the IdP-initiation link.

To confirm that 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

This error indicates a TLS handshake failure—typically the server and client cannot agree on a supported TLS version or cipher suite.

As of July 2022: iMIS SSO supports TLS 1.1, 1.2, and 1.3 (TLS 1.0 is deprecated).

As of June 12, 2023: iMIS SSO supports TLS 1.2 only. Refer to the iMIS SSO TLS 1.2 Guidelines for details.

Fix TLS issues

You may need to apply one or both of these fixes:

1. Enable appropriate TLS versions using IIS Crypto.
Download IISCrypto and run it on the iMIS App Server. Ensure that TLS 1.2 is enabled (TLS 1.1 is optional) and verify that at least one supported cipher suite matches those required by iMIS SSO.

2. Enable strong cryptography via registry keys.
Download and apply the Enable TLS 1.2 registry update on the iMIS App Server. Then run iisreset from an administrative command prompt.

If making registry edits manually, update the following keys:

				Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
				Key: SchUseStrongCrypto
				Value: [DWORD] = 1
		
				Path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
				Key: SchUseStrongCrypto
				Value: [DWORD] = 1

On older operating systems (Windows Server 2016 and earlier), .NET applications attempt TLS protocols in ascending order (SSL3 → TLS 1.0 → TLS 1.1 → TLS 1.2).

Enabling SchUseStrongCrypto reverses this order, forcing the system to try the most secure protocols first (TLS 1.3 → TLS 1.2 → TLS 1.1).