一些背景知识:
我的公司(作为SP)目前通过AD FS 2.0与我们的联盟合作伙伴(IdP' s)处理SSO。每个合作伙伴都设置为声明提供程序,并且会创建用于转换将发送到我们的Web应用程序的传入声明的规则。
在认证之后,包含声明的令牌被发布到我们的STS端点(例如https://sts.companyname.ca/adfs/ls),其中声明被转换并发送到我们的Web应用程序URL(例如https://companyname.ca/externalsignin.aspx)并由OWIN中间件处理在帐户查找/创建之前。
这一切都很完美。现在,我们的任务是将Azure AD SSO集成到混合中,以帮助简化入门过程。
我已经在Azure中创建新目录并在其中创建新应用程序。我已将该应用程序标记为多租户,并将回复网址设置为" https://sts.companyname.ca/adfs/ls"。在我们服务器上的AD FS 2.0客户端中,我创建了一个名为" AzureAD"并从Azure控制台上的应用程序的端点部分导入metadataurl。使用来自我们的租户的电子邮件测试登录工作完美。问题在于使用来自其他租户的组织电子邮件进行测试时,身份验证失败并显示错误的请求消息:
经过一些研究后,这似乎是由于登录表单是为login.microsoftonline.com/tenantid构建的,而login.microsoftonline.com/common应该用于多租户应用程序。所以我重新从https://login.microsoftonline.com/common/federationmetadata/2007-06/federationmetadata.xml导入了元数据并进行了更新。
现在,当我使用其他租户组织帐户登录时,我实际上可以看到同意请求,但在身份验证之后,sts.companyname.ca / adfs / ls的帖子失败,因为该标记是为" sts签名的。 windows.net/0000-000000-000000-0000"但AD FS中的声明提供程序由sts.windows.net/{tenantid}占位符标识。
我不知道如何使用带有模板化终点的单个Azure声明提供程序来完成此工作(我也只能添加1个azure声明提供程序,因为它们都使用相同的签名证书)。
非常感谢任何克服这一障碍的帮助。
答案 0 :(得分:2)
这不起作用,因为Azure AD如何使用ADFS中的约束发出令牌(相同的签名密钥但是不同的租户发行者)阻塞不匹配,该约束不允许具有相同签名密钥的多个声明提供者信任。
执行此操作的方法是以下之一
希望能回答你的问题。
由于 // Sam(@MrADFS)