.NET Core 6集成Azure AD SAML无法获取SAMLResponse问题

/Saml2/Acs端点返回303状态码是Sustainsys.Saml2库的默认正常行为：该内置端点完成SAML响应验签、身份声明提取、认证Cookie签发后，会自动执行303重定向到配置的登录后路径，不属于异常表现。
请求未被捕获、断点不触发、Postman调用抛NoSamlResponseFoundException可按以下顺序排查：

1. 检查中间件注册顺序 #

.NET Core 6中间件按注册顺序先后执行，顺序错误会导致Saml2端点拿不到请求：

• app.UseAuthentication() 必须放在app.UseAuthorization()、app.MapControllers()/app.MapDefaultControllerRoute()之前
• 全局过滤器、请求拦截中间件（比如防伪验证、请求大小限制、HTTPS重定向）不能拦截到/Saml2/Acs路径的POST请求
  正确中间件顺序参考：

var app = builder.Build();
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication(); // 位置不能错
app.UseAuthorization();
// 其他自定义中间件
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");
app.Run();

如果配置了全局表单大小限制，需要放开SAML请求的长度限制，避免大SAML报文被截断：

builder.Services.Configure<FormOptions>(opt =>
{
    opt.ValueLengthLimit = int.MaxValue;
    opt.KeyLengthLimit = int.MaxValue;
});

2. 验证请求是否真的到达本地应用 #

Sustainsys的Acs端点是内置中间件实现，不会走自定义Controller的Action，所以在自己写的Acs接口上打断点永远不会触发。可以先写一个临时测试接口验证请求链路：

// 临时测试接口，注册在所有中间件之后、路由映射之前
app.MapPost("/testacs", async (HttpContext ctx) =>
{
    // 开启表单读取缓冲，避免影响后续Saml2中间件读取
    ctx.Request.EnableBuffering();
    var hasSamlField = ctx.Request.Form.TryGetValue("SAMLResponse", out var samlResp);
    return Results.Ok(new 
    {
        RequestMethod = ctx.Request.Method,
        ContentType = ctx.Request.ContentType,
        HasSamlResponseField = hasSamlField,
        SamlRespLength = samlResp.FirstOrDefault()?.Length ?? 0
    });
});

将Azure AD应用注册里的Reply URL临时改成https://localhost:5002/testacs，走完一次完整登录流程：

• 如果接口返回HasSamlResponseField = false，说明请求在到达应用前就被篡改了，常见原因是浏览器插件拦截、本地反向代理/抓包工具改写了POST表单、IIS请求过滤规则拦截了表单字段
• 如果能拿到SAMLResponse字段，说明链路没问题，问题出在Saml2配置上

3. 修正现有SAML配置问题 #

当前贴的配置存在几个会导致响应解析失败的问题：

• 实体ID配置错误：SPOptions.EntityId必须和Azure AD应用注册里配置的「标识符（实体ID）」完全一致，新增IdP的EntityId也必须和Azure AD元数据里的实体ID完全匹配（格式为https://sts.windows.net/{你的Azure租户ID}/），不能用通配符*占位，否则SAML响应的受众校验不通过，库会直接丢弃响应
• 签名算法配置不匹配：Azure AD默认使用rsa-sha256作为SAML响应签名算法，强制设置MinIncomingSigningAlgorithm = "http://www.w3.org/2000/09/xmldsig#rsa-sha1"会导致签名校验不通过，库直接丢弃合法请求，建议删除该配置项，让库自动从元数据拉取匹配的算法
• 缺少默认返回路径配置：SPOptions未配置ReturnUrl时，Acs端点处理完请求后会303重定向到站点根路径，容易被误认为处理失败，可补充配置：

  options.SPOptions.ReturnUrl = new Uri("/home/index", UriKind.Relative);
  

• 元数据拉取验证：不要硬编码IdP的SSO地址、签名证书，确保填的MetadataLocation地址可在本地浏览器正常访问，库启动时能拉到完整的Azure AD联邦元数据。如果元数据拉取失败，库不会抛出显性异常，只会默默丢弃无法识别的SAML响应

4. Postman调试的正确方式 #

直接Postman调用Acs接口抛异常是因为请求格式不对：

• 必须使用POST方法，Content-Type为application/x-www-form-urlencoded
• 表单字段名严格为SAMLResponse（大小写敏感），值为Azure AD返回的未解码的base64编码SAML响应报文
• 不要把SAMLResponse放在JSON请求体、Query参数、Header里，否则库永远读不到

内置端点调试方法 #

要断点调试Saml2中间件的处理流程，不需要自己实现Acs接口，直接在配置里注册通知事件打端点即可：

options.Notifications.MessageReceived = (rawMessage) =>
{
    // 这里打端点，可以拿到原始请求里的SAML报文
};
options.Notifications.AcsCommandResultCreated = (authResult, samlResponse) =>
{
    // 这里打端点，可以拿到解析后的用户声明、认证结果
    var userClaims = samlResponse.GetClaims();
};

内容的提问来源于stack exchange，提问作者michal