1

我试图想出一个相当不寻常的场景的身份验证方案。多对多身份验证模式

我已经有多个Azure的活动目录(可能是数十个),以及多个Web API服务。 客户可以注册/登录到任一AD,然后能够使用任一服务验证请求。

直截了当的解决方案将需要我与所有的广告信息来配置我的所有服务。 这种多对多的关系就是我想要避免的。

我想过建设一个会发出一个标准化的令牌集中令牌交换服务器的解决方案,但我不知道这种方法的安全程度,我宁愿使用“开箱即用”的解决方案,而不是实施我自己的。

你将如何去解决这个问题?

+0

这听起来像一个多租户应用程序?您是否看过使用Azure AD构建多租户应用程序? – Thomas

+0

我看着它。问题是用户不能选择登录哪个AD。它应该由重定向用户登录的服务决定。 –

+0

用户不会选择。您输入您的电子邮件并根据您的电子邮件将其重定向到您组织的登录页面。 – Thomas

回答

0

multi-tenancy support of Azure AD旨在解决您的方案。

首先您将服务作为Azure AD中的多租户应用程序发布。然后,租户目录管理员通过通过同意流程来订阅该应用程序。

您的服务需要将TokenValidationParametersValidateIssuer属性设置为false以禁用检查令牌的颁发者。

现在,用户可以使用登录任何目录,前提是他们同意该应用程序。要将此限制为仅需要的目录,您可以将IssuerValidator代理添加到TokenValidationParameters

IssuerValidator = (issuer, token, params) => 
{ 
    if (_db.FindIssuer(issuer) != null) 
     return issuer; 
    else 
     throw new SecurityTokenInvalidIssuerException("Not a valid issuer"); 
}, 
+0

原则上,您是对的,但这不完全是我的场景。 有一些额外的要求,可能会相互碰撞。 1.我希望用户能够在多个承租人中使用同一个电子邮件地址(可能不是问题,但是 - ) 2.我不希望他们能够选择使用哪个AD登录,我想将它们重定向到我为他们选择的那个。 3.我不想在注册时显示同意页面。我想创造用户直接与提供商签约的感觉。 –

+0

不确定你为什么在意用户登录的目录。除了'tenantid'声明外,发布的令牌将是相同的。用户不会选择他们登录的目录,只需输入他们的凭据,Azure AD将根据他们的域选择正确的目录。如果租户管理员已获得全球同意,则不会为每个用户显示同意页面。 – MvdD

+0

因此,您希望创建自定义登录页面,然后调用Azure AD Graph API来获取身份验证令牌?可能是你应该编辑你的问题来解释一些关于你的需求和为什么默认多租户不符合你的要求。但是您所描述的是多租户应用程序 – Thomas