我正在与第三方集成,并且对于声明配置,他们建议我们为名称ID创建sAM-Account-Name,并在SAML响应中不断收到此错误:
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" />
</samlp:StatusCode>
</samlp:Status>
所以我假设我没有发送格式正确的NameID。在SP的元数据中,他们列出了这个:
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
</NameIDFormat>
正确,我认为我应该使用瞬态NameID格式。但是,这也不起作用,并且供应商坚称他们希望我们的SAML响应使用urn:oasis:names:tc:SAML:1.1:nameid-format:未指定为Name ID格式。据我所知,这是ADFS的默认值。
作为测试,我按照这里的步骤:https://blogs.msdn.microsoft.com/card/2010/02/17/name-identifiers-in-saml-assertions/并且能够将伪造的NameID(瞬态)传递到供应商的网站,然后在浏览器中显示用户名无效,所以至少我得到的东西让我相信我在正确的轨道上并且他们的身份验证服务器期望他们的应用程序不是短暂的。
我会尝试这里的步骤,但我不想影响我的整个声明提供者:https://social.technet.microsoft.com/wiki/contents/articles/4038.ad-fs-2-0-how-to-request-a-specific-name-id-format-from-a-claims-provider-cp-during-saml-2-0-single-sign-on-sso.aspx
我们为ADFS服务器运行Server 2012 R2。这不是我们配置的第一个中继方信任,我们的设置与我们的其他供应商合作良好。然而,我对管理ADFS相对较新,所以我可能错过了一些简单的东西。
任何想法或指导都将不胜感激。
答案 0 :(得分:1)
如果您的依赖方在ADFS中的声明映射包括Active Directory samAccountName到SAML NameID,则服务提供商的元数据指定的“urn:oasis:names:tc:SAML:2.0:nameid-format:transient”不会真的很有道理,因为这个价值不是短暂的。
根据SAML v2.0规范,SAML authn请求中的可选NameIDPolicy“指定用于表示所请求主题的名称标识符的约束”。
实际上,不包含NameIDPolicy更简单,因此默认为“urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified”或显式使用此值。
鉴于上述情况,可以安全地忽略服务提供者的元数据中的NameIDFormat,并且不包含在authn请求中的NameIDPolicy。
答案 1 :(得分:1)
SP可以根据其格式拒绝索赔,这最终是问题。那么解决方案是SP应该改变他们的要求,或者必须以所需的格式发送索赔。
在这种情况下,SP要求声明是暂时的,即使它们口头上要求未指定(默认)。在处理系统时,口头声明要求不计算在内!
要使用此SP配置ADFS,只需:
这将允许sAM-Account-Name以瞬态格式发送到SP,即使我们知道该属性是定义的,而不是瞬态的。
查看截图: