中国区 IAM Identity Center 做 ABAC 实战：从身份属性到 PrincipalTag 的设计与取舍
内容提要
文章讨论企业从传统SAML联合登录迁移到AWS IAM Identity Center后，如何继续用身份属性实现ABAC。迁移后会话落在不可打标签的托管角色上，标签只能通过SAML claim带入会话。作者在中国区验证了配置流程，并指出一条claim只产生单值：一人一应用可用单值claim配合动态策略；一人多应用需为每个应用创建值为true的claim，且无法用一条通用动态策略覆盖，需改用角色ARN授权等替代方案。
延伸解读
迁移后标签来源的变化是设计起点
文章指出，从传统SAML联合登录迁移到IAM Identity Center后，会话落在不可打标签的AWSReservedSSO_*托管角色上，权限集标签也不会传播到会话。这意味着原先“角色自身标签变成principal tag”的路径失效，业务标签只能通过SAML claim带入会话。理解这一变化，才能判断是否需要继续使用ABAC，还是直接改用角色ARN授权。
单值claim与多flag claim的分界
一条SAML claim只产生一个值，即使配置多个组条件，最终也只取最后一个匹配值。因此，若一个用户只对应一个应用，可用单值claim（如app=app1）配合动态策略；若一人负责多个应用，则需为每个应用建一条值为true的独立claim（如app1=true、app2=true），策略侧改为逐key判断。两种配法的代价不同，需按用户身份复杂度选择。
动态匹配策略的能力边界
资源策略中“principal tag等于resource tag”的动态匹配写法很优雅，但文章明确其仅适用于“一人一值”场景。当用户同时对应多个应用时，会话标签是单值、Entra无法拼接多个组、IAM策略变量不能出现在condition的key上，这三层限制叠加导致没有一条通用动态策略能覆盖。此时需改用按角色ARN授权、保留带标签的per-app角色再切换，或CLI传session tag等替代方案。
中国区落地需注意的配置细节
文章在中国区验证了完整链路，强调SAML断言的Audience和ACS指向中国区sign-in端点，策略ARN使用aws-cn分区，但属性名前缀仍为https://aws.amazon.com/SAML/Attributes/AccessControl:，与分区无关。此外，SAML透传的属性无需在IDC的Attributes for access control页面重复映射同名key，否则IDC目录值可能覆盖SAML值。排错时可用SAML-tracer核对断言中的属性名和值。
Q&A
迁移到 IAM Identity Center 后，为什么原来基于角色标签的 ABAC 不能直接用了？
因为 IDC 登录后拿到的是 AWSReservedSSO_* 服务托管角色，AWS 不允许给这个角色打标签，权限集上的标签也不会传播到会话。传统方式中“角色自身标签变成会话的 aws:PrincipalTag”这个来源就断了，标签只能改由 SAML 断言带进会话。
在 IDC 里把业务标签放进会话有哪两种方式？分别有什么限制？
方式一是用 IDC 的 Attributes for access control 做属性映射，把身份源的标准属性（如 department）映射成会话标签，但 Value 只能从固定的标准属性列表里选，用不了自定义属性，且常需修改 Entra ID 用户对象。方式二是在 Entra 企业应用里定义 AccessControl:<key> 的 SAML claim，用组条件下发值，不依赖 SCIM 标准字段，灵活度最高。
一条 SAML claim 能同时带出多个应用的值吗？比如一个人负责 app1 和 app2。
不能。一条 claim 在 SAML 断言里只产生一个 AttributeValue，即使配置了多个组条件，Entra 也只会取最后一个匹配的值，不会把多个值拼接起来。要表达一个人同时负责多个应用，必须为每个应用单独建一条 claim，值写死为 true（如 AccessControl:app1=true、AccessControl:app2=true），这样用户命中几个组就拿到几个标签。
在中国区配置 SAML claim 做 ABAC 时，有哪些分区相关的注意事项？
机制与全球区一致，但端点要用中国区 sign-in 端点（*.signin.amazonaws.cn），策略 ARN 使用 aws-cn 分区。属性名前缀仍然是 https://aws.amazon.com/SAML/Attributes/AccessControl:，用的是 aws.amazon.com 而不是 amazonaws.cn，这是 SAML 属性的命名约定，与分区无关。
什么情况下“principal tag 等于 resource tag”的动态匹配策略在 IDC 下会失效？失效后有哪些替代方案？
当一个用户同时对应多个应用值（一人多应用）时会失效，因为会话标签是单值的装不下集合，Entra 无法把多个组拼成一个值，且 IAM 策略变量不能出现在 condition 的 key 上，写不出一条通用动态策略。替代方案有：按角色 ARN 授权（每个应用一个权限集，用 aws:PrincipalArn 匹配）；保留带标签的 per-app IAM 角色，IDC 只当登录入口再切进去（会话最长 1 小时）；CLI/SDK 场景用 assume-role --tags 当场传标签（控制台不支持）。
登录后标签没进会话，应该怎么排查？
用浏览器扩展 SAML-tracer 抓取原始 SAML 断言，找到提交给中国区 IDC 的 ACS 请求（URL 形如 https://cn-north-1.signin.amazonaws.cn/platform/saml/acs/XXXXX），在 AttributeStatement 里逐字符核对属性名是否为 https://aws.amazon.com/SAML/Attributes/AccessControl:app，以及 AttributeValue 是否期望的值。属性没出现多半是组条件没命中或用户不是直接成员；key 或 namespace 有出入则 IDC 不会透传。断言核对无误后，再到 CloudTrail 的 AssumeRoleWithSAML 事件确认 principalTags。
从传统 SAML 迁移到 IDC 后，做 ABAC 应该怎么选型？
按条件从上往下判断：如果策略可以直接写死角色，就用 aws:PrincipalArn 匹配权限集角色 ARN，最简单；如果需要标签且业务值能放进受支持的标准属性、也能改 Entra ID 用户属性，就用方式一属性映射；如果字段受限或改不动 Entra ID，且一个用户只对应一个值，就用方式二加单值 claim（app=app1），一条动态策略可通吃所有资源；如果一个用户同时对应多个值，就用方式二加多个 flag claim（app1=true、app2=true），但需按 key 逐条判断，没有通用动态策略。
