If I understand your desired configuration correctly, AWS might have just released a feature enabling this scenario, see Variables in AWS Access Control Policies:
AWS Identity and Access Management (IAM) enables you to create policies that control access to AWS service APIs and resources. Today we’re extending the AWS access policy language to include support for variables. Policy variables make it easier to create and manage general policies that include individualized access control.
Here's the provided example policy for regular IAM users:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": ["s3:ListBucket"],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::myBucket"],
"Condition":{"StringLike":
{"s3:prefix":["home/${aws:username}/*"]}}
},
{
"Action":["s3:GetObject", "s3:PutObject", "s3:DeleteObject*"],
"Effect":"Allow",
"Resource": ["arn:aws:s3:::myBucket/home/${aws:username}",
"arn:aws:s3:::myBucket/home/${aws:username}/*"]
}
]
}
While the ${aws:username}
included in this example isn't available for federated users (or assumed roles), there is another variable ${aws:userid}
, which will be substituted with account:caller-specified-name
for the respective ${aws:principaltype}
FederatedUser
, - please refer to the table within Request Information That You Can Use for Policy Variables for details on how these variables are substituted depending on principal type.