SurePassID Identity Provider

SAML ACR / AMR Configuration Guide

Applies to: SurePassID Identity Provider 2026.4 Audience: Tenant administrators configuring SAML 2.0 service provider apps Protocol scope: SAML 2.0 only (see Notes for OIDC and EAM)

What ACR and AMR Provide

When a SAML app is configured for these signals, the IdP tells the service provider how the user authenticated, so the SP can apply its own risk or step-up policy.

SAML 2.0 has a native element for ACR but none for AMR, so AMR is emitted as an attribute using the widely supported ADFS claim URI.

How to Enable It

Configuration is performed in the Admin Portal, on the SSO app's attribute list. There are no global switches and no new configuration files.

1. Open the Admin Portal and edit the SAML SSO app.
2. Go to the app's Attributes (name/value pair) list.
3. Add one row whose Value is the literal text amr or acr.
   • The Name column is not used for detection; you may use amr for clarity.
   • Matching is case-insensitive and surrounding whitespace is ignored.
4. Save the app.

That single row is the opt-in switch. Both amr and acr behave identically - adding either one turns on both the ACR element and the AMR attribute.

Important: The placeholder row is never sent as-is. The IdP removes the literal amr/acr value and replaces it with the computed values at response time.

Turning it off

Delete the placeholder row. Apps without the row are completely unaffected, so existing integrations keep their current behavior.

What the Service Provider Receives

ACR

Emitted inside the <AuthnStatement>:

AMR

Emitted as a multi-valued attribute, one <AttributeValue> per factor:

• Name: http://schemas.microsoft.com/claims/authnmethodsreferences
• FriendlyName: amr

Example for a password plus push approval login:

<saml:Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences"
                FriendlyName="amr">
  <saml:AttributeValue>pwd</saml:AttributeValue>
  <saml:AttributeValue>mfa</saml:AttributeValue>
</saml:Attribute>

Factor token reference (RFC 8176)

Rules applied automatically:

• Tokens are de-duplicated and kept in a stable order.
• If two or more distinct factors were used, mfa is appended to the list.
• If no factors were recorded for the session, the IdP emits pwd so behavior matches earlier releases.

Service Provider Setup

The SP must be told to read the signals. Configuration is SP-specific, but generally:

• ACR - map or accept the two URIs listed above. Many SPs allow a required ACR value so that single-factor logins are rejected.
• AMR - map the claim named http://schemas.microsoft.com/claims/authnmethodsreferences. Salesforce and other ADFS-compatible consumers recognize this URI directly.

If your SP expects a single space-delimited AMR string rather than multiple values, contact SurePassID Support - the formatting is centralized and can be adjusted.

Verifying the Configuration

1. Sign in to the app using a single factor and capture the SAML response (browser SAML tracer or the IdP audit log).
2. Confirm <AuthnContextClassRef> is the ...ac:classes:Password URI and the AMR attribute contains pwd.
3. Sign in again completing MFA.
4. Confirm the ACR URI changes to ...MobileTwoFactorContract and the AMR attribute lists each factor plus mfa.
5. Confirm no attribute contains the literal value amr or acr.

Troubleshooting

Notes for OIDC and EAM

• EAM reuses the same captured authentication methods and emits acr and amr claims in the id_token.
• OIDC app configuration for these signals is not driven by the SAML attribute placeholder described here.
• Federation policy evaluation is enforced for SAML 2.0 only in this release.

Related Documents

• SurePassID Identity Provider User Guide
• SurePassID Identity Provider Capabilities
• Document History