Support assume-role profile chains backed by named SSO sessions

[tisonkun]

Summary

DefaultCredentialProvider cannot resolve a standard shared AWS configuration where the selected profile assumes a role through source_profile and the source profile obtains credentials from a named IAM Identity Center (sso_session) session.

This is one credential graph rather than two independent fallback providers: the SSO credentials must first be loaded for the source profile, then used to sign an STS AssumeRole request for the selected profile.

Reproduction

The following example is entirely synthetic:

[profile operator]
role_arn = arn:aws:iam::111122223333:role/Operator
source_profile = sso-source
role_session_name = local-operator
region = us-west-2

[profile sso-source]
sso_session = example-session
sso_account_id = 111122223333
sso_role_name = ExampleAccess

[sso-session example-session]
sso_start_url = https://example.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

Select operator through AWS_PROFILE or DefaultCredentialProvider::builder().with_profile("operator") after logging in with the AWS CLI.

Current behavior

• ProfileCredentialProvider only returns static aws_access_key_id / aws_secret_access_key values. It does not interpret role_arn, source_profile, or execute STS AssumeRole.
• SSOCredentialProvider requires the legacy inline sso_start_url and sso_region fields. The sso_session key is declared but unused, and token cache lookup always hashes the start URL.
• Since the provider chain treats Profile and SSO as independent fallback slots, the selected operator profile cannot combine the SSO source credentials with the target role.

The result is no usable credential even when the AWS CLI can resolve the same profile and has a valid cached SSO login.

Expected behavior

Resolve the shared-profile credential graph in AWS order:

1. Follow source_profile references until reaching a supported base credential provider.
2. For a named SSO base profile, resolve sso_region and sso_start_url from [sso-session NAME], and use the session name for the AWS CLI token cache key.
3. Exchange the cached SSO token for source-role credentials.
4. Call STS AssumeRole sequentially for each role in the chain.
5. Detect missing profiles, cycles, and invalid combinations such as both source_profile and credential_source.

Legacy inline SSO configuration should remain compatible. Automated SSO token refresh can be scoped separately, but the intended behavior should be explicit because named SSO sessions support refresh while legacy SSO configuration does not.

AWS sources

• AWS SDKs and Tools: Assume role credential provider documents role_arn, source_profile, and sequential role-chain resolution.
• AWS SDKs and Tools: Assuming a role with AWS credentials states that SDKs automatically make the corresponding STS AssumeRole call and that source_profile supports role chaining.
• AWS CLI: Configuring IAM Identity Center authentication documents the recommended sso_session layout, requires sso_region and sso_start_url in the [sso-session] section, and states that the cached token filename is based on the session name.
• The AWS SDK for Rust models this as a flattened base-provider plus role chain in profile/credentials/repr.rs, with synthetic table-driven coverage in assume-role-tests.json. These are useful behavioral references without requiring an AWS SDK dependency.

Implementation constraint

DefaultCredentialProvider currently lives in aws-core, while the concrete SigV4 request signer lives in aws-v4, which already depends on aws-core. Performing STS AssumeRole from the profile provider therefore needs an intentional ownership boundary to avoid a circular dependency or duplicated signing implementation.

Tests should use synthetic profiles, temporary config/cache directories, and mock HTTP responses only; they must not depend on or expose a developer's local ~/.aws configuration.