How to avoid duplicate realms for IWA and MFA users

Version Affected:  All

Description:  

For On Prem/Hybrid customers who do not have both DMZ and Internal IdPs, there has always been an issue with allowing IWA/Windows SSO for the internal users but maintaining MFA for external. 

This was typically solved with duplicate realms. Hit the MFA realm first and use a rule to move the internal users to the IWA version of the same realm.

Cause:  

Duplicate realms work fine but it is a lot of work for the Admins

Resolution:  

1. Pick a realm to act as the "main" realm for internal users. This could be a portal realm or simply the most popular realm.

2. Have this setup with the usual MFA realm + duplicate IWA realm

3. Edit the FormsAuth cookies on this realm so that the Forms and Post Auth cookies have the same name and the machinekeys have been generated

4. Copy these same FormsAuth settings to the other realms that you wish the users to be able to access without needing to re-enter credentials. 

5. On the participating realms, go to the workflow tab and enable Transparent SSO. 

User Experience:  

1. User open their browser which loads the WindowsSSO realm automatically and the user is logged in seemlessly. The TSSO cookies are created.

2. User goes to another realm which participates in the TSSO group

3. They login automatically as they have a current cookie

Special Considerations:

Transparent SSO is only as strong as your weakest realm as all realms in the TSSO group are capable of creating the cookies after a successful login. This means that you should only apply TSSO to realms that have the same workflow/policy/adaptive settings.

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.