[Access] Document AAGUID restrictions and AMR matching for independent MFA - #30252
Conversation
| @@ -0,0 +1,14 @@ | |||
| --- | |||
| title: AAGUID restrictions and AMR matching for Access independent MFA | |||
| description: Restrict which WebAuthn authenticators users can enroll and skip redundant MFA prompts when the identity provider already performed MFA. | |||
There was a problem hiding this comment.
AMR matching is available for all MFA methods, but this sentence makes it sound like it's only available for WebAuthn-backed authenticators i.e., it can be used for TOTP in addition to biometrics, and security keys.
We should reword this sentence to the following to improve readability:
"Restrict which WebAuthn authenticators users can enroll and allow users to skip redundant MFA prompts when they have already performed MFA using their IdP"
| 3. Select an existing [AAGUID list](#create-an-aaguid-list). | ||
| 4. Select **Save**. | ||
|
|
||
| After you save, only authenticators whose AAGUIDs appear in the list can be enrolled. Users with previously enrolled authenticators outside the list can continue to use them until an administrator deletes the device. |
There was a problem hiding this comment.
"device" makes me think of a ZT device, and not an authenticator: use "MFA device" or reword the sentence to "Users with previously enrolled authenticators outside the list can continue to use them until they are deleted by an administrator."
Also, add a link to the section where we explain how an administrator can delete MFA devices (under " Delete an authenticator").
| - [Required AAGUIDs](#restrict-authenticators-by-aaguid) is set at the organization level. AAGUID information is not present in the IdP's AMR claim, so Access cannot verify that the IdP's MFA came from an approved device. | ||
| - The IdP does not return an `amr` claim. | ||
| - The IdP returns only AMR values that do not map to an [allowed authenticator type](#supported-mfa-methods) for the application or policy. | ||
| - The user's last IdP MFA is older than the configured AMR session duration. |
There was a problem hiding this comment.
Could reword this as: "The user's AMR matching session has expired because they last performed MFA via their IdP too long ago".
| - The IdP returns only AMR values that do not map to an [allowed authenticator type](#supported-mfa-methods) for the application or policy. | ||
| - The user's last IdP MFA is older than the configured AMR session duration. | ||
|
|
||
| In these cases, Access prompts the user to complete independent MFA. |
There was a problem hiding this comment.
It depends.
We will fall back to checking for existing MFA sessions. If there are no valid MFA sessions, then the user will be prompted to perform independent MFA.
fix API examples and UI labels
Updated the MFA settings instructions to include the option for using identity provider MFA, which prevents double prompting for MFA. Adjusted the section title to reflect the new feature.
Co-authored-by: ranbel <101146722+ranbel@users.noreply.github.com>
5 participants
Summary
Documents two features added under SHIP-1287 (IdP Agnostic Multi-Factor Authentication) that shipped under RM-27743 but were not included in the initial docs PR (#29713):
AAGUID.amrclaim defined in RFC 8176.Also adds
AAGUIDto the list of supported Lists data types and cross-links both new sections frommfa-requirements.mdx.Related
Items pending update: AAGUID & AMR matchingDraft / needs review
A few things would benefit from confirmation from the Access team before merging. Flagged inline:
mfa_config.required_aaguids,mfa_config.amr_matching_enabled, andmfa_config.amr_session_duration. The first is explicit in the Required AAGUIDs UI wiki page; the AMR field names are my best guess and may differ in the shipped API.Required AAGUIDsandTrust identity provider MFA (AMR matching)are placeholders; actual UI labels may differ.mfa(flagged as open question in the wiki) and values the wiki marks as unsupported.Zero Trust > Resources > Lists; please confirm that is where these lists live.cc @asamborski for a review — happy to iterate on wording or restructure once the API surface is confirmed.