I know that there are couple of questions posted on this topic but I believe my situation is slightly different.
I have a team which is called team A that has AWS account A with federated user mapped to corporate AD. Another team I am supplying data to is team B with AWS account B and their user is also federated. Team B wants a file to be delivered to S3 bucket and they created an IAM role called B1.
Account A created role A1 and asked team B to permit role arn:aws:iam:A:role/A1 to assume B1. Team A developed AWS batch job to extract data from on-premise database. When container was called via job definition, arn:aws:iam:A:role/A1 was supplied via job role field. Batch job automatically assumed A1 role when it started. When it tried to assume arn:aws:iam:B:role/B1, it was declined because now role is arn:aws:sts::B:assumed-role/B1/ where is a session id I have no control over.
Error I get is: "User: arn:aws:sts::A:assumed-role/A1/b9d11e1a8a98446b927d0d9353b5f1a6 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::B:role/B1"
My implementation runtime is Node.js/Typescript (not that it matters). When I initiate an STS session with temp credentials of federated user, there is no random session id that is part of assumed role and file upload to S3 in B works. But I can not rely on it. Appreciate the suggestion.
