如何实现基于SAML认证的AWS STS临时凭证通用刷新机制？

针对你遇到的「无法让所有已登录用户自动刷新STS凭证」的问题，我分享几个经过验证的通用化方案，核心思路是利用SAML断言属性或IAM会话标签来动态匹配用户身份，而不是硬编码单个用户ARN：

方案1：基于SAML用户标识的条件匹配（推荐） #

这个方案利用sts:SourceIdentity条件键，结合SAML断言中传递的用户唯一身份标识（比如NameID）来实现权限控制，确保只有用户自己的临时身份能刷新凭证。

调整后的IAM信任策略 #

{
  "Version": "2012-10-17",
  "Statement": [
    // 保留原有的AssumeRoleWithSAML授权规则
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::xxxxxxxxxxxx:saml-provider/myidp.com"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    },
    // 新增通用的AssumeRole授权规则
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        // 匹配SAML断言中的用户唯一标识（NameID）
        "StringEquals": {
          "sts:SourceIdentity": "${saml:sub}"
        },
        // 限制只能是当前角色下的临时身份
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/testapp/*"
        }
      }
    }
  ]
}

原理说明 #

• 当用户通过AssumeRoleWithSAML获取临时凭证时，AWS会自动将sts:SourceIdentity设置为SAML断言中的NameID（对应${saml:sub}变量）。
• 后续调用AssumeRole刷新凭证时，会验证发起请求的临时身份的sts:SourceIdentity是否与角色信任策略中的${saml:sub}匹配，确保只有用户自己的身份能刷新。
• ArnEquals条件进一步限制了只能是testapp角色下的临时身份，避免其他角色的用户滥用权限。

方案2：基于IAM会话标签的身份匹配 #

如果你的SAML断言没有传递合适的唯一标识，也可以在首次获取凭证时手动添加会话标签，然后通过标签匹配来实现刷新控制。

步骤1：首次获取凭证时添加会话标签 #

调用AssumeRoleWithSAML时，通过--tags参数添加用户唯一标识（比如员工ID、邮箱）：

aws sts assume-role-with-saml \
  --role-arn arn:aws:iam::xxxxxxxxxxxx:role/testapp \
  --principal-arn arn:aws:iam::xxxxxxxxxxxx:saml-provider/myidp.com \
  --saml-assertion <你的SAML断言内容> \
  --tags Key=EmployeeID,Value=<用户唯一员工ID>

步骤2：调整IAM信任策略 #

{
  "Version": "2012-10-17",
  "Statement": [
    // 原有的AssumeRoleWithSAML规则
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::xxxxxxxxxxxx:saml-provider/myidp.com"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    },
    // 基于标签的AssumeRole授权
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        // 匹配临时身份的EmployeeID标签
        "StringEquals": {
          "aws:PrincipalTag/EmployeeID": "${aws:PrincipalTag/EmployeeID}"
        },
        // 限制角色范围
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/testapp/*"
        }
      }
    }
  ]
}

原理说明 #

• 首次获取的临时凭证会携带你指定的EmployeeID标签，后续调用AssumeRole时，AWS会验证请求者的标签是否与策略中的标签一致，确保只有用户自己的身份能刷新凭证。

关键注意事项 #

1. 权限最小化：不要直接给Principal: AWS: "*"无限制的AssumeRole权限，必须通过ArnEquals和用户身份条件键缩小范围，避免权限泄露。
2. 凭证刷新时机：建议在原凭证过期前30分钟左右调用AssumeRole刷新，这样用户完全无感知，同时避免过期后重新触发SAML登录。
3. SAML属性验证：确保你的企业IDP在SAML断言中传递了唯一的用户标识（比如NameID），并且IAM SAML提供商已正确配置这些属性的映射。

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