Breadcrumbs

Default Authentication Method per each SAML Application

VeridiumID 3.9 allows administrators to configure the SAML Authentication Context Class Reference, or AuthnContextClassRef, separately for each SAML Service Provider application.

The authentication context communicates how the user was authenticated by the Identity Provider. A Service Provider can use this information to determine whether the completed authentication satisfies its security requirements.

This application-level configuration is especially useful when different Service Providers expect different authentication assurance values.

Why Configure an Authentication Context?

When no application-specific authentication context is configured, Shibboleth uses the default authentication context:

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

This value may be suitable for standard SAML integrations, but it is insufficient for scenarios in which the Service Provider expects the federated authentication session to be identified as multifactor authentication.

For example, Microsoft Entra requires the following authentication context to recognize the federated session as MFA:

http://schemas.microsoft.com/claims/multipleauthn

Without this value, Microsoft Entra may ignore the MFA status of the federated VeridiumID session and enforce its own MFA methods.

Configure the Default Authentication Method

The authentication context can be configured directly from the individual SAML application in Veridium Manager.

To configure it:

  1. Navigate to Applications in Veridium Manager.

  2. Open the required SAML application.

  3. Locate the Default Authentication Method field.

  4. Select or enter the authentication context required by the Service Provider.

  5. Save the application.

The configured value applies only to the selected SAML Service Provider.

Other SAML applications can use a different authentication context or continue using the platform default.

Authentication Context Resolution

Shibboleth uses a three-level resolution mechanism when selecting the authentication context.

Level

Configuration location

Purpose

1

authn/general-authn.xml

Declares which authentication context class references each authentication flow can produce

2

relying-party.xml

Defines the default authentication context expected by a specific Service Provider

3

shibboleth.AuthenticationPrincipalWeightMap

Provides the global fallback when no application-specific value is configured

The new Default Authentication Method field controls the second level of this resolution mechanism.

When a value is configured for a SAML application, it is added to the corresponding Service Provider configuration in relying-party.xml.

When no value is configured, Shibboleth falls back to the global AuthenticationPrincipalWeightMap and selects PasswordProtectedTransport.

Microsoft Entra MFA Use Case

For a SAML application integrated with Microsoft Entra, configure the following value as the default authentication method:

http://schemas.microsoft.com/claims/multipleauthn

The resulting behavior is:

Before configuration

After configuration

Shibboleth sends PasswordProtectedTransport

Shibboleth sends http://schemas.microsoft.com/claims/multipleauthn

Microsoft Entra does not recognize the federated session as MFA

Microsoft Entra recognizes the federated Identity Provider session as MFA

The user may be prompted for an additional Microsoft Entra MFA method

The VeridiumID federated MFA session can satisfy the Microsoft Entra MFA requirement

The configured value must be supported by the VeridiumID Identity Provider and accepted by the Service Provider.

Generated Shibboleth Configuration

When the Default Authentication Method field is configured, VeridiumID includes the corresponding defaultAuthenticationMethods property when generating the Service Provider configuration in relying-party.xml.

Example:

HTML
<bean id="SAML_CLIENT_xyz"
      c:relyingPartyIds="https://your-sp-entity-id"
      parent="RelyingPartyByName">

    <property name="profileConfigurations">
        <list>
            <bean parent="SAML2.SSO"
                  p:authenticationFlows="#{{'VeridiumJourney'}}"
                  p:encryptAssertions="false"
                  p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">

                <property name="defaultAuthenticationMethods">
                    <list>
                        <bean
                            c:classRef="http://schemas.microsoft.com/claims/multipleauthn"
                            parent="shibboleth.SAML2AuthnContextClassRef"/>
                    </list>
                </property>
            </bean>

            <ref bean="SAML2.Logout"/>
        </list>
    </property>
</bean>

The defaultAuthenticationMethods property applies the selected authentication context to the corresponding SAML Service Provider.

Supported Authentication Principals

The saml2SupportedPrincipals configuration in ZooKeeper, stored in idp-properties.json, has been extended to include the Microsoft MFA authentication context:

http://schemas.microsoft.com/claims/multipleauthn

This makes the value available as a supported principal for SAML application configuration.

Configuration Scope

The application-level setting does not modify general-authn.xml.

That file remains a global declaration of the authentication contexts that each VeridiumID authentication flow can produce.

The shibboleth.AuthenticationPrincipalWeightMap also remains unchanged and continues to provide the global fallback for SAML applications that do not configure a Default Authentication Method.

Backward-Compatible Behavior

Existing SAML applications retain their current behavior unless an administrator explicitly configures a different authentication context.

Applications without an application-specific value continue to use:

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

This allows administrators to introduce specialized authentication-context requirements for individual Service Providers without affecting unrelated SAML integrations.

Last updated: