On the evening of Tuesday 11 January, we will deploy a number of changes to the SAFIRE Federation hub to allow for the bi-directional signalling of REFEDS MFA. No downtime is expected, and we do not anticipate any impact on any service- or identity-provider that does not currently support such signalling.
Once complete, the changes summarised below should allow our Federation to fully support the requirements of REFEDS MFA. A growing number of research collaborations require the use of multi-factor authentication for their users, and these changes ensure that those identity providers that themselves support MFA are able to signal this when needed. Given the predominance of Microsoft-based solutions (AD FS & Azure AD) in our Federation, we’ve made a specific effort to ensure that these can be used with minimal changes.
Participants looking for more information on signalling MFA are encouraged to look at the REFEDS MFA supporting material.
Incoming MFA requests (service → identity provider)
Incoming requests containing a
will be proxied to the identity provider. This change will allow service
providers to signal that they require multi-factor authentication. For
the most part, the RequestedAuthnContext will be proxied as requested.
However, in the specific case of identity providers that we
have tagged1 as Microsoft’s
or Azure AD,
incoming RequestedAuthnContext requests for the REFEDS MFA profile
https://refeds.org/profile/mfa) will be rewritten into Microsoft’s
http://schemas.microsoft.com/claims/multipleauthn claim. This
quirk allows service providers to trigger native support for MFA
in these identity providers without requiring specific changes on
the identity provider side. It can be disabled
on request on a
per-IdP basis (for instance, in the case of AD FS using the
ADFSToolkit and having native REFEDS MFA
Outgoing MFA assertions (identity → service provider)
As a result of changes made in December,
outbound responses will have any
proxied to the service provider. Identity providers with native support
for REFEDS MFA can already use this to signal users’ multi-factor
authentications to service providers.
With this change, we will additionally be able to translate outbound
assertions with a
into the corresponding REFEDS MFA (
<samlp:AuthnContextClassRef> assertion. However, because not
all multi-factor authentication methods supported by Microsoft are
compatible with REFEDS MFA, this quirk is not enabled by default. It
can be enabled on a per-IdP basis on request and after the IdP has
implementation of MFA meets the requirements of the REFEDS MFA profile.
The work required to support REFEDS MFA has allowed us to resolve several other problems, which will be propagated at the same time. Notably, these include:
Translation of the SAFIRE-specific
https://safire.ac.za/namespace/claimsnamespace that was introduced to work around the lack of support for multi-valued claims in Azure AD will now only be enabled when an identity provider is tagged1 as Azure AD. (These claims will be ignored for all other identity providers.)
We will resume proxying the
<samlp:Scoping>element to all identity providers except those tagged1 as AD FS or Azure AD. This quirk was introduced in May 2017 to work around a bug in AD FS that resulted in a hard error for those identity providers, and has applied globally since then. As noted at the time, stripping the Scoping element violates the SAML2 specification. We’re now able to target this quirk much more specifically and so will no longer withhold it globally.
SAML responses that do not contain a corresponding assertion will be proxied correctly. This will allows identity provider software such as Oracle Access Manager to signal that MFA is not configured for a user.
You can confirm we’ve correctly classified your identity provider by looking for its metadata in our aggregator and verifying the values of the
urn:x-safire.ac.za:quirksattribute. AD FS should include an AttributeValue of “adfs” and Azure AD should include an AttributeValue of “azure” (case is important). ↩︎ ↩︎ ↩︎