Date: Thu, 28 Mar 2024 09:10:45 +0000 (UTC) Message-ID: <1226972112.27.1711617045947@wiki-prod.refeds.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_26_1910459278.1711617045946" ------=_Part_26_1910459278.1711617045946 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A new FAQ is now available.
This version of Refeds MFA Profile FAQ has been replaced with a new vers= ion. Visit the new REFEDS MFA Prof= ile FAQ.
The following FAQ support the use of the REFEDS Multifactor Authenticati= on Profile. This documentation is intended to be non-normative suppor= ting information. If you have any questions about the use of the REFE= DS MFA Profile, please direct them to the REFEDS mailing list (refeds@lists= .refeds.org).
In order to assert the REFEDS MFA profile, the Identity Provider must be= using an authentication method that meets the following requirements:
The combination of the factors mitigates single-factor only risks re= lated to non-real-time attacks such as phishing, offline cracking, online g= uessing and theft of a (single) factor.
The Profile signals that the specific user in question is using multifac= tor authentication in a way that meetings the requirements shown above.&nbs= p; Mutlifactor provides additional safeguards for both IdPs and SPs but is = not completely resistant to all possible threats - this should be kept in m= ind when selecting appropriate approaches and technologies.
The REFEDS MFA Profile makes no statement about the types of technologie= s that could be used as the second or multi factor. The InCommon MFA = Interoperability Profile Working Group has prepared some useful advice on approaches that might be useful.
Each factor in the MFA profile must be of a different type. = This means that validating two separate passwords is not sufficient - the s= econd (and further) factors must use a different factor approach. &nbs= p; This is to address any generic point of failure with one factor type.&nb= sp;
Many assurance profiles will include approaches to MFA within them. = ; REFEDS Assurance Framework does not reference the REFEDS = MFA Profile but is intended to work in parallel with this profile.
The Profile is not intended to be SAML specific and can be extended for = use with other technologies, such as OIDC. This will be reviewed subj= ect to demand in those areas and examples provided when appropriate and mat= ure.
The recommended means of representing these profiles in a SAML assertion= are via the <AuthContextClassRef> element (SAML 2.0). These are expr= essed in SAML statements used to represent acts of authentication by the su= bject of an assertion. In the case of SAML 2.0, the use of the Authenticati= on Context mechanism has the benefit of enabling signaling of requirements = by a relying party in its requests to an identity provider.
Configuration examples for several identity provider t= echnologies are available.
Most IdPs and campuses that support MFA services do not provide universa= l MFA coverage for their user communities. This means that even when a give= n IdP is capable of supporting this profile, there is a significant probabi= lity that any given user may not be able to authenticate using MFA. T= here is no defined mechanism at present to identify whether a given IdP is = configured to assert <AuthnContextClassRef> values, and SAML it= self does not rely on that knowledge; it assumes that IdPs will respond in = accordance with the standard when handling a request containing requirement= s it cannot meet.. If the SP does not have any information about an IdP=E2= =80=99s capabilities, it may not be able to distinguish between a case of s= pecific users being unable to satisfy the profile, and an IdP as a whole no= t supporting it. Whether this distinction is relevant will depend on the SP= . <AuthnContextClassRef> value is returned in SAML responses; i= t is not sufficient to configure an SP to request MFA and assume all respon= ses will therefore contain the MFA context. This is because users can gener= ally bypass an SP=E2=80=99s SAML request configuration using unsolicited re= sponses from an IdP, or by handcrafting a SAML request that does not includ= e the MFA requirement.
If an application intends to provide limited services to non MFA authent= icated users, the actual <AuthnContextClassRef> value returned to the= SP will need to be evaluated dynamically by the application to determine t= he appropriate access to provide to the user.
From a technical standpoint, when generating a SAML authentication reque= st where the MFA profile is desired, the approach is fairly straightforward= :
This use case is most relevant if the SP operator knows that the IdP in =
question supports this profile. To require that all users must authenticate=
using MFA, a SAML authentication request
should include:
<samlp:RequestedAuthnContext Comparison=3D"exact">
<saml:AuthnContextClassRef>
https://refeds.org/prof=
ile/mfa
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
That is, MFA is the (only) requested value.
Even if an IdP supports the MFA Profile, it can only respond successfull= y to such a request if MFA is actually performed. If the user can authentic= ate to the IdP, but is not able to use MFA, the IdP must respond with an er= ror, and the SP will not receive any information about the user who tried t= o authenticate. If this distinction is important, and it=E2=80=99s importan= t to know the identity of the user even if MFA is not possible, consider on= e of the later uses case of preferring MFA, but accepting less. Appli= cation error messages when using this model should explicitly note that MFA= is required to access the SP=E2=80=99s services.
In some cases, an SP may prefer that users authenticate with MFA but is = willing to accept non-MFA authentication. Some scenarios where this approac= h would make sense:
In this scenario it is recommended that the SP request not just the REFE=
DS MFA Profile, but also any other standard or common <AuthnContextClass=
Ref> values that are acceptable and frequently encountered. A
recommended request that should cover most of these use cases would include=
:
<samlp:RequestedAuthnContext Comparison=3D"exact">
<saml:AuthnContextClassRef>
https://refeds.org/prof=
ile/mfa
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</saml:AuthnContextClassRef>
The actual list of AuthnContextClassRef values to support is up to the SP, =
but this list is likely to address the majority of IdPs. To support arbitra=
ry IdPs, it may still be necessary to respond to SAML errors by issuing a s=
eparate SAML request that includes no <RequestedAuthnContext> element=
.
If a user was initially authenticated without MFA then depending on the = identity of the user or the services the user is accessing, the SP may want= to =E2=80=9Celevate=E2=80=9D the user=E2=80=99s authentication profile as = a prerequisite to allowing further access. To do this, a new SAML authentic= ation request must be generated that includes only http= s://refeds.org/profile/mfa. This request would be equivalent to the req= uests generated under the =E2=80=9CSP always requires MFA=E2=80=9D section,= above.
The REFEDS Multifactor Authentication Profile references ITU-T X.1254 as= it references four different factors for authentication in a well describe= d way. Other frameworks define 3 factors, which is more limiting for = implementors. These four areas are:
Please note that this reference is purely to the good definitions used b= y ITU-T X.1254 for authentication factors - there is no other relationship = between the MFA Profile and this, or any other, assurance framework at this= time.
REFEDS is developing a Profile to flag approaches that do not provide mu= ltifactor. The scope of this is still to be decided, but this FAQ wil= l be updated as appropriate.
The following FAQ support the use of the REFEDS Multifactor Authenticati= on Profile. This documentation is intended to be non-normative suppor= ting information. If you have any questions about the use of the REFE= DS MFA Profile, please direct them to the REFEDS mailing list (refeds@lists= .refeds.org).
In order to assert the REFEDS MFA profile, the Identity Provider must be= using an authentication method that meets the following requirements:
The combination of the factors mitigates single-factor only risks re= lated to non-real-time attacks such as phishing, offline cracking, online g= uessing and theft of a (single) factor.
The Profile signals that the specific user in question is using multifac= tor authentication in a way that meetings the requirements shown above.&nbs= p; Mutlifactor provides additional safeguards for both IdPs and SPs but is = not completely resistant to all possible threats - this should be kept in m= ind when selecting appropriate approaches and technologies.
The REFEDS MFA Profile makes no statement about the types of technologie= s that could be used as the second or multi factor. The InCommon MFA = Interoperability Profile Working Group has prepared some useful advice on approaches that might be useful.
Each factor in the MFA profile must be of a different type. = This means that validating two separate passwords is not sufficient - the s= econd (and further) factors must use a different factor approach. &nbs= p; This is to address any generic point of failure with one factor type.&nb= sp;
Many assurance profiles will include approaches to MFA within them. = ; REFEDS Assurance Framework does not reference the REFEDS = MFA Profile but is intended to work in parallel with this profile.
The Profile is not intended to be SAML specific and can be extended for = use with other technologies, such as OIDC. This will be reviewed subj= ect to demand in those areas and examples provided when appropriate and mat= ure.
The recommended means of representing these profiles in a SAML assertion= are via the <AuthContextClassRef> element (SAML 2.0). These are expr= essed in SAML statements used to represent acts of authentication by the su= bject of an assertion. In the case of SAML 2.0, the use of the Authenticati= on Context mechanism has the benefit of enabling signaling of requirements = by a relying party in its requests to an identity provider.
Configuration examples for several identity provider t= echnologies are available.
Most IdPs and campuses that support MFA services do not provide universa= l MFA coverage for their user communities. This means that even when a give= n IdP is capable of supporting this profile, there is a significant probabi= lity that any given user may not be able to authenticate using MFA. T= here is no defined mechanism at present to identify whether a given IdP is = configured to assert <AuthnContextClassRef> values, and SAML it= self does not rely on that knowledge; it assumes that IdPs will respond in = accordance with the standard when handling a request containing requirement= s it cannot meet.. If the SP does not have any information about an IdP=E2= =80=99s capabilities, it may not be able to distinguish between a case of s= pecific users being unable to satisfy the profile, and an IdP as a whole no= t supporting it. Whether this distinction is relevant will depend on the SP= . <AuthnContextClassRef> value is returned in SAML responses; i= t is not sufficient to configure an SP to request MFA and assume all respon= ses will therefore contain the MFA context. This is because users can gener= ally bypass an SP=E2=80=99s SAML request configuration using unsolicited re= sponses from an IdP, or by handcrafting a SAML request that does not includ= e the MFA requirement.
If an application intends to provide limited services to non MFA authent= icated users, the actual <AuthnContextClassRef> value returned to the= SP will need to be evaluated dynamically by the application to determine t= he appropriate access to provide to the user.
From a technical standpoint, when generating a SAML authentication reque= st where the MFA profile is desired, the approach is fairly straightforward= :
This use case is most relevant if the SP operator knows that the IdP in =
question supports this profile. To require that all users must authenticate=
using MFA, a SAML authentication request
should include:
<samlp:RequestedAuthnContext Comparison=3D"exact">
<saml:AuthnContextClassRef>
https://refeds.org/prof=
ile/mfa
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
That is, MFA is the (only) requested value.
Even if an IdP supports the MFA Profile, it can only respond successfull= y to such a request if MFA is actually performed. If the user can authentic= ate to the IdP, but is not able to use MFA, the IdP must respond with an er= ror, and the SP will not receive any information about the user who tried t= o authenticate. If this distinction is important, and it=E2=80=99s importan= t to know the identity of the user even if MFA is not possible, consider on= e of the later uses case of preferring MFA, but accepting less. Appli= cation error messages when using this model should explicitly note that MFA= is required to access the SP=E2=80=99s services.
In some cases, an SP may prefer that users authenticate with MFA but is = willing to accept non-MFA authentication. Some scenarios where this approac= h would make sense:
In this scenario it is recommended that the SP request not just the REFE=
DS MFA Profile, but also any other standard or common <AuthnContextClass=
Ref> values that are acceptable and frequently encountered. A
recommended request that should cover most of these use cases would include=
:
<samlp:RequestedAuthnContext Comparison=3D"exact">
<saml:AuthnContextClassRef>
https://refeds.org/prof=
ile/mfa
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</saml:AuthnContextClassRef>
The actual list of AuthnContextClassRef values to support is up to the SP, =
but this list is likely to address the majority of IdPs. To support arbitra=
ry IdPs, it may still be necessary to respond to SAML errors by issuing a s=
eparate SAML request that includes no <RequestedAuthnContext> element=
.
If a user was initially authenticated without MFA then depending on the = identity of the user or the services the user is accessing, the SP may want= to =E2=80=9Celevate=E2=80=9D the user=E2=80=99s authentication profile as = a prerequisite to allowing further access. To do this, a new SAML authentic= ation request must be generated that includes only http= s://refeds.org/profile/mfa. This request would be equivalent to the req= uests generated under the =E2=80=9CSP always requires MFA=E2=80=9D section,= above.
The REFEDS Multifactor Authentication Profile references ITU-T X.1254 as= it references four different factors for authentication in a well describe= d way. Other frameworks define 3 factors, which is more limiting for = implementors. These four areas are:
Please note that this reference is purely to the good definitions used b= y ITU-T X.1254 for authentication factors - there is no other relationship = between the MFA Profile and this, or any other, assurance framework at this= time.
REFEDS is developing a Profile to flag approaches that do not provide mu= ltifactor. The scope of this is still to be decided, but this FAQ wil= l be updated as appropriate.