Permissions in Temporary Security Credentials for Federated Users

Suppose that an IAM user named Issuer wants to grant read-only permissions to federated users for the AWS account's Amazon S3 buckets. The AWS account administrator (the admin) could scope the Amazon S3 permissions of Issuer with the following IAM user policy.

{
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "sts:GetFederationToken"]
    "Resource": "arn:aws:s3:::mybucket/federated-user/*"
  }]
}

When Issuer wants to delegate permissions to a federated user, Issuer can call GetFederationToken with the name of the federated user, the duration the token is valid, and a policy granting access to Amazon S3, minimally. Any temporary security credentials Issuer creates will enable a federated user to read from the Amazon S3 bucket as long as the temporary security credentials are valid.

Issuer can restrict the permissions he delegates. For example, if Issuer wants to restrict the permissions he delegates based on the name of the user, so that a user named Jill is able to read her own files but not the files of any other federated user, then Issuer could do this by passing in a policy when he calls GetFederationToken. The policy that Issuer passes in might look like the following example.

{
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::mybucket/federated-user/Jill/*"
  }]
}

In this way, Issuer can delegate an arbitrary number of permissions, leveraging the hierarchical structure of Amazon S3 object names.

Additionally, because AWS checks permissions at authorization time rather than when the temporary security credentials are created, permissions are impacted by the policies in effect when a request is made, regardless of the policies in effect when the temporary security credentials were created. So in this example, Issuer might create temporary security credentials with the following general wildcard permissions.

{
  "Statement": [{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }]
}

As a result, even though Issuer doesn't have these general permissions, Issuer can successfully call GetFederationToken and receive temporary security credentials with this policy. Jill will then have whatever permissions Issuer has when her temporary security credentials are authenticated by AWS, but no more. In this case, if Jill were to attempt to delete an Amazon S3 bucket, the request would fail because Issuer does not have permission to delete a bucket.

If after issuing the temporary security credentials to Jill, the AWS account owner wanted to revoke Jill's permissions, but no one else's, the account owner could use a deny policy like the one in the following example. To effect this policy, the AWS account owner would attach this policy to Issuer (the IAM user who created the temporary security credentials). For the purposes of this policy, it doesn't matter that IAM doesn't know who Jill is; the policy works because it denies the permission of Issuer to enable the Amazon S3 GetObject action for Jill.

{
  "Statement": [{
    "Effect": "Deny",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::mybucket/federated/Jill/*"
  }]
}