Azure B2C自定义策略对接SAML2身份提供者时无法在AuthNRequest中发送ProviderName属性
我之前也遇到过一模一样的问题——在SAML技术配置里设置了ProviderName的InputClaim,但B2C就是不会把它放到发送给IDP的AuthnRequest里。这是因为Azure B2C的SAML技术配置默认不会将普通的InputClaims直接注入到SAML请求XML中,尤其是ProviderName这个声明本身是B2C内部用于标识身份提供者的,不会自动转发给外部IDP。
下面是几个经过验证的解决办法,你可以根据IDP的需求选择:
1. 使用额外请求参数传递(最简单的方式)
如果你的IDP接受通过HTTP POST参数接收这个值,直接在技术配置的Metadata里添加AdditionalRequestParameters即可:
<Metadata> <!-- 保留你现有的其他Metadata项 --> <Item Key="AdditionalRequestParameters">ProviderName=someImportantValue</Item> </Metadata>
这样B2C会在发送SAML AuthnRequest的POST请求里,额外带上这个参数,IDP可以从请求参数中读取它。
2. 在SAML AuthnRequest的Extensions节点中添加自定义属性
如果IDP要求必须在SAML XML的<samlp:Extensions>里包含这个属性,需要通过声明转换来实现:
步骤1:定义自定义声明
在你的策略文件的<ClaimsSchema>部分添加:
<ClaimType Id="CustomSamlExtension"> <DisplayName>Custom SAML Extension</DisplayName> <DataType>string</DataType> </ClaimType>
步骤2:创建声明转换生成扩展内容
在<ClaimsTransformations>部分添加:
<ClaimsTransformation Id="GenerateProviderNameExtension" TransformationMethod="GenerateStringClaim"> <InputParameters> <InputParameter Id="value" Value="<custom:ProviderName xmlns:custom='urn:your:custom:namespace'>someImportantValue</custom:ProviderName>" /> </InputParameters> <OutputClaims> <OutputClaim ClaimTypeReferenceId="CustomSamlExtension" /> </OutputClaims> </ClaimsTransformation>
这里的xmlns:custom可以替换成你IDP要求的命名空间。
步骤3:在技术配置中应用转换并关联扩展
修改你的SAML技术配置文件,添加InputClaimsTransformations和指定扩展声明:
<TechnicalProfile Id="CustomIDP"> <!-- 保留现有配置 --> <InputClaimsTransformations> <InputClaimsTransformation ReferenceId="GenerateProviderNameExtension" /> </InputClaimsTransformations> <Metadata> <!-- 保留现有Metadata项 --> <Item Key="SamlRequestExtensionsClaimType">CustomSamlExtension</Item> </Metadata> </TechnicalProfile>
这样B2C会把生成的扩展内容插入到AuthnRequest的<samlp:Extensions>节点里,IDP就能读取到了。
3. 确认声明定义的正确性
最后,确保你的策略里已经正确定义了ProviderName声明(虽然这不是问题的核心,但缺失的话会导致B2C忽略该InputClaim):
<ClaimType Id="ProviderName"> <DisplayName>Provider Name</DisplayName> <DataType>string</DataType> </ClaimType>
需要注意的是:SAML 2.0的AuthnRequest本身并不设计用来传递用户属性,这些属性通常是IDP在返回的断言中携带的。所以如果你的IDP要求在AuthnRequest里接收这个值,优先用方案1的额外参数方式,这是最符合B2C设计逻辑的。
内容的提问来源于stack exchange,提问作者Diego

