Why can't I access my s3 private objects using AWS Amplify storage.get with Admin access and proper policy set. Getting 403 error

Question

so the default "I looked all over...etc", but no luck.

My problem is I can't seem to download or access my s3 objects through my client. I can't access it as the user who uploaded the object nor as a test user who has access to the group with a policy specifically set to access that bucket. Uploading it is fine.

I tried downloading the file in the console and that works fine, but I get a 403 error when trying the url. I know they say that the URL request needs to be pre-signed but according to Amplify documentation, it should already be pre-signed. I don't know if it matters or not but I created the s3 bucket manually but grant access through the Amplify config.

My use case: I have a user authenticate with AWS Cognito, which allows them to upload a file to an s3 bucket. I then want to allow that user and users assigned to an AdminPortalUserAccess group to be able to access the objects. The goal is for our employees to review the files a user uploads and provide notes/feedback on the report back to the user through an interface.

Here is my set up and use:

Amplify Configuration:

Amplify.configure({
  Auth: {
    identityPoolId: 'us-east-2:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
    region: 'us-east-2',
    userPoolId: 'us-east-2_xxxxxxxxx',
    userPoolWebClientId: 'xxxxxxxxxxxxxxxxxxxxxxxxxxx'
  },
  Storage: {
    AWSS3: {
      bucket: 's3-user-documents-uploads-dev',
      region: 'us-east-2',
      identityPoolId: 'us-east-2:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
    }
  }
});

Here is my AdminPortalUserAccess group policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::s3-credit-report-uploads-dev"
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "VisualEditor2",
      "Effect": "Allow",
      "Action": "s3:*Object",
      "Resource": "arn:aws:s3:::s3-user-documents-uploads-dev/*"
    }
  ]
}

Client side:

  async getSummaryPdf(report: any) {
    // const user = await Auth.currentCredentials(); // <-- just to confirm I am logged in
    // console.log('user: ', user); // <-- just to confirm I am logged in
    
    const data = await Storage.get(report.reportId, {
      level: 'private',
      identityId: report.reportUserId
    })
    console.log('data: ', data); // <-- never reaches here
    return data;
  }

If I change Storage.get to a then/catch, I can see what the pre-signed URL is and my public access key looks correct and is the one assigned to the identityId I use to put and get (attempt to) on the s3 bucket.

https://s3-user-documents-uploads-dev.s3.us-east-2.amazonaws.com/private/8ef10ec4-efd2-47c3-bed9-f6c878c8ce29/910c335a-46a6-42d1-b4f3-67507cd11322?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=[CREDENTIALS-REMOVED]us-east-2%2Fs3%2Faws4_request&X-Amz-Date=20200620T204746Z&X-Amz-Expires=900&X-Amz-Security-Token=[TOKEN-REMOVED]X-Amz-Signature=[REMOVED]X-Amz-SignedHeaders=host&x-amz-user-agent=[REMOVED]

What am I missing?

EDIT So I was able to figure out the root cause although I don't think this will solve the problem. When I call Storage.put it is creating a new identity in my federated identity pool and using these as credentials. One that is unauthenticated and does not have the proper role assigned to access the bucket. I found this by calling currentUserCredentials(), which returned a completely different identity ID. Now the question is, why is Amplify not using the identity ID associated with my login which links the user pool to the identity ID????

Answer 1

So after looking at the docs and several github bug reports, I determined that the config was incorrect in my .amplify folder. I recreated the storage through the amplify cli and deployed the resource and it worked. So nothing appears wrong with my approach above other than my .amplify files must have been altered when we migrated the repo earlier this week.