Cognito NameID Persistent转Unspecified：SAML身份源策略错误解决方案咨询

方案1：通过Pre Token Generation Lambda触发器修改SAML响应 #

利用Cognito的Pre Token Generation Lambda触发器，在SAML断言生成前直接修改NameID的格式：

• 创建Lambda函数，拦截Cognito准备发送的SAML响应内容，将其中的urn:oasis:names:tc:SAML:2.0:nameid-format:persistent格式标识替换为urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified。
• 将该Lambda函数配置为目标用户池的Pre Token Generation触发器，确保修改逻辑在断言生成前执行。

示例Node.js代码片段：

exports.handler = async (event) => {
  if (event.request.samlResponse) {
    let samlContent = decodeURIComponent(event.request.samlResponse);
    // 替换NameID格式字段
    samlContent = samlContent.replace(
      /urn:oasis:names:tc:SAML:2.0:nameid-format:persistent/g,
      'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'
    );
    event.request.samlResponse = encodeURIComponent(samlContent);
  }
  return event;
};

方案2：调整Cognito身份提供商的SAML属性映射 #

若外部IDP支持接收非Persistent格式的NameID，可在Cognito身份提供商配置中做如下调整：

• 将用户池的标准属性（如email或username）映射为SAML断言的NameID字段；
• 在SAML断言配置中显式指定NameID格式为Unspecified，需确保该配置与外部IDP的要求匹配。

方案3：部署中间代理修改SAML流量 #

在Cognito与外部IDP之间部署反向代理（如Nginx、自定义Node.js服务），拦截并修改SAML请求/响应：

• 当Cognito向IDP发送SAML请求时，代理修改请求中的NameIDPolicy节点，指定格式为Unspecified；
• 若IDP返回的响应格式仍不符合要求，代理同步修改响应中的NameID格式标识。

注意：此方案需额外承担代理的运维与安全保障成本。

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