How To: Chain Realms to Require Two Different MFA Methods Instead of a Password

Version Affected: All

 

Overview

Some use cases call for a login flow of Username, then a first Multi-Factor Authentication (MFA) method, then a second, different MFA method — replacing the usual password step with an additional MFA method instead. This is not yet available as a single built-in Policy option, but you can achieve the same result today by chaining two realms together, each with its own Policy.

This article walks through building a two-realm chain where a user authenticates with a username, completes one MFA method on the first realm, and is then automatically moved to a second realm to complete a different MFA method — optionally followed by a password.

Chain Two Realms for Sequential MFA

1. Create a Policy for the first realm in the chain:

• Add an Authentication Rule that always prompts for MFA.
• Set the Login Workflow to Passwordless.
• Under Multi-Factor Methods, allow only the specific MFA method(s) you want required on this first realm.
• Save the Policy.

2. Create the first realm in the chain:

• Go to Application Manager or Internal Application Manager and click Add New.
• Set the realm's name, Data Store, and any Group restrictions as needed.
• Set the Authentication Policy to the Policy created in step 1.
• Set the Authenticate User Redirect to Custom Redirect, and set the redirect target to the next realm in the chain.
• Click Create Connection.

3. Create a second Policy for the second realm in the chain, and set this to always prompt for MFA as well:

• Set the Login Workflow. Choose Passwordless if the finished chain should be Username | MFA | MFA, or choose Username | MFA Method | Password if the finished chain should be Username | MFA | MFA | Password.
• Under Multi-Factor Methods, require a different method (or methods) than the first Policy used, so the user is forced to complete two distinct MFA methods.
• Save the Policy.

4. Go to Application Manager or Internal Application Manager and click Add New to create the second realm:

• Select the required Data Store and Realm Number, and set the Authentication Policy to the Policy created in step 3.
• Set the required Authenticate User Redirect. This is commonly an enrollment realm, but it can be any realm type.
• Click Create Connection.

5. Switch to Advanced Settings and open the Post Auth tab of the first realm created in step 2:

• Click View and Configure FormsAuth Keys/SSO Token, then click Generate New Keys.
• Copy these same Machine Key settings over to the second realm created in step 4.
• On the second realm, change the Pre-Auth Cookie to the first realm's Post-Auth Cookie name (for example, PostAuthToken450 if the first realm's Post-Auth Cookie is named that).
• Change the second realm's own Post-Auth Cookie to a distinct name (for example, PostAuthToken451).
• On the second realm's Workflow tab, open the Custom Identity Consumer section and set: Receive Token to Token, Require Begin Site to True, Begin Site to Custom, and Begin Site URL to the first realm's URL path (for example, /SecureAuth450/).

With this configuration in place, the resulting login experience is:

1. The user starts at the first realm, enters their username, and completes the first realm's required MFA method.
2. Upon success, they are automatically redirected to the second realm.
3. At the second realm, they are presented with the second realm's different MFA method.
4. Once that MFA method also succeeds, the user is either considered fully authenticated, or is prompted for a password as well — whichever the second realm's Login Workflow setting specifies.

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.