Skip to main content
Submit a Request

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

Andrew Wood
Updated
    Applies to:
  • SecureAuth Identity Platform
    Deployment model:
  • Cloud
  • Hybrid
  • On Premises

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.
    The Authentication Rules tab of a Policy, with a rule to block the IP after 5 failed attempts, and an Else rule set to Prompt for MFA for all other logins.
  • Set the Login Workflow to Passwordless.
    The Login Workflow tab of the Policy, with Login Workflow set to Passwordless.
  • Under Multi-Factor Methods, allow only the specific MFA method(s) you want required on this first realm.
    The Multi-Factor Methods tab of the Policy, with One-Time Passcode via text message selected as the only allowed method.
  • 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.
    The New Internal Application form, with the Internal Application Name set to First Realm, a Data Store selected, and the Authentication Policy set to the policy created in step 1.
  • 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.
    The Authenticate User Redirect settings set to Custom Redirect, with the Redirect To field pointing 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:
A new custom policy being created, on the Authentication Rules tab.

  • 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.
    The Login Workflow tab of the second Policy, set to Username | MFA Method | 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.
    The Multi-Factor Methods tab of the second Policy, with PIN selected as the required method - a different method than the first Policy used.
  • 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.
    The New Internal Application form for the second realm, with the Authentication Policy set 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.
    The Authenticate User Redirect settings for the second realm, set to a Generic redirect - in this example, a Multi-Factor App Enrollment URL.
  • 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.
    The realm's FormsAuth Keys/SSO Token settings, showing the Forms Authentication, Machine Key, and Authentication Cookies sections with a Generate New Keys button.
  • 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).
    The Authentication Cookies fields on the second realm, with the Pre-Auth Cookie set to the first realm's Post-Auth Cookie name, and the Post-Auth Cookie set to a new, distinct name.
  • 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/).
    The Custom Identity Consumer section on the second realm's Workflow tab, with Receive Token set to Token, Require Begin Site set to True, Begin Site set to Custom, and the Begin Site URL set to the first realm's path.

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.

Comments

0 comments

Please sign in to leave a comment.