Granted populate does not populate profile region

[BryanTurns]

The organization I work for has just started using granted. We have our accounts on a separate region from where our sso is. As a result when we run assume we run into errors because the profile takes on the sso-region. Would it be possible to add a flag to allow for setting the profile regions to a value or maybe even get that information from AWS itself? I would be willing to work on this as well.

[cunymatthieu]

I ran into this too and put together a working implementation. Proposing the approach here in case it's useful.

Proposal: a --default-region flag

Add an optional --default-region flag to both sso generate and sso populate that writes an explicit region key on every generated profile, independent of the SSO region:

granted sso populate --sso-region us-east-1 --default-region eu-west-1 https://example.awsapps.com/start

[profile AccountName/RoleName]
region                 = eu-west-1   # ← default API region
granted_sso_region     = us-east-1   # ← unchanged: SSO/IdC region
granted_sso_account_id = 123456789012
granted_sso_role_name  = RoleName
granted_sso_start_url  = https://example.awsapps.com/start
credential_process     = granted credential-process --profile AccountName/RoleName

• Also settable as a persistent default in ~/.granted/config under [SSO.<name>] → DefaultRegion.
• Accepts region shorthands (ew1 → eu-west-1), consistent with assume --region.
• Backwards compatible: unset → no region key written, identical to today's output (ini:"region,omitempty").

Why this matters

Generated profiles today only carry granted_sso_region (the IAM Identity Center region), never the region key the AWS SDK/CLI uses for API calls. Orgs whose SSO lives in one region but whose workloads run in another (e.g. SSO in us-east-1, infra in eu-west-1) currently have to edit ~/.aws/config by hand after every populate (which then overwrites it), export AWS_REGION globally, or maintain a Profile Registry just to inject one key.

How it works

It reuses the existing, but currently unset, Region field of awsconfigfile.SSOProfile, so the change is small:

1. Add DefaultRegion to the [SSO] config struct.
2. Add the flag to both commands; resolve flag→config, then expand shorthands via cfaws.ExpandRegion.
3. Thread it into SSOProfile.Region in GetProfiles.

On the consumption side, assume already picks it up for free: profile.Region() returns the region key as its first fallback before granted_sso_region, and ParseGrantedSSOProfile never overwrites it.

Limitation: applies the same region to all profiles in a run — per-account regions stay the job of a Profile Registry.

I have this implemented and tested locally and would be happy to open a PR if there's interest.