Developer SSO sessions carry no team tag, so DenyXTeam blocks all access to their own team's resources (javabin secret list/set fails) #144

I got to the point where the backend is deployed and I need to set 4 secrets.

I logged in with aws sso - and tried secret list

From claude:

javabin secret list (javabin-cli #6) fails for every secret of a team's own app:

User: arn:aws:sts::553637109631:assumed-role/AWSReservedSSO_javabin-team-cupcake_86d8ba0713e502cf/chris.searle@java.no
is not authorized to perform: ssm:GetParameter on resource:
arn:aws:ssm:eu-central-1:553637109631:parameter/javabin/apps/cupcake/cupcake-backend/sp_user
with an explicit deny in an identity-based policy: arn:aws:iam::553637109631:policy/javabin-developer-boundary

The parameter was created by the platform and is tagged team=cupcake. The user is only in team cupcake (registry/teams/cupcake.yaml), and the session is the per-team permission set javabin-team-cupcake.

Cause (from reading the code): the only boundary statement that matches is DenyXTeam (terraform/platform/iam/boundary.tf:125): aws:ResourceTag/team must equal ${aws:PrincipalTag/team}. PrincipalTag/team comes from the Identity Center ABAC mapping ${path:enterprise.team} (terraform/org/identity-center.tf:25), but nothing sets the team enterprise attribute on Identity Center users. team_provisioner creates the per-team permission set and group but never writes the attribute, and the Google Workspace SAML app doesn't appear to map it either. So developer sessions carry no team tag, and every team-scoped resource is denied.

To confirm: check principalTags on the user's latest AssumeRoleWithSAML event in CloudTrail.

Impact:

• No team can set its resources.secrets, so feat(org): let developers set their own team's app secrets #139 / javabin secret set can't work for anyone.
• DenyXLogs blocks developers from reading their own /ecs//* logs.
• Every other PrincipalTag/team rule in the boundary and the developer permission set is affected the same way.

Possible fixes:

1. Have team_provisioner set the Identity Center user attribute (enterprise.team, or a custom attribute mapped in ABAC) from registry membership. A user in several teams needs a rule for which team wins; per-team sessions are one answer.
2. For per-team permission sets (javabin-team-), the team is already known from the permission set itself. A per-team boundary, or an inline policy that hardcodes the team instead of ${aws:PrincipalTag/team}, would not need ABAC at all.
3. Short term: document that an admin must set app secrets until this is fixed.

Workaround in use: an admin sets the values with aws ssm put-parameter --overwrite.