P-initiated SAML resolves to Okta Dashboard instead of the relying party (AWS IAM Identity Center) — no SAMLResponse emitted; IdP-initiated works

Questions SAML
1

I’m federating Okta to AWS IAM Identity Center via SAML. IdP-initiated sign-in (clicking the app tile) works perfectly. SP-initiated sign-in (user starts at the AWS access portal; AWS sends an AuthnRequest to Okta) authenticates the user but then drops them on the Okta end-user dashboard — and no SAMLResponse is ever sent back to AWS’s ACS URL, so the user never reaches AWS.

Environment

  • Okta Integrator Free Plan, OIE
  • App: AWS IAM Identity Center, added fresh from the OIN catalog (I deleted and rebuilt the app from scratch to rule out config drift)
  • SP: AWS IAM Identity Center (external IdP mode)

What the System Log shows on an SP-initiated attempt (single sign-in, in order):

  1. policy.evaluate_sign_on — target AWS IAM Identity Center — outcome CHALLENGE — requestUri /idp/idx/identify → correct: the AuthnRequest for the AWS app arrives and challenges for login
  2. user authenticates successfully (password + Okta Verify MFA, all SUCCESS)
  3. policy.evaluate_sign_on — target Okta Dashboard — outcome ALLOW — requestUri /oauth2/v1/authorize
  4. user.authentication.sso — target Okta Dashboard — outcome SUCCESS — requestUri /oauth2/v1/token

So the flow begins as a SAML request for the AWS app (step 1) but resolves into an OIDC SSO to the Okta Dashboard (steps 3–4). No user.authentication.sso event with the AWS app as target is ever generated on SP-initiated.

SAML-tracer confirms the same: on SP-initiated, the SAMLRequest reaches Okta but no SAMLResponse is POSTed back to …``signin.aws.amazon.com/platform/saml/acs/…. On IdP-initiated, a valid SAMLResponse is produced with correct Destination (ACS), Audience (Issuer), and Subject NameID (emailAddress format, matching the SCIM-provisioned user).

Already ruled out (config):

  • Fresh app from catalog (not an upgraded/edited instance)
  • Clean two-way metadata exchange; ACS + Issuer URLs verified against AWS’s SP metadata
  • NameID format = EmailAddress; value matches the SCIM-provisioned user exactly
  • Default Relay State is empty
  • Signing certificate confirmed current on the AWS side
  • No denial/failure event in the System Log for the attempt — auth succeeds, it just routes to the dashboard

Question: What causes an SP-initiated AuthnRequest that correctly evaluates sign-on policy against the AWS app (step 1) to then resolve to a Dashboard OIDC SSO (steps 3–4) instead of emitting a SAMLResponse to the SP? Is there an org-level session policy, app-visibility, or routing setting that governs which app a post-authentication flow lands on? Anything that would make Okta “forget” the original SP context across the login step?

Happy to share the trimmed System Log CSV and a decoded SAMLRequest.