需要提升的服务提供者

Question

我们的身份被存储在一个单独的IdP中(在本例中是Azure)，并且应用程序充当服务提供者。MFA是根据某些规则(基于geoIP等)触发的。我们现在将添加一个新的应用程序，其中包含敏感数据，并希望它触发MFA。

服务提供者请求提升的机制是什么？

例如，是否有一个属性应该通过OIDC/SAML传递以指示它是否为MFAed？是否有服务提供者请求提升以使IdP知道触发它的协议？它是否被IAM产品广泛实施，特别是在Azure广告中？

Answer 1

该机制依赖于协议，但在实践中，协议级的MFA并不是标准化的。例如，在SAML中，您可以使用身份验证上下文：

如果依赖方依赖于认证机构对另一实体的认证，则依赖方可能需要认证本身之外的信息，以使其能够将认证置于风险管理上下文中。这方面的资料可包括：

• 初始用户识别机制(例如，面对面、在线、共享秘密)。
• 最大限度地减少凭据危害的机制(例如，证书更新频率、客户端密钥生成)。
• 用于存储和保护凭据的机制(例如智能卡、密码规则)。
• 身份验证机制或方法(例如，密码、基于证书的SSL)

如果不使用MFA，依赖方可以要求身份提供者在对用户进行身份验证时使用MFA，依赖方可以拒绝SAML断言，从而拒绝访问。听起来不错，不是吗？这是理论。实际上，这在协议级别上不起作用，因为定义特定身份验证上下文的行为不是可以普遍指定的。

SAML作为协议允许扩展，因此任何一方都可以发布自己的身份验证上下文。只要参与联邦的社会保障方案和国内流离失所者能够理解这一背景，这一切都是可行的。不太普遍，但这是个解决办法。在一个通过Shibboleth的SAML很普遍的高等教育社区中，他们为MFA定义了一个配置文件以及相关的身份验证上下文，并将其放入实现中。

OIDC还具有身份验证上下文，它们遇到的问题与上面描述的相同。由于OIDC是建立在oAuth之上的，它也有作用域作为另一个控制杠杆来请求所需的访问。如果有一个标准的“mfa”范围，那么客户端可以从授权服务中请求它。唉，只有少数几个范围是标准化的。

当您与大型商业身份提供者(如Azure AD )打交道时，您实现需求的能力取决于

1. 他们所支持的规格
2. 他们对这些规格的解释
3. 您可以自定义它们的行为，并且仍然保留在规范中。

虽然AAD支持SAML和OIDC，但它的功能范围很窄，您可以定制的很少。具体来说，您不能要求AAD解释您自己的作用域或身份验证上下文。

由于您预先知道这个特定的应用程序将需要MFA，所以您在AAD中的最佳实现选项是一个条件接收策略。