Troubleshooting: Transparent SSO Redirects to Login Again for SP-Initiated Realms

Version Affected: 9.0.x, 9.1, 9.2
 
 

Overview

A user successfully authenticates to the Secure Portal realm, but clicking a tile for an SP-Initiated application redirects correctly and then asks the user to enter their username, password, and second factor again instead of completing Transparent SSO. The same issue occurs with Transparent SSO between realms that don't go through the Secure Portal.

Cause

The Transparent SSO settings on the Secure Portal realm expect the request to go straight to the Authorized folder. When an SP-Initiated realm is used instead, the request is redirected to the SecureAuth.aspx page, which does not let Transparent SSO through.

Resolution

1. Go to the Post Authentication tab of the Secure Portal realm.
2. Scroll down and select View and Configure FormsAuth keys/SSO Token.
3. In the Forms Authentication section, set a Name (for example, SSOToken), then copy that same name into the Post-Auth Cookie field under Authentication Cookies below.
4. Under Machine Key, click Generate New Keys, confirm a Validation and Decryption key both appear, then click Save.
5. Uncheck the box next to the Secure Portal realm, check the box next to the realm you want to include in the Transparent SSO setup, and click Save.
6. In the application realm, go to the Workflow tab and locate the Custom Identity Consumer section.
7. Change the Receive Token drop-down to Token.
8. Change the Allow Transparent SSO drop-down to True.
9. Click Save and test.

Special Considerations

To check whether the application realm is receiving the authenticated user ID in the cookie, append cookietest.aspx to the end of the realm's URL in the browser. If the username does not appear, the cookie is not being sent from the Secure Portal realm.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.