Date: Fri, 29 Mar 2024 07:22:50 +0000 (UTC) Message-ID: <1034584113.7615.1711696970202@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7614_935214421.1711696970202" ------=_Part_7614_935214421.1711696970202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
While signaling is out of scope for this work group, an understa= nding of how signaling occurs when the SAML protocol used by InCommon can h= elp understanding of how an MFA profile will be used. For each of the follo= wing use cases, we describe how they would be (or would not be) addressed i= n the Multi-Context Broker (MCB) Model for the behavior of an = IdP when multiple authentication methods are available.
The MCB Model assumes that each user is certified for specific authentic= ation contexts, and each authentication context has an associated authentic= ation method. Those certifications are stored in the IAM. This mechanism ca= n be used to require, for example, that certain users must use MFA. M= ore complex risk assessment strategies, however, would require custom code,= although that code could, in many cases, be implemented as a "scripted att= ribute," so that the IdP can use continue to use the same mechanism. (Out of scope for the MFA Interoperability Profile.)
This is a direct application of our MFA profile. The SP requests the MFA= profile as an authentication context, and the IdP invokes whatever specifi= c authentication method it has associated with that profile. The SP is sign= aled in the response as to whether the request was successful. = ; (In scope for the MFA Interoperability Profile.)
Assuming this use case is needed when the SP does not request an authent= ication context, then the MCB Model allows for the specification of a defau= lt context to be used for that SP. If the intent is to override an SP's req= uest, then custom code would be required. It may also requiring viola= ting the specification of the SP's requested context, so is not recommended= . (Out of scope for the MFA Interoperability Profile.)
From the IdP's point of view, this is the same as SP initial request above=
. The SP requested the MFA profile at the time it is needed, essentially cr=
eating another session with the IdP, and the IdP responds accordingly.