Assumed Role Cannot Assume Another Role - amazon-web-services

Question

I'm bumping into a role chaining issue when utilizing AWS EKS and I'm not able to identify where the chaining is incorrect.
Role A in account 1 will be assuming role B in account 2.
Role A is an arn:aws:sts::{ACCOUNT-ID-1}:assumed-role/{ROLE-NAME}/{SESSION-NAME}
Role B is a standard: arn:aws:iam::{ACCOUNT-ID-2}:role/{ROLE-NAME}
Role A is an assumed-role because on deployments into EKS, the role is assumed.
The Policy for role A is
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": "sts:*",
"Resource": "*"
}
]
}
The Trust Policy for B is
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "{ORD}"
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:sts::{ACCOUNT-ID-1}:assumed-role/{ROLE-NAME}/{SESSION-NAME}"
]
}
}
}
]
}
*The aws:PrincipalOrgID match up correctly on validation
The role assumption is conducted in SpringBoot
#Bean
public WebIdentityTokenCredentialsProvider getCredProvider() {
return WebIdentityTokenCredentialsProvider.builder().roleSessionName("SESSION-NAME").build();
}
public AWSCredentialsProvider assumeRole() {
AWSCredentialsProvider credentials = getCredProvider();
AWSSecurityTokenService sts = AWSSecurityTokenServiceClientBuilder.standard()
.withRegion("us-west-1")
.withCredentials(credentials)
.build();
return new STSAssumeRoleSessionCredentialsProvider.Builder("arn:aws:iam::{ACCOUNT-ID-2}:role/{ROLE-NAME}", "role-b-session")
.withStsClient(sts)
.build();
}
This role assumption fails as:
com.amazonaws.services.securitytoken.model.AWSSecurityTokenServiceException:
User: arn:aws:sts::{ACCOUNT-ID-1}:assumed-role/{ROLE-NAME}/{SESSION-NAME}
is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::{ACCOUNT-ID-2}:role/{ROLE-NAME}
(Service: AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied;
I am not sure why the above would return an AccessDenied based on the configured trust and permission policies as well as the Java code.