DO NOT MERGE, REFERENCE ONLY Support high assurance level

[bheesham]

Jira: IAM-1989

---

tl;dr: for some RPs we need to support a stricter policy for MFA. This PR adds support for HIGH.

[Copilot]

Pull request overview

Adds support for a stricter authenticator assurance policy (HIGH) in the accessRules Auth0 Action, along with Terraform secret wiring and test updates, to enable RPs to require stronger MFA characteristics.

Changes:

• Introduces an AAL→AAI mapping (including HIGH) and updates decision logic to select the highest AAL across matching authorization rules.
• Updates Duo configuration handling to select credentials based on the required AAL.
• Adjusts Jest tests to reflect new HIGH behavior (Duo treated as satisfying HARDWARE).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
tf/actions/accessRules.js	Adds HIGH AAL support, mapping/selection logic, and Duo config selection changes.
tf/tests/accessRules.test.js	Updates tests for the new HIGH behavior expectations.
tf/actions.tf	Renames/splits Duo Action secrets into medium/high variants for the Action runtime.

Comments suppressed due to low confidence (1)

tf/actions/accessRules.js:382

• For LDAP (strategy === "ad") users that require Duo, enableDuo is set but aai remains empty. That causes MEDIUM requirements to fail the AAI check (since AAI_MAPPING["MEDIUM"] is non-empty), denying access before the Duo challenge can be triggered. If enabling Duo is intended to satisfy MEDIUM, add the relevant AAI indicator(s) when enableDuo is set.

    // Allow certain LDAP service accounts to fake their MFA. For all other LDAPi accounts, enforce MFA
    if (event.connection.strategy === "ad") {
      // No support for HIGH or MAXIMUM assurance levels.
      if (mfaBypassAccounts.includes(event.user.email)) {
        console.log(
          `LDAP service account (${event.user.email}) is allowed to bypass MFA`
        );
        aai.add("2FA");
      } else {
        enableDuo = true;
        console.log(
          `duosecurity: ${event.user.email} is in LDAP and requires 2FA check`
        );
      }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bheesham]

Tested successfully on dev:

[gcoxmoz]

I don't love it. If landed, I hope you'll add notes to apps.yml that explain that AAL: LOW has a new path / doesn't mean what is written. But that's a nitpick, whatevs.

Really, I worry that there might be RPs in here that will burp because of a new minimum. Just top of my head, there appears to be a conflation of AD_MIN being taken to mean 'employee' when it's LDAP users, which may have non-employees.

This might be fine! But I am first-blush skeptical.

[bheesham]

Good catch, there was a bug here. The bit of code where this is used should have instead lived in a different if statement: where we check if Duo is included in their profile.

The original one didn't hit the duo branch, and I missed that in this implementation. The test now passes here, and continues to pass on master.

The behaviour for LDAPers hasn't changed (anymore!), and I added to the comment for AAL_AD_MIN. But yeah, because this was always the behaviour, the docs in apps.yml are still out of date. PR incoming.

[bheesham]

Potentially clarified in apps.yml?

[gcoxmoz]

I don't think we should default-allow here. aal goes through checks above, and should arrive here as a valid value because of AAL_DEFAULT existing. And if it doesn't, then we've missed something above, big time.

IMO, default-deny here. It probably isn't a big win, I get it.

[bheesham]

(er, before and after. nothing related to this is changing.)

[bheesham]

I chatted with @VegasNative about this, and I'm way off base! AAL is defined here, and I'll quote for convenience.

AAL1 permits single-factor authentication using a wide variety of authenticators listed in SP 800-63B Section 4.1.1. By far the most common authenticator at AAL1 is the memorized secret, but from the standpoint of meeting AAL1 requirements it is equally acceptable to use a physical authenticator such as an OTP device.

This is our LOWEST.

AAL2 requires the use of two authentication factors, either (1) a physical authenticator and a memorized secret, or (2) a physical authenticator and a biometric that has been associated with it. Multi-factor authentication can be performed using either a multi-factor authenticator or through the use of two independent authenticators.

This is our MEDIUM.

This PR adds HIGH, but I don't think that's the intention here. We want to restrict which factors are used in the authentication process, not necessarily give a higher level of assurance.

Some of the logic here can be kept, but I think anything related to us saying HIGH AAL should be removed. I think what we really want is to add a new key to the apps.yml spec, to specify which authenticators should be allowed, and add that to the AAI (ref for future dev). (Maybe?)

I have a meeting scheduled with @gene1wood tomorrow to chat more.

[bheesham]

(Dunno though! I'll keep reading.)

[bheesham]

More info! I chatted with @gene1wood!

re: changing remembered devices in Duo: no policy; it was easier to remember in Auth0 than in Duo. I believe we should be able to change the settings for only the SSO application in Duo. That would still remember clients for 30 days. It does come at the cost of an extra HTTP call, but, it's probably fine.

re: AAL The AAL stuff is really a mapping Mozilla's risk standard levels (referenced in, the archived, mozilla-iam repository). I'll have to ensure the docs in mozilla-iam are copied over to Confluence, or some easier to find place.

A brief detour into AALs

Quoting the docs:

The AALs are ranked using the Mozilla Standard Levels, i.e. LOW/MEDIUM/HIGH/MAXIMUM. The AAL is used to determine if a user should be granted access per relying party.

And, quoting a bit from SP 800-63B Section 4.1.1:

AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

A memorized secret covers this when we don't prompt for MFA, and roughly corresponds to our LOW risk.

At AAL2, authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators. A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptographically-secure device with an integrated biometric sensor that is required to activate the device. Authenticator requirements are specified in Section 5.

AAL2 maps to roughly our MEDIUM. Since we always ask for a password, the following applies to us:

When a combination of two single-factor authenticators is used, it SHALL include a Memorized Secret authenticator (Section 5.1.1) and one possession-based (i.e., “something you have”) authenticator from the following list:

• Look-Up Secret (Section 5.1.2)
• Out-of-Band Device (Section 5.1.3)
• Single-Factor OTP Device (Section 5.1.4)
• Single-Factor Cryptographic Software (Section 5.1.6)
• Single-Factor Cryptographic Device (Section 5.1.7)

But, most of that's not really relevant to the issue: an RP requiring specific factors to be used.