[BUG] SSO Application ARN Hardcodes Data-Platform Account ID

[marcinc]

Summary

CreateLakeFormationIdentityCenterConfiguration fails with AccessDeniedException when the AWS IAM Identity Center (IdC) instance lives in a different AWS account than the data platform (typical in Control Tower / AWS Organizations deployments).

Affected Component

packages/constructs/L3/governance/lakeformation-settings-l3-construct/lib/lakeformation-settings-l3-construct.ts

Error

AccessDeniedException: User: arn:aws:sts::<account>:assumed-role/<lambda-role>/<lambda-role> is not authorized to perform: sso:PutApplicationAssignmentConfiguration on resource: arn:aws:sso::*:application/<sso-instance-id>/* because no identity-based policy allows the sso:PutApplicationAssignmentConfiguration action (Service: SsoAdmin, Status Code: 400)

The error is surfaced as a CloudFormation custom resource failure, causing the lakeformation-settings stack to roll back with ROLLBACK_COMPLETE.

Root Cause

The Lambda execution role's IAM policy scopes sso:PutApplicationAssignmentConfiguration to the SSO application ARN using the CDK this.account token:

// BEFORE (broken)
arn:${this.partition}:sso::${this.account}:application/${this.props.iamIdentityCenter.instanceId}/*

this.account resolves to the data platform account (the account where the CDK stack is deployed). However, AWS IAM Identity Center is an organisation-level service. When LakeFormation internally calls sso:PutApplicationAssignmentConfiguration during
CreateLakeFormationIdentityCenterConfiguration, the SSO application ARN carries the IdC management account (the AWS Control Tower management account or the delegated SSO admin account), not the data platform account.

IAM evaluates the policy against the actual resource ARN and denies the call because the account segments do not match.

Proposed Fix

Replace ${this.account} with * in the resource ARN:

// AFTER (fixed)
arn:${this.partition}:sso::*:application/${this.props.iamIdentityCenter.instanceId}/*

The wildcard covers both same-account and cross-account IdC deployments. The action scope is still constrained to the specific SSO instance ID, so the policy remains appropriately scoped.

File: packages/constructs/L3/governance/lakeformation-settings-l3-construct/lib/lakeformation-settings-l3-construct.ts
Line: resource ARN inside manageSsoAppPolicyStatement in createIdcConfig()

Impact

• Severity: Blocker — lakeformation-settings stack cannot be created in any Control Tower
  or AWS Organizations environment where the IdC instance lives outside the data platform account.
• Introduced: v1.5.0 (iamIdentityCenter feature)
• Scope: Any deployment with iamIdentityCenter configured in lakeformation-settings.yaml

Verification

After applying the fix, re-synthesize and redeploy the lakeformation-settings module.
The IAM policy on the Lambda execution role should show:

"Resource": [
  "arn:aws:sso:::instance/<sso-instance-id>",
  "arn:aws:sso::*:application/<sso-instance-id>/*",
  "arn:aws:sso::aws:applicationProvider/*"
]

CreateLakeFormationIdentityCenterConfiguration should succeed and the stack should reach CREATE_COMPLETE.

[marcinc]

I'm happy to open a PR (changes ready to go) if approved

[suddash24]

Hi @marcinc,

Thank you for the detailed report. We have confirmed this issue and your proposed patch is correct. IAM Identity Center applications are owned by the IdC instance's account, typically the Organization management account or the delegated SSO admin account, rather than the data platform account. As a result, scoping the resource ARN to ${this.account} causes IAM to deny the call whenever the IdC instance and data platform accounts differ.

We will apply the wildcard fix as proposed. The action set remains scoped to the specific instanceId, so the policy continues to be appropriately constrained, and the existing AwsSolutions-IAM5 suppression covers the rationale for the wildcarded account segment.

The fix will be in main shortly and included in the next release. We will share the release details on this issue once it is published, at which point a re-synthesis and redeployment of the lakeformation-settings module will resolve the failure.

We are also evaluating an optional iamIdentityCenter.instanceAccount property as a follow-up enhancement, which would allow the ARN account segment to be pinned explicitly when the IdC account is known. The wildcard remains the appropriate default.

Thank you again for the thorough analysis and for taking the time to file this with a clear reproduction and proposed remediation.